Académique Documents
Professionnel Documents
Culture Documents
ACCESIBLES
Santiago de Cali
2012
Proyecto de Grado
Notas de aceptacin:
______________________________
______________________________
______________________________
______________________________
______________________________
______________________________
Firma del jurado
______________________________
Firma del jurado
______________________________
Firma del jurado
TABLA DE CONTENIDO
GLOSARIO ............................................................................................. 10
RESUMEN.............................................................................................. 14
INTRODUCCIN ...................................................................................... 15
1.
2.
JUSTIFICACIN ................................................................................. 19
3.
4.
5.
NORMAS ......................................................................................... 28
5.1. NORMAS. ................................................................................... 28
5.2. LEYES ....................................................................................... 28
5.3. NORMAS Y LEYES COLOMBIANAS ........................................................ 28
5.3.1. Manual de Estrategias en Lnea ................................................... 29
5.3.1.1. Componentes de Gobierno en Lnea ........................................ 30
5.3.1.2. Niveles de Gobierno en Lnea ................................................ 31
5.3.1.3. Gobierno como Plataforma ................................................... 32
5.4. NORMAS Y LEYES EN OTROS PAISES ..................................................... 33
6.
ESTNDAR ....................................................................................... 35
6.1. EL CONSORCIO PARA LA WEB(W3C, POR SUS SIGLAS EN INGLS WORLD WIDE WEB
CONSORTIUM) ........................................................................................ 35
6.2. PAUTAS PARA LA ACCESIBILIDAD WEB .................................................. 36
6.2.1. Pautas de Accesibilidad al Contenido en la Web (WCAG, por sus siglas en
ingls Web Content Accessibility Guidelines). ............................................. 36
6.2.2. Pautas de Accesibilidad para Agentes de Usuario (UAAG, por sus siglas en
ingls Agent Accessibility Guidelines). ..................................................... 37
6.2.3. Pautas de Accesibilidad para Herramientas de Autor (ATAG, por sus siglas
en ingls Authoring Tool Accessibility Guidelines). ....................................... 37
METODOLOGA .................................................................................. 55
7.1.
7.2.
7.3.
8.
LINEAMIENTOS .................................................................................. 60
8.1. DEFINICIN DE LINEAMIENTOS .......................................................... 60
8.2. LINEAMIENTOS PARA DESARROLLADORES .............................................. 60
8.2.1. Lineamientos para el Contenido de la Web ..................................... 60
8.2.2. Lineamientos para autores de contenido Web. ................................. 86
9.
10.
11.1.
11.2.
12.
13.
LISTA DE TABLAS
LISTA DE ILUSTRACIONES
GLOSARIO
CAPTCHA: Acrnimo de Completely Automated Public Turing test to tell Computers and
Humans Apart (Prueba de Turing pblica y automtica para diferenciar a mquinas y
humanos). Las pruebas de CAPTCHA a menudo consisten en pedirle al usuario que
escriba en forma de texto aquello que aparece en una imagen o en un archivo de audio
distorsionados [1].
10
CONTENIDO NO TEXTUAL: Cualquier contenido que no est formado por una secuencia
de caracteres que puede ser determinado por software o donde la secuencia no expresa
nada en ningn idioma [1].
DECORACIN: Que slo persigue un propsito esttico, no proporciona informacin y
no tiene ninguna funcionalidad [1].
DESTELLO: Son los cambios opuestos en la luminosidad relativa que pueden causar
convulsiones en algunas personas si son lo suficientemente pronunciados y en un rango
de frecuencia determinado [1].
ETIQUETA: Corresponde al texto u otro componente con una alternativa textual que se
presenta al usuario para identificar un componente dentro del contenido Web [1].
RsRGB = R8bit/255
GsRGB = G8bit/255
11
RsRGB/12.92
si
no
GsRGB/12.92
si
no
BsRGB/12.92
si
no
BsRGB = B8bit/255
NIVEL DE EDUCACIN PRIMARIO: Periodo de seis aos que empieza a las edades de
entre cinco y siete, posiblemente sin ninguna educacin previa.
Nota: Esta definicin est basada en la Clasificacin Internacional Normalizada de la
Educacin (UNESCO) [1].
NIVEL MNIMO DE EDUACIN SECUNDARIA: Los dos o tres aos de educacin que se
inician al trmino de seis aos de escuela y finalizan nueve aos despus del comienzo
de la enseanza primaria.
Nota: Esta definicin se basa en la Clasificacin Internacional Normalizada de la
Educacin (UNESCO).
SLO AUDIO: Una presentacin basada en el tiempo que contiene nicamente audio
(sin vdeo y sin interaccin) [1].
SLO VIDEO: Una presentacin basada en el tiempo que contiene nicamente imgenes
(vdeo), sin sonidos (audio) ni interaccin [1].
12
W3C: Abreviacin de World Wide Web Consortium, que en espaol traduce Consorcio
para la World Wide Web.
13
RESUMEN
Este documento presenta el desarrollo del proyecto cuyo propsito es proponer una serie
de lineamientos para el desarrollo de sitios Web gubernamentales colombianos
accesibles; a partir de las normas y leyes tanto colombianas como de otros pases y el
estndar de la W3C que se tom como base para su desarrollo.
Adicionalmente, se incluye la metodologa que explica el proceso para la generacin de
los lineamientos y el anlisis que se realiz sobre el estndar mencionado en el
documento. Finalmente, el documento incluye los lineamientos para herramientas de
desarrolladores y de contenido y algunas de las tcnicas de evaluacin propuestas por la
W3C.
14
INTRODUCCIN
15
16
17
18
2. JUSTIFICACIN
19
Objetivo general
Generar un referente terico para el desarrollo de sitios Web del Gobierno en Colombia,
de tal manera que estos sean accesibles.
Objetivos especficos
1. Generar una
accesibilidad.
base
conceptual
sobre
los
aspectos
relacionados
con
la
20
4. BASE CONCEPTUAL
4.1.
DISCAPACIDAD
4.2.
ACCESIBILIDAD
22
4.3.
Uno de los aspectos que debemos tener en mente es que todos en algn u otro
momento somos discapacitados o podemos serlo. El estndar ISO/TS 16071 [ISO03]
destaca que tener una discapacidad debe ser visto como un elemento natural de la vida
humana, pues todos podemos, en algn periodo de nuestra vida, vernos afectados por
diversas circunstancias que nos dificulten usar y acceder a sistemas, productos y
servicios. Incluso aquellas personas que en principio disponen de todas sus
capacidades, pueden en determinadas circunstancias, considerarse de este grupo. Este
fenmeno se repite al disear sistemas interactivos accesibles. As, tenemos que si un
sistema es accesible tambin beneficia a: [7]
23
Personas muy jvenes. Caso contrario al anterior, puede ser considerado una
forma de discapacidad, sobre todo debido a la falta de adquisicin de muchos
conocimientos propios de edades primarias. [8]
Personas con dispositivos muy modernos. Con el uso de los dispositivos recin
desarrollados, se encuentran multitud de dificultades debido a que las
infraestructuras no suelen estar preparadas para dichos mecanismos.
Una persona diestra que realiza su trabajo diario con la ayuda de un computador
de escritorio y debido a una operacin en el codo derecho tiene inmovilizada
dicha extremidad durante unas semanas, esta persona tiene dificultad o
discapacidad temporal con el uso de los dispositivos habituales como son el
teclado y el ratn.
24
Una persona que se encuentra en un pas del cual desconoce su lengua, padece
un cierto grado de discapacidad temporal al ver limitadas sus discapacidades de
expresin. [7]
Las personas con discapacidades temporales, precisamente por ser conscientes de
dicha temporalidad, no suelen adoptar medidas para saltar dicha discapacidad,
siendo por ello necesario que las caractersticas del sistema sean muy fciles de
encontrar y aprender.
Se ha visto que en el desarrollo de aplicaciones accesibles, sucede lo mismo que pasaba
con las infraestructuras urbanas: la mejora se realiza para favorecer el acceso a
un determinado colectivo que est en clara minora, pero el resultado es una mejora de
dicho acceso para un nmero mayor de personas. [7]
4.4.
BENEFICIOS DE LA ACCESIBILIDAD
Una pgina Web accesible proporciona mltiples beneficios a sus propietarios y usuarios.
Ya slo el hecho de mejorar el posicionamiento de una pgina Web en los buscadores es
una razn de peso para mejorar la accesibilidad de las pginas Web. Pero existen otras
razones que tambin son importantes. Por ejemplo, la Asociacin Espaola de
Normalizacin y Certificacin (AENOR) 1que proporciona certificados de accesibilidad
Web, da las siguientes razones:
25
Fran Tarifa en su blog Mas Que Accesibilidad [10], indica en su comentario Otra razn
ms para hacer una Web accesible: obtener ayudas y subvenciones, una serie de razones
(beneficios) para hacer un sitio Web accesible (adems del evidente de la eliminacin de
las barreras que afectan a las personas con discapacidad):
Razones Sociales.
Motores de bsqueda.
Aumenta la usabilidad de la pgina.
Se cumplen los estndares Web.
Dispositivos mviles.
Navegadores Web.
Posibilidad de tener ms visitantes.
Reducir el coste de mantenimiento.
Cumplir la ley.
Obtener ayudas y subvenciones.
26
27
5. NORMAS
5.1.
NORMAS.
Las normas son disposiciones para uso comn y repetido, encaminadas al logro del
grado ptimo de orden con respecto a problemas reales o potenciales, en un contexto
dado [11].
5.2.
LEYES
Una ley es una norma o una regla que nos dice cul es la forma en la que debemos
comportarnos o actuar en la sociedad. Las Leyes nos dicen lo que es permitido y lo que
es prohibido hacer en Colombia; as si todos las cumplimos podramos lograr que existan
menos conflictos en la poblacin. [12]
5.3.
29
5.3.1.1.
El documento comprende cinco componentes sobre los cuales se debe tomar decisiones y
asegurar los medios para lograr su desarrollo. Desde otro punto de vista, su desarrollo es
el que permite el logro de los objetivos de Gobierno en Lnea. Estos componentes, con
sus respectivas actividades son:
Para cada componente se especifican los criterios que deben cumplir los sitios Web
principales de las entidades y algunos que deben considerarse en los sitios Web
adicionales de los programas que adelanten las mismas. Los sitios Web correspondientes
a planes, sistemas de informacin o temas relacionados con la actividad de la entidad y
que dependan de sta, debern cumplir por lo menos los criterios correspondientes a los
30
5.3.1.2.
Nivel Inicial: Nivel en el cual se cuenta con las condiciones institucionales para
habilitar cada uno de los componentes. Las entidades caracterizan y analizan a
sus usuarios tomando en cuenta variables como composicin, necesidades y
acceso a tecnologa. Igualmente, analizan sus procesos misionales, estratgicos y
de apoyo, al igual que la informacin que se genera a partir de los mismos. De
otra parte, analizan los esquemas de prestacin de servicios y los recursos con los
cuentan para su provisin. Finalmente, priorizan sus acciones y definen su plan
de accin para avanzar en el uso del Gobierno en lnea y apropian los recursos
econmicos, humanos, administrativos y legales para ello.
31
5.3.1.3.
32
5.4.
En otros otros paises como Argentina, Espaa y Estados Unidos, poseen leyes y normas
especficas para la accesibilidad Web. En el caso de Argentina, el congreso aprob el 3
de noviembre del 2010 la Ley 26.653 de accesibilidad de la informacin en las pginas
Web [15];la cual menciona que las empresas del Estado y las empresas privadas
concesionarias de servicios pblicos, empresas prestadoras o contratistas de bienes y
servicios, debern respetar en los diseos de sus pginas Web las normas y requisitos
sobre accesibilidad de la informacin que faciliten el acceso a sus contenidos, a todas
las personas con discapacidad con el objeto de garantizarles la igualdad real de
oportunidades y trato, evitando as todo tipo de discriminacin [16]. Todos estos
diseos deben estar contemplados dentro del marco de las obligaciones que surgen de la
Convencin sobre los Derechos de las Personas con Discapacidad (ley 26.378 de la
repblica de Argentina).
En el caso de Europa, la unin europea a travs del organismo CEN (Comit Europeo de
Normalizacin), ha diseado la norma CWA 15554:2006 que proporciona la definicin de
la inspeccin y certificacin en materia de Accesibilidad Web.Para el caso especfico de
Espaa, existe un gran nmero de leyes que definen varios niveles de accesibilidad y
fechas de cumpliento; las cuales han sido aprobadas desde el ao 2002. Entre las leyes
se encuentran:
33
Estas leyes contemplan las normas CWA 15554:2006 y UNE 139803:2004. La primera ya
ha sido mencionada anteriormente, mientras que la segunda establece las
caractersticas para cumplir con una Web accesible, cubriendo la mayora de las
discapacidades [18].
Finalmente, en Estados Unidos, el acta de rehabilitacin de 1973 seccin 508 establece
que existen todos los conocimientos y productos necesarios para servir a todos los
usuarios (sin importar su discapacidad), por lo que se debe realizar una mejor utilizacin
de la tecnologa existente para crear productos accesibles. [19] La seccin 508
contempla el estndar Electronic and Information Technology Accessibility Standards
de la United States Access Board [20].
34
6. ESTNDAR
Como ya se vio en el capitulo 5, los sitios Web de las insituaciones del estado
colombiano
debern cumplir por lo menos los criterios correspondientes a los
estndares de navegacin incluidos en el nivel de accesibilidad Doble A (AA) de la W3C.
6.1.
El Consorcio para la Web fue creado en octubre de 1994 para conducir a la World Wide
Web a su mximo potencial, desarrollando protocolos de uso comn que condujeran a su
evolucin y al mejoramiento dela interoperabilidad. Tambin constituyen un consorcio
industrial internacional alojado por el Laboratorio de Ciencias de la Computacin del
Instituto de Tecnologa de Massachusetts en EEUU, el Instituto Nacional de Investigacin
en Informtica y Robtica en Francia y la Universidad Shonan Fujisawa de Keio en Japn.
El consorcio est liderado por Tim Berners-Lee, creador de la World Wide Web y director
del consorcio, y por Jean-Franois Abramatic, como presidente. Tambin est formado
por Organizaciones Miembro sin nimo de lucro que trabajan en la comunidad
internacional para desarrollar especificaciones y programas informticos de referencia,
que son distribuidos gratuitamente a lo largo de todo el planeta.
El compromiso del Consorcio para la Web es el de encaminar la Web a su mximo
potencial, proporcionando un alto grado de accesibilidad para las personas con
discapacidades. El grupo interno de trabajo permanente conocido como Iniciativa para
la Accesibilidad de la Red (WAI, por sus siglas en ingls Web Accesibility Initiative), en
coordinacin con asociaciones y organizaciones de todo el mundo, promueven la
accesibilidad de la Web a travs de cinco actividades complementarias: Tecnologa,
normativa, herramientas (de validacin y reparacin), educacin y formacin, e
investigacin y desarrollo. [21]
35
6.2.
El grupo interno de trabajo WAI (por sus siglas en ingls Web Accesibility Initiative)
desarroll un grupo de pautas para la accesibilidad Web que son distribuidas en los
siguientes componentes:
Los componentes listados anteriormente tienen como objetivo satisfacer las necesidades
de diversos usuarios con discapacidades. Adems, estn basados en tcnicas
fundamentales para la accesibilidad en la Web y son desarrollados en coordinacin con
las especificaciones tcnicas de la W3C (HTML, XML, CSS, SVG y SMIL, entre otros).
36
6.2.2. Pautas de Accesibilidad para Agentes de Usuario (UAAG, por sus siglas en
ingls Agent Accessibility Guidelines).
Las UAAG explican cmo hacer que los agentes de usuario sean accesibles para personas
con discapacidad, en especial cmo incrementar la accesibilidad al contenido Web.
Entre los agentes de usuario se incluyen navegadores, reproductores multimedia,
tecnologas asistidas cualquier software que algunas personas con discapacidad utilizan
para interactuar con los dispositivos.
Cada pauta est propuesta principalmente para Reproductores Multimedia, Tecnologas
Asistidas, Desarrolladores de Navegadores Web, entre otros, adems, tienen como
objetivo los siguientes puntos:
6.2.3. Pautas de Accesibilidad para Herramientas de Autor (ATAG, por sus siglas
en ingls Authoring Tool Accessibility Guidelines).
Las ATAG definen cmo hacer que las herramientas de autor (aquellas que son utilizadas
para crear pginas y contenidos Web) sean accesibles para personas con discapacidad.
Entre los objetivos de la ATAG se encuentran:
Produccin de contenido accesible (es decir, pginas Web) que cumpla los
estndares y las pautas.
Solicitud de informacin al autor de contenido (es decir, al usuario de la
herramienta de autor) sobre accesibilidad.
Formas de comprobar y corregir el contenido que no es accesible.
Formas de hacer la herramienta en s misma accesible para personas con
discapacidad.
37
6.2.4. Pautas para la Accesibilidad de Aplicaciones Dinmicas en la Internet (WAIARIA, por sus siglas en ingls Accessible Rich Internet Applications).
Las WAI-ARIA definen cmo hacer el contenido y aplicaciones Web ms accesibles para
las personas con discapacidad. Especialmente, ayuda con contenido dinmico e
interfaces de usuario con controles avanzados, desarrollados con Ajax, HTML,
JavaScript, y tecnologas relacionadas.
En la actualidad algunas funciones utilizadas en sitios Web no estn disponibles para
algunos usuarios con discapacidad, especialmente las personas que utilizan lectores de
pantalla y personas que no pueden utilizar un mouse. WAI-ARIA enfrenta a estos retos de
accesibilidad, por ejemplo, definiendo nuevos caminos para proveer tecnologas que
asistan a las personas discapacitadas. Con WAI-ARIA, los desarrolladores pueden crear
aplicaciones Web accesibles y usables para personas con discapacidad.
Muchas aplicaciones Web desarrolladas con Ajax, DHTML y otras tecnologas plantean
retos adicionales de accesibilidad. Por ejemplo, si el contenido de una pgina Web
cambia en respuesta a acciones del usuario, eventos o por intervalos de tiempo, el
nuevo contenido puede no estar disponible para algunas personas con discapacidades
que utilizan un lector de pantalla. Con WAI-ARIA, todo esto puede ser accesible y til
para las personas con discapacidad. Adems, brinda un marco para que el desarrollador
agregue atributos que identifiquen las caractersticas de interaccin con el usuario y la
pagina Web. [25]
38
Defensor
Esto puede incluir informacin acerca de quin o qu ejecut la prueba. Por
ejemplo, los evaluadores humanos, los testers automticos, o combinaciones de
estos.
39
Sujeto de Prueba
Esto puede incluir el contenido de la Web (como pginas Web, videos, applets,
etc), software (tales como herramientas de autor), u otro tipos de temas que
puedan ser testados mediante EARL.
Prueba de Criterio
Contra qu estamos evaluando el sujeto de prueba? Esto podra ser una
especificacin, un conjunto de directrices, una prueba de un conjunto de
pruebas, o algunos otros criterios de prueba.
Resultado de la prueba
Cul fue el resultado de la prueba? Un resultado tambin podra incluir
informacin contextual, tales como mensajes de error o lugares de importancia
en el sujeto de prueba.
Ejemplo 1: Una persona que lleva a cabo una evaluacin manual de una pgina Web a un
requisito de accesibilidad.
o
Defensor
Bob B. Bobbington
Sujeto de Prueba
Una pgina Web ubicada en http://www.example.org/page.html
Prueba de Criterio
Criterio de xito 1.1.1 de las Directrices de Accesibilidad para el
Contenido Web (WCAG) 2.0
Resultado de la prueba
Aprobado
Defensor
El W3C Markup Validator se encuentra en http://validator.w3.org/
Sujeto de Prueba
El XHTML de una solicitud GET a
la URL http://www.example.org/page.html en 2004-04-14T14: 00:04 1000
40
Prueba de Criterio
La validez del cdigo XHTML
Resultado de la prueba
Error, el <li> elemento en la lnea 53, char 7 no estaba cerrado.
Con un formato estndar legible por mquina, EARL facilita el procesamiento de los
resultados de las pruebas, tales como los generados por las herramientas de Web
automticas o semiautomticas que sirven para realizar la evaluacin de la
accesibilidad. Herramientas de creacin de pginas Web y software de control de
calidad pueden servir para apoyar a los desarrolladores Web en el desarrollo
de contenido Web de alta calidad. EARL ha sido especficamente diseado para soportar
una amplia variedad de casos de uso, incluyendo las siguientes:
41
Friend of a Friend (FOAF) .El proyecto FOAF se trata de crear una Web de
recursos de lectura mecnica describiendo a las personas, los vnculos entre ellos
y las cosas que crean y hacen [FOAF].
42
</rdf:RDF>
43
Este documento tiene tres errores que constituyen la base de nuestro informe EARL:
El primer paso es definir quin realiz la prueba, ya sea un ser humano o una
herramienta de software. Esto se nota en el marco EARL como un defensor. En primer
lugar, se supondr que slo el W3C HTML Validator realiza la prueba. Esto puede ser
expresado como un defensor:
Ejemplo: Una herramienta genrica como un defensor
<earl:Assertorrdf:about="http://validator.w3.org/about.html#">
<dct:titlexml:lang="en">W3C HTML Validator</dct:title>
<dct:descriptionxml:lang="en">
W3C Markup Validation Service, a free service that checks Web documents in
formats like HTML and XHTML for conformance to W3C Recommendations and other
standards.
</dct:description>
</earl:Assertor>
44
<http://www.w3.org/ns/earl#> .
@prefix dct:
<http://purl.org/dc/terms/> .
<http://validator.w3.org/about.html#>
aearl:Assertor ;
dct:description """W3C Markup Validation Service, a free service that checks Web
documents in formats like HTML and XHTML for conformance to W3C
Recommendations and other standards."""@en ;
dct:title "W3C HTML Validator"@en .
Un defensor es un tipo genrico. EARL permite el uso de ciertas clases de FOAF como
agente, organizacin o persona para proporcionar ms informacin semntica sobre el
tipo de defensor. Adems, Por lo tanto, la W3C Validator se podra describir de manera
ms adecuada de la siguiente manera:
Ejemplo: Un software defensor
<earl:Softwarerdf:about="http://validator.w3.org/about.html#">
<dct:titlexml:lang="en">W3C HTML Validator</dct:title>
<dct:hasVersion>0.7.1</dct:hasVersion>
<dct:descriptionxml:lang="en">
W3C Markup Validation Service, a free service that checks Web documents in
formats like HTML and XHTML for conformance to W3C Recommendations and other
standards.
</dct:description>
45
</earl:Software>
requisitos
de
prueba y resultados,
respectivamente. De los
ejemplos
anteriores, podemos construir nuestro informe completo con tres afirmaciones:
Ejemplo: Resultados de las pruebas elaboradas con W3C Validator
<earl:Assertionrdf:ID="ass1">
<earl:resultrdf:resource="#error1" />
<earl:testrdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" />
<earl:subjectrdf:resource="http://example.org/resource/index.html" />
<earl:assertedByrdf:resource="#assertor01" />
</earl:Assertion>
<earl:Assertionrdf:ID="ass2">
<earl:resultrdf:resource="#error2" />
<earl:testrdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" />
<earl:subjectrdf:resource="http://example.org/resource/index.html" />
<earl:assertedByrdf:resource="#assertor01" />
</earl:Assertion>
<earl:Assertionrdf:ID="ass3">
<earl:resultrdf:resource="#error3" />
<earl:testrdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" />
<earl:subjectrdf:resource="http://example.org/resource/index.html" />
<earl:assertedByrdf:resource="#assertor01" />
</earl:Assertion>
acuerdos contractuales. Con el fin de cumplir con las necesidades de los diferentes
grupos y situaciones, se definen tres niveles de conformidad: A (el ms bajo), AA y AAA
(el ms alto).
El nivel A recoge los requisitos mnimos de accesibilidad que debe observar un sitio Web.
El nivel doble A indica los requisitos que debera cumplir un sitio para alcanzar un nivel
adecuado de accesibilidad. El nivel triple A define los requisitos que podra cumplir un
sitio para alcanzar un nivel mximo de accesibilidad.
6.2.7. Principios, guas y tcnicas
Cada componente de la iniciativa para la accesibilidad Web est compuesto por
principios, que a su vez contiene una cantidad determinada de guas. Estas guas
proveen al usuario de tcnicas que lo ayudan a cumplir con uno de los tres (3) niveles de
conformidad y de esta forma, cumplir con un sitio Web que incluya todas las pautas para
ser catalogado como accesible.
6.2.7.1.
Las personas y organizaciones que pueden utilizar las ATAG 2.0 varan ampliamente,
entre ellos se pueden encontrar desarrolladores, usuarios y responsables polticos. Con
el fin de satisfacer las diversas necesidades de este pblico, se proporcionan varias
capas:
Partes: ATAG 2.0 se divide en dos partes, cada una refleja un aspecto clave de
las herramientas accesibles. La parte A se refiere a garantizar la accesibilidad de
las interfaces de usuario de la herramienta a personas con discapacidades. La
parte B se refiere a asegurar el apoyo de herramientas para la creacin, por
cualquier autor (no slo las personas con discapacidad), de contenido Web.
Principios: Debajo de cada parte existen varios principios que organizan las
directrices.
Guas: Bajo los principios se encuentran las guas. Las guas establecen los
objetivos bsicos que los desarrolladores de herramientas de autora deben seguir
para elaborar herramientas fciles de creacin para personas discapacitadas y
usuarios finales de contenido Web con diferentes discapacidades. Las guas no
son comprobables, pero proporcionan el marco y los objetivos generales para
48
49
50
51
PRINCIPIO B.1: Todos los procesos automticos deben producir contenido accesible.
Gua B.2.1: Brindar una gua para que las personas puedan producir
contenido accesible.
Justificacin: Al brindar guas a las personas desde el principio en la
creacin y mantenimiento de contenidos Web accesibles (WCAG), los
problemas de accesibilidad Web de se ven mitigados y menos esfuerzo de
reparacin serian necesarios.
PRINCIPIO B.3: Los personas deben ser apoyados en la mejora de la accesibilidad de los
contenidos existentes.
6.2.7.2.
Configurabilidad.
Dispositivo de la independencia.
Interoperabilidad.
Apoyo directo a las reproducciones, tanto grfica y auditiva.
Algunos usuarios tienen ms de una discapacidad, y las necesidades de los distintos tipos
de discapacidad se pueden contradecir. As, muchos de los requisitos en UAAG 2,0
realizan nfasis en proveer al usuario la opcin de utilizar la configuracin para
asegurarse de que una funcionalidad diseada para mejorar la accesibilidad de un
usuario no interfiera con la accesibilidad de otro. Una configuracin predeterminada del
agente puede ser til para un usuario, pero interfieren con la accesibilidad para otro.
Capas de UAAG 2.0:
Con el fin de satisfacer las necesidades de diferentes pblicos que utilizan capas UAAG,
varias capas se presentan varias capas de orientacin, incluyendo los
principios generales y directrices comprobables y criterios de xito.
Principios - En la parte superior hay cinco principios que constituyen la base para
las aplicaciones de usuario accesibles. Los Principios 1, 2 y 3 son congruentes con
las Directrices de Accesibilidad para el Contenido Web (WCAG) 2.0: perceptibles,
operables y comprensibles. Principios 4 y 5 son especficos para los agentes de
usuario: facilitar el acceso programtico y cumplir con las especificaciones y
convenciones.
53
54
7. METODOLOGA
7.1.
7.2.
IDENTIFICACIN
TCNICAS
DE
PRINCIPIOS,
55
PUNTOS
DE
VERIFICACIN
Es necesario para cada una de las pautas de accesibilidad identificar los principios,
puntos de verificacin y guas. Los principios constituyen los objetivos del diseo
accesible, las guas corresponden con las caractersticas del diseo accesible y los puntos
de verificacin representan el cmo y el qu se debe hacer.
Cada principio cambia de acuerdo a la pauta que se est consultando, por ejemplo, en el
caso de las WCAG los principios estarn relacionados nicamente al mejoramiento del
contenido Web y por ende sus guas y puntos de verificacin estarn relacionados al
mismo objetivo.
7.3.
CONSTRUCCIN DE LINEAMIENTOS
Una vez identificados cada uno de los elementos de la pauta de accesibilidad que se
desea definir como lineamiento, se debe crear el ttulo. Es necesario tener en cuenta
que el ttulo debe resaltar la caracterstica del diseo accesible para que el lineamiento
sea fcil de identificar.
Despus, se debe evaluar si existen uno o ms puntos de verificacin funcionalmente
relacionados ya que las descripciones del lineamiento no corresponden necesariamente a
una gua sino a un conjunto de puntos de verificacin.
Un ejemplo de esto sera la gua 1.1. Alternativas Textuales que define:
Proporcionar alternativas textuales para que todo el contenido se pueda configurar de
acuerdo a las necesidades de las personas, por ejemplo agrandar las letras, agregar
smbolos o permitir un lenguaje ms sencillo. [1]
Y un punto de verificacin de esta gua define:
1.1.1 Contenido no textual: Todo contenido no textual que se presenta al usuario
tiene una alternativa textual que cumple el mismo propsito, excepto en las situaciones
enumeradas a continuacin. (Nivel A)
56
Basado en el ejemplo anterior, se debe leer detenidamente la gua para identificar cada
una de las caractersticas del diseo accesible y de esta forma considerar si es necesario
o no separarla en diferentes lineamientos. En este caso, debido a que el contenido no
textual abarca imgenes, videos u otro tipo de presentacin de informacin y adems se
incluyen funcionalidades como lo son CAPTCHA, se debe dividir esta gua en diferentes
lineamientos. Lo mismo ocurrir si existen otras gruas con puntos de verificacin
similares, ya que de existir un lineamiento con caractersticas similares, deber incluirse
en l.
Una vez definida la caracterstica del lineamiento, se debe conocer el nivel de
conformidad de la gua que se est analizando, para este caso la gua tiene un nivel A lo
que significa que puede existir otra gua con las mismas caractersticas pero con un nivel
de conformidad AA o AAA. De encontrarse un caso como el descrito anteriormente, se
debe definir el lineamiento nombrando la mayor caracterstica accesible pero dndole al
usuario la posibilidad de elegir el nivel de accesibilidad que desea implantar.
57
Textos grandes: Los textos de gran tamao y las imgenes de texto de gran
tamao tienen una relacin de contraste de, al menos, 3:1.
Textos grandes: Los textos de gran tamao y las imgenes de texto de gran
tamao tienen una relacin de contraste de, al menos, 4.5:1.
El ejemplo anterior nos muestra dos puntos de verificacin con las mismas
caractersticas pero con un nivel de conformidad distinto (AA y AAA). Para la
construccin del lineamiento se debe incluir la caracterstica ms accesible (Contraste
de 4.5:1) pero dndole la posibilidad al usuario de seleccionar el nivel de
implementacin, esto puede lograrse con el uso de palabras como al menos o hasta.
58
59
8. LINEAMIENTOS
8.1.
DEFINICIN DE LINEAMIENTOS
La palabra lineamento (que proviene del trmino latino lineamentum) hace referencia a
las directrices especficas que facilitan la orientacin operativa a la cual se pretende
llegar al cumplimiento de los objetivos, en este contexto, el de ser un sitio Web
gubernamental accesible. Estas directrices no son ms que propuestas para ayudar a
mejorar la accesibilidad en la Web, por lo que estarn sujetas a la decisin y al criterio
de cada persona. [26]
8.2.
Los lineamientos para los desarrolladores son los que aplican en la fase de construccin
de un proyecto de software. Durante este proceso, el desarrollador deber conocer
previamente cmo se aplicarn los lineamientos y el nivel de conformidad que desea
implementar.
60
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
62
Beneficio
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
N/A
Beneficio
64
Ejemplo
N/A
Beneficio
Las personas que son sordas pueden comprender los videos con
informacin presentada en lenguaje de seas.
Las personas que son ciegas o tienen baja visin, as como las
personas con limitaciones cognitivas que tienen dificultad para
interpretar visualmente lo que est sucediendo se benefician de la
audio-descripcin de la informacin visual.
Descripcin
Ejemplo
Las personas que son sordas pueden comprender los videos con
informacin presentada en lenguaje de seas.
Beneficio
66
Descripcin
Ejemplo
Beneficio
67
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
N/A
Beneficio
Ayuda a los usuarios con baja visin, hacindoles ver el texto sin
la distraccin de elementos de presentacin. Les permite
configurar el texto de manera que ser ms fcil para ellos ver al
permitirles controlar el color y el tamao de los bloques de texto.
Descripcin
Ejemplo
Beneficio
69
Descripcin
Ejemplo
Beneficio
Los
usuarios
que
tienen
70
daltonismo
debera
tener
su
Descripcin
Ejemplo
Beneficio
71
Es importante que el audio que se realice para una Web deba evitar
el ruido ambiental o generado por terceros, de forma que puedan
causar confusin o poco entendimiento al usuario final. Es necesario
tener en cuenta que:
Ejemplo
N/A
Beneficio
Tabla 15. Permitir el manejo del teclado como componente de interfaz de usuario
Descripcin
Ejemplo
72
Las personas con baja visin (que pueden tener problemas para
encontrar o el seguimiento de un indicador de puntero en la
pantalla).
Tabla 16. Proporcionar a los usuarios el tiempo suficiente para leer y usar el contenido.
Descripcin
Ejemplo
Las personas con baja visin necesitan ms tiempo para ubicar los
elementos de la pantalla. Las personas que son ciegas y usan
73
Beneficio
Las personas con baja visin (que pueden tener problemas para
encontrar o el seguimiento de un indicador de puntero en la
pantalla).
Descripcin
74
Logotipos:
mnimo).
Ejemplo
N/A.
Beneficio
sin
requisito
de
contraste
(preferiblemente
Descripcin
Ejemplo
N/A
75
Descripcin
Ejemplo
N/A
Beneficio
76
Descripcin
Ejemplo
N/A.
Beneficio
Descripcin
Ejemplo
77
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
N/A
Beneficio
79
Descripcin
Ejemplo
Beneficio
80
Ejemplo
N/A
Beneficio
Descripcin
Ejemplo
N/A
Beneficio
81
Descripcin
Ejemplo
N/A
Beneficio
Descripcin
Ejemplo
82
Descripcin
Ejemplo
Beneficio
83
Descripcin
Ejemplo
Beneficio
84
Ejemplo
N/A
Beneficio
Ayuda a los usuarios con todas las discapacidades que pueden ser
ms propensos a cometer los mismos errores una y otra vez.
Descripcin
85
N/A
Beneficio
Descripcin
Ejemplo
Beneficio
86
Descripcin
Ejemplo
N/A
Beneficio
Configurar el texto.
87
Ejemplo
Beneficio
Descripcin
Ejemplo
Beneficio
88
Descripcin
Ejemplo
N/A
Beneficio
Descripcin
Ejemplo
N/A
Beneficio
89
Descripcin
Ejemplo
Beneficio
Tabla 40. La herramienta debe permitir el uso de sus funcionalidades mediante accesos rpidos
Descripcin
Ejemplo
90
Tabla 41. Proveer a los usuarios con suficiente tiempo para usar las funcionalidades
Descripcin
Ejemplo
N/A
Beneficio
91
Descripcin
Ejemplo
N/A
Beneficio
Permite que todas las personas ya sea que presenten algn tipo de
discapacidad se les permita el uso de todas las funcionalidad
presentes en la pagina y/o el contenido.
Descripcin
Ejemplo
Beneficio
92
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
Beneficio
93
Descripcin
Ejemplo
Beneficio
Descripcin
Ejemplo
94
95
9. TCNICAS DE EVALUACIN
9.1.
Una evaluacin de accesibilidad eficaz exige tanto buenas capacidades para llevar a
cabo la evaluacin, como contar con la experiencia de personas con discapacidad. Si no
resulta muy complicado disponer de la colaboracin de personas con discapacidad
(porque trabajen en tu mismo edificio, por ejemplo) para que ayuden en la evaluacin,
es probable que se quiera llevar a cabo con ellos numerosas evaluaciones informales
sobre los primeros prototipos que se haya diseado. Si, como es habitual, resulta ms
difcil contar con la ayuda de personas con discapacidad para realizar la evaluacin,
quiz se prefiera utilizar, primero, los otros mtodos de evaluacin.
Si se posee un presupuesto limitado, quiz se tenga que hacer las evaluaciones por si
mismo o quiz puedas permitirte contratar a un especialista en accesibilidad. Un
experto que tenga experiencia de primera mano sobre cmo interactan con un
producto personas con distintas discapacidades puede:
Aunque cada plan de evaluacin ser diferente dependiendo de los recursos y dems
factores, se debe de asegurar de que se lleva a cabo una evaluacin exhaustiva que
incluye, al menos, parte de los mtodos que se describen a continuacin: revisin de
estndares, evaluacin heurstica, simulaciones de diseo, tcnicas de filtrado y pruebas
de usabilidad.
96
97
realizar sobre unos primeros prototipos. A veces, otro miembro del equipo hace de
ordenador o de dispositivo, cambiando las maquetas en papel de las ventanas, mens
desplegables, cuadros de dilogo en forma de ventanas emergentes (pop-ups) y otros
elementos de la interfaz.
Algunas vas para incorporar la accesibilidad a las simulaciones de diseo son:
99
9.2.
100
Access Monitor: Herramienta online que permite revisar WCAG 1.0 y WCAG 2.0.
Permite revisar una pgina publicada en Internet o subir o pegar directamente su
cdigo HTML. Revisar los puntos de verificacin uno a uno y adems ofrece una
puntuacin del 1 al 10.
AChecker: Herramienta online que permite revisar BITV, Section 508, WCAG 1.0
y WCAG 2.0 al mismo tiempo. Adems, tambin permite validar el cdigo HTML y
CSS. Permite revisar una pgina publicada en Internet o subir o pegar
directamente su cdigo HTML. [30]
Cynthia Says: Revisa WCAG 1.0 y Section 508. Tambin analiza la calidad de los
textos alternativos de las imgenes. [31]
Deque World space: Herramienta online que permite verificar WCAG 1.0, WCAG
2.0 y Section 508. [32]
Deque World space Fire Eyes: Herramienta gratuita para descargar que permite
revisar la accesibilidad de contenido esttico y dinmico. [32]
EvalAccess 2.0: Herramienta online que permite evaluar una pgina Web o todo
un sitio Web. [33]
TAW: Revisa WCAG 1.0, 2.0 y mobileOK. Dispone de versin online, para
descargar y como complemento para Mozilla Firefox. [36]
102
Total Validator: Revisa el cdigo XHTML, la accesibilidad Web y los enlaces rotos.
Dispone de una versin gratuita para descargar para Windows, OS X, Linux y como
extensin de Mozilla Firefox. y otra versin profesional de pago. [37]
103
10.
104
105
diferentes
aspectos
de
las
7.2.
7.2.1. LinkedIn
Este portal de temtica profesional ha conseguido el mayor nmero de estrellas: tres
procedentes del anlisis tcnico (que indican un nivel de accesibilidad moderado)
Algunas de las barreras de accesibilidad que presenta LinkedIn, y que le han impedido
obtener una puntuacin ms alta, son las siguientes:
108
109
Otros criterios en los que LinkedIn tambin presenta barreras para los usuarios, aunque
en menor grado, son los siguientes:
Algunos de los formularios que se necesita cumplimentar para realizar los diferentes
procesos carecen de un etiquetado correcto de sus controles; por ejemplo, a la hora de
buscar y aadir contactos. Por ello, el usuario, al intentar crear su red de contactos,
puede no saber qu datos introducir en cada campo del formulario, o quiz no
interprete correctamente los resultados presentados. Los usuarios participantes que ms
problemas han tenido en este aspecto, as como en cuanto a la informacin sobre
errores y sugerencias en los formularios, han sido los de los perfiles de resto visual,
sordera y discapacidad intelectual.
Respecto a la estructura, en el anlisis tcnico se ha encontrado que las pginas de la
Web de LinkedIn no se encuentran estructuradas de forma idnea mediante
encabezados, por lo que los usuarios que emplean lectores de pantalla pueden tener
problemas para identificar las diferentes secciones del portal. Por otra parte, el
agrupamiento de elementos homogneos mediante listas no es el correcto, de modo que
las personas usuarias de lector de pantalla pueden no llegar a hacerse una idea correcta
de la situacin de las diferentes opciones del sitio, y tener dificultades para saltar entre
las secciones del mismo.
En cuanto a las tablas de datos, las que se utilizan en este portal para presentar los
contactos encontrados no se marcan correctamente, lo que provoca, en el caso de los
usuarios que emplean lectores de pantalla, que no puedan asociar correctamente el
ttulo de las diferentes columnas con el contenido de las mismas.
Por ltimo, si bien en el anlisis tcnico se ha observado con relativa frecuencia el uso
de texto presentado en color azul sobre un fondo de color azul claro, lo que
formalmente no constituye un uso apropiado del color, los usuarios no han detectado
barrera alguna en este sentido. No obstante, es conveniente tener en cuenta la
necesidad de que el contraste entre el texto y el fondo de las imgenes sea
suficientemente alto, para evitar la aparicin de este problema.
En resumen, en la siguiente imagen se presentan los resultados derivados del anlisis
tcnico de cada uno de los criterios de accesibilidad evaluados en LinkedIn:
110
7.2.2. Twitter
Twitter, el sitio de micro blogging por excelencia, que cada da crece en nmero de
usuarios y expansin mundial, obtiene una sola estrella en el anlisis tcnico
(accesibilidad muy deficiente).
Los incumplimientos de los criterios de accesibilidad ms relevantes detectados en esta
plataforma se presentan a continuacin:
Los usuarios del perfil de discapacidad visual (ceguera) han encontrado en esta
plataforma considerables barreras en relacin con las imgenes, tanto por la carencia
de texto alternativo para muchas de ellas, como por la inadecuacin del contenido del
mismo, en las imgenes que s lo presentan, para la descripcin de las mismas. Algunos
usuarios han sealado dificultades, e imposibilidad en algn caso, para realizar el alta
en el servicio, ya que la alternativa al captcha mediante audio resulta complicada de
descifrar.
Respecto a la estructura, existen en Twitter algunos errores en cuanto a los
encabezados de seccin, para determinar las diferentes secciones de la pgina, tanto
por falta de uso de los mismos como por un uso incorrecto. Igualmente ocurre con la
agrupacin de elementos mediante listas. Esto supone una barrera muy importante para
las personas con ceguera que usan lector de pantalla para navegar, como han sealado
los propios usuarios.
111
113
11.
114
115
En la ilustracin 3, se puede apreciar que el sitio Web no cumple con los siguientes
lineamientos del diseo accesible:
La ilustracin 6 presenta el scroll que se utiliza para navegar sobre las imgenes,
claramente el portal no incluye ninguna descripcin en los botones > y <.
La ilustracin 7 y 8 presentan el foco, que a pesar de cambiar de color, no realiza de
forma consistente la navegacin a travs del teclado.
117
118
12.
TRABAJOS FUTUROS
Hoy la mayora de los usuarios discapacitados y las personas que de alguna u otra
manera estn vinculadas al tema, estn convencidos de que el escenario futuro ser el
siguiente: una web cada da ms accesible donde no slo se corregirn los problemas
pasados, sino que los avances a desarrollar, contemplarn su utilizacin por las personas
discapacitadas.
Actualmente el Grupo de Trabajo de Aplicaciones Web del W3C est trabajando en una
nueva iniciativa para hacer frente "al acceso universal a las aplicaciones web mediante
una amplia gama de dispositivos y por una gran diversidad de usuarios". [40]
Tambin se pueden encontrar iniciativas como se describe en el articulo HTML5 and
Accessibility [41], el cual es un pequeo artculo escrito por Bruce Lawson y Steve
Faulkner, en el que se muestran las nuevas caractersticas de HTML5 que pueden ayudar
a mejorar la accesibilidad de las pginas web.
Quizs lo ms interesante del artculo sea el apartado dedicado al uso de las nuevas
etiquetas estructurales de HTML5 (header, nav, section, article, footer) o al uso de los
roles de WAI-ARIA (banner, navigation, article, contentinfo).
Adems, algunos temas que se estn investigando o desarrollando y que se emplearn en
el futuro para mejorar la accesibilidad de las pginas web:
CSS: CSS3 Speech Module es una propuesta del W3C (se encuentra todava en
fase de borrador de trabajo) permite crear hojas de estilo en cascada que
definen cmo reproducir mediante un sintetizador de voz un documento XML (y,
por supuesto, una pgina web). Es de esperar que los lectores de pantalla sean
capaces de interpretar estas hojas de estilo para lograr una reproduccin ms
correcta. [42]
119
contenido, su significado y la relacin que guarda un dato con otros. Una de las
tecnologas que se propone es RDFa2. [44]
RDFa es un conjunto de extensiones de XHTML propuestas por W3C para introducir semntica en los
documentos. RDFa aprovecha atributos de los elementos meta y link de XHTML y los generaliza de forma que
puedan ser utilizados en otros elementos. Adems se ha definido una correspondencia simple que permite
extraer tripletes RDF.
120
13.
CONCLUSIONES
121
de
uso
tipo
de
la
de
de
sus
BIBLIOGRAFA
[7] T. Granollers, MPIu+a. Una metodologa que integra la ingeniera del software, la integracin
humano computador y la accesibilidad en el context de equipos de desarrollo
multidisciplinares, 2007.
122
123
[20] Federal Agency Commited to Accesible Design, [En lnea]. Available: http://accessboard.gov/gs.htm.
[27] Inclusion-Ia, Guia para las leyes de los derechos de las personas con discapacidades, [En
lnea]. Available: http://www.inclusion-ia.org/espa%F1ol/Norm/compend-usa.htm.
124
125
126