Directivas pro promover le accessibilitate del contento del
Web (1.0)
Recommendation del W3C de 5 de maio 1999
- Iste version:
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
- (texto simple, PostScript,
PDF,
fichiero gzip tar de HTML,
archivo zip de HTML)
- Ultime version:
- http://www.w3.org/TR/WAI-WEBCONTENT
- Version anterior:
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324
- Editores:
- Wendy Chisholm, Trace R & D
Center, University of Wisconsin -- Madison
Gregg Vanderheiden, Trace R &
D Center, University of Wisconsin -- Madison
Ian Jacobs, W3C
Copyright © 1999 W3C
(MIT,
INRIA, Keio),
tote le derectos reservate. Tote le regulas del W3C referente a responsabilitate,
marca
de fabrica, uso
de documentos e licentiamento
de software se applica a iste documento.
Iste directivas explica como crear contento
pro le Web accessibile a personas con incapacitate. Le directivas
es destinate a tote disveloppatores
de contento web (autores de paginas e creatores de sitos) e a disveloppatores
de instrumentos de creation.
Le objectivo principal de iste directivas es promover le accessibilitate. Totevia,
lor observantia va facilitar le accesso al Web pro tote le utilizatores,
independentemente del interprete
que illes utiliza (p.ex., navigator traditional, navigator vocal, telephono
mobile, computator personal pro automobiles, etc.) o del limitationes sub le
quales illes opera (p.ex., ambientes ruitose, cameras insufficiente- o excessivemente
illuminate, ambientes in le quales uno debe mantener le manos libere, etc.)
Additionalmente, le observantia de iste directivas va adjutar le personas a
trovar information in le Web plus rapidemente. Iste directivas non discoragia
le disveloppatores de contento a usar imagines, video, etc., mais plus tosto
illo explica como render le contento multimedial plus accessibile a un publico
plus vaste.
Isto es un documento de referentia pro principios de accessibilitate e ideas
de projecto. Alcunes del strategias discutite in iste documento tracta de topicos
de internationalization del Web e accesso mobile. Totevia, iste documento se
concentra super le accessibilitate e non tracta in profunditate le topicos affin
de altere Activitates del W3C. Pro major informationes, consulta le pagina
initial del Activitate del W3C pro Accesso Mobile e le pagina
initial del Activitate del W3C pro Internationalization.
Uno intende que iste documento sia durabile, consequentemente illo non forni
informationes specific super supporte de navigatores a differente technologias,
viste que tal information es subjecte a modificationes frequente. Totevia, tal
informationes pote esser trovate in le sito del Initiativa
pro le Accessibilitate del Web (Web Accessibility Initiative -- WAI)
(vide [WAI-UA-SUPPORT]).
Iste documento include un appendice que organiza tote le requisitos
per topico e prioritate. Le requsitos in le appendice ha un ligamine verso lor
definitiones in le presente documento. Le topicos identificate in le appendice
include imagines, multimedia, tabellas, quadros, formularios, e scripts. Le
appendice es disponibile in forma de un
tabella resumite o de un lista
simple.
Un documento separate, intitulate "Technicas relative al directivas pro
promover le accessibilitate del contento del Web (1.0)" ([TECHNIQUES]),
explica como implementar le requisitos definite in le presente documento. Le
documento de Technicas discute cata requisito in major detalios e forni exemplos
usante linguage de marcatores de hypertextos (Hypertext Markup Language -- HTML), folios de stilo in cascada (Cascading Style Sheets
-- CSS), linguage de integration
de multimedia synchronizate (Synchronized Multimedia Integration Language --
SMIL), e le
linguage de marcatores mathematic (Mathematical Markup Language -- MathML). Le documento de Technicas include equalmente
technicas pro le validation e test de documentos, e un indice de elementos e
attributos del HTML (e qual technicas usar con illos). Le documento de Technicas
ha essite concipite pro accompaniar le modificationes technologic e uno expecta
que illo sia actualizate plus frequentemente que le presente documento. Nota.
Non tote le navigatores o instrumentos multimedial pote supportar le characteristicas
descripte in le directivas. In particular, nove characteristicas de HTML 4.0
o CSS 1 o CSS 2 pote non esser supportate.
Le "Directivas pro promover le accessibilitate del contento del Web (1.0)"
es parte de un serie de directivas de accessibilitate publicate per le Initiativa
pro le Accessibilitate del Web. Le serie include equalmente "Directivas
pro promover le accessibilitate de interpretes" ([WAI-USERAGENT])
e "Directivas pro promover le accessibilitate del instrumentos de creation"
([WAI-AUTOOLS]).
Iste documento ha essite revidite per membros del W3C e altere interessatos
e ha essite indorsate per le Director como un Recommendation del W3C. Illo es
un documento stabile e pote esser usate como material de referentia o citate
como un referentia normative de altere documentos. Le rolo del W3C in facer
le Recommendation es attraher le attention al specification e promover su adoption.
Illo extende le functionalitate e le universalitate del Web.
Le version anglese de iste specification es le unic version normative. Totevia,
pro traductiones in altere linguas vide http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
Le lista de tote le errores cognite de iste documento es disponibile a http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA.
Pro favor, relata errores in iste documento a wai-wcag-editor@w3.org.
Un lista del actual Recommendationes del W3C e altere documentos technic es
disponibile a http://www.w3.org/TR.
Iste documento ha essite producite como parte del Initiativa
pro le Accessibilitate del Web del W3C. Le objectivo del Gruppo
de Travalio de directivas pro le contento del Web es discutite in le charta
del Gruppo de Travalio.
Le appendice con le lista de requisitos es disponibile in forma de un tabella
resumite o de un lista simple.
Pro aquelles qui non es familiarizate con le themas de accessibilitate pertinente
al projecto de paginas Web, considera que multe utilizatores pote operar in
contextos multo differente del tue:
- Illes pote non esser capace de vider, audir, mover se, o pote haber difficultate
in, o esser totalmente incapace de, processar alcun typos de information.
- Illes pote haber difficultate in leger o comprender textos.
- Illes pote non haber claviero o ratto, o esser incapace de usar los.
- Illes pote haber un schermo textual, un schermo de dimensiones reducite,
o un connexion lente con le Internet.
- Illes pote non parlar o comprender fluentemente le lingua in le qual le
documento es scripte.
- Illes pote trovar se in un situation in le qual lor oculos, aures, o manos
es occupate o impedite (p.ex., guidante al travalio, travaliante in un ambiente
ruitose, etc.)
- Illes pote haber un version anterior de un navigator, un navigator totalmente
differente, un navigator vocal, o un systema operative differente.
Le disveloppatores de contento debe considerar iste situationes differente
durante le projecto del paginas. Malgrado le multiplicitate del situationes
a considerar, cata puncto de projecto pro accessibilitate generalmente beneficia
varie gruppos de invaliditate simultaneemente e le communitate del Web como
un toto. Per exemplo, per medio del utilization del folios de stilo
pro controlar stilos de fonte e le elimination del elemento FONT, le autores
de HTML va haber major controlo super lor paginas, render le paginas plus accessibile
a personas con problemas visual e, per medio del co-utilization del folios de
stilo, illes va abbreviar le tempore de discarga del paginas pro tote le utilizatores.
Le directivas discute themas de accessibilitate e forni solutiones de projecto
pro accessibilitate. Illos abborda scenarios typic (similar al exemplo del stilo
de fonte) que pote causar problemas pro utilizatores con certe incapacitates.
Per exemplo, le prime directiva explica como le disveloppatores
de contento debe render le imagines accessibile. Alcun utilizatores pote esser
incapace de vider imagines, alteres pote usar navigatores textual que non supporta
imagines, durante que alteres pote haber disactivate le supporto a imagines
(p.ex., debite a un connexion lente con le Internet). Le directivas non suggere
evitar le imagines como un maniera de augmentar le accessibilitate. In vice,
illos explica que fornir un equivalente
textual del imagine va render lo plus accessibile.
Como un equivalente textual rende le imagine accessibile? Le duo parolas in
"equivalente textual" es importante:
- Contento textual pote esser convertite in voce synthetizate, presentate
in systema braille, o simplemente exhibite super le schermo. Cata un de iste
mechanismos usa un senso differente -- audito pro le voce synthetizate, tacto
pro le braille, e vision pro le texto -- rendente le information accessibile
a gruppos representante un varietate de incapacitates sensorial e de altere
naturas.
- Pro esser utile, le texto debe haber le mesme function o proposito del imagine.
Per exemplo, considera un equivalente textual pro un imagine photographic
del planeta Terra viste del spatio. Si le proposito del imagine es principalmente
decorative, le texto "Photographia del Terra viste del spatio" pote
complir le function necessari. Si le proposito del photographia es illustrar
un information specific super le geographia del mundo, le equivalente textual
deberea fornir aquelle information. Si le photographia ha essite designate
pro indicar al utilizator que ille debe selectionar le imagine (p.ex., cliccar
super illo) pro obtener information super le Terra, le equivalente textual
deberea esser "Information super le planeta Terra". Assi, si le
texto ha le mesme function o proposito pro le utilizator con incapacitate
que le imagine ha pro altere utilizatores, alora illo pote esser considerate
un equivalente textual.
Nota que, ultra beneficiar le utilizatores con incapacitates, le equivalentes
textual pote adjutar tote le utilizatores a trovar paginas plus rapidemente,
perque le robots de recerca pote usar le texto pro le indexation del paginas.
Durante que le fornimento de equivalentes textual pro le imagines e altere
contentos multimedial compete al disveloppatores de contento pro le Web, es
responsabilitate del interpretes
(p.ex., navigatores e technologias assistential como lectores
de schermo, monitores
braille, etc.) presentar le information al utilizator.
Equivalentes non-textual
de texto (p.ex., icones, voce pre-registrate, o un video de un persona traducente
le texto in le linguage del signos) pote render le documentos accessibile a
personas qui pote haber difficultate in accessar texto scripte, inclusive multe
individuos con incapacitates cognitive, incapacitates de apprender, e surditate.
Equivalentes non-textual del texto equalmente pote esser utile a personas qui
non lege. Un description
auditive es un exemplo de un equivalente non-textual de information
visual. Un description auditive de un fragmento visual de un presentation beneficia
personas qui non pote vider le information visual.
Le directivas se basa super duo principios general: assecurar un transformation
elegante, e render le contento comprensibile e navigabile.
Sequente iste directivas, disveloppatores de contento pote crear paginas que
se transforma de un maniera elegante. Paginas que se transforma de un maniera
elegante remane accessibile in despecto de qualcunque del limitationes descripte
in le introduction, inclusive incapacitates physic,
sensorial, e cognitive, limitationes imponite per le travalio, e barrieras technologic.
Ecce alcun punctos-clave pro le projecto de paginas que se transforma de maniera
elegante:
- Separar structura e presentation (vide le differentia inter contento,
structura, e presentation).
- Includer texto (incluse equivalentes
textual). Le texto pote esser reproducite in modalitates que es
disponibile a tote le dispositivos de navigation e accessibile a quasi tote
le utilizatores.
- Crear documentos que functiona mesmo si le utilizator non pote vider e/o
audir. Forni information que servi al mesme proposito o function que le audio
o le video in un maniera que equalmente sia adequate a canales sensorial alternative.
Isto non significa crear un version pre-registrate de audio de tote un sito
pro render lo accessibile al utilizatores qui es cec. Utilizatores cec pote
utilizar un lector
de schermo pro reproducer tote le information textual de un pagina.
- Crear documentos que non depende de un typo specific de equipamento. Le
paginas deberea esser usabile per personas sin ratto, con schermos de dimensiones
reducite, schermos de basse resolution, schermos in nigro-e-blanco, sin schermo,
solo con exito de voce o texto, etc.
Le principio del transformation elegante es tractate principalmente in le directivas
1 a 11.
Disveloppatores de contento deberea render le contento comprensibile e navigabile.
Isto implica non solmente utilizar un linguage clar e simple, mais equalmente
fornir mechanismos comprensibile de navigation intra un pagina e inter paginas.
Dotar le pagina de instrumentos de navigation e informationes de orientation
va maximizar le accessibilitate e le usabilitate. Non tote le utilizatores pote
servir se de indicationes visual como mappas de imagine, barras de rolamento
proportional, quadros adjacente, o graphicos que guida utilizatores de navigatores
graphic dotate de vision. Le utilizatores equalmente perde information contextual
quando illes solo pote vider un portion de un pagina, o perque illes accessa
le pagina un parola per vice (synthese vocal o
monitor braille), o un section per vice (schermo de dimensiones reducite,
o multo grande). Sin information de orientation, le utilizatores pote non esser
capace de comprender tabellas, listas o menus, per exemplo, que sia multo grande.
Le principio de render le contento comprensibile e navigabile es tractate principalmente
in le directivas 12 a 14.
Iste documento comprehende dece-quatro directivas,
o principios general de projecto pro accessibilitate. Cata directiva contine:
- Le numero del directiva.
- Le enunciato del directiva.
- Ligamines de navigation. Tres ligamines permitte le navigation al directiva
sequente (icone de flecha al dextra), le directiva precedente (icone de flecha
al sinistra), o le position del directiva actual in le indice (icone de flecha
al alto).
- Le logica detra le directiva e alcun gruppos de utilizatores destinate a
beneficiar se de illo.
- Un lista de definitiones de requisitos.
Le definitiones de requisitos in cata directiva
explica como le directiva se applica al scenarios typic de disveloppamento de
contento. Cata definition de requisito contine:
- Le numero del requisito.
- Le enunciato del requisito.
- Le prioritate del requisito. Le requisitos de prioritate 1 es evidentiate
per medio de folios de stilo.
- Optionalmente, notas informative, exemplos clarificatori, e referentias
cruciate a directivas o requisitos correlate.
- Un ligamine a un section del documento de Technicas ([TECHNIQUES])
in le qual uno discute implementationes e exemplos del requisito.
Uno intende que cata requisito sia sufficientemente specific, a fin que un
persona que examina un pagina o sito pote verificar si le requisito ha essite
satisfacte.
Le sequente conventiones editorial es usate in iste documento:
- Nomines de elementos es scripte in litteras majuscule.
- Nomines de attributos es scripte in litteras minuscule.
- Ligamines al definitiones es evidentiate per medio de folios de stilo.
Le Gruppo de Travalio ha assignate un nivello de prioritate a cata requisito,
basate super su impacto super le accessibilitate.
- [Prioritate 1]
- Le disveloppator de contento pro le Web debe satisfacer
iste requisito. In caso contrari, un o plus gruppos essera incapacitate de
accessar le informationes presente in le documento. Le satisfaction de iste
requisito es un requisito basic pro que alcun gruppos sia capace de usar documentos
del Web.
- [Prioritate 2]
- Le disveloppator de contento pro le Web deberea satisfacer
iste requisito. In caso contrari, un o plus gruppos va trovar difficultates
in accessar le informationes presente in le documento. Le satisfaction de
iste requisito elimina barrieras significative al accesso a documentos del
Web.
- [Prioritate 3]
- Le disveloppator de contento pro le Web pote considerar
iste requisito. In caso contrari, un o plus gruppos va sentir alcun difficultate
in accessar le informationes presente in le documento. Le satisfaction de
iste requisito meliora le accesso al documentos del Web.
Le nivello de prioritate de alcun requisito pote variar secundo certe conditiones
(indicate).
Iste section defini tres nivellos de conformitate con iste documento:
- Nivello de conformitate "A": tote le requisitos de prioritate
1 ha essite satisfacte;
- Nivello de conformitate "Duple-A": tote le requisitos de
prioritate 1 e 2 ha essite satisfacte;
- Nivello de conformitate "Triple-A": tote le requisitos
de prioritate 1, 2, e 3 ha essite satisfacite;
Nota. Le nivellos de conformitate es descripte textualmente
a fin que illos pote esser comprendite quando convertite in voce.
Le declarationes de conformitate a iste documento debe utilizar un del duo
sequente formas.
Forma 1: Specificar:
- Le titulo del directivas: "Directivas pro promover le accessibilitate del
contento del Web (1.0)"
- Le URI del directivas:
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
- Le nivello de conformitate attingite: "A", "Double-A", or "Triple-A".
- Le ambito del delcaration (p.ex., pagina, sito, o un portion definite de
un sito).
Exemplo del forma 1:
Iste pagina se conforma al "Directivas pro promover le accessibilitate del
contento del Web (1.0)" de W3C, disponibile a http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505,
nivello Duple-A.
Forma 2: Includer, in cata pagina que se declara conforme, un del tres icones
fornite per W3C e liga le icone al explication appropriate del conformitate
secundo le W3C. Informationes super le icones e como inserer los in paginas
es disponibile a [WCAG-ICONS].
Ben que alcun personas non pote usar imagines, films, sonos, applets, etc.
directemente, illes pote totevia usar paginas que contine information equivalente
al contento visual o auditive. Le information equivalente debe servir al mesme
proposito que le contento visual o auditive. Assi, un equivalente textual pro
un imagine de un flecha verso le alto que se liga a un indice debe esser "Ir
al indice". In alcun casos, le equivalente equalmente deberea describer le
apparentia del contento visual (p.ex., pro graphicos, pannellos o diagrammas
complexe) o le sono del contento auditive (p.ex., pro fragmentos de audio utilizate
pro fines educative).
Iste directiva emphatiza le importantia de fornir equivalentes
textual de contento non textual (imagines, audio pre-registrate,
video). Le potentialitate del equivalentes textual reside in lor capacitate
de esser convertite in manieras que es disponibile a personas de varie gruppos
de incapacitate, usante varie technologias. Le texto pote esser promptemente
reproducite per synthetizatores vocal e monitores
braille, e pote esser presentate visualmente (in varie dimensiones)
super le schermos de computatores e papiro. Le voce synthetizate es essential
pro cecos e pro multe personas con difficultates de lectura que frequentemente
accompania incapacitates cognitive, de apprendimento, e surditate. Le systema
braille es essential pro surdos-cecos e pro multe individuos cuje unic incapacitate
sensorial es le cecitate. Le texto exhibite visualmente beneficia utilizatores
qui es surde, e equalmente le majoritate del utilizatores del Web.
Fornir equivalentes non textual (p.ex., imagines, videos, e audio pre-registrate)
de texto es equalmente benefic pro alcun utilizatores, specialmente analphabetos
o personas qui ha difficultate de lectura. In films o presentationes visual,
le action visual como le linguage corporal o altere indicios visual pote non
esser accompaniate per information auditive sufficiente pro codificar le mesme
information. A minus que descriptiones verbal de iste information visual es
fornite, personas qui non pote vider (o reguardar) le contento visual non sera
capace de perciper lo.
- 1.1
Fornir un equivalente textual pro cata elemento non textual (p.ex., per medio
de "alt", "longdesc", o in le contento del elemento).
Isto include: imagines, representationes graphic de texto (incluse
symbolos), regiones de mappas de imagine, animationes (p.ex., GIFs animate),
applets and objectos programmate, arte ASCII,
quadros, scripts, imagines usate como marcatores de listas, spatiatores, buttones
graphic, sonos (actionate con o sin interaction del utilizator), files de
audio autonome, pistas de audio de video, e video. [Prioritate 1]
- Per exemplo, in HTML:
- Usar "alt" pro le elementos IMG, INPUT, e APPLET, o fornir un equivalente
textual in the contento del elementos OBJECT e APPLET.
- Pro contentos complexe (p.ex., un diagramma) in que le texto "alt" non
forni un equivalente textual complete, fornir un description additional
usante, per exemplo, "longdesc" con IMG o FRAME, un ligamine intra un
elemento OBJECT, o un ligamine descriptive.
- Pro mappas de imagine, usar le attributo "alt" con AREA, o usar le elemento
MAP con elementos A (e altere texto) como contento.
Consulta equalmente le requisito
9.1 e le requisito 13.10.
- Technicas
pro le requisito 1.1
- 1.2
Fornir ligamines textual redundante pro cata region active de un mappa de
imagine al latere del servitor. [Prioritate 1]
- Consulta equalmente le requisito
1.5 e le requisito 9.1.
- Technicas
pro le requisito 1.2
- 1.3
Usque a quando le interpretes
potera leger automaticamente in alte voce le equivalento textual de un pista
visual, fornir un description auditive del information importante del pista
visual de un presentation multimedial. [Prioritate 1]
- Synchronizar le description
auditive con le pista de audio conforme le requisito
1.4. Consulta le requisito
1.1 pro obtener information super equivalentes textual pro information
visual.
- Technicas
pro le requisito 1.3
- 1.4
Pro qualcunque presentation multimedial temporizate (p.ex., un film o animation),
synchronizar le alternativas equivalente (p.ex., legendas o descriptiones
auditive del pista visual) con le presentation. [Prioritate 1]
- Technicas
pro le requisito 1.4
- 1.5
Usque a quando le interpretes
exhibira equivalentes textual pro ligamines de mappa de imagine al latere
del cliente, fornir ligamines textual redundante pro cata region active de
un mappa de imagine al latere del cliente. [Prioritate 3]
- Consulta equalmente le requisito
1.2 e le requisito 9.1.
- Technicas
pro le requisito 1.5
Si solmente le color es usate pro codificar information, personas qui non pote
distinguer certe colores e utilizatores con dispositivos que ha interfacies
monochromatic o non visual non recipera le information. Quando le colores frontal
e de fundo es excessivemente proxime al mesme tono, illos pote non fornir contrasto
sufficiente quando visualizate per medio de monitores monochromatic o per personas
con differente typos de incapacitates visual.
- 2.1
Assecurar que tote le information transmittite con color es equalmente disponibile
sin color, per exemplo per medio del contexto o marcation. [Prioritate 1]
- Technicas
pro le requisito 2.1
- 2.2
Assecurar que le combinationes de color frontal e de fundo forni contrasto
sufficiente quando visualizate per un persona con incapacitate visual o quando
visualizate in un monitor nigro-e-blanc. [Prioritate 2 pro imagines,
Prioritate 3 pro texto].
- Technicas
pro le requisito 2.2
Utilizar marcatores inadequatemente -- non conforme al specification -- obstrue
le accessibilitate. Utilizar incorrectemente marcatores pro producer effectos
de presentation (p.ex., usar un tabella pro structurar le disposition del pagina
o un titulo pro cambiar le dimension del fonte) rende difficile que utilizatores
con software specializate comprende le organization del pagina o naviga per
illo. Additionalmente, utilizar marcatores de presentation in vice de marcatores
structural pro codificar le structura (p.ex., construer un cosa que resimila
un tabella de datos con un elemento PRE del HTML) rende difficile converter
un pagina intelligibilemente a altere dispositivos (consulta le description
del
differentia entre contento, structura, e presentation).
Disveloppatores de contento pote esser tentate a usar (incorrectemente) constructos
que produce un effecto de formatation desirate in navigatores plus antique.
Illes debe esser consciente que iste practicas causa problemas de accessibilitate
e debe consider si le effecto de formatation es tanto critic a puncto de justificar
render le documento inaccessibile a alcun utilizatores.
Al altere extremo, le disveloppatores de contento non debe sacrificar marcatores
appropriate perque un certe navigator o technologia assistential non lo processa
correctemente. Per exemplo, es appropriate utilizar le elemento TABLE in HTML
pro marcar information
tabular mesmo si alcun lectores de schermo plus antique non pote
tractar texto juxtaposite correctemente (consulta le requisito
10.3). Utilizar TABLE correctemente e crear tabellas que se transforma de
maniera elegante (consulta le directiva
5) rende possibile que le software representa le tabellas de manieras differente
del reticulato bidimensional.
- 3.1
Quando existe un linguage de marcatores appropriate, utilizar marcatores in
vice de imagines pro codificar le information. [Prioritate 2]
- Per exemplo, usar MathML pro codificar equationes mathematic,
e Folios
de stilo pro formatar texto e controlar le disposition. Additionalmente,
evitar utilizar imagines pro representar texto -- usar texto e folios de stilo
in vice. Consulta equalmente le directiva
6 e le directiva 11.
- Technicas
pro le requisito 3.1
- 3.2
Crear documentos es valide secundo grammaticas formal publicate. [Prioritate 2]
- Per exemplo, include un declaration de typo de documento
al initio de un documento que se refere a un DTD
publicate (p.ex., le DTD de HTML 4.0 stricte).
- Technicas
pro le requisito 3.2
- 3.3
Utilizar folios de stilo pro controlar disposition e presentation. [Prioritate 2]
- Per exemplo, utilizar le proprietate 'font' de CSS in
vice del elemento FONTE de HTML pro controlar stilos de fonte.
- Technicas
pro le requisito 3.3
- 3.4
Utilizar unitates relative in vice de absolute in valores de attributo de
linguages de marcatores e valores de proprietate de folios de stilo. [Prioritate 2]
- Per exemplo, in CSS, utilizar 'em' o longitudes percentual
in vice de 'pt' o 'cm', que es unitates absolute. Si le unitates absolute
es utilizate, valida que le contento presentate es usabile (consulta le section
super validation).
- Technicas
pro le requisito 3.4
- 3.5
Utilizar elementos de titulo pro codificar le structura del documento e utilizar
los de accordo con le specification. [Prioritate 2]
- Per exemplo, in HTML, utilizar H2 pro indicar un subsection
de H1. Non utilizar titulos pro effects de fonte.
- Technicas pro le requisito 3.5
- 3.6
Codificar listas e articulos de lista adequatemente. [Prioritate 2]
- Per exemplo, in HTML, annidar listas OL, UL, e DL adequatemente.
- Technicas pro le requisito 3.6
- 3.7
Codificar citationes. Non utilizar marcatores de citation pro formatar effectos
tal como indentation. [Prioritate 2]
- Per exemplo, in HTML, utilizar le elementos Q e BLOCKQUOTE
pro codificar citationes breve e longe, respectivemente.
- Technicas pro le requisito 3.7
Quando le disveloppatores de contento codifica cambios de lingua natural in
un documento, synthetizatores de voce e dispositivos braille pote adaptar se
automaticamente al nove lingua, rendente le documento plus accessibile a utilizatores
multilingue. Le disveloppatores de contento deberea identificar le lingua
natural predomindante del contento de un documento (per medio de
marcatores o titulos HTTP).
Le disveloppatores de contento deberea equalmente fornir expansiones de abbreviationes
and acronymos.
In addition a auxiliar le technologias assistential, le marcatores de lingua
natural permitte que le mechanismos de recerca trova parolas-clave e identifica
documentos in un lingua desirate. Le marcatores del lingua natural meliora equalmente
le legibilitate del Web pro tote le personas, includente aquelles con incapacitates
de apprendimento o cognitive, e le surdos.
Quando abbreviationes e cambios de lingua natural non es identificate, illos
pote esser indecifrabile quando pronunciate mechanicamente o transformate in
braille.
- 4.1
Identificar clarmente cambios in le lingua natural del texto e qualcunque
text
equivalents (p.ex., legendas) de un documento. [Prioritate 1]
- Per exemplo, in HTML utilizar le attributo "lang". In
XML, utilizar "xml:lang".
- Technicas
pro le requisito 4.1
- 4.2
Specificar le expansion de cata abbreviation o acronymo in un documento in
le momento de su prime occurrentia. [Prioritate 3]
- Per exemplo, in HTML, utilizar le attributo "title" del
elementos ABBR e ACRONYM. Fornir le expansion in le corpore principal del
documento equalmente auxilia le usabilitate del documento.
- Technicas
pro le requisito 4.2
- 4.3
Identificar le lingua natural primari del documento. [Prioritate 3]
- Per exemplo, in HTML definir le attributo "lang" del
elemento HTML. In XML, utilizar "xml:lang". Operatores de servitor deberea
configurar le servitores pro beneficiar se de mechanismos de negotiation de
contento HTTP ([RFC2068], section 14.13) de maniera
que le clientes pote automaticamente recuperar documentos in le lingua preferite.
- Technicas
pro le requisito 4.3
Le tabellas deberea esser usate pro codificar
information tabular de facto ("tabellas de datos"). Disveloppatores
de contento deberea evitar utilizar los pro structurar le disposition del paginas
("tabellas de disposition"). Tabellas de qualcunque proposito additionalmente
presenta problemas special pro utilizatores de lectores
de schermo (consulta le requisito
10.3).
Alcun interpretes
permitte que le utilizatores naviga inter le cellulas del tabella e accessa
le titulos e altere informationes del cellulas. Excepte si illos es codificate
adequatemente, iste tabellas non fornira le information appropriate al interpretes.
(Consulta equalmente le directiva
3.)
Le directivas sequente beneficiara directemente personas qui accessa un tabella
per medios auditive (p.ex., un lector de schermo o un computator personal installate
in un automobile) o qui visualiza solo un portion del pagina a cata momento
(p.ex., utilizatores con cecitate o vision basse utilizante un synthetizator
de voce o un monitor
braille, o altere utilizatores de dispositivos con schermos de dimensiones
reducite, etc.).
- 5.1
Pro tabellas de datos, identificar titulos de linea e columna. [Prioritate 1]
- Per exemplo, in HTML, utilizar TD pro identificar cellulas
de datos e TH pro identificar titulos.
- Technicas pro le requisito 5.1
- 5.2
Pro tabellas de datos que ha duo o plus nivellos logic de titulos de linea
o columna, utilizar marcatores pro associar cellulas de datos e cellulas de
titulo. [Prioritate 1]
- Per exemplo, in HTML, utilizar THEAD, TFOOT, e TBODY
pro aggruppar lineas, COL e COLGROUP pro aggruppar columnas, e le attributos
"axis", "scope", e "headers" pro describer relationes plu complexe inter le
datos.
- Technicas pro le requisito 5.2
- 5.3
Non utilizar tabellas pro structurar le disposition del paginas, excepte si
le tabella remane significative quando linearizate. De altere modo, si le
tabella non remane significative, fornir un equivalente alternative (que pote
esser un
version linearizate). [Prioritate 2]
- Nota. Un
vice que le interpretes supporta positionamento per medio de folio
de stilo, le tabellas non deberea esser utilizate pro structurar disposition.
Consulta equalmente le requisito
3.3.
- Technicas
pro le requisito 5.3
- 5.4
Si un tabella es utilizate pro structurar disposition, non utilizar marcatores
structural pro le proposito de formatation visual. [Prioritate 2]
- Per exemplo, in HTML non utilizar le elemento TH pro
exhibir un cellula (non-titulo) centralizate e in nigretto.
- Technicas
pro le requisito 5.4
- 5.5
Fornir summarios pro tabellas. [Prioritate 3]
- Per exemplo, in HTML, utilizar le attributo "summary"
del elemento TABLE.
- Technicas
pro le requisito 5.5
- 5.6
Fornir abbreviationes pro etiquettas de titulo de tabella. [Prioritate 3]
- Per exemplo, in HTML, utilizar le attributo "abbr" in
le elemento TH.
- Technicas
pro le requisito 5.6
Consulta equalmente le requisito
10.3.
Malgrado que le disveloppatores de contento es stimulate a utilizar nove technologias
que resolve problemas surgite per technologias existente, illes deberea saper
como facer lor paginas functionar con navigatores plus antique e personas qui
opta pro inactivar functionalitates.
- 6.1
Organizar le documentos de maniera que illos pote esser legite sin le folios
de stilo. Per exemplo, quando un documento HTML es presentate sin le folios
de stilo associate, il debe ancora esser possibile leger le documento. [Prioritate 1]
- Quando le contento es organizate logicamente, illo sera
presentate in un ordine significative quando le folios de stilo es inactive
o non es supportate.
- Technicas
pro le requisito 6.1
- 6.2
Assecurar que le equivalentes pro contento dynamic es actualizate quando le
contento dynamic cambia. [Prioritate 1]
- Technicas
pro le requisito 6.2
- 6.3
Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide
equivalent information on an alternative accessible page. [Priority 1]
- Per exemplo, ensure that links that trigger scripts
work when scripts are turned off or not supported (p.ex., do not use "javascript:"
as the link target). If it is not possible to make the page usable without
scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side
script instead of a client-side script, or provide an alternative accessible
page as per checkpoint 11.4.
Refer also to guideline 1.
- Technicas pro le requisito 6.3
- 6.4
For scripts and applets, ensure that event handlers are input device-independent.
[Priority 2]
- Refer to the definition of
device independence.
- Technicas pro le requisito 6.4
- 6.5
Ensure that dynamic content is accessible or provide an alternative presentation
or page. [Priority 2]
- Per exemplo, in HTML, use NOFRAMES at the end of each
frameset. For some applications, server-side scripts may be more accessible
than client-side scripts.
- Technicas pro le requisito 6.5
Refer also to checkpoint 11.4.
Some people with cognitive or visual disabilities are unable to read moving
text quickly enough or at all. Movement can also cause such a distraction that
the rest of the page becomes unreadable for people with cognitive disabilities.
Screen
readers are unable to read moving text. People with physical disabilities
might not be able to move quickly or accurately enough to interact with moving
objects.
Note. All of the following checkpoints involve some content
developer responsibility until
user agents provide adequate feature control mechanisms.
- 7.1
Until
user agents allow users to control flickering, avoid causing the
screen to flicker. [Priority 1]
- Note. People with photosensitive epilepsy can have seizures
triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz)
range with a peak sensitivity at 20 flashes per second as well as quick changes
from dark to light (like strobe lights).
- Technicas pro le requisito 7.1
- 7.2
Until
user agents allow users to control blinking, avoid causing content
to blink (i.e., change presentation at a regular rate, such as turning on
and off). [Priority 2]
- Technicas pro le requisito 7.2
- 7.3
Until
user agents allow users to freeze moving content, avoid movement
in pages. [Priority 2]
- When a page includes moving content, provide a mechanism
within a script or applet to allow users to freeze motion or updates. Using
style sheets with scripting to create movement allows users to turn off or
override the effect more easily. Refer
also to guideline 8.
- Technicas pro le requisito 7.3
- 7.4
Until
user agents provide the ability to stop the refresh, do not create
periodically auto-refreshing pages. [Priority 2]
- Per exemplo, in HTML, don't cause pages to auto-refresh
with "HTTP-EQUIV=refresh" until user agents allow users to turn off the feature.
- Technicas pro le requisito 7.4
- 7.5
Until
user agents provide the ability to stop auto-redirect, do not use
markup to redirect pages automatically. Instead, configure the server to perform
redirects. [Priority 2]
- Technicas pro le requisito 7.5
Note. The BLINK and MARQUEE elements are not defined in any
W3C HTML specification and should not be used. Refer
also to guideline 11.
When an embedded object has its "own interface", the interface -- like the
interface to the browser itself -- must be accessible. If the interface of the
embedded object cannot be made accessible, an alternative accessible solution
must be provided.
Note. For information about accessible interfaces, please
consult the User Agent Accessibility Guidelines ([WAI-USERAGENT]) and the Authoring Tool Accessibility
Guidelines ([WAI-AUTOOL]).
- 8.1
Make programmatic elements such as scripts and applets directly accessible
or compatible with assistive technologies [Priority 1
if functionality is important
and not presented elsewhere, otherwise Priority 2.]
- Refer also
to guideline 6.
- Technicas pro le requisito 8.1
Device-independent access means that the
user may interact with the user agent or document with a preferred input (or
output) device -- mouse, keyboard, voice, head wand, or other. If, per exemplo,
a form control can only be activated with a mouse or other pointing device,
someone who is using the page without sight, with voice input, or with a keyboard
or who is using some other non-pointing input device will not be able to use
the form.
Note. Providing text equivalents for image maps or images
used as links makes it possible for users to interact with them without a pointing
device. Refer also to guideline
1.
Generally, pages that allow keyboard interaction are also accessible through
speech input or a command line interface.
- 9.1
Provide client-side image maps instead of server-side image maps except where
the regions cannot be defined with an available geometric shape. [Priority 1]
- Refer also to checkpoint
1.1, checkpoint
1.2, and checkpoint
1.5.
- Technicas pro le requisito 9.1
- 9.2
Ensure that any element that has its own interface can be operated in a device-independent
manner. [Priority 2]
- Refer to the definition of
device independence.
- Refer also
to guideline 8.
- Technicas pro le requisito 9.2
- 9.3
For scripts, specify logical event handlers rather than device-dependent event
handlers. [Priority 2]
- Technicas pro le requisito 9.3
- 9.4
Create a logical tab order through links, form controls, and objects. [Priority 3]
- Per exemplo, in HTML, specify tab order via the "tabindex"
attribute or ensure a logical page design.
- Technicas pro le requisito 9.4
- 9.5
Provide keyboard shortcuts to important links (including those in client-side
image maps), form controls, and groups of form controls. [Priority 3]
- Per exemplo, in HTML, specify shortcuts via the "accesskey"
attribute.
- Technicas pro le requisito 9.5
Per exemplo, older browsers do not allow users to navigate to empty edit boxes.
Older screen readers read lists of consecutive links as one link. These active
elements are therefore difficult or impossible to access. Also, changing the
current window or popping up new windows can be very disorienting to users who
cannot see that this has happened.
Note. The following checkpoints apply until user agents (including assistive technologies) address
these issues. These checkpoints are classified as "interim", meaning that the
Web Content Guidelines Working Group considers them to be valid and necessary
to Web accessibility as of the publication of this document. However,
the Working Group does not expect these checkpoints to be necessary in the future,
once Web technologies have incorporated anticipated features or capabilities.
- 10.1
Until
user agents allow users to turn off spawned windows, do not cause
pop-ups or other windows to appear and do not change the current window without
informing the user. [Priority 2]
- Per exemplo, in HTML, avoid using a frame whose target
is a new window.
- Technicas pro le requisito 10.1
- 10.2
Until
user agents support explicit associations between labels and form
controls, for all form controls with implicitly associated labels, ensure
that the label is properly positioned. [Priority 2]
- The label must immediately precede its control on the
same line (allowing more than one control/label per line) or be in the line
preceding the control (with only one label and one control per line). Refer
also to checkpoint 12.4.
- Technicas pro le requisito 10.2
- 10.3
Until
user agents (including assistive technologies) render side-by-side
text correctly, provide a linear text alternative (on the current page or
some other) for all tables that lay out text in parallel, word-wrapped
columns. [Priority 3]
- Note. Please consult the definition
of linearized table.
This checkpoint benefits people with user
agents (such as some screen readers) that are unable to handle blocks
of text presented side-by-side; the checkpoint should not discourage content
developers from using tables to represent
tabular information.
- Technicas pro le requisito 10.3
- 10.4
Until
user agents handle empty controls correctly, include default, place-holding
characters in edit boxes and text areas. [Priority 3]
- Per exemplo, in HTML, do this for TEXTAREA and INPUT.
- Technicas pro le requisito 10.4
- 10.5
Until
user agents (including assistive technologies) render adjacent
links distinctly, include non-link, printable characters (surrounded by spaces)
between adjacent links. [Priority 3]
- Technicas pro le requisito 10.5
The current guidelines recommend W3C technologies (p.ex., HTML, CSS, etc.) for
several reasons:
- W3C technologies include "built-in" accessibility features.
- W3C specifications undergo early review to ensure that accessibility issues
are considered during the design phase.
- W3C specifications are developed in an open, industry consensus process.
Many non-W3C formats (p.ex., PDF,
Shockwave, etc.) require viewing with either plug-ins or stand-alone applications.
Often, these formats cannot be viewed or navigated with standard user
agents (including assistive technologies). Avoiding
non-W3C and non-standard features (proprietary elements, attributes, properties,
and extensions) will tend to make pages more accessible to more people using
a wider variety of hardware and software. When inaccessible technologies (proprietary
or not) must be used, equivalent accessible pages must be provided.
Even when W3C technologies are used, they must be used in accordance with accessibility
guidelines. When using new technologies, ensure that they transform gracefully
(Refer also to guideline 6.).
Note. Converting documents (from PDF, PostScript, RTF,
etc.) to W3C markup languages (HTML, XML)
does not always create an accessible document. Therefore, validate each page
for accessibility and usability after the conversion process (refer to the section
on validation). If a page does not readily convert, either revise the page
until its original representation converts appropriately or provide an HTML
or plain text version.
- 11.1
Use W3C technologies when they are available and appropriate for a task and
use the latest versions when supported. [Priority 2]
- Refer to the list of references
for information about where to find the latest W3C specifications and [WAI-UA-SUPPORT]
for information about user agent support for W3C technologies.
- Technicas pro le requisito 11.1
- 11.2
Avoid deprecated features of W3C technologies. [Priority 2]
- Per exemplo, in HTML, don't use the deprecated
FONT element; use style sheets instead (p.ex., the 'font' property in CSS).
- Technicas pro le requisito 11.2
- 11.3
Provide information so that users may receive documents according to their
preferences (p.ex., language, content type, etc.) [Priority 3]
- Note. Use content negotiation where
possible.
- Technicas pro le requisito 11.3
- 11.4
If, after best efforts, you
cannot create an accessible
page, provide a link to an alternative page that uses W3C technologies, is
accessible, has equivalent
information (or functionality), and is updated as often as the inaccessible
(original) page. [Priority 1]
- Technicas pro le requisito 11.4
Note. Content developers should
only resort to alternative pages when other solutions fail because alternative
pages are generally updated less often than "primary" pages. An out-of-date
page may be as frustrating as one that is inaccessible since, in both cases,
the information presented on the original page is unavailable. Automatically
generating alternative pages may lead to more frequent updates, but content
developers must still be careful to ensure that generated pages always make
sense, and that users are able to navigate a site by following links on primary
pages, alternative pages, or both. Before resorting to an alternative page,
reconsider the design of the original page; making it accessible is likely to
improve it for all users.
Grouping elements and providing contextual information about the relationships
between elements can be useful for all users. Complex relationships between
parts of a page may be difficult for people with cognitive disabilities and
people with visual disabilities to interpret.
- 12.1
Title each frame to facilitate frame identification and navigation. [Priority 1]
- Per exemplo, in HTML use the "title" attribute on FRAME
elements.
- Technicas pro le requisito 12.1
- 12.2
Describe the purpose of frames and how frames relate to each other if it is
not obvious by frame titles alone. [Priority 2]
- Per exemplo, in HTML, use "longdesc," or a description
link.
- Technicas pro le requisito 12.2
- 12.3
Divide large blocks of information into more manageable groups where natural
and appropriate. [Priority 2]
- Per exemplo, in HTML, use OPTGROUP to group OPTION elements
inside a SELECT; group form controls with FIELDSET and LEGEND; use nested
lists where appropriate; use headings to structure documents, etc. Refer
also to guideline 3.
- Technicas pro le requisito 12.3
- 12.4
Associate labels explicitly with their controls. [Priority 2]
- Per exemplo, in HTML use LABEL and its "for" attribute.
- Technicas pro le requisito 12.4
Clear and consistent navigation
mechanisms are important to people with cognitive disabilities or
blindness, and benefit all users.
- 13.1
Clearly identify the target of each link. [Priority 2]
- Link
text should be meaningful enough to make sense when read out of
context -- either on its own or as part of a sequence of links. Link text
should also be terse.
- Per exemplo, in HTML, write "Information about version
4.3" instead of "click here". In addition to clear link text, content developers
may further clarify the target of a link with an informative link title (p.ex.,
in HTML, the "title" attribute).
- Technicas pro le requisito 13.1
- 13.2
Provide metadata to add semantic information to pages and sites. [Priority 2]
- Per exemplo, use RDF
([RDF]) to indicate the document's author, the type
of content, etc.
- Note. Some HTML
user agents can build navigation tools
from document relations described by the HTML LINK element and "rel" or "rev"
attributes (p.ex., rel="next", rel="previous", rel="index", etc.). Refer
also to checkpoint 13.5.
- Technicas pro le requisito 13.2
- 13.3
Provide information about the general layout of a site (p.ex., a site map or
table of contents). [Priority 2]
- In describing site layout, highlight and explain available
accessibility features.
- Technicas pro le requisito 13.3
- 13.4
Use navigation mechanisms in a consistent manner. [Priority 2]
- Technicas pro le requisito 13.4
- 13.5
Provide navigation bars to highlight and give access to the navigation mechanism.
[Priority 3]
- Technicas pro le requisito 13.5
- 13.6
Group related links, identify the group (for user agents), and, until
user agents do so, provide a way to bypass the group. [Priority 3]
-
- Technicas pro le requisito 13.6
- 13.7
If search functions are provided, enable different types of searches for different
skill levels and preferences. [Priority 3]
- Technicas pro le requisito 13.7
- 13.8
Place distinguishing information at the beginning of headings, paragraphs,
lists, etc. [Priority 3]
- Note. This is commonly referred to as "front-loading" and
is especially helpful for people accessing information with serial devices
such as speech synthesizers.
- Technicas pro le requisito 13.8
- 13.9
Provide information about document collections (i.e., documents comprising
multiple pages.). [Priority 3]
- Per exemplo, in HTML specify document collections with
the LINK element and the "rel" and "rev" attributes. Another way to create
a collection is by building an archive (p.ex., with zip, tar and gzip, stuffit,
etc.) of the multiple pages.
- Note. The performance improvement gained
by offline processing can make browsing much less expensive for people with
disabilities who may be browsing slowly.
- Technicas pro le requisito 13.9
- 13.10
Provide a means to skip over multi-line ASCII art. [Priority 3]
- Refer to checkpoint
1.1 and the example of ascii art in the glossary.
- Technicas pro le requisito 13.10
Consistent page layout, recognizable graphics, and easy to understand language
benefit all users. In particular, they help people with cognitive disabilities
or who have difficulty reading. (However, ensure that images have text equivalents
for people who are blind, have low vision, or for any user who cannot or has
chosen not to view graphics. Refer
also to guideline 1.)
Using clear and simple language promotes effective communication. Access to
written information can be difficult for people who have cognitive or learning
disabilities. Using clear and simple language also benefits people whose first
language differs from your own, including those people who communicate primarily
in sign language.
- 14.1
Use the clearest and simplest language appropriate for a site's content. [Priority 1]
- Technicas pro le requisito 14.1
- 14.2
Supplement text with graphic or auditory presentations where they will facilitate
comprehension of the page. [Priority 3]
- Refer also to guideline
1.
- Technicas pro le requisito 14.2
- 14.3
Create a style of presentation that is consistent across pages. [Priority 3]
- Technicas pro le requisito 14.3
Validate accessibility with automatic tools and human review. Automated
methods are generally rapid and convenient but cannot identify all accessibility
issues. Human review can help ensure clarity of language and ease of navigation.
Begin using validation methods at the earliest stages of development. Accessibility
issues identified early are easier to correct and avoid.
Following are some important validation methods, discussed in more detail in
the section
on validation in the Techniques Document.
- Use an automated accessibility tool and browser validation tool. Please
note that software tools do not address all accessibility issues, such as
the meaningfulness of link text, the applicability of a text equivalent, etc.
- Validate syntax (p.ex., HTML, XML, etc.).
- Validate style sheets (p.ex., CSS).
- Use a text-only browser or emulator.
- Use multiple graphic browsers, with:
- sounds and graphics loaded,
- graphics not loaded,
- sounds not loaded,
- no mouse,
- frames, scripts, style sheets, and applets not loaded
- Use several browsers, old and new.
- Use a self-voicing browser, a screen reader, magnification software, a small
display, etc.
- Use spell and grammar checkers. A person reading a page with a speech synthesizer
may not be able to decipher the synthesizer's best guess for a word with a
spelling error. Eliminating grammar problems increases comprehension.
- Review the document for clarity and simplicity. Readability statistics,
such as those generated by some word processors may be useful indicators of
clarity and simplicity. Better still, ask an experienced (human) editor to
review written content for clarity. Editors can also improve the usability
of documents by identifying potentially sensitive cultural issues that might
arise due to language or icon usage.
- Invite people with disabilities to review documents. Expert and novice users
with disabilities will provide valuable feedback about accessibility or usability
problems and their severity.
- Accessible
- Content is accessible when it may be used by someone with
a disability.
- Applet
- A program inserted into a Web page.
- Assistive technology
- Software or hardware that has been specifically designed
to assist people with disabilities in carrying out daily activities. Assistive
technology includes wheelchairs, reading machines, devices for grasping, etc.
In the area of Web Accessibility, common software-based assistive technologies
include screen readers, screen magnifiers, speech synthesizers, and voice
input software that operate in conjunction with graphical desktop browsers
(among other user agents). Hardware
assistive technologies include alternative keyboards and pointing devices.
- ASCII art
- ASCII art refers to text characters and symbols that are
combined to create an image. Per exemplo ";-)" is the smiley emoticon. The following is an ascii
figure showing the relationship between flash frequency and photoconvulsive
response in patients with eyes open and closed [skip
over ascii figure or consult a description
of chart]:
% __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 | * |
90 | * * |
80 | * * |
70 | @ * |
60 | @ * |
50 | * @ * |
40 | @ * |
30 | * @ @ @ * |
20 | |
10 | @ @ @ @ @ |
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Flash frequency (Hertz)
- Authoring tool
- HTML editors, document conversion tools, tools that generate
Web content from databases are all authoring tools. Refer to the "Authoring
Tool Accessibility Guidelines" ([WAI-AUTOOLS]) for information about developing accessible
tools.
- Backward compatible
- Design that continues to work with earlier versions of
a language, program, etc.
- Braille
- Braille uses six raised dots in different patterns to represent
letters and numbers to be read by people who are blind with their fingertips.
The word "Accessible" in braille follows:
- A braille display,
commonly referred to as a "dynamic braille display," raises or lowers dot
patterns on command from an electronic device, usually a computer. The result
is a line of braille that can change from moment to moment. Current dynamic
braille displays range in size from one cell (six or eight dots) to an eighty-cell
line, most having between twelve and twenty cells per line.
- Content developer
- Someone who authors Web pages or designs Web sites.
- Deprecated
- A deprecated element or attribute is one that has been
outdated by newer constructs. Deprecated elements may become obsolete in future
versions of HTML. The
index of HTML elements and attributes in the Techniques Document indicates
which elements and attributes are deprecated in HTML 4.0.
- Authors should avoid using deprecated elements and attributes.
User agents should continue to support for reasons of backward compatibility.
- Device independent
- Users must be able to interact with a user agent (and
the document it renders) using the supported input and output devices of their
choice and according to their needs. Input devices may include pointing devices,
keyboards, braille devices, head wands, microphones, and others. Output devices
may include monitors, speech synthesizers, and braille devices.
- Please note that "device-independent support" does not
mean that user agents must support every input or output device. User agents
should offer redundant input and output mechanisms for those devices that
are supported. Per exemplo, if a user agent supports keyboard and mouse input,
users should be able to interact with all features using either the keyboard
or the mouse.
- Document Content, Structure,
and Presentation
- The content of a document refers to what it says to the
user through natural language, images, sounds, movies, animations, etc. The
structure of a document is how it is organized logically (p.ex., by chapter,
with an introduction and table of contents, etc.). An element
(p.ex., P, STRONG, BLOCKQUOTE in HTML) that specifies document structure is
called a structural element. The presentation
of a document is how the document is rendered (p.ex., as print, as a two-dimensional
graphical presentation, as an text-only presentation, as synthesized speech,
as braille, etc.) An element
that specifies document presentation (p.ex., B, FONT, CENTER) is called a presentation
element.
- Consider a document header, per exemplo. The content of
the header is what the header says (p.ex., "Sailboats"). In HTML, the header
is a structural element marked up with, per exemplo, an H2 element. Finally,
the presentation of the header might be a bold block text in the margin, a
centered line of text, a title spoken with a certain voice style (like an
aural font), etc.
- Dynamic HTML (DHTML)
- DHTML is the marketing
term applied to a mixture of standards including HTML,
style sheets, the Document Object Model [DOM1]
and scripting. However, there is no W3C specification that formally defines
DHTML. Most guidelines may be applicable to applications using DHTML, however
the following guidelines focus on issues related to scripting and style sheets:
guideline 1, guideline
3, guideline 6, guideline
7, and guideline 9.
- Element
-
- This document uses the term "element" both in the strict SGML sense (an
element is a syntactic construct) and more generally to mean a type of content
(such as video or sound) or a logical construct (such as a header or list).
The second sense emphasizes that a guideline inspired by HTML could easily
apply to another markup language.
- Note that some (SGML) elements have content that is rendered
(p.ex., the P, LI, or TABLE elements in HTML), some are replaced by external
content (p.ex., IMG), and some affect processing (p.ex., STYLE and SCRIPT cause
information to be processed by a style sheet or script engine). An element
that causes text characters to be part of the document is called a
text element.
- Equivalent
- Content is "equivalent" to other content when both fulfill
essentially the same function or purpose upon presentation to the user. In
the context of this document, the equivalent must fulfill essentially the
same function for the person with a disability (at least insofar as is feasible,
given the nature of the disability and the state of technology), as the primary
content does for the person without any disability. Per exemplo, the text
"The Full Moon" might convey the same information as an image of a full moon
when presented to users. Note that equivalent information focuses on fulfilling
the same function. If the image is part of a link and understanding
the image is crucial to guessing the link target, an equivalent must also
give users an idea of the link target. Providing equivalent information for
inaccessible content is one of the primary ways authors can make their documents
accessible to people with disabilities.
- As part of fulfilling the same function of content an
equivalent may involve a description of that content (i.e., what the content
looks like or sounds like). Per exemplo, in order for users to understand
the information conveyed by a complex chart, authors should describe the visual
information in the chart.
- Since text content can be presented to the user as synthesized
speech, braille, and visually-displayed text, these guidelines require text
equivalents for graphic and audio information. Text equivalents
must be written so that they convey all essential content. Non-text
equivalents (p.ex., an auditory description of a visual presentation,
a video of a person telling a story using sign language as an equivalent for
a written story, etc.) also improve accessibility for people who cannot access
visual information or written text, including many individuals with blindness,
cognitive disabilities, learning disabilities, and deafness.
- Equivalent information may be provided in a number of
ways, including through attributes (p.ex., a text value for the "alt" attribute
in HTML and SMIL), as part of element content (p.ex., the OBJECT in HTML),
as part of the document's prose, or via a linked document (p.ex., designated
by the "longdesc" attribute in HTML or a description link). Depending on the complexity of
the equivalent, it may be necessary to combine techniques (p.ex., use "alt"
for an abbreviated equivalent, useful to familiar readers, in addition to
"longdesc" for a link to more complete information, useful to first-time readers).
The details of how and when to provide equivalent information are part of
the Techniques Document ([TECHNIQUES]).
- A text transcript
is a text equivalent of audio information that includes spoken words and non-spoken
sounds such as sound effects. A caption
is a text transcript for the audio track of a video presentation that is synchronized
with the video and audio tracks. Captions are generally rendered visually
by being superimposed over the video, which benefits people who are deaf and
hard-of-hearing, and anyone who cannot hear the audio (p.ex., when in a crowded
room). A collated text transcript
combines (collates) captions with text descriptions of video information (descriptions
of the actions, body language, graphics, and scene changes of the video track).
These text equivalents make presentations accessible to people who are deaf-blind
and to people who cannot play movies, animations, etc. It also makes the information
available to search engines.
- One example of a non-text equivalent is an auditory description of the
key visual elements of a presentation. The description is either a prerecorded
human voice or a synthesized voice (recorded or generated on the fly). The
auditory description is synchronized with the audio track of the presentation,
usually during natural pauses in the audio track. Auditory descriptions include
information about actions, body language, graphics, and scene changes.
- Image
- A graphical presentation.
- Image map
- An image that has been divided into regions with associated
actions. Clicking on an active region causes an action to occur.
- When a user clicks on an active
region of a client-side image map, the user agent calculates in which
region the click occurred and follows the link associated with that region.
Clicking on an active region of a server-side image
map causes the coordinates of the click to be sent to a server, which
then performs some action.
- Content developers can make client-side image maps accessible
by providing device-independent access to the same links associated with the
image map's regions. Client-side image maps allow the user agent to provide
immediate feedback as to whether or not the user's pointer is over an active
region.
- Important
- Information in a document is important if understanding
that information is crucial to understanding the document.
- Linearized table
- A table rendering process where the contents of the cells
become a series of paragraphs (p.ex., down the page) one after another. The
paragraphs will occur in the same order as the cells are defined in the document
source. Cells should make sense when read in order and should include structural
elements (that create paragraphs, headers, lists, etc.) so the page makes
sense after linearization.
- Link text
- The rendered text content of a link.
- Natural Language
- Spoken, written, or signed human languages such as French, Japanese, American
Sign Language, and braille. The natural language of content may be indicated
with the "lang" attribute in HTML ([HTML40], section 8.1) and the "xml:lang" attribute in
XML ([XML], section 2.12).
- Navigation Mechanism
- A navigation mechanism is any means by which a user can
navigate a page or site. Some typical mechanisms include:
- navigation bars
- A navigation bar is a collection of links to the most important parts
of a document or site.
- site maps
- A site map provides a global view of the organization of a page or
site.
- tables of contents
- A table of contents generally lists (and links to) the most important
sections of a document.
- Personal Digital Assistant (PDA)
- A PDA is
a small, portable computing device. Most PDAs are used to track personal data
such as calendars, contacts, and electronic mail. A PDA is generally a handheld
device with a small screen that allows input from various sources.
- Screen magnifier
- A software program that magnifies a portion of the screen,
so that it can be more easily viewed. Screen magnifiers are used primarily
by individuals with low vision.
- Screen reader
- A software program that reads the contents of the screen
aloud to a user. Screen readers are used primarily by individuals who are
blind. Screen readers can usually only read text that is printed, not painted,
to the screen.
- Style sheets
- A style sheet is a set of statements that specify presentation
of a document. Style sheets may have three different origins: they may be
written by content providers, created by users, or built into user agents.
In CSS ([CSS2]), the interaction of content provider,
user, and user agent style sheets is called the cascade.
- Presentation markup is markup
that achieves a stylistic (rather than structuring) effect such as the B or
I elements in HTML. Note that the STRONG and EM elements are not considered
presentation markup since they convey information that is independent of a
particul
