WCAG 1.0. Introduzione, metodi e priorità

Considerazioni generali sulle WCAG 1.0

Le prime linee guida dedicate dal WAI-W3C all’accessibilità dei contenuti del Web, anzi le prime in generale dedicate al tema dell’accessibilità, sono le Web Content Accessibility Guidelines (WCAG) 1.0, pubblicate il 5 maggio 1999.

Poco più di un anno e mezzo più tardi, il 25 gennaio 2001, il WCAG WG, cioè il gruppo di lavoro per l’accessibilità dei contenuti del Web presso il WAI-W3C, pubblicava la prima bozza di lavoro delle WCAG 2.0, destinate a succedere alla versione 1.0. I numerosi anni trascorsi da allora non sono bastati per traghettare le WCAG 2.0 allo stadio finale di Raccomandazione W3C (al momento in cui viene “chiuso” questo libro, l’ultima bozza pubblica è datata 17 maggio 2007). Ciò per via dell’ampiezza che
il progetto ha assunto in corso d’opera e della difficoltà
di trovare un accordo largamente condiviso tra i membri del gruppo su molti degli argomenti ancora in discussione.

A causa dell’interminabile fase di gestazione della nuova versione delle linee guida, le WCAG 1.0 sono quindi, a settembre 2007, lo standard ufficiale di riferimento a livello internazionale per lo sviluppo di siti web accessibili. Anche se diverse nazioni, tra cui l’Italia, si sono dotate nel frattempo di una legislazione propria sull’accessibilità dei contenuti del Web, il punto di riferimento delle normative nazionali sono pur sempre le WCAG 1.0, le cui raccomandazioni sono trapassate – integralmente o parzialmente o con modifiche – nelle legislazioni dei Paesi che hanno regolato la materia.

Per un documento così datato, è la prova di una longevità e di un successo notevoli, considerata la rapidità dei cambiamenti che interessano il Web.

Limiti e invecchiamento delle WCAG 1.0

È innegabile, però, che i tanti cambiamenti intercorsi nella pratica dello sviluppo di siti web dal 1999 a oggi abbiano reso obsolete alcune parti delle WCAG 1.0 e dei documenti tecnici di supporto. Per esempio, l’insistere sui metodi per rendere accessibili i frame risente di criteri di progettazione che sono ormai sorpassati: nessuno oggi penserebbe seriamente di progettare un sito accessibile, impiantandolo su un’architettura a frame.

Analogamente, il suggerimento di usare NOSCRIPT, per fornire alternative statiche a contenuti generati dinamicamente tramite linguaggi di scripting, si rivela non al passo coi tempi: la costruzione di funzioni dinamiche col metodo del potenziamento progressivo (si vedano in proposito i Capitoli 11 e 12 di questo libro) rende oggi inutile, nella maggior parte dei casi, il ricorso a NOSCRIPT. Garantire l’accesso ai contenuti indipendentemente dal supporto per gli script è, infatti, una caratteristica di base della progettazione accessibile contemporanea; gli script dovrebbero essere usati, nella cornice attuale, solo per aggiungere comportamenti, non per creare un accesso esclusivo ai contenuti, come invece accadeva di frequente negli anni a cavallo della pubblicazione delle WCAG 1.0.

Un altro punto debole sono le raccomandazioni provvisorie della linea guida 7 e, in particolare, quelle della linea guida 10. Alcuni suggerimenti erano già discutibili nel 1999, come quello di includere del testo segnaposto nei campi di immissione dei moduli (punto di controllo 10.4) e quello di fornire una versione linearizzata di qualsiasi tabella contenente testo che scorra su più righe in almeno due celle affiancate (punto di controllo 10.3). Ma la debolezza delle raccomandazioni provvisorie non sta tanto in ciò che richiedono agli sviluppatori, quanto nell’indeterminatezza del termine di applicazione. A parte un vecchissimo e non più aggiornato documento W3C dedicato a tener traccia dei progressi di browser e tecnologie assistive, non c’è, infatti, un riscontro ufficiale del W3C, che vincoli o sciolga gli sviluppatori dal continuare a rispettare il dettato delle linee guida provvisorie delle WCAG 1.0 (cioè tutte quelle introdotte dalla formula “Until user agents”).

Altri problemi applicativi sono legati alla laconicità delle tecniche e delle spiegazioni associate ad alcune raccomandazioni. La richiesta, per esempio, di marcare i cambi di lingua presenti nei documenti HTML, contenuta nel punto di controllo 4.1, è del tutto ragionevole, ma le WCAG 1.0 tralasciano, però, di spiegare a sviluppatori e autori di contenuti cos’è un cambio di lingua, il che ha portato ad applicazioni a dir poco improbabili del punto di controllo e, più spesso, a trascurare semplicemente ciò che esso raccomanda.

Altri problemi applicativi, infine, dipendono dalla mancanza di regole oggettive per determinare quando una raccomandazione possa dirsi soddisfatta. È il caso della richiesta di spostare il contenuto informativo distintivo all’inizio di titoli, paragrafi, elenchi ecc. (punto di controllo 13.8) e, soprattutto, della raccomandazione di usare il linguaggio più chiaro e più semplice in relazione all’argomento trattato (punto di controllo 14.1). Per quanto i documenti di supporto alle WCAG 1.0 forniscano indicazioni empiriche su come applicare questi, e altri analoghi, punti di controllo, uno sviluppatore - anche il più scrupoloso - non ha che il proprio giudizio per decidere, in base ai riscontri degli utenti e all’esito di eventuali test automatici e con umani, se sia riuscito, e in quale misura, ad applicare tali raccomandazioni.

Inizio pagina

Pregi e attualità delle WCAG 1.0

I limiti evidenziati nel precedente paragrafo non riescono a oscurare i meriti delle WCAG 1.0, che sono senz’altro maggiori. Buona parte dei principi generali di accessibilità che esse formulano sono validi ancora oggi e fanno di queste linee guida un documento largamente attuale e meritevole di essere conosciuto e analizzato in profondità.

L’elenco dei principi e delle buone pratiche di sviluppo che le WCAG 1.0 introducono o consolidano, e che possiamo considerare a buon diritto caposaldi della progettazione accessibile, comprende quanto meno:

• la definizione del concetto di equivalente;
• il metodo della degradazione elegante dei contenuti (cioè il principio della scalabilità);
• l’idea che l’accessibilità non riguardi solo la tecnica informatica, ma anche la comprensibilità dell’informazione e, perciò, la qualità della comunicazione;
• l’idea di non vincolare i contenuti a una sola modalità sensoriale (vista, udito, colore), a una sola tecnologia (JavaScript, Java ecc.), a una sola modalità di input (il mouse), cioè, in breve, il principio dell’indipendenza dal dispositivo;
• l’idea che i contenuti debbano essere strutturati tramite il codice di marcatura e presentati per mezzo dei fogli di stile;
• l’idea di vincolare accessibilità e interoperabilità mediante la raccomandazione di rispettare gli standard W3C;
• l’idea che la facilità di utilizzo e la navigabilità delle interfacce utente siano strettamente connesse con l’accessibilità dei contenuti.

Tutto ciò fa delle WCAG 1.0, almeno fino a quando non saranno rese obsolete dalle WCAG 2.0, il nodo centrale di ogni trattazione sistematica dei criteri per progettare siti web accessibili, che voglia dirsi obiettiva e ben fondata.

Non è possibile, per esempio, capire e applicare i ventidue requisiti tecnici della legge italiana sull’accessibilità (di cui tratta il Capitolo 22 di questo libro), se non si conoscono le raccomandazioni e i punti di controllo delle WCAG 1.0, al cui dettato si richiamano esplicitamente i requisiti della legge italiana. Lo stesso vale per i sedici articoli del capitolo 1194.22 della cosiddetta Section 508 (la legge statunitense che definisce, tra molte altre cose, le regole per l’accessibilità dei contenuti web): molti di quegli articoli ripetono quasi letteralmente il dettato dei punti di controllo delle WCAG 1.0, che il legislatore americano ha preso a riferimento.

Italia e Stati Uniti a parte, anche Austria, Belgio, Danimarca, Finlandia, Germania, Irlanda, Olanda, Norvegia, Portogallo, Gran Bretagna, Unione Europea, Canada, Hong Kong, Giappone, Corea del Sud, Nuova Zelanda, Singapore, Thailandia – ed è sicuramente un elenco incompleto – hanno già promulgato, o stanno per promulgare, leggi e direttive per l’accessibilità dei siti web d’interesse pubblico, le quali sono in tutto o in parte basate sulle WCAG 1.0 o, quanto meno, sono ispirate alla medesima visione dello sviluppo accessibile fatta propria dalle WCAG 1.0.

Tutto ciò premesso, questo libro non solo riconosce l’importanza delle WCAG 1.0 per la diffusione e la comprensione dell’accessibilità, ma ne fa il filo conduttore dell’esposizione che occuperà la maggior parte dei capitoli seguenti. Tolto, infatti, il capitolo corrente, che contiene nozioni introduttive, i capitoli dal quarto al diciannovesimo analizzeranno e commenteranno dettagliatamente ciascuna delle quattordici raccomandazioni che costituiscono il nucleo delle WCAG 1.0.

Inizio pagina

Organizzazione del documento

Le Web Content Accessibility Guidelines 1.0 sono racchiuse tutte in un lungo documento in inglese (traduzione italiana disponibile presso l’indirizzo http://www.aib.it/aib/cwai/WAI-trad.htm ). Il documento è costituito – al netto di presentazione, sommario, riferimenti e ringraziamenti – dalle seguenti parti:

• l’introduzione, che elenca i beneficiari delle linee guida e delinea il concetto di equivalente, fondamentale per l’accessibilità;
• temi di design accessibile, che presenta i due criteri generali sotto i quali possono essere raccolte tutte le raccomandazioni di accessibilità, cioè:
  • assicurare una trasformazione elegante dei contenuti;
  • rendere i contenuti comprensibili e navigabili;
• le tre priorità in cui sono suddivise le linee guida;
• i tre corrispondenti gradi di conformità raggiungibili;
• il nucleo vero e proprio del documento, cioè le 14 linee guida, suddivise in 65 punti punti di controllo;
• l’Appendice A, dedicata ai criteri per la verifica del grado di accessibilità raggiunto;
• l’Appendice B, contenente un glossario di termini di riferimento.

Completano la dotazione alcuni documenti accessori:

• Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 , la lista completa dei punti di controllo per la verifica della conformità alle WCAG 1.0, suddivisa in tre sezioni, ciascuna delle quali contiene i punti di controllo relativi a una sola delle tre priorità;
• Techniques for Web Content Accessibility Guidelines 1.0 , un elenco di tecniche di sviluppo, pubblicato come Nota W3C del 6 novembre 2000, che contiene una serie di esempi di applicazione dei sessantacinque punti di controllo racchiusi nelle WCAG 1.0. La Nota è suddivisa in tre parti:
  • Core Techniques for Web Content Accessibility Guidelines 1.0 (“Tecniche di base per le WCAG 1.0”), che contiene alcune tecniche fondamentali per l’accessibilità – quali la separazione della presentazione dai contenuti e l’uso degli equivalenti – che sono indipendenti dalla tecnologia. Possono cioè essere applicate a qualsiasi contenuto web, indipendentemente da quale sia il linguaggio con cui è codificato il documento;
  • HTML Techniques for Web Content Accessibility Guidelines 1.0 (“Tecniche HTML per le WCAG 1.0”), http://www.w3.org/TR/WCAG10-HTML-TECHS/, che contiene una serie di tecniche per sviluppare contenuti HTML accessibili;
  • CSS Techniques for Web Content Accessibility Guidelines 1.0 (“Tecniche CSS per le WCAG 1.0”), dedicato alle tecniche per un uso accessibile dei fogli di stile CSS.
• Techniques for Accessibility Evaluation and Repair Tools , una bozza del 26 aprile 2000, che contiene, oltre a informazioni sulla valutazione della conformità alle linee guida, anche indicazioni tecniche su come modificare documenti HTML non conformi alle WCAG 1.0, in modo da renderli conformi.

Inizio pagina

I due metodi dello sviluppo accessibile

Nel Capitolo 1 sono stati già elencati beneficiari e destinatari delle WCAG 1.0 (“L’accessibilità secondo le WCAG 1.0”): non è il caso di ritornarvi sopra. Possiamo cominciare dunque la nostra esposizione partendo dai due metodi generali dello sviluppo accessibile: 1) assicurare una trasformazione elegante dei contenuti; 2) rendere i contenuti comprensibili e navigabili. Questi due metodi sono la base teorica a cui si ispirano tutte le quattordici raccomandazioni delle WCAG 1.0.

Assicurare una trasformazione elegante dei contenuti

È il criterio di riferimento delle linee guida dalla 1 alla 11. Per “trasformazione elegante” – graceful transformation, in inglese – s’intende l’adattabilità di un contenuto, ottenibile eventualmente per mezzo di equivalenti, alle più diverse modalità di fruizione. Ricomprende in sostanza i concetti di indipendenza dal dispositivo, flessibilità e scalabilità, introdotti alla fine del capitolo precedente.

Una tabella inaccessibile, per esempio, è dipendente dal dispositivo, non flessibile, non scalabile: potrà essere consultata solo attraverso un browser grafico, e magari solo su schermi ad alta risoluzione. Per renderla accessibile bisogna modificarla in modo da consentirne una trasformazione elegante. Per esempio:

• inserendo marcatori che mettano in relazione le celle di dati con quelle d’intestazione, affinché uno screen reader possa leggere questa relazione all’ascoltatore; oppure
• fornendo una versione linearizzata della tabella, cioè un suo equivalente, in modo che i contenuti possano essere letti serialmente senza perdita d’informazione;
• usando unità di misura relative e proporzionali, in modo che le celle possano allargarsi o restringersi a seconda della larghezza della finestra disponibile, limitando al massimo la comparsa della barra di scorrimento orizzontale.

Assicurare una trasformazione elegante dei contenuti vuol dire, ancora, evitare di vincolare l’interazione con l’utente all’uso di un unico dispositivo di input e di un unico dispositivo di output (per esempio, il mouse e il monitor). Vuol dire, inoltre, separare tra loro contenuto, presentazione e struttura del documento, affinché la presentazione possa essere convenientemente adattata ai diversi dispositivi utilizzabili per la navigazione.

Rendere i contenuti comprensibili e navigabili

È il criterio di riferimento delle linee guida 12, 13 e 14. La comprensibilità si può raggiungere (o migliorare) mantenendo i contenuti semplici e chiari, relativamente all’argomento trattato. La navigabilità ha a che fare invece con il fornire all’utente strumenti di orientamento e meccanismi per velocizzare la ricerca delle informazioni: mappe del sito, sistemi per saltare gruppi di link, strumenti di ricerca semplice e avanzata, menu di navigazione ben organizzati e coerenti.

Inizio pagina

Le tre priorità

I sessantacinque punti di controllo in cui sono suddivise le quattordici linee guida sono raggruppabili anche in base al livello di priorità a cui appartengono. Le priorità sono tre e identificano tre successivi gradi di accessibilità, che vanno dal fondamentale (priorità 1) al facoltativo (priorità 3).

Ciascuna priorità è legata all’uso di una diversa parola chiave, che descrive l’importanza di applicare la raccomandazione di accessibilità a cui è associata. Le tre parole chiave sono must (“deve”), should (“dovrebbe”) e may (“può”), riferite rispettivamente alle priorità 1, 2 e 3. Di seguito riportiamo in traduzione italiana la descrizione del significato di ciascuna priorità, così come appare nella quarta sezione delle WCAG 1.0, intitolata appunto Priorities.

Priorità 1. Uno sviluppatore deve soddisfare questo punto di controllo. In caso contrario, uno o più gruppi troveranno impossibile accedere alle informazioni nel documento. Soddisfare questo punto di controllo è un requisito fondamentale per consentire ad alcuni gruppi di fruire dei documenti web.

Priorità 2. Uno sviluppatore dovrebbe soddisfare questo punto di controllo. In caso contrario, uno o più gruppi troveranno difficile accedere alle informazioni nel documento. Soddisfare questo punto di controllo rimuoverà significative barriere all’accesso dei documenti web.

Priorità 3. Uno sviluppatore può soddisfare questo punto di controllo. In caso contrario, uno o più gruppi incontreranno qualche difficoltà ad accedere alle informazioni nel documento. Soddisfare questo punto di controllo migliorerà l’accesso ai documenti web.

La ripartizione dei punti di controllo in tre diversi livelli di priorità ha fatto sorgere nel corso degli anni una serie di dispute tra i sostenitori del modello di classificazione adottato dalle WCAG 1.0, da un lato, e i suoi critici, dall’altro. Secondo alcuni, infatti, tale modello sarebbe artificioso, non essendovi ragioni evidenti, tratte dall’esperienza, che obblighino a definire tre diversi gradi di accessibilità. Vi è, poi, chi ha sostenuto che le raccomandazioni di priorità 3 sarebbero di fatto inapplicabili, perché troppo onerose e troppo dipendenti da valutazioni soggettive.

Comunque si valuti il criterio delle priorità, la suddivisione dei punti di controllo in tre livelli è un dato di fatto e chi sviluppa siti accessibili conformi alle WCAG 1.0 deve tenerne conto. In particolare, dei sessantacinque punti di controllo complessivi in cui sono suddivise le WCAG 1.0:

• sedici sono di priorità 1;
• ventinove sono di priorità 2;
• diciotto sono di priorità 3;
• due sono di priorità mista: il punto di controllo 2.2, che può essere a seconda dei casi di priorità 2 o di priorità 3, e il punto di controllo 8.1, che può essere di priorità 1 o di priorità 2.

In virtù di tale ripartizione, il minimo livello di accessibilità compatibile con l’applicazione delle WCAG 1.0 consiste nel realizzare documenti che soddisfino tutti i requisiti di priorità 1, purché applicabili (per esempio, il punto di controllo 12.1, che richiede di dare un titolo a ogni frame, non può essere applicato ai siti non organizzati a frame, nonostante abbia priorità 1).

Il massimo livello di conformità alle WCAG 1.0 implica, invece, la realizzazione di documenti che soddisfino tutti i punti di controllo, dalla priorità 1 alla 3 compresa, purché applicabili.

Inizio pagina

Introduzione alla lettura dei capitoli dal 4 al 19

I capitoli dal 4 al 19 compreso sono quelli centrali nell’economia di questo libro. Trattano i principi dello sviluppo accessibile, seguendo l’ordine di suddivisione delle WCAG 1.0 in raccomandazioni e punti di controllo.

Ogni capitolo è dedicato a una diversa raccomandazione, con l’eccezione della linea guida 8, alla quale, per la complessità dell’argomento (la diretta accessibilità delle interfacce utente incorporate), sono dedicati tre capitoli: l’11, che tratta di JavaScript e AJAX, il 12, dedicato alle interfacce Flash, e il 13, dedicato all’accessibilità dei documenti in formato PDF. Ecco perché le linee guida sono quattordici, mentre i capitoli che le analizzano sono sedici.

Il titolo di ogni capitolo dal 4 al 19 corrisponde al testo di una raccomandazione delle WCAG 1.0, mentre il testo in evidenza posto immediatamente sotto il titolo corrisponde al sottotitolo della raccomandazione.

Ogni capitolo, inoltre, presenta il testo di tutti i punti di controllo dipendenti dalla raccomandazione a cui è dedicato; ogni punto di controllo è seguito, a sua volta, da un commento più o meno approfondito, in ragione della sua importanza per l’accessibilità. Fanno eccezione a questo schema i Capitoli 12 e 13, che costituiscono nel loro complesso una prosecuzione del commento al punto di controllo 8.1, presentato nel Capitolo 11.

I commenti contengono, laddove disponibili e appropriati, testi ed esempi tratti dai documenti di tecniche applicative associati alle WCAG 1.0 (si veda l’elenco nel paragrafo Organizzazione del documento, più sopra).

Lo scopo principale di questo libro non è, però, quello di fotografare i problemi e le soluzioni per l’accessibilità al tempo delle WCAG 1.0, bensì quello di presentare le tecniche più aggiornate ed efficaci, per risolvere i problemi di accessibilità sentiti come importanti al giorno d’oggi.

In virtù di questa esigenza, i commenti ai punti di controllo delle WCAG 1.0 non si dilungano oltre un necessario dovere d’informazione, quando si tratta di descrivere tecniche obsolete e ormai poco utilizzate (frame, uso dell’elemento NOSCRIPT, applet Java ecc.). Diventano, invece, lunghi e approfonditi, quando si tratta di descrivere argomenti non contemplati dalle WCAG, che sono diventati importanti per l’accessibilità solo in tempi più recenti (per esempio, il metodo del potenziamento progressivo); oppure quando si tratta di descrivere tecniche di sviluppo di importanza centrale, non solo per l’accessibilità ma per lo sviluppo di siti web in generale, come la separazione del contenuto dalla presentazione, l’implementazione di interfacce utente accessibili incorporate (Flash, PDF, AJAX), l’uso appropriato di XHTML e di XML.

Le WCAG 1.0 rappresentano perciò, in molti casi, solo uno spunto per allargare il discorso agli sviluppi più recenti della progettazione accessibile, il fil rouge che tiene insieme tutti gli argomenti.

Un’altra delle caratteristiche salienti dei capitoli successivi è il richiamo costante agli standard promossi dal W3C. Questo libro, infatti, non intende rivolgersi solo a coloro che desiderano informarsi sull’accessibilità, ma a chiunque sia interessato allo sviluppo di siti web conformi agli standard. A tal riguardo, crediamo che il Web sia ormai uscito da tempo dall’epoca pionieristica, e che ai professionisti di oggi e di domani serva acquisire una solida conoscenza dei linguaggi di marcatura, di presentazione e di programmazione, coinvolti a vario titolo nell’attività di progettazione di siti web.

Da questo punto di vista, le competenze per l’accessibilità non sono più un qualcosa di separato, da aggiungere successivamente a un bagaglio di conoscenze più essenziali, che servono per sviluppare siti web indifferenti all’accessibilità. La capacità di strutturare i contenuti, di separare la presentazione dal codice di marcatura, di aggiungere comportamenti dinamici senza impedire l’accesso a chi naviga con dispositivi obsoleti, la capacità di usare i numerosi linguaggi di marcatura basati su XML sono competenze che servono in generale a tutti i professionisti del Web, non solo a quelli direttamente coinvolti nella ricerca dell’accessibilità.

Speriamo, pertanto, che le informazioni presentate nei capitoli successivi possano essere utili a chiunque stia cercando un approccio organico, aggiornato e professionale alla progettazione di siti web.

Inizio pagina

Figure professionali coinvolte nello sviluppo accessibile

Il lettore troverà nei capitoli seguenti, sotto il testo di ogni punto di controllo, una didascalia che comincia con le parole “si rivolge a”, seguita dall’indicazione delle categorie professionali – tecnici del codice, grafici, autori ecc. – direttamente interessate all’applicazione di quel punto di controllo.

Fornendo una simile indicazione, segniamo una differenza netta rispetto alle WCAG 1.0, che affidano alla figura generica del “web developer” – lo sviluppatore di siti web – il compito di applicare tutte, indistintamente, le raccomandazioni contenute nel documento.

Noi riteniamo, invece, che occorra distinguere le figure professionali coinvolte nella progettazione di siti accessibili. Autori di contenuti, grafici, esperti di linguaggi di marcatura, programmatori di linguaggi lato server (ASP, PHP ecc.), programmatori di linguaggi lato client (JavaScript), gestori di database, esperti di architettura dell’informazione, usabilisti, tecnici dell’area multimediale: a ognuna di queste figure toccano – ed è giusto che tocchino – compiti differenti.

Chi si occupa per lavoro di scrivere codice HTML e CSS può non essere in grado di produrre anche una grafica accessibile; può non saper riconoscere nei testi i passaggi che richiedono cambi di lingua; può non sapere se il linguaggio usato sia davvero chiaro e semplice come richiede il punto di controllo 14.1. Per risolvere un così ampio spettro di problemi, com’è quello che interessa l’accessibilità, occorre collaborazione e coordinamento tra figure professionali differenti, ma occorre soprattutto che ognuno faccia – e gli si lasci fare – il proprio lavoro.

Per tale ragione, crediamo di aver reso un servizio utile ai lettori, indicando, per ogni punto di controllo, le figure professionali che, secondo la nostra esperienza, sarebbero più adatte ad applicarlo.

Ciò non esclude la possibilità di affidare la cura dell’accessibilità, in un progetto complesso, a un unico esperto, a cui tocchi il compito di dare agli altri professionisti le direttive per lo sviluppo accessibile dei contenuti, di coordinarne il lavoro e di controllarne i risultati. In ogni caso, sarà però compito del grafico, sia pure assistito dall’esperto di accessibilità, sviluppare una grafica accessibile; così come sarà compito del programmatore JavaScript sviluppare un menu dinamico accessibile anche da tastiera. Lo stesso vale per ogni altro compito specialistico, che richieda il possesso di una precisa professionalità.

Inizio pagina