Requisito 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 requisito.

Punto di controllo 3.1 (Priorità 2). Quando esiste un linguaggio di marcatura adatto, per veicolare informazione usare un marcatore piuttosto che le immagini

Le equazioni matematiche/scientifiche, i simboli e le note musicali in una pagina Web spesso vengono rappresentate con immagini. Un’equazione rappresentata sotto forma di immagine è di fatto inaccessibile, in quanto anche un’alternativa testuale non consentirà di comprenderne chiaramente il contenuto.

Alcuni gruppi di lavoro del W3C stanno definendo una serie di linguaggi di marcatura (tra cui il MathML <http://www.w3.org/Math/>) che consentono di creare le formule in modo semplice. Esistono diversi linguaggi di marcatura e diverse tecnologie che consentono di leggere questi valori. Utilizzando XML le formule sono di facile interpretazione sia per le tecnologie assistive che per le applicazioni matematiche. Un editor che consente di creare funzioni matematiche è Amaya del W3C. Per esempio, la seguente formula matematica potrà essere inserita in una pagina Web in MathML con il codice seguente:

formula matematica

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msubsup>
<mo>&int;</mo>
<mn>0</mn>
<mi>t</mi>
</msubsup>
<mfrac>
<mrow>
<mo>d</mo>
<mi>x</mi>
</mrow>
<mi>x</mi>
</mfrac>
</mrow>
</math>

Per visualizzare contenuti in MathML è comunque necessaria la presenza
di plug-in, disponibili per i browser più diffusi.

Per quanto riguarda la validazione della grammatica del linguaggio di marcatura MathML, è possibile utilizzare il W3C Markup Validator, che dal 2002 integra la possibilità di controllare anche questa grammatica formale. Maggiori informazioni sono disponibili nel sito del W3C dedicato alla matematica.

Punto di controllo 3.2 (Priorità 2). Creare documenti che rispettino le grammatiche formali.

Abbiamo già visto nelle motivazioni dell’applicazione del requisito come sia necessario rispettare la DTD dichiarata. Michele Diodati <http://www.diodati.org/> in un suo scritto ha spiegato chiaramente com’è composta una DTD e cosa significando quindi quelle sigle e quei riferimenti contenuti nell’elemento DocType. Prendiamo ad esempio il DocType di XHTML 1.0 Strict:

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

la DTD è composta dai seguenti valori:

  • TopElement: html. Il tipo di documento SGML.
  • Availability: PUBLIC. Dichiara se il tipo di documento referenziato è pubblico o meno (il valore alternativo è SYSTEM).
  • Formal public identifier: “-//W3C//DTD XHTML 1.0 Strict//EN”.
  • Registration: -. Indica se l’organizzazione che ha definito la DTD è registrata all’ISO o meno (il W3C non lo è). Il valore alternativo è +.
  • Organization: W3C. L’organizzazione che ha creato e mantiene la DTD.
  • Type: DTD. Specifica a cosa si riferisce la dichiarazione (una DTD, nel nostro caso).
  • Label: XHTML 1.0. Il nome descrittivo della DTD referenziata, che può contenere la versione del documento.
  • Definition: Strict. Il tipo di DTD, se ne esiste più di un tipo per il linguaggio referenziato.
  • Language: EN. La lingua in cui è scritta la DTD.
  • URI: “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”. L’indirizzo dove fisicamente risiede il documento referenziato.

L’URI indica un documento che contiene i riferimenti al corretto utilizzo degli elementi e degli attributi spiegati nella specifica: un uso non corretto di questi attributi, come ad esempio utilizzare l’elemento <b> per effettuare decorazioni grafiche tramite fogli di stile anzichè utilizzarlo per la definizione del grassetto per un testo, significa violazione del primo requisito. Inoltre il requisito richiede il rispetto anche della conformità dei fogli di stile che, come vedremo, è verificabile tramite l’applicazione CSS Validator del W3C.

Il primo requisito richiede di utilizzare, per i nuovi siti, la DTD Strict per HTML 4.01 oppure XHTML 1.0: questo comporta l’indisponibilità, per esempio, dell’attributo target per i collegamenti esterni. È possibile quindi utilizzare codice javascript conforme ai requisiti in modo da garantire l’apertura della nuova finestra informando allo stesso tempo l’utente di tale funzionalità (Requisito 19).

Una soluzione ottimale ottenibile tramite DOM Injection è la seguente:

<a href="destinazione.html" class="targetblank" title="Descrizione">Prova</a>

Utilizzando la funzione seguente e richiamandola all’interno della pagina web con un collegamento ad un documento Javascript, si otterrà a livello di DOM un risultato come il seguente:

<a href="destinazione.html" class="targetblank"
title="Descrizione (collegamento in nuova finestra)"
onclick="window.open(this.href); return false;"
onkeypress="window.open(this.href); return false;">Prova</a>

In questo modo si potrà quindi aprire la nuova finestra (e l’utente ne sarà informato) esclusivamente se Javascript è attivo, altrimenti l’utente potrà comunque accedere al contenuto nella stessa finestra. Lo script che consente tale funzionalità è riportato qui di seguito.

function TargetBlank() {
if(document.getElementsByTagName){
var msg = " (collegamento in nuova finestra)";
var links = document.getElementsByTagName("a");
for (i = 0; i < links.length; i++) {
var link = links[i];
if (link.className.indexOf("targetblank") != -1)
{
link.title += msg;
var fn = function () {
window.open(this.href); return false; }
link.onclick = link.onkeypress = fn;
}
}
}
}

Si tiene comunque a precisare che l’apertura di nuove finestre andrebbe evitata in quanto non consente di evitarne l’apertura ad un utente dotato di tecnologia assistiva. Inoltre oggi la maggior parte dei browser contiene delle funzionalità per impedire l’apertura di nuove finestre. Se un utente desidera aprire una pagina in una nuova finestra, esistono delle funzionalità idonee all’interno del browser: evitiamo quindi di limitare la libertà dell’utente obbligandolo ad azioni non gradite o non consentite dal browser utilizzato.

Punto di controllo 3.5 (Priorità 2). Usare elementi di intestazione per veicolare la struttura del documento e usarli in modo conforme alle specifiche

Una pagina Web può essere formata da brevi contenuti, ma può contenere anche testi molto articolati (per esempio, un bando di gara d’appalto, un comunicato stampa, ecc.) che per poter essere letti devono essere organizzati in modo da garantirne la leggibilità: come per i libri, anche sul Web servono titoli, sottotitoli, capitoli, sottocapitoli e così via. Gli elementi di titolazione (<h1><h6>) devono essere utilizzati in modo corretto per garantire una corretta visualizzazione e il rispetto della semantica dei contenuti. Alcuni programmi di navigazione utilizzano gli elementi di titolazione per ottimizzare la navigazione della pagina da parte degli utenti. Utilizzando gli elementi <hx> si garantirà maggiore accessibilità ai contenuti della pagina: tutte le pagine dovrebbero prevedere almeno un elemento <h1> e via via, a scalare di importanza, gli elementi <h2>, <h3> che forniscono all’utente la possibilità di individuare i paragrafi considerati importanti dall’autore dei contenuti. Da ciò si può chiaramente comprendere che è importante rispettare l’ordine di importanza dei titoli, in modo che un elemento <h2> segua un elemento <h1>, mentre un elemento <h3> deve seguire un elemento di tipo <h2>. È errato quindi saltare livelli, passando ad esempio da <h1> a <h3> senza evidenziare l’elemento <h2> e nella verifica del requisito vedremo come è possibile controllare il corretto utilizzo di tali elementi.

<h1>Titolo livello 1</h1>
<p>... testo di esempio ..... </p>
<h2>Titolo livello 2</h2>
<h3>Titolo livello 3</h3>
<p>... testo di esempio ..... </p>
<h2>Titolo livello 2</h2>
<p>... testo di esempio ..... </p>
<h3>Titolo livello 3</h3>
<p>... testo di esempio ..... </p>
<p>... testo di esempio ..... </p>
<h3>Titolo livello 3</h3>
<p>... testo di esempio ..... </p>
<h1>Titolo livello 1</h1>
<p>... testo di esempio ..... </p>

Va precisato inoltre che la titolazione deve avvenire in tutti i contesti (struttura pagina, contenuti, ecc.) ma soprattutto che può ripartire dall’elemento di titolazione principale <h1> per ogni contesto che sia racchiuso dentro un elemento di blocco con attributo “id” univoco.

Non bisogna mai utilizzare gli elementi di titolazione a puro scopo decorativo, come per ottenere un incremento nella dimensione del testo, poiché tale comportamento inibisce la comprensione della semantica del documento: l’utilizzo dei fogli di stile, anche in questo caso, è la miglior soluzione per definire le modifiche degli attributi grafici dei testi.

Per quanto riguarda invece le tecnologie assistive, i lettori dello schermo utilizzano gli elementi di titolazione per determinare la struttura del documento, e quindi la sua lettura corretta e la possibilità di muoversi agevolmente tra i contenuti: è chiaro quindi che i testi dei titoli di capitolo, settore o paragrafo dovranno essere chiari e comprensibili.

Punto di controllo 3.6 (Priorità 2). Marcare le liste ed elencare le voci della lista in modo appropriato

Gli elementi di lista <dl>, <ul> e <ol> devono essere utilizzati unicamente per la definizione delle liste e non devono essere utilizzati a scopo di formattazione, ad esempio per rientrare dei contenuti. Vediamo quindi di approfondire la conoscenza di tali elementi.

Un corretto utilizzo delle liste senza ordinamento (unordered list, con l’elemento <ul>) è rappresentato nell’esempio seguente:

<ul>
<li>Prima voce di lista</li>
<li>Seconda voce di lista</li>
<li>Terza voce di lista</li>
</ul>

Per modificare la formattazione delle liste, anche in questo caso ci si affiderà ai fogli di stile. Ad esempio tramite i fogli di stile è possibile modificare il classico pallino delle liste non ordinate per l’elemento <li> con una immagine personalizzata.

ul {
color: #036;
list-style: url(/immagini/pallino.gif) disc;
}

Come si noterà, nell’esempio proposto viene indicato anche il valore disc, che consente di visualizzare il classico pallino vuoto se l’immagine indicata dal parametro url non è disponibile.

Se le liste non sono definite in modo corretto oppure se si diramano troppo profondamente gli utenti non vedenti durante la navigazione possono perdere l’orientamento: è necessario pertanto che gli sviluppatori mettano a disposizione di tali utenti indicazioni riepilogative per la navigazione dei vari livelli di lista raggiunti.

Finché i CSS2 non saranno supportati in modo uniforme da tutti i programmi utente e sarà possibile ottimizzare la navigazione delle liste tramite CSS, gli sviluppatori dovrebbero considerare di aiutare gli utenti non vedenti fornendo delle “annotazioni”, per ricordare all’utente l’argomento principale dell’elenco che sta navigando. Usando i fogli di stile è possibile definire un attributo che renda invisibile questo testo agli utenti vedenti, mentre sarà letto agli utenti non vedenti dai lettori vocali. Il foglio di stile conterrà quindi una nuova opzione (suggerita da Gianluca Troiani <http://www.constile.org> nella lista CSSdesign):

.finelista {
width:0;
position:absolute;
height:0;
overflow:hidden;
top:-200em;
}

È inoltre possibile creare collegamenti che consentano di saltare gli elenchi contenenti collegamenti ipertestuali, tecnica analizzata nel Requisito 19.

Applicando la classe sopra riportata a un esempio di lista di tipo descrittivo, il codice di una pagina accessibile sarà simile al seguente.

<ul>
<li>Veneto:
<ul>
<li>Belluno</li>
<li>Padova</li>
<li>Rovigo</li>
<li>Venezia</li>
<li>Verona</li>
<li>Vicenza</li>
</ul>
<span class="finelista">(Fine Veneto)</span></li>
<li>Liguria:
<ul>
<li>Genova</li>
<li>Imperia</li>
<li>La Spezia</li>

<li>Savona</li>
</ul>
<span class="finelista">(Fine Liguria)</span></li>
</ul>

Se invece è necessario dare una certa importanza all’ordine degli elementi, sono disponibili le liste ordinate (ordered list, elemento <ol>):

<ol>
<li>Scaricare il modulo</li>
<li>Compilare il modulo in ogni sua parte</li>
<li>Inviare il modulo</li>
</ol>

Considerando che per le liste ordinate l’utilizzo degli attributi compact, start e type è stato deprecato, è possibile aggirare il problema usando CSS2, che permette di definire il formato di auto numerazione delle liste (1, 1.1, 1.1.1, ecc.).

ul {
counter-reset: item;
}
li {
display: block;
}
li:before
{
content: counters(item, ".");
counter-increment: item;
}

Questa specifica contenuta nella raccomandazione CSS 2.0 attualmente non risulta supportata dai browser, ad eccezione di Opera.

L’ultima tipologia di liste è formata dalle liste di definizione (definition list, elemento <dl>). Le liste di definizione sono formate da elementi contenenti il termine (definition term, ovvero l’elemento <dt>) e la sua descrizione (definition description, ovvero l’elemento <dd>).

<dl>
<dt>SEO</dt>
<dd><span xml:lang="en">Search Engine Optimizers</span>,
ovvero gli esperti di posizionamento nei motori di
ricerca.</dd>
</dl>

Un’altra possibile applicazione delle liste di definizione, consentita dalla specifica HTML 4.x, è la possibilità di utilizzare tali elementi per riportare dei dialoghi, indicando con l’elemento <dt> il nome della persona e con l’elemento <dd> il testo del discorso. Un esempio pratico può essere un verbale di una seduta del Consiglio Comunale.

<dl>
<dt><abbr title="Consigliere">Cons.</abbr> Rossi</dt>
<dd>Signor Presidente, chiedo di poter esporre il progetto.<dd>
<dt>Presidente Consiglio Comunale</dt>
<dd>Ne ha facoltà.<dd>
</dl>

Utilizzando i fogli di stile sarà quindi possibile rappresentare i contenuti in modo gradevole, affiancando ad esempio l’elemento <dt> all’elemento <dd>.

Dopo aver analizzato le diverse tipologie di liste è quindi necessario fare delle considerazioni finali che coinvolgono tutte le diverse tipologie analizzate.

Si consiglia innanzitutto di evitare la creazione di lunghi elenchi con le liste, in quanto rendono il sito di difficile utilizzo e ne danneggiano l’usabilità, poiché un utente non riesce a memorizzare contemporaneamente tutti i collegamenti.

Per esempio, un sito istituzionale in cui siano presenti decine di collegamenti ipertestuali ad un gran numero di comunicati stampa o notizie può creare confusione agli utenti, che probabilmente preferirebbero poter consultare singole pagine di riepilogo (per data, per argomento, ecc.) oppure gradirebbero poter saltare tali elenchi utilizzando la navigazione delle intestazioni. Inoltre è necessario precisare che la creazione di menu utilizzando elementi differenti dalle liste (per esempio, utilizzando elementi specifici di tabelle) è un errore che porta alla violazione del primo requisito in quanto i menu sono di natura delle liste di elementi.

Punto di controllo 3.7 (Priorità 2). Marcare le citazioni

Le citazioni devono essere marcate utilizzando gli elementi <q> e <blockquote> che non devono essere usati per effetti estetici ma per fornire al browser e alle tecnologie assistive le informazioni necessarie per identificare il blocco di citazione, lasciando ai fogli di stile eventuali effetti di indentazione dei testi.

Elemento <q>

La rappresentazione delle virgolette tipografiche e dei relativi stili varia da lingua a lingua. L’utilizzo dell’elemento <q> al posto del corrispondente carattere ASCII o dell’entità &quot; consente al browser di visualizzare le virgolette secondo la codifica attiva sul computer in uso.

<q lang="en">What a wonderful web!</q>

Nota: l’elemento <q> non risulta completamente supportato dai browser ed in ogni caso per ottenere una corretta interpretazione delle virgolette richiede la presenza dell’attributo lang e/o xml:lang.

Elemento <blockquote>

L’elemento <blockquote> è utilizzato per identificare un blocco di testo di citazione che richiede maggior visibilità, per separarlo e distinguerlo dal corpo del testo normale.

<blockquote xml:lang="en"
cite="http://www.w3.org/TR/WCAG10-HTML-TECHS/">
<p>
Do not use quotation markup for formatting
effects such as indentation. [Priority 2]
</p>
</blockquote>

È da notare che nell’esempio viene utilizzato l’attributo “cite”, che riporta l’URI del documento origine della citazione e che è utilizzabile anche per l’elemento <q>. L’attributo cite può essere utilizzato per identificare anche un URN (Uniform Resource Name) per marcare citazioni che non sono direttamente riferite al web quale per esempio il codice ISBN di un libro.

<blockquote cite="urn:isbn:88-7633-000-3">
<p>
Al termine della lettura di questo libro si auspica che
al lettore sia maggiormente comprensibile la necessità
di puntare sull'accessibilità reale, rispettando
le raccomandazioni internazionali senza abusare di loghi
o bollini.
</p>
</blockquote>

Un ulteriore esempio è la citazione di RFC (Request for Comments): nell’esempio che segue è citato del testo dalla RFC 2141 emanata dall’IETF.

<blockquote xml:lang="en" cite="urn:ietf:rfc:2141">
<p>
Assignment of URNs from this namespace occurs in three ways.
The first is through publication of a new RFC, FYI, STD or BCP
is by the RFC Editor. This new document will have a new series
number and will therefore define a new URN.
</p>
</blockquote>

Molti sviluppatori però utilizzano l’elemento <blockquote> per impaginare i contenuti anziché creare uno stile di paragrafo per l’indentazione del testo. Se si desidera solamente ottenere degli effetti grafici simili a quelli generati dall’elemento <blockquote>, in questo caso utilizzando i fogli di stile è possibile definire delle personalizzazioni nella visualizzazione dei paragrafi per l’elemento <p>:

p.rientro { margin-left: 10%; margin-right: 10%;}

mentre nel codice HTML sarà sufficiente richiamare la classe:

<p class="rientro">Questo testo è rientrato in quanto...</p>

È chiaro quindi che la differenza tra le due soluzioni è semantica: l’elemento <blockquote> deve essere utilizzato solamente per la funzionalità assegnatagli (citazioni), mentre per ottenere effetti grafici similari è necessario evitare l’uso di <blockquote> ricorrendo a paragrafi correttamente formattati tramite fogli di stile.

Punto di controllo 11.1 (Priorità 2). Utilizzare le tecnologie W3C quando sono disponibili e sono appropriate per un certo compito usando le versioni più recenti quando sono supportate dai programmi utente.

I gruppi di lavoro che si occupano della creazione delle specifiche delle raccomandazioni del W3C tengono in considerazione l’attività del progetto WAI e quindi coinvolgono gli esperti di accessibilità per valutare di volta in volta come le nuove specifiche possano rispettare il principio di universalità del World Wide Web: è anche questo il motivo per cui le raccomandazioni del W3C sono universalmente riconosciute come standard de facto. È pur vero che con il rilascio di nuove specifiche i browser e le tecnologie assistive devono aggiornare i loro motori per rendere fruibili queste nuove caratteristiche, considerando che tutte le nuove specifiche mirano a mantenere una compatibilità con le precedenti. Può quindi succedere che attributi come longdesc per le immagini non vengano riconosciuti e ignorati da alcuni browser e/o tecnologie assistive ma questo non significa che per una tecnologia che non lo utilizza non ve ne siano altre che rispettano le raccomandazioni del W3C. Un altro problema che si è riscontrato è relativo al mancato supporto dell’elemento <object> da parte di Microsoft Internet Explorer e da Netscape che causa problemi di accessibilità (per esempio per la creazione di mappe immagine lato client). I contenuti delle pagine Web devono quindi validare secondo le grammatiche formali utilizzando per esempio il W3C Markup Validator o il validatore di fogli di stile. È bene quindi cercare di mantenere le proprie pagine secondo le ultime specifiche del W3C: l’elenco completo e costantemente aggiornato è disponibili nella pagina W3C Technical Reports and Publications <http://www.w3.org/TR/>.

Alcune di queste specifiche sono le seguenti:

  • MathML per equazioni matematiche;
  • HTML, XHTML, XML per la struttura dei documenti;
  • RDF per i meta data;
  • SMIL per creare presentazioni multimediali;
  • CSS e XSL per la definizione dei fogli di stile;
  • PNG per la grafica.

Quali sono quindi i programmi utente (user agent) che supportano le raccomandazioni W3C, e in che modo? Non è facile rispondere alla domanda e neppure il W3C ci riesce nella pagina dedicata al supporto dei programmi utente alle linee guida WAI. Sul Web sono disponibili alcune risorse, come webstandards.org, che hanno la finalità di fornire informazioni sull’effettiva applicazione degli standard, mentre sul sito del W3C è presente una sezione di riferimento <http://www.w3.org/WAI/Resources/WAI-UA-Support> delle risorse che supportano le User Agent Acces-sibility Guidelines.

Punto di controllo 11.2 (Priorità 2). Evitare l’utilizzo di tecnologie disapprovate dal W3C.

Con la definizione di nuove raccomandazioni e con l’avvento di nuove tecnologie alcuni elementi e attributi possono essere eliminati a favore di nuove raccomandazioni che ne migliorano l’utilizzo. Un esempio concreto è dato dall’elemento <font> che è stato disapprovato (deprecated) dal W3C a favore dei fogli di stile che consentono di separare il contenuto dalla presentazione. Per lo stesso motivo, l’attributo “color” è stato deprecato, sempre a favore dell’utilizzo dei fogli di stile. Gli elementi e gli attributi disapprovati diventano quindi obsoleti e vengono solitamente mantenuti nelle grammatiche dei DOCTYPE di tipo Transitional (ossia grammatiche di transizione) mentre vengono rimossi nelle grammatiche dei DOCTYPE di tipo Strict: un ulteriore esempio è dato dall’elemento <center> e dall’attributo target per i collegamenti che in XHTML 1.0 Strict e XHTML 1.1 non è previsto dalla DTD e quindi non è utilizzabile, nemmeno utilizzando la cosiddetta DOM Injection che vedremo nel paragrafo dedicato alla verifica del requisito. Un interesse particolare va verso gli elementi <b> / <strong> e <i> / <em>. Entrambe le coppie di elementi si occupa rispettivamente di formattare il testo in grassetto e in corsivo ma il loro significato semantico è nettamente differente: gli elementi <strong> ed <em> servono per enfatizzare il contenuto (hanno quindi valore “logico”), mentre <b> ed <i> hanno uno scopo puramente decorativo, tenendo presente che entrambe le coppie di elementi sono disponibili anche nelle versioni più recenti di XHTML.

Elementi come <applet> ed <embed> sono stati sostituiti dall’elemento <object>, che consente di trasformare il contenuto in modo gradevole nel caso non sia presente l’oggetto richiesto ma il cui supporto però con alcuni browser e tecnologie assistive non è ancora ottimale. Per la massima accessibilità si consiglia quindi di utilizzare le grammatiche con DOCTYPE di tipo Strict. L’elenco degli elementi ed attributi utilizzabili <http://www.w3.org/TR/WCAG10-HTML-TECHS/#html-index> è disponibile direttamente nel sito del W3C, dove con asterisco sono indicati gli elementi e gli attributi disapprovati. Ma come possiamo ottenere gli effetti grafici e le impostazioni che utilizzavamo tramite l’elemento font tramite i fogli di stile ed allo stesso tempo garantire l’accessibilità della nostra pagina web? Invece di utilizzare elementi ed attributi disapprovati per controllare la presentazione dei documenti è possibile, per esempio, utilizzare le seguenti proprietà CSS:

  • font (solo CSS 2.x)
  • font-family
  • font-size
  • font-size-adjust (eliminata in CSS 2.1)
  • font-stretch (eliminata in CSS 2.1)
  • font-style
  • font-variant
  • font-weight
  • color
  • background-color

ecc.

È importante controllare sempre il contrasto tra il colore di sfondo ed il colore del testo (Requisito 6), consentire il ridimensionamento dei caratteri utilizzando unità di misura in em o in percentuale (Requisito 12) e definire sempre un tipo di carattere generico per consentire a chiunque di fruire del contenuto anche in mancanza di un particolare carattere prescelto dallo sviluppatore.

Potrebbero interessarti anche i seguenti articoli

  • Requisiti 15, 16, 17Requisiti 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; […]
  • Requisiti 4, 5, 6Requisiti 4, 5, 6 Requisito 4 Enunciato: Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato […]
  • 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 […]
  • Requisiti 7, 8, 9, 10Requisiti 7, 8, 9, 10 Requisito 7 Enunciato: Utilizzare mappe immagine sensibili di tipo lato client piuttosto che lato server, salvo il caso in cui le zone sensibili non possano essere […]
  • 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 […]
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