Accessibilità: tecniche e validazione

Click here to load reader

  • date post

    19-Jun-2015
  • Category

    Technology

  • view

    150
  • download

    3

Embed Size (px)

description

L’accessibilità non è solamente un problema tecnico, ovvero legato a particolari linguaggi di markup o a tecnologie specifiche; un sito può essere tecnicamente accessibile, ma di fatto non fruibile per un disabile. Dopo alcune brevissime considerazioni di carattere “filosofico” sulle prassi che gli sviluppatori dovrebbero seguire ed una panoramica su XHTML e CSS, verranno introdotte le priorità e le conformità stabilite dalle WCAG 1.0 e dalle future WCAG 2.0; infine, saranno mostrati dei tools per l'analisi e la validazione dell'accessibilità.

Transcript of Accessibilità: tecniche e validazione

  • 1. 3 WorkshopAccessibilit:primi passi per un mondo fruibile da tuttiTECNICHE E VALIDAZIONEdott. Dario Santarellie-Lios s.r.l. (Area Sviluppo)Email: [email protected]: +39 333 3742535WeBlog: http://www.dariosantarelli.wordpress.com

2. SommarioIntroduzione Accessibilit: un fatto tecnico?Separazione tra presentazione e contenuto XHTML e CSS Il supporto dei browserWAI WCAG 1.0 Alcune DemoWAI WCAG 2.0 Confronto con il passatoValidazione dell accessibilit I migliori strumentiConclusioni 3. Introduzione 4. Accessibilit: un fatto tecnico?Schiacciante verit: un sito pu essere tecnicamente accessibile, madi fatto non fruibile per un disabile La vera sfida del Web l usabilit!Dov il Problema? L'accessibilit, cos come concepita dalle attuali WCAG 1.0, rivolge le sueraccomandazioni al "content developer (Someone who authors Webpages or designs Web sites) Progettista/Web Designer Sviluppatore Lautore dei contenuti Alcune raccomandazioni delle WCAG 1.0 hanno a che vedere conlusabilit, ma non forniscono metodologie.Il primo passo per creare siti accessibili creare siti che sianoaccessibili alle macchine. La migliore chance per ottenere ci usarelinguaggi di markup standard. 5. Separazione traContenuto e PresentazioneXHTML + CSS 6. Separare il contenuto dalla PresentazioneIl contenuto di un documento ci che questo comunicaall'utente attraverso linguaggio naturale, immagini, suoni,filmati, animazioni, ecc.La presentazione di un documento il modo in cui ildocumento riprodotto (es. stampato, presentazione grafica bi-dimensionale, presentazione solotestuale, discorso riprodotto da un sintetizzatore, braille, ecc.)Tutti i possibili tipi di presentazione di un documentodovrebbero mostrare contenuti equivalenti Prevedere pi canali sensoriali Non prevedere vincoli su parametri di utilizzo di undeterminato user agent 7. Separare il contenuto dalla PresentazionePrimo passo da compiere: eliminare dal codice HTML glielementi e gli attributi di presentazione. A partire dalla versione 4 delle specifiche HTML, l'uso di elementie attributi di presentazione stato disapprovato dal W3C infavore, appunto, dell'uso dei fogli di stile.Presentazione: Impatto dei CSS sul Web Riduzione del peso medio di una pagina del 50-60%. Possibilit di presentazioni alternative, ciascuna adatta allariproduzione su una differente periferica (schermo, stampa,sintetizzatori vocali, ecc.) Ottenimento di un codice (x)HTML pi lineare e pulito, senza ilricorso ad artifici sconsigliati per l'accessibilit 8. Presentazioni alternativePi dispositivi = Pi presentazioni I browser non offrono un supporto uniformeed universale al cambio automatico del foglio distile a seconda del tipo di media.. Si deve spessoricorrere a Tecniche di Style SwitchingTerminali / Telescriventi / Palmari(media="tty o media=handheld)Impossibile trovare un foglio di stile universalmenteadatto Braille(media=braille)Sono realmente supportati dai CSS?Uno sviluppatore vedente possiede lecompetenze per generare un tale foglio di stile? Sintetizzatori vocali(media=aural)Praticamente nessuno sviluppatore conosce leesigenze di ascolto dellutente finale..CSS 2 Media Typesallauralbrailleembossedhandheldprintprojectionscreenttytv 9. XHTML (eXtensible HyperText Markup Language)XHTML il successore di HTML XHTML 1.0 = riformulazione di HTML 4.01 in XML 1.0Obiettivi Separazione tra la struttura del documento e la presentazione utilizzare CSS preferibilmente esterni Riformulare HTML come XMLVersioni XHTML 1.0 Transitional XHTML 1.0 Strict XHTML 1.0 Frameset XHTML 1.1 XHTML 2.0 10. Creazione di pagine XHTML (1/3)Specificare un XHTML DOCTYPE validoXHTML 1.0 Transitional (default in ASP.NET 2.0)XHTML 1.0 StrictXHTML 1.0 FramesetXHTML 1.1XHTML 2.0 11. Creazione di pagine XHTML (2/3)Lelemento root deve referenziare un namespace XHTMLTutti gli elementi e gli attributi devono essere lowercaseI valori degli attributi devono essere compresi tra quotationmarksGli elementi non vuoti che possiedono un tag di apertura devonoavere un corrispondente tag di chiusura. Es.

o
(meglio!)No tag overlappingNo attribute minimization (NO)Usare lattributo id invece dellattributo name 12. Creazione di pagine XHTML (3/3)Il contenuto di 13. XHTML e MIME (Content) TypesW3C specifica un MIME Type per i documenti XHTMLapplication/xhtml+xmlCome presentare contenuti XHTML IE6+ non supporta application/xhtml+xml Firefox e Opera supportano application/xhtml+xmlPossibili Rendering Workarounds per IE6+:Utilizzare il MIME Type text/html (ASP.NET default)Utilizzare application/xml o text/xml (XML + XSL)Negoziazione: MIME Types differenti in base al Browser ASP.NET: evento Application_PreSendRequestHeaders 14. Usato dai browser per effettuare il corretto rendering di siti Websia standard-compliant che legacyQUIRKSModeDOCTYPE Sniffing (Switching)ALMOSTStandardsModeStandardsModeFULLStandardsModeJavascript Property document.compatModeBackCompat/QuirksModeCSS1Compat (Standards) 15. WAIWCAG 1.0 16. W3C WAI (Web Accessibility Initiative) 17. Web Content Accessibility Guidelines 1.0Priorit Ogni checkpoint (65 in totale) ha un livello di priorit aseconda dellimpatto che esso possiede a livello diaccessibilit Priorit 1: must (requisiti di base) Priorit 2: should (rimozione di barriere per laccessibilit) Priorit 3: may (miglioramenti per laccessibilit)Conformit Tutti i checkpoints con priorit 1 sono soddisfatti Tutti i checkpoints con priorit 1 e 2 sono soddisfatti Tutti i checkpoints con priorit 1,2 e 3 sono soddisfattiLa dichiarazione di conformit responsabilit del webmaster o del content provider.Lo spirito quello di dimostrare l' impegno e testimoniare i risultati conseguiti. 18. Web Content Accessibility Guidelines 1.01. Fornire alternative equivalenti al contenuto audio evisivo Fornire un contenuto che, quando viene presentato all'utente, glitrasmetta essenzialmente la stessa funzione o scopo del contenutoaudio o visivo.Considerazioni La versione testuale pu essere velocemente incanalato verso lasintesi vocale e la display braille, e pu essere presentatovisivamente (in vari formati) sul video del computer o su carta. Anche fornire equivalenti non testuali (come immagini, video eaudio pre-registrati) del testo scritto di beneficio per alcuni utenti,specialmente per gli illetterati o per le persone che hanno difficolt dilettura. 19. Web CaptioningCaption = versione testuale di una parola pronunciata Sincronizzazione: il testo dovrebbe apparire approssimativamente nello stesso istante incui laudio diventa disponibile Equivalenza: il contenuto fornito nella versione testuale dovrebbe essere equivalente aquello pronunciato Accessibilit: la versione testuale deve essere leggibile da un qualunque dispositivoTecnologie SMIL (Synchronized Multimedia Integration Language) Quicktime e RealPlayer SAMI (Synchronized Accessible Media Interchange) Windows Media Player Text Track Quicktime MAGpie Creazione di caption files Hi-Caption Creazione di caption files 20. Web Content Accessibility Guidelines 1.02. Non fare affidamento sul solo coloreAssicurarsi che il testo e la parte grafica siano comprensibili seconsultati senza il colore. 2.2 [Priorit 2 per le immagini, Priorit 3 per il testo] (Sbagliato?)Assicurarsi che le combinazioni fra colori dello sfondo e del primo piano forniscano unsufficiente contrasto se visti da qualcuno con deficit percettivi sul colore o se visti su unoschermo in bianco e nero.ConsiderazioniTra primo piano e sfondo ci dovrebbe essere il massimo contrastopossibile, privilegiando la luminosit e non il tono (frequenza).Per gli ipovedenti, usare colori non eccessivamente luminosi e saturi,altrimenti possono verificarsi fastidiosi fenomeni di abbagliamento.Evitare sia Texture sotto il testo che il movimento disaccoppiato deltesto rispetto allimmagine sullo sfondo 21. Web Content Accessibility Guidelines 1.03. Usare marcatori e fogli di stile e farlo in modoappropriato Marcare i documenti con i corretti elementi strutturali. Controllare lapresentazione con fogli di stile piuttosto che con elementi e attributidi presentazione.Considerazioni Un titolo = un contenuto Non saltare livelli logici nell'uso delle intestazioni (H1H6) Scegliere bene gli elementi strutturali Quando esiste un linguaggio di marcatori adatto, per veicolareinformazione usare un marcatore piuttosto che le immagini (es.MathML Mathematical Markup Language). 22. Web Content Accessibility Guidelines 1.04. Chiarire l'uso di linguaggi naturali Utilizzare marcatori che facilitino la pronuncia o l'interpretazione ditesti stranieri o abbreviati.Considerazioni Contrassegnare i cambiamenti di linguaggio naturale: gli screenreader e le periferiche braille possono selezionare automaticamentela nuova lingua, rendendo il documento pi accessibile agli utentimultilingue. Gli sviluppatori dovrebbero identificare il linguaggio naturaleprincipale del contenuto di un documento (mediante marcatori ointestazioni HTTP). anche per i motori di ricerca! quando una stessa sigla ricorre pi volte, viene definita da unelemento ABBR o ACRONYM solo la prima volta che appare neltesto 23. Web Content Accessibility Guidelines 1.05. Creare tabelle che si trasformino in maniera elegante. Assicurarsi che le tabelle abbiano la marcatura necessaria peressere trasformate dai browser accessibili e da altri interpreti.Considerazioni Le tabelle, in qualsiasi modo siano usate, presentano problemiparticolari per gli utenti con lettori di schermo Alcuni interpreti consentono agli utenti di navigare fra le celle delletabelle e di accedere alle intestazioni e ad altre informazioni nellecelle. Due tipi: tabelle dati e tabelle di impaginazione, distinguibilitramite relazioni semantiche (orizzontali/verticali) tra celle nellaversione linearizzata Caso critico: tabelle di impaginazione contenenti tabelle dati. Le tabelle dati possono essere rese accessibili, o pi accessibili,utilizzando un apposito codice di marcatura strutturale 24. Web Content Accessibility Guidelines 1.06. Assicurarsi che le pagine che danno spazio a nuovetecnologie si trasformino in maniera elegante. Assicurarsi che le pagine siano accessibili anche quando letecnologie pi recenti non sono supportate o sono disabilitate.Considerazioni Comunicare la struttura logica unicamente per mezzo della presentazionevisuale non una soluzione accessibile!7. Assicurarsi che l'utente possa tenere sotto controllo icambiamenti di contenuto nel corso del tempo. Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli oche si autoaggiornano possano essere arrestati temporaneamente odefinitivamente. 25. Web Content Accessibility Guidelines 1.08. Assicurare l'accessibilit diretta delle interfacceutente incorporate. Assicurarsi che la progettazione delle interfacce utente segua iprincipi dell'accessibilit: accesso alle diverse funzionalitindipendente dai dispositivi usati, possibilit di operare da tastiera,comandi vocali, ecc.9. Progettare per garantire l'indipendenza da dispositivo Usare caratteristiche che permettono di attivare gli elementi dellapagina attraverso una molteplicit di dispositivi di input. In genere, le pagine che permettono di interagire tramite tastiera sono accessibilianche tramite input vocale o interfaccia a linea di comando. 26. Javascript e AccessibilitQuestioni CriticheNavigazione, Contenuti Nascosti, Controllo da partedellutente, DisorientamentoSoluzioni Usare Gestori di eventi indipendenti dal dispositivo (ad esempio,quelli che non richiedono l'uso del solo mouse) Pagine web che utilizzano gli script devono essere completamentenavigabili da tastiera Javascript non dovrebbe modificare o ridefinire le normalifunzionalit del browser Nel caso in cui javascript non possa essere reso direttamenteaccessibile, deve essere predisposta un'alternativa accessibile Contenuti e funzionalit devono comunque essere accessibili 27. Web Content Accessibility Guidelines 1.010. Usare soluzioni provvisorie. Usare soluzioni provvisorie in modo che le tecnologie assistive e ibrowser pi vecchi possano operare correttamente.11. Usare le tecnologie e le raccomandazioni del W3C. Usare le tecnologie del W3C (in conformit con le specifiche) eseguire le raccomandazioni sull'accessibilit. Nei casi in cui non siapossibile usare una tecnologia del W3C, oppure se nell'utilizzarla siottenesse materiale che non si trasforma in maniera elegante,fornire una versione alternativa del contenuto che sia accessibile.12. Fornire informazione per la contestualizzazione el'orientamento. Fornire informazione per la contestualizzazione e l'orientamento,per aiutare gli utenti a comprendere pagine od elementi complessi. 28. Web Content Accessibility Guidelines 1.013. Fornire chiari meccanismi di navigazione. Identificare con chiarezza l'obiettivo di ogni collegamento Creare una Mappa oppure un indice del sito Usare meccanismi di navigazione in modo coerente. Fornire barre di navigazione Raggruppare i collegamenti correlati, identificare i gruppi (per gli interpreti) e, fornire unmodo per saltare il gruppo. Se sono fornite funzionalit di ricerca, rendere possibili diversi tipi di ricerca per differentilivelli di abilit e per preferenze diverse.14. Assicurarsi che i documenti siano chiari e semplici. Assicurarsi che i documenti siano chiari e semplici in modo che possanoessere compresi pi facilmente. Usare il linguaggio pi chiaro e semplice possibile che sia adatto al contenuto di un sito. Integrare il testo con presentazioni grafiche o uditive nei casi in cui esse possanofacilitare la comprensione della pagina. Creare uno stile di presentazione coerente fra le pagine. 29. WAIWCAG 2.0 30. Web Content Accessibility Guidelines 2.0Evoluzione delle WCAG 1.0Stessi principi ispiratoriStruttura diversaSi considerano anche aspetti di qualit del sito: usabilit rispetto delle specifiche tecniche.Concetti generali da applicare ai contenuti webPrincipi di progettazione non specifici per HTML, XML, o altretecnologiePrincipi da applicare a una variet di situazioni e tecnologie,anche non ancora esistentiAttualmente a livello di Working Draft (aprile 2007: Candidate Recommendation) 31. Web Content Accessibility Guidelines 2.0La strutturaQuattro principi di progettazione Percezione: il contenuto deve essere percettibile Operabilit: gli elementi dell' interfaccia presenti nel contenutodevono essere azionabili Comprensibilit: contenuto e controlli devono essere comprensibili Robustezza: il contenuto deve essere abbastanza robusto da poteroperare con le tecnologie presenti e futurePer ogni principio, delle linee guida (13 in tutto) definisconocome si applica il principio in un' area specificaPer ogni linea guida, tre livelli di criteri di successo (successcriteria), verificabili, per definire meglio le linee guida edeterminare la conformit 32. Confronto tra WCAG 1.0 e WCAG 2.0Stato del documento WCAG 1.0: unico documento stabile e referenziabile (Recommendation) WCAG 2.0: documento ancora in fase di raffinamento (Working Draft)Conformit WCAG 1.0: guideline con checkpoint. Conformit basata su checkpoint. WCAG 2.0: principi, guideline e success criteria. Conformit basata susuccess criteria.Tecniche WCAG 1.0: un documento contenente i link alle varie tecniche, un documento("Core") generale, e due documenti specifici (HTML e CSS) WCAG 2.0: un documento generale, contenente link e tecniche generali, evari documenti specifici (gi disponibili HTML, CSS, client-side scripting, etc.)Checklist WCAG 1.0: lista di checkpoint raggruppati per priorit WCAG 2.0: lista di proposizioni verificabili che specificano cosa richiestoper essere conformi alle WCAG 2.0 in quella specifica tecnologia 33. ValidazioneAccessibilit 34. Validare XHTMLUn documento XHTML, come HTML valido seAl suo inizio dichiarata la DTD utilizzata nel documento;Gli elementi e gli attributi adoperati rispettano alla lettera lasintassi per loro definita nella DTD dichiarata all'inizioMarkup Validator Service (http://validator.w3.org/)Errori comuni: Elementi aperti e non chiusi o viceversa Elementi incastrati invece che annidati (p.es. ... ,invece di ... ) Uso di elementi e attributi non consentiti dalla Dtd adoperata Uso del carattere &' in una stringa di query invece di &' Uso di valori di attributo non consentiti Il testo di deve essere incluso in un elemento strutturale lang invece di xml:lang Lattributo language non pu essere usato per