Requisiti 15, 16, 17

Requisito 15

Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; ove ciò non sia possibile fornire una spiegazione testuale della funzionalità svolta e garantire una alternativa testuale equivalente, in modo analogo a quanto indicato nel requisito n. 3.

Riferimenti WCAG 1.0: 6.3

Riferimenti Section 508: 1194.22 (l), 1194.22 (m)

Motivazione

Gli sviluppatori devono creare contenuti per il web fruibili anche quando gli script, applet o altri oggetti di programmazione vengono disattivati o se il browser in uso non ne supporta l’esecuzione. Questo significa fornire la possibilità di accedere ai contenuti anche ad utenti che non posseggono un particolare plug-in, sistema operativo o la cui tecnologia assistiva non riesce ad interagire con la tecnologia utilizzata. Come vedremo dall’analisi del requisito, spesso gli sviluppatori utilizzano funzionalità esclusivamente usando i suddetti oggetti di programmazione, non fornendo alternative e quindi possibilità a talune categorie di utenti di fruire dei contenuti.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti a causa di oggetti di programmazione contenuti in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di oggetti di programmazione e, ove individuati, garantire un’alternativa equivalente.

Il requisito richiede inoltre, ove non sia possibile garantire l’utilizzo dei contenuti della pagina web senza l’uso degli oggetti di programmazione, di descrivere la funzionalità degli oggetti di programmazione oltre a fornire un’alternativa testuale equivalente.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 6.3 (Priorità 1). Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati. Se questo non è possibile, fornire informazione equivalente in una pagina accessibile alternativa

Gli sviluppatori devono creare contenuti per il Web fruibili anche quando gli script vengono disattivati o se il browser in uso non li supporta. Un’istruzione come la seguente, che consente di tornare alla pagina precedente, non potrà essere utilizzata dagli utenti che hanno disabilitato gli script o che utilizzano browser che non li supportano, come mostrato di seguito.

<a href="javascript:history.go(-1)">
Pagina Precedente
</a>

Per ottenere particolari risultati spesso si ricorre a DHTML (combinando JavaScript, CSS e HTML). Per esempio, immaginiamo un menu realizzato con JavaScript e CSS: come potrà essere fruito dagli utenti in caso di disabilitazione di script ed oggetti? Usando l’elemento <noscript> si potrà fornire una versione alternativa e il menu JavaScript verrà riprodotto anche in HTML.

<script type="text/javascript" src="menu.js"></script>
<noscript>
<ul>
<li><a href="pagina1.html">Menu 1</a></li>
<li><a href="pagina2.html">Menu 2</a></li>
<li><a href="pagina3.html">Menu 3</a></li>
</ul>
</noscript>

Per quanto riguarda gli oggetti di programmazione e le applet abbiamo già analizzato degli esempi per il requisito 3, a cui si riferisce anche il presente requisito ma va chiaramente ribadito che ogni caratteristica o funzionalità vitale dello script deve essere riproposta utilizzando del codice HTML.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare la presenza di script, applet e oggetti di programmazione;
  • verificare il funzionamento della pagina disabilitando l’uso di script, applet ed oggetti di programmazione;
  • verificare la presenza di contenuti alternativi per script, applet ed oggetti di programmazione.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Informazioni

Identifica Applet/Script. Apre una nuova finestra elencando le applet e gli script presenti all’interno della pagina (Punto di controllo 6.3).

Opzioni IE

Attiva/Disattiva Javascript. Attiva/Disattiva Javascript col comando di IE Strumenti>Opzioni Internet>Protezione>Livello personalizzato>Abilita/disabilita Esecuzione Script (Punto di controllo 6.3).

Attiva/Disattiva ActiveX. Attiva/Disattiva ActiveX col comando di IE Strumenti>Opzioni Internet>Protezione>Livello personalizzato>Abilita/disabilita Controlli e plug-in ActiveX (Punto di controllo 6.3).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 16

Enunciato: Garantire che i gestori di eventi che attivano script, applet o altri oggetti di programmazione o che possiedono una propria specifica interfaccia, siano indipendenti da uno specifico dispositivo di input.

Riferimenti WCAG 1.0: 6.4, 9.2, 9.3

Riferimenti Section 508: 1194.22 (l), 1194.22 (m)

Motivazione

L’errore più comune da parte degli sviluppatori è assegnare una determinata funzionalità ad un determinato evento dipendente da un determinato dispositivo di input. L’esempio più classico è l’uso di comandi legati al mouse (clic, doppio clic) che di fatto diventano ingestibili dagli utenti che non possono utilizzare il mouse, ad esempio, utenti non vedenti che navigano tramite lettori di schermo o utenti che utilizzano periferiche di navigazione sprovviste di mouse. Non tutti gli utenti navigano il Web tramite interfaccia grafica, utilizzando il mouse come periferica di input: molti utenti – anche a causa di disabilità – utilizzano la tastiera, tastiere alternative o comandi vocali per accedere a collegamenti ipertestuali, per accedere o inviare dati da un modulo, ecc. È quindi importante che qualsiasi elemento contenuto nella pagina sia interagibile tramite tastiera in modo che sia fruibile anche da sistemi assistivi di navigazione (oltre all’uso del mouse).

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti a causa di impostazioni legate a particolari dispositivi di input per oggetti di programmazione contenuti in una pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di oggetti di programmazione e, ove individuati, garantire l’accessibilità indipendentemente dal dispositivo di input utilizzato.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 6.4 (Priorità 2). Garantire che i gestori di eventi per gli script e le applet siano indipendenti dai dispositivi di input

Un gestore di eventi, o event handler, è un insieme di istruzioni che vengono richiamate quando un particolare evento viene soddisfatto (per esempio, il movimento del mouse, la pressione di un tasto, il caricamento della pagina, e così via). In HTML 4.01 e XHTML gli event handler associati agli elementi vengono gestiti dai seguenti attributi, ordinati per tipo di evento.

onload onunload
onclick ondblclick
onmousedown onmouseup onmouseover onmousemove onmouseout
onfocus onblur
onkeypress onkeydown onkeyup
onsubmit
onreset
onselect
onchange

Alcuni di questi eventi, come onsubmit, sono indipendenti dai dispositivi di input, altri invece richiedono l’utilizzo del mouse (tutto il gruppo onmouse.. e onclick). Altri ancora richiedono l’utilizzo della tastiera (onkey…). Se fosse necessario usare eventi che richiedano interazione all’utente, bisogna garantirne l’esecuzione, che l’utente utilizzi una periferica di puntamento, una tastiera o un emulatore di tastiera. È quindi necessario definire un equivalente comando da tastiera per ogni comando tramite mouse: i comandi da tastiera vengono spesso utilizzati per le tecnologie assistive e possono essere attivati anche tramite comandi vocali.

Possiamo quindi affiliare alcuni eventi nel modo seguente:

  • utilizzare onmousedown con onkeydown;
  • utilizzare onmouseup con onkeyup;
  • utilizzare onclick con onkeypress.

Nota: non esiste un comando da tastiera equivalente al doppio clic (ondblclick) in HTML 4.01 e XHTML.

Il codice seguente è un esempio mostra come usare correttamente gli eventi, utilizzando JavaScript per aprire una nuova finestra. Se JavaScript non è disponibile, selezionando il collegamento la nuova pagina sarà aperta nella stessa finestra mentre se è attivo il clic sul collegamento ipertestuale o l’uso di qualsiasi tasto (con il focus sul collegamento ipertestuale) aprirà una nuova finestra.

<a href="nuovapagina.html"
onclick="window.open(this.href); return false;"
onkeypress="window.open(this.href); return false;">Nuova Pagina</a>

Punto di controllo 9.2 (Priorità 2). Garantire che ogni elemento dotato di una sua specifica interfaccia possa essere gestito in una modalità indipendente dal dispositivo

Gli elementi con una propria interfaccia (come per esempio degli applet java) devono essere accessibili e compatibili con le tecnologie assistive. Nel caso non sia possibile rendere accessibile l’interfaccia, per esempio per limitazioni legate al tipo di oggetto, è necessario provvedere una versione alternativa: per ulteriori indicazioni su come creare interfacce accessibili per gli oggetti di programmazione è possibile consultare il requisito 17.

Punto di controllo 9.3 (Priorità 2). Negli script, specificare gestori di evento logici piuttosto che gestori di evento dipendenti dal dispositivo

Questo punto di controllo può definirsi una accentuazione di quanto richiesto dal 6.4 con particolare interesse per gli script. Ricordo che i comandi tastiera vengono spesso utilizzati dalle tecnologie assistive e possono essere utilizzati per attivare funzionalità tramite comandi vocali. Rispetto quindi ai comandi visionati nel punto di controllo 6.4, il requisito 9.3 consiglia di utilizzare espressamente i seguenti eventi, considerando comunque che alcuni, come ad esempio onchange, possono creare problemi di accessibilità se utilizzati con alcuni elementi nei moduli (form):

onload onunload
onfocus onblur
onsubmit
onreset
onselect
onchange

La maggior parte dei produttori di tecnologie assistive preferisce quindi appoggiarsi alle caratteristiche di accessibilità dei sistemi operativi sui quali sviluppa le applicazioni, in modo da consentirne la piena interazione e compatibilità.

È quindi importante specificare sempre eventi che non siano legati, per esempio, al movimento del mouse ma che abbiano sempre un equivalente tramite comando da tastiera in quanto su tali comandi si basano principalmente le tecnologie assistive.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la barra dell’accessibilità per:

  • verificare la presenza di script, applet e oggetti di programmazione;
  • verificare la presenza di eventi dipendenti dal dispositivo di input.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Informazioni

Identifica Applet/Script. Apre una nuova finestra elencando le applet e gli script presenti all’interno della pagina.

Struttura

Gestione eventi. Visualizza la presenza o meno di eventi indipendenti dal dispositivo di input (Punti di controllo 6.4, 9.2 e 9.3).

Visualizza un simbolo di avvertimento accanto ad un elemento, se l’elemento:

  • ha un attributo onmouseover senza il corrispondente onfocus;
  • ha un attributo onclick senza il corrispondente onkeypress;
  • è un elemento <select> ed ha un attributo onchange;
  • ha un attributo onfocus ma non è in grado di ricevere il focus.

Visualizza un simbolo di informazione accanto ad un elemento, se:

  • ha un attributo onmouseover con un onfocus corrispondente;
  • ha un attributo onclick con un onkeypress corrispondente.

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 17

Garantire che le funzionalità e le informazioni veicolate per mezzo di oggetti di programmazione, oggetti che utilizzano tecnologie non definite da grammatiche formali pubblicate, script e applet siano direttamente accessibili.

Riferimenti WCAG 1.0: 8.1

Riferimenti Section 508: 1194.22 (l), 1194.22 (m)

Motivazione

Tutti i programmatori dovrebbero garantire l’accessibilità dei loro programmi, specialmente se fruibili dal grande pubblico tramite un canale di comunicazione come Internet. Gli script, le applet e qualsiasi altro oggetto fornito di propria interfaccia deve esser reso compatibile con le tecnologie assistive, come gli i lettori di schermo e gli ingranditori di schermo (screen magnifier). Sarà quindi compito dello sviluppatore di tali oggetti utilizzare le tecniche di accessibilità delle interfacce stabilite dal produttore della tecnologia.

Implementazione

Il requisito chiede di garantire l’accesso di una pagina web tramite tecnologie assistive anche quando sono presenti oggetti di programmazione. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di verificare l’utilizzo di oggetti di programmazione e, ove individuati, garantire l’accessibilità tramite tecnologie assistive oppure fornire una soluzione equivalente che abbia la stessa finalità dell’oggetto non accessibile. Ad esempio, se si tratta di menu creati con Macromedia Flash bisogna garantire che tali menu siano accessibili, oppure è necessario fornire un contenuto alternativo all’oggetto. Nel caso, ad esempio, di un plug-in per un CMS con finalità di generare codice conforme al primo requisito, se non è possibile generare un oggetto accessibile è necessario fornire una soluzione alternativa che garantisca comunque la pubblicazione di contenuti e preferibilmente con la stessa finalità del plug-in (es: generazione di codice conforme al linguaggio di marcatura utilizzato).

Tra gli oggetti vanno considerati anche i plug-in che consentono la visualizzazione di contenuti all’interno del browser e questo significa che se nel sito internet è offerta la possibilità di aprire direttamente dei documenti pdf, rtf, ecc. questi documenti dovranno essere sviluppati seguendo le linee guida per l’accessibilità definite dal produttore della tecnologia: qualsiasi cosa venga fornito tramite web dovrà quindi essere accessibile, indipendentemente dalla tecnologia utilizzata.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 8.1 (Priorità 1 se importante, altrimenti priorità 2). Fare in modo che elementi di programmi come script e applet siano direttamente accessibili o compatibili con le tecnologie assistive

Prendiamo come esempio un’applet (creata con l’elemento <object> in quanto l’elemento <applet> non fa parte delle raccomandazioni del W3C): se richiede l’iterazione con l’utente (per esempio la facoltà di inserire delle informazioni per effettuare dei calcoli) e queste funzionalità non possono esser rese disponibili in una versione alternativa è necessario rendere l’applet accessibile. Se l’interfaccia non può esser resa accessibile a causa delle limitazioni del tipo di oggetto è importante garantire una funzionalità equivalente che fornisca all’utente la possibilità di ottenere la medesima informazione o funzionalità/obiettivo dell’oggetto. Nel caso si utilizzi per esempio Macromedia Flash MX, il prodotto contiene alcune funzionalità che consentono di rendere maggiormente accessibile il contenuto generato in Flash (come per esempio la possibilità di inserire l’attributo alt per le immagini) ma questo di fatto non è sufficiente per definire i contenuti in Flash “accessibili”. Alcune indicazioni su come rendere maggiormente accessibile il contenuto di Macromedia Flash sono disponibili sul sito di Macromedia <http://www.macromedia.com/macromedia/accessibility/features/flash/hints.html>.

Spesso questi oggetti si basano sulle API definite dai diversi sistemi operativi. Ad esempio, Macromedia Flash risulta “accessibile” solamente su piattaforma Microsoft Windows con Microsoft Internet Explorer.

Nel caso di Java, invece, è disponibile un pacchetto per la piattaforma Java 2: javax.accessibility che rende disponibile una serie di funzionalità <http://java.sun.com/j2se/1.3/docs/api/javax/accessibility/package-summary.html> per ottimizzare l’accessibilità dell’applicazione.

A titolo di esempio, usiamo l’oggetto AccessibleContext che fornisce informazioni sull’accessibilità di un particolare componente: i componenti che non contengono testi modificabili otterranno automaticamente un nome e una descrizione in formato accessibile:

AccessibleContext context = email.getAccessibleContext();
context.setAccessibleName("Email");
context.setAccessibleDescription("Indirizzo e-mail");

Gli oggetti devono essere indipendenti dalla periferica di input: in Java è possibile utilizzare dei valori mnemonici e degli acceleratori tramite tastiera che consentono l’utilizzo di funzionalità come per esempio l’accesso ad un menu con qualsiasi periferica di input.

‘ Associa una etichetta ad un componente
JLabel label = new JLabel("Nome Utente:");
label.setDisplayedMnemonic(‘U');
label.setLabelFor(username);
‘ Valore mnemonico per un menu
JMenu menu = new JMenu("File");
menu.setMnemonic(‘F');
‘ Tasto di scelta rapida per una voce di menu
JMenuItem item = new JMenuItem("Apri");
item.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_O,
KeyEvent.SHIFT_MASK));

In fase di definizione dei tasti di scelta rapida è necessario controllare sempre che non siano in conflitto con altre funzionalità del sistema operativo. In questo caso consultare le linee guida per le applicazioni in quanto i plug-in installati su personal computer dovrebbero ispirarsi ai requisiti software.

È da ricordare inoltre che i documenti contenenti script devono essere comunque accessibili se gli script non sono supportati o se sono stati disattivati (requisito 15).

Verifica del requisito

L’unico modo per testare gli oggetti è utilizzando una tastiera verificando che le funzionalità e le informazioni siano accessibili e verificando che per le immagini siano presenti dei testi alternativi equivalenti.

È altresì necessario valutare l’oggetto con un lettore dello schermo per verificare la presenza di informazioni non visibili (esempio: identificazione elementi/ oggetti, testi alternativi, ecc.). Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Potrebbero interessarti anche i seguenti articoli

  • Requisiti 19, 20, 21, 22Requisiti 19, 20, 21, 22 Requisito 19 Enunciato: Rendere chiara la destinazione di ciascun collegamento ipertestuale (link) con testi significativi anche se letti indipendentemente dal proprio […]
  • Requisito 1 – Riferimento WCAG 1.0 – parte 1Requisito 1 – Riferimento WCAG 1.0 – parte 1 Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al […]
  • Requisiti 11, 12, 13, 14Requisiti 11, 12, 13, 14 Requisito 11 Enunciato: Usare i fogli di stile per controllare la presentazione dei contenuti e organizzare le pagine in modo che possano essere lette anche quando i […]
  • Requisito 1 – Enunciato, motivazione ed implementazioneRequisito 1 – Enunciato, motivazione ed implementazione Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti […]
  • Guida ai requisiti tecnici – PremessaGuida ai requisiti tecnici – Premessa Nel decreto per sito INTERNET si intende l'insieme di componenti (pagine, link, funzioni) che risiedono su uno o più computer collegati alla rete Internet e che […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

Nessun commento

    Rispondi

    Link e informazioni