Accessibilità: tecniche e validazione

3° Workshop Accessibilità:

“primi passi per un mondo fruibile da tutti”

TECNICHE E VALIDAZIONE

dott. Dario Santarelli e-Lios s.r.l. (Area Sviluppo)Email: [email protected] Mobile: +39 333 3742535WeBlog: http://www.dariosantarelli.wordpress.com

2

Sommario

Introduzione Accessibilità: un fatto tecnico?

Separazione tra presentazione e contenuto XHTML e CSS Il supporto dei browser

WAI WCAG 1.0 Alcune Demo

WAI WCAG 2.0 Confronto con il passato

Validazione dell’ accessibilità I migliori strumenti

Conclusioni

“Accessibilità: primi passi per un mondo fruibile da tutti – Tecniche e validazione”dott. Dario Santarelli – Martedì 17 Aprile 2007

3“Accessibilità: primi passi per un mondo fruibile da tutti – Tecniche e validazione”dott. Dario Santarelli – Martedì 17 Aprile 2007

Introduzione

4

Accessibilità: un fatto tecnico?

Schiacciante verità: un sito può essere tecnicamente accessibile, ma di 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 sue

raccomandazioni al "content developer” (Someone who authors Web pages or designs Web sites“)

Progettista/Web Designer Sviluppatore L’autore dei contenuti

Alcune raccomandazioni delle WCAG 1.0 hanno a che vedere con l’usabilità, ma non forniscono metodologie.

Il primo passo per creare siti accessibili è creare siti che siano accessibili alle macchine. La migliore chance per ottenere ciò è usare linguaggi di markup standard.



Separazione tra Contenuto e Presentazione

XHTML + CSS

6

Separare il contenuto dalla Presentazione


Il contenuto di un documento è ciò che questo comunica all'utente attraverso linguaggio naturale, immagini, suoni, filmati, animazioni, ecc.

La presentazione di un documento è il modo in cui il documento è riprodotto (es. stampato, presentazione grafica bi-dimensionale, presentazione solo

testuale, discorso riprodotto da un sintetizzatore, braille, ecc.)

Tutti i possibili tipi di presentazione di un documento dovrebbero mostrare contenuti equivalenti Prevedere più canali sensoriali Non prevedere vincoli su parametri di utilizzo di un

determinato “user agent”

7

Separare il contenuto dalla Presentazione


Primo passo da compiere: eliminare dal codice HTML gli elementi e gli attributi di presentazione. A partire dalla versione 4 delle specifiche HTML, l'uso di elementi

e attributi di presentazione è stato disapprovato dal W3C in favore, 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 alla

riproduzione su una differente periferica (schermo, stampa, sintetizzatori vocali, ecc.)

Ottenimento di un codice (x)HTML più lineare e pulito, senza il ricorso ad artifici sconsigliati per l'accessibilità

8

Presentazioni alternative


Più dispositivi = Più presentazioni I browser non offrono un supporto uniforme

ed universale al cambio automatico del foglio di stile a seconda del tipo di media.. Si deve spessoricorrere a Tecniche di Style Switching

Terminali / Telescriventi / Palmari(media="tty” o media=“handheld”)Impossibile trovare un foglio di stile universalmente adatto

Braille (media=“braille”) Sono realmente supportati dai CSS? Uno sviluppatore vedente possiede le competenze per generare un tale foglio di stile?

Sintetizzatori vocali (media=“aural”) Praticamente nessuno sviluppatore conosce le esigenze di ascolto dell’utente finale..

all

CSS 2 Media Types

aural

braille

embossed

handheld

print

projection

screen

tty

tv

9

XHTML (eXtensible HyperText Markup Language)

XHTML è il successore di HTML XHTML 1.0 = riformulazione di HTML 4.01 in XML 1.0

Obiettivi Separazione tra la struttura del documento e la presentazione

utilizzare CSS preferibilmente esterni Riformulare HTML come XML

Versioni 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 valido


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Transitional (default in ASP.NET 2.0)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">

XHTML 1.1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml2.dtd">

XHTML 2.0

11


L’elemento root deve referenziare un namespace XHTML

Tutti gli elementi e gli attributi devono essere “lowercase”

I valori degli attributi devono essere compresi tra “quotation marks”

Gli elementi non vuoti che possiedono un tag di apertura devono avere un corrispondente tag di chiusura. Es. <br> <br></br> o <br /> (meglio!)

No “tag overlapping”

No “attribute minimization” <input id=“mcb” type="checkbox" checked /> (NO)

Usare l’attributo ‘id’ invece dell’attributo ‘name’


<html xmlns="http://www.w3.org/1999/xhtml" >

12


Il contenuto di <script> e <style> all’interno di una pagina deve essere compreso nella sezione CDATA


<script type="text/javascript"> <![CDATA[ function isLess(a, b) { if (a < b) return true; else return false; } ]]> </script>

<script type="text/javascript"> /* <![CDATA[ */

function isLess(a, b) { if (a < b) return true; else return false;} /* ]]> */ </script>

13

XHTML e MIME (Content) Types

W3C specifica un MIME Type per i documenti XHTML

Come presentare contenuti XHTML IE6+ non supporta application/xhtml+xml Firefox e Opera supportano application/xhtml+xml

Possibili 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


application/xhtml+xml

14

QUIRKSMODE

DOCTYPE Sniffing (Switching)


ALMOSTSTANDARDS

MODE

STANDARDSMODE

FULLSTANDARDS

MODE

Javascript Property document.compatMode

BackCompat/QuirksMode

CSS1Compat (Standards)

Usato dai browser per effettuare il corretto rendering di siti Web sia standard-compliant che legacy


WAIWCAG 1.0


W3C WAI (Web Accessibility Initiative)

Web Content Accessibility Guidelines

• WCAG 1.0 (1999)come creare contenuti accessibili

• WCAG 2.0Working Draft

“Candidate Recommendation“ (aprile 2007)

Authoring Tool Accessibility Guidelines

• ATAG 1.0 (2000) come progettare strumenti di authoring, utilizzabili da autori disabili, che producano contenuti accessibili

• ATAG 2.0Working Draft

User Agent Accessibility Guidelines

• UAAG 1.0 (2002)cosa devono fare gli sviluppatori di software per migliorare l' accessibilità di:• browser• multimedia player

17

Web Content Accessibility Guidelines 1.0

Priorità Ogni checkpoint (65 in totale) ha un livello di priorità a

seconda dell’impatto che esso possiede a livello di accessibilità Priorità 1: must (requisiti di base) Priorità 2: should (rimozione di barriere per l’accessibilità) Priorità 3: may (miglioramenti per l’accessibilità)

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 soddisfatti


La dichiarazione di conformità è responsabilità del webmaster o del content provider.Lo spirito è quello di dimostrare l' impegno e testimoniare i risultati conseguiti.

18


1. Fornire alternative equivalenti al contenuto audio e visivo “Fornire un contenuto che, quando viene presentato all'utente, gli

trasmetta essenzialmente la stessa funzione o scopo del contenuto audio o visivo.”

Considerazioni La versione testuale può essere velocemente incanalato verso la

sintesi vocale e la display braille, e può essere presentato visivamente (in vari formati) sul video del computer o su carta.

Anche fornire equivalenti non testuali (come immagini, video e audio pre-registrati) del testo scritto è di beneficio per alcuni utenti, specialmente per gli illetterati o per le persone che hanno difficoltà di lettura.


19

Web Captioning

Caption = versione testuale di una parola pronunciata Sincronizzazione: il testo dovrebbe apparire approssimativamente nello stesso

istante in cui l’audio diventa disponibile Equivalenza: il contenuto fornito nella versione testuale dovrebbe essere equivalente

a quello pronunciato Accessibilità: la versione testuale deve essere leggibile da un qualunque dispositivo

Tecnologie 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


2. Non fare affidamento sul solo colore “Assicurarsi che il testo e la parte grafica siano comprensibili se

consultati 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 un sufficiente contrasto se visti da qualcuno con deficit percettivi sul colore o se visti su uno schermo in bianco e nero.

Considerazioni Tra primo piano e sfondo ci dovrebbe essere il massimo contrasto

possibile, 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 del testo rispetto all’immagine sullo sfondo


21


3. Usare marcatori e fogli di stile e farlo in modo appropriato “Marcare i documenti con i corretti elementi strutturali. Controllare la

presentazione con fogli di stile piuttosto che con elementi e attributi di presentazione.”

Considerazioni Un titolo = un contenuto Non saltare livelli logici nell'uso delle intestazioni (H1…H6) Scegliere bene gli elementi strutturali Quando esiste un linguaggio di marcatori adatto, per veicolare

informazione usare un marcatore piuttosto che le immagini (es. MathML – Mathematical Markup Language).


22


4. Chiarire l'uso di linguaggi naturali “Utilizzare marcatori che facilitino la pronuncia o l'interpretazione di

testi stranieri o abbreviati.”

Considerazioni Contrassegnare i cambiamenti di linguaggio naturale: gli screen

reader e le periferiche braille possono selezionare automaticamente la nuova lingua, rendendo il documento più accessibile agli utenti multilingue.

Gli sviluppatori dovrebbero identificare il linguaggio naturale principale del contenuto di un documento (mediante marcatori o intestazioni HTTP).… anche per i motori di ricerca!

quando una stessa sigla ricorre più volte, viene definita da un elemento ABBR o ACRONYM solo la prima volta che appare nel testo


23


5. Creare tabelle che si trasformino in maniera elegante. “Assicurarsi che le tabelle abbiano la marcatura necessaria per

essere trasformate dai browser accessibili e da altri interpreti.”

Considerazioni Le tabelle, in qualsiasi modo siano usate, presentano problemi

particolari per gli utenti con lettori di schermo Alcuni interpreti consentono agli utenti di navigare fra le celle delle

tabelle e di accedere alle intestazioni e ad altre informazioni nelle celle.

Due tipi: tabelle dati e tabelle di impaginazione, distinguibili tramite relazioni semantiche (orizzontali/verticali) tra celle nella versione 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

“ASP.NET AJAX v1.0 Beta”dott. Dario Santarelli - Domenica 29 Ottobre 2006

24


6. Assicurarsi che le pagine che danno spazio a nuove tecnologie si trasformino in maniera elegante. “Assicurarsi che le pagine siano accessibili anche quando le

tecnologie più recenti non sono supportate o sono disabilitate”.

Considerazioni Comunicare la struttura logica unicamente per mezzo della presentazione

visuale non è una soluzione accessibile!

7. Assicurarsi che l'utente possa tenere sotto controllo i cambiamenti di contenuto nel corso del tempo. “Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o

che si autoaggiornano possano essere arrestati temporaneamente o definitivamente”.


25


8. Assicurare l'accessibilità diretta delle interfacce utente incorporate. “Assicurarsi che la progettazione delle interfacce utente segua i

principi dell'accessibilità: accesso alle diverse funzionalità indipendente 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 della

pagina attraverso una molteplicità di dispositivi di input.” In genere, le pagine che permettono di interagire tramite tastiera sono accessibili

anche tramite input vocale o interfaccia a linea di comando.


26

Javascript e Accessibilità

Questioni CriticheNavigazione, Contenuti Nascosti, Controllo da parte

dell’utente, Disorientamento

Soluzioni 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 completamente

navigabili da tastiera Javascript non dovrebbe modificare o ridefinire le normali

funzionalità del browser Nel caso in cui javascript non possa essere reso direttamente

accessibile, deve essere predisposta un'alternativa accessibile Contenuti e funzionalità devono comunque essere accessibili


27


10. Usare soluzioni provvisorie. “Usare soluzioni provvisorie in modo che le tecnologie assistive e i

browser più vecchi possano operare correttamente.”

11. Usare le tecnologie e le raccomandazioni del W3C. “Usare le tecnologie del W3C (in conformità con le specifiche) e

seguire le raccomandazioni sull'accessibilità. Nei casi in cui non sia possibile usare una tecnologia del W3C, oppure se nell'utilizzarla si ottenesse materiale che non si trasforma in maniera elegante, fornire una versione alternativa del contenuto che sia accessibile.”

12. Fornire informazione per la contestualizzazione e l'orientamento. “Fornire informazione per la contestualizzazione e l'orientamento,

per aiutare gli utenti a comprendere pagine od elementi complessi.”


28


13. 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

un modo per saltare il gruppo. Se sono fornite funzionalità di ricerca, rendere possibili diversi tipi di ricerca per

differenti livelli 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 possano

essere 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 possano

facilitare la comprensione della pagina. Creare uno stile di presentazione coerente fra le pagine.



WAIWCAG 2.0

30


Evoluzione delle WCAG 1.0 Stessi principi ispiratori Struttura diversa Si considerano anche aspetti di qualità del sito:

usabilità rispetto delle specifiche tecniche.

Concetti generali da applicare ai contenuti web Principi di progettazione non specifici per HTML, XML, o altre

tecnologie Principi da applicare a una varietà di situazioni e tecnologie,

anche non ancora esistenti Attualmente a livello di Working Draft

(aprile 2007: Candidate Recommendation)


31


La strutturaQuattro principi di progettazione

Percezione: il contenuto deve essere percettibile Operabilità: gli elementi dell' interfaccia presenti nel contenuto

devono essere azionabili Comprensibilità: contenuto e controlli devono essere

comprensibili Robustezza: il contenuto deve essere abbastanza robusto da

poter operare con le tecnologie presenti e future Per ogni principio, delle linee guida (13 in tutto) definiscono

come si applica il principio in un' area specifica Per ogni linea guida, tre livelli di criteri di successo (“success

criteria”), verificabili, per definire meglio le linee guida e determinare la conformità


32

Confronto tra WCAG 1.0 e WCAG 2.0

Stato 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 su

success 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, e

vari 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 è richiesto

per essere conformi alle WCAG 2.0 in quella specifica tecnologia



ValidazioneAccessibilità

34

Validare XHTML

Un documento XHTML, come HTML è valido seAl suo inizio è dichiarata la DTD utilizzata nel documento; Gli elementi e gli attributi adoperati rispettano alla lettera la

sintassi per loro definita nella DTD dichiarata all'inizio

Markup Validator Service (http://validator.w3.org/)

Errori comuni: Elementi aperti e non chiusi o viceversa Elementi incastrati invece che annidati (p.es. <b><i> ... </b></i>,

invece di <b><i> ... </i></b>) 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 <noscript> deve essere incluso in un elemento strutturale lang invece di xml:lang L’attributo language non può essere usato per <script> e <style>


http://validator.w3.org/

35

Validare CSS

CSS Validator (http://jigsaw.w3.org/css-validator/)

CSS Check (http://www.htmlhelp.com/tools/csscheck/)

Errori Comuni Mancanza del punto e virgola finale che chiude la dichiarazione di una

proprietà Mancanza della parentesi graffa che chiude un elenco di proprietà Un colore dichiarato in valori esadecimali non preceduti dal simbolo ‘#' ‘Sans-serif' scritto senza il trattino separatore Nomi di classe e id non validi Un commento (/* ... */) aperto e non chiuso, o viceversa

Risolvere gli avvertimenti (warning) Mancata indicazione di una famiglia di caratteri generica (Sans-Serif) Mancata definizione del colore di primo piano se è stato definito il colore di

sfondo, e viceversa Uso di dimensionamenti fissi in luogo di quelli relativi e percentuali


http://jigsaw.w3.org/css-validator/



http://www.htmlhelp.com/tools/csscheck/





36

Validazione dell’accessibilità (W3C)

WCAG 1.0 – Appendice A “Verificate l'accessibilità per mezzo di strumenti automatici e della

revisione umana. I metodi automatici sono in genere rapidi e convenienti ma non possono identificare tutti i problemi di accessibilità. La revisione umana può aiutare a garantire la chiarezza del linguaggio e la semplicità della navigazione”

Consigli W3C Controllare con strumenti automatici la validità della sintassi

(x)HTML e CSS, nonché le misure prese per favorire l'accessibilità. Nessun controllo automatico è in grado di valutare al 100% l'accessibilità

di una pagina web Verificare la percepibilità dei contenuti per mezzo della vista e

dell'udito nelle più disparate condizioni d'uso Controllare l’ortografia e valutare la leggibilità, eventualmente con

strumenti automatici Ricorrere al giudizio possibilmente di persone con disabilità


37

Dichiarare la conformità alle WCAG 1.0


La guerra dei bollini Una pretesa di conformità spesso senza certificazione Di fatto è una truffa per l’utente che non ha bisogno di bollini, ma di

accessibilità Senza revisori umani l’accessibilità non esiste Esporre soltanto le dichiarazioni di conformità di cui si è

assolutamente sicuri e che possono essere verificate dall'utente Predisporre nel sito una pagina, in cui dichiarate quali controlli di

revisione umana sono stati effettuati in aggiunta ai test automatici, e quando e come sono stati eseguiti l'ultima volta.

Portale “Spazio Europa della regione Emilia Romagna” Conformità ad HTML 4.01, CSS 2.0, Bobby AAA e Bobby Section

508, WCAG 1.0 AAA … NOOOO! Diffidare di siti con abbondanza di bollini, soprattutto se sono

teoricamente incompatibili

http://www.spazioeuropa.it/

38

I migliori strumenti automatici


AIS (Web Accessibility Toolbar) IE

Web Developer (Firefox)

Internet Explorer Developer Toolbar IE

Lynx Browser/Viewer

Fang (Firefox)

HTML Tidy strumento a linea di comando molto potente: è in grado di individuare e correggere

errori di sintassi (X)HTML e di fornire utili suggerimenti per il miglioramento dell'accessibilità. Ora su Source Forge

A-Prompt Un valutatore dell'accessibilità sviluppato dall'Università di Toronto, da scaricare in

locale: è in grado di fornire indicazioni di conformità sia alla Section 508 sia alle WCAG 1.0.

Wikipedia (Paragone tra Screen Reader) ( http://en.wikipedia.org/wiki/List_of_screen_readers )

http://en.wikipedia.org/wiki/List_of_screen_readers

39

I migliori strumenti automatici


WebXact (http://webxact.watchfire.com) Strumento di validazione on line della Watchfire, la stessa casa produttrice di Bobby.

Offre all'incirca le stesse informazioni di Bobby, ma in un modo più organizzato ed usabile.

Cynthia Says portal (http://www.contentquality.com) Consente una valutazione dell'accessibilità che si estende in qualche misura anche

alla proprietà dei testi alternativi: valuta per esempio la lunghezza dei testi ALT e se questi ripetono il nome dell'immagine a cui si riferiscono.

Torquemada (http://www.webxtutti.it) Valutatore automatico dell'accessibilità tutto italiano, sviluppato dalla Fondazione Ugo

Bordoni.

WAVE 3.5 Accessibility Tool (development version) (http://dev.wave.webaim.org) I risultati della validazione sono rappresentati graficamente e gli avvertimenti sono

contestuali alla posizione di rilevamento.

Web Accessibility Checker (http://checker.atrc.utoronto.ca) Supporto alla Legge Stanca

http://webxact.watchfire.com/

http://www.contentquality.com/

http://www.webxtutti.it/

http://dev.wave.webaim.org/

http://checker.atrc.utoronto.ca/

40

Conclusioni


Consigli Finali per una buona accessibilitàSeparare SEMPRE la presentazione dal contenuto Usare DTD rigorose (es. XHTML 1.1 o XHTML 1.0 Strict)Mai basarsi sul colore per fornire informazioni Evidenziare la struttura logica dei contenuti testuali

H1,H2,H3 etc.Realizzare moduli accessibili

FIELDSET, LEGEND, LABEL etc. + CSSMassima attenzione alle tabelle dati

TH, SUMMARY, CAPTION etc.Occhio alla linearizzazione dei contenuti (sostituire le tabelle usate

a scopo di impaginazione con soluzioni basate sui CSS)

Scrivere testi accessibili e non dipendenti da un ambito

41

Conclusioni


Consigli Finali per una buona accessibilitàNon usare i FRAME Assicurarsi di scrivere XHTML e CSS validiUsare revisione automatiche per gli errori di accessibilità legati

al codiceUsare la revisione umanaPorsi come obiettivo il raggiungimento di un'accessibilità

reale

42

Grazie per l’attenzione…


FINE

Accessibilità: tecniche e validazione

Technology

Transcript of Accessibilità: tecniche e validazione