Se negli obiettivi delle due discipline si ha in certi casi una più o meno ampia sovrapposizione, la differenza tra accessibilità e usabilità diviene più chiara quando si guarda ai rispettivi metodi. L'appendice A delle WCAG 1.0, dedicata ai modi per verificare il raggiungimento dei requisiti di accessibilità richiesti dalle quattordici raccomandazioni, propone una serie di metodi che consistono principalmente nella validazione automatica del codice della pagina per mezzo di appositi software e nell'effettuazione di una serie di prove tecniche, che - disponendo delle opportune attrezzature - possono essere compiute dallo stesso sviluppatore. Solo ai punti 9 e 10 dell'appendice si fa un riferimento a possibili test con utenti umani, ma senza suggerire specificamente il ricorso ai metodi sviluppati in questo campo dall'usabilità.
L'accessibilità, così come è concepita dalle WCAG 1.0, rivolge le sue raccomandazioni allo sviluppatore (il "content developer"), tralasciando più o meno completamente di occuparsi del rapporto tra il prodotto "accessibile" e l'utente finale – anzi le varie categorie possibili di utenti finali – il che costituirebbe invece il centro dell'interesse dell'usabilità, se applicata agli obiettivi dell'accessibilità.
La soluzione decisa dagli estensori delle WCAG 1.0 ha un indubbio vantaggio economico dal punto di vista dei costi di sviluppo di un sito: quanto più la cura dell'accessibilità può focalizzarsi – grazie all'adozione dei suggerimenti tecnici acclusi alle linee guida - sul codice e sulla struttura della pagina, piuttosto che sui risultati dell'interazione tra la pagina e gli utenti finali, tanto più sarà semplice e veloce portare a termine il lavoro.
Una buona analisi delle ragioni per cui l'accessibilità si rivolge essenzialmente allo sviluppatore, ed ha per suo oggetto la pagina web piuttosto che l'interazione tra questa e l'utente, è contenuta in un lungo ed interessante articolo di Jim e Pat Byrne, intitolato "What is an accessible website?".
L'articolo analizza i numerosi problemi e le contraddizioni che sorgono quando si tenta di realizzare in concreto un'accessibilità veramente universale. Riportiamo di seguito, per brevità, solo la traduzione in italiano delle conclusioni a cui giunge l'articolo.
- «Cercare di rendere i nostri contenuti accessibili a tutti indistintamente è pressoché impossibile. L'accessibilità è un concetto relativo: dipende dal proprio pubblico di riferimento, dalla conoscenza che si ha dei suoi bisogni e dalle risorse che si hanno a disposizione».
- «Non è possibile controllare il modo in cui una pagina sarà presentata all'utente finale; la sola cosa su cui è possibile avere un controllo assoluto è il codice di marcatura usato nelle pagine (per es. l'HTML).».
- «Tutti i contenuti arrivano all'utente attraverso un qualche tipo di computer e di browser».
- «Il primo passo per creare siti accessibili è creare siti che siano accessibili alle macchine. La migliore chance per ottenere ciò è usare HTML standard».
- «Quando il contenuto può essere divorziato dalla presentazione, usando i fogli di stile, il medesimo contenuto può essere presentato in molti modi differenti. Non occorre pertanto preoccuparsi di creare molteplici versioni di una stessa pagina per venire incontro ai bisogni di un pubblico diversificato».
- «Le Linee Guida del W3C sull'accessibilità possono essere usate per rendere i vostri siti web, basati sugli standard, più flessibili e più capaci di soddisfare i diversi bisogni del vostro pubblico di riferimento».
Insomma, rendere una pagina web accessibile alle macchine (computer e browser) e flessibile nella struttura sono gli obiettivi principali a cui evidentemente puntano le raccomandazioni di accessibilità.
In ciò la differenza con l'usabilità è grande: quest'ultima infatti lavora essenzialmente sull'interazione tra la pagina e gli utenti, anzi le specifiche categorie di utenti considerate come pubblico di riferimento dei siti da testare.
Tuttavia una vera accessibilità, come si evince dalla ultime tre raccomandazioni delle WCAG 1.0, non è solo questione di codice standard e struttura di pagina flessibile. È anche una questione di comprensibilità dei testi, di chiarezza di esposizione, di facilità di navigazione. Questi obiettivi non solo sono comuni all'usabilità, ma richiederebbero anche i metodi dell'usabilità - sebbene questo le WCAG 1.0 non lo dicano - perché qualcuno possa affermare con un accettabile grado di sicurezza di averli raggiunti.
Non bastano infatti la buona volontà e lo scrupolo professionale dello sviluppatore per asserire con certezza di aver prodotto pagine web scritte in modo chiaro e comprensibile, o dotate di meccanismi di navigazione facili e intuitivi da utilizzare. Molto meglio sarebbe organizzare opportuni test di usabilità e lasciare che siano questi a dire l'ultima parola in proposito, magari proponendo correzioni e miglioramenti suggeriti dall'interazione con utenti reali, che allo sviluppatore non sarebbero mai venuti in mente.