Criterios de accesibilidad

De Recursos Educativos y Discapacidad en Colombia
Saltar a: navegación, buscar

Un recurso virtual es accesible si cumple con ciertos criterios establecidos que se aplican en diferentes fases, tanto del diseño, como del acceso -válgase la redundancia- por parte del usuario. Es así como el Consorcio World Wide Web ha establecido la Iniciativa de Accesibilidad Web (WAI por las siglas en inglés de Web Accessibility Iniciative) que pretende establecer tres conjuntos de pautas dirigidas a los diseñadores-desarroladores de contenido e incluso a los diseñadores-desarrolladores de agentes de usuario y deben poder ser compatibles entre sí para lograr mayores niveles de accesibilidad en los recursos virtuales.


Introducción[editar]

Para efectos del desarrollo de este artículo, llamaremos establecimiento de un recurso web al proceso que éste atraviesa, desde el momento del diseño hasta la experiencia de usuario mediada por los agentes que la hacen posible. En este orden de ideas podemos decir que son tres los “momentos” que atraviesa un recurso web durante su camino hacia la accesibilidad, y podemos clasificarlos en el diseño-desarrollo de herramientas de autor como momento inicial, diseño-desarrollo y evaluación de contenido web como momento intermedio y diseño-desarrollo de agentes de usuario como momento final o más bien culminante del establecimiento de un recurso web. Vale la pena anotar que estas clasificaciones en “momentos” no son un criterio oficial de clasificación, pero servirán para los efectos de este artículo. Cada conjunto de pautas está dirigido a cada uno de los “momentos” del establecimiento de un recurso digital, y los tres “momentos” se asocian a ciertos componentes esenciales de accesibilidad web.


Componentes de accesibilidad web[editar]

El diseño-desarrollo de herramientas de autor, el diseño-desarrollo y la evaluación de contenido web y el diseño-desarrollo de los agentes de usuario conforman el conjunto de momentos con los que se relacionan los componentes de accesibilidad, pero estos componentes no se deben considerar de manera desagregada, pues su intercompatibilidad hará posible el aumento de accesibilidad de un recurso web, cada agente en el establecimiento de un recurso digital ha de atender a la accesibildad de los distintos componentes.

Podemos contar los siguientes como componentes esenciales de accesibilidad web:

1. Contenido (información contenida en el recurso.)

2. Agentes de usuario (navegadores, reproductores multimedia, etc.)

3. Tecnología asistiva (lectores de pantalla, teclados braile, etc.)

4. La experiencia particular de los usuarios (esto es, los “trucos” de los que se pueda valer un usuario dada su experiencia en la adaptación de diferentes recursos virtuales, su criterio frente a las tecnologías que lo asisten en el acceso, etc.)

5. Diseñadores-desarrolladores (entre los que se cuentan los autores, los codificadores e incluso usuarios que aportan contenido.)

6. Herramientas de autor (software para crear sitios web.)

7. Herramientas de evaluación (como por ejemplo validadores HTML, validadores CSS, etc.)

Uno sólo de los componentes que falle hará que se sobrecargue la exigencia de los otros, e incluso puede hacer que la accesibilidad al recurso web se reduzca o sea imposible. Pero la accesibildad de los componentes le compete a la totalidad de los participantes del establecimiento de un recurso web. Para ello la Iniciativa de Accesibilidad Web ha establecido diferentes conjuntos de pautas para lograr el canon mencionado.


Pautas de accesibilidad web[editar]

Tanto el diseño y desarrollo, como la evaluación e incluso la experiencia de usuario son objeto de la Iniciativa de Accesibildad Web. Para el diseño-desarrollo de herramientas de autor existe un conjunto de pautas, para el diseño-desarrollo y la evaluación de contenidos web exite otro conjunto de pautas y para el diseño-desarrollo de agentes de usuario la WAI también ha establecido un dictamen. Cada uno de los participantes de este proceso, cumpliendo las pautas de accesibilidad, podrá hacer que los componentes esenciales sean compatibles entre sí. La accesibilidad entonces es un proceso de construcción multilateral y de cooperación entre todos los agentes involucrados en la publicación de un recurso web.


Pautas de accesibilidad para herramientas de autor (ATAG)[editar]

Durante la etapa de diseño-desarrollo de herramientas de autor de un recurso web los autores, en aras de lograr o aumentar la accesibilidad del producto, deben atender las especificaciones propuestas por el Consorcio World Wide Web en lo referente a las herramientas de las que se valen para dicha etapa o “momento”. Tales especificaciones son las Pautas de Accesibilidad para herramientas de Autor (ATAG) 1.0, documento destinado a los desarrolladores de las herramientas de las que se valen los autores durante la etapa de diseño de un recurso web. Las herramientas de autor son, por ejemplo, productores-editores de contenido web (HTML o XML), herramientas que transforman documentos a un formato Web (filtros que transforman formatos de publicación a HTML), herramientas que producen multimedia, herramientas para la administración y publicación de contenidos web, herramientas de diseño, etc.

En Enero del año 2000, el Consorcio World Wide Web lanzó las Pautas de Accesibilidad para Herramientas de Autor 1.0 (ATAG por las siglas en inglés de Authoring Tool Accessibility Guidelines 1.0), las cuales quedan establecidas como punto de referencia oficial. No obstante, el desarrollo de las ATAG 2.0 ha sido anunciado a partir del año 2005, mas su publicación se dio apenas el 24 de noviembre de 2008 y no se ha recomendado oficialmente, hasta la fecha de elaboración de este artículo, su establecimiento como documento de referencia. Tampoco hay una versión en español del documento disponible en la Web. Quienes se encargan del diseño y desarrollo de estas pautas son el Grupo de Trabajo de las Pautas de Accesibilidad para Herramientas de Autor (AUWG por las siglas en inglés de Authring Tool Accessibility Guidelines Working Group) del Consorcio World Wide Web.


ATAG 1.0[editar]

Las ATAG 1.0 contienen 7 guías matrices. La intención de estas guías o pautas tiene dos objetos: el primero es que los desarrolladores de herramientas de autor puedan producir contenidos accesibles en los recursos web, el segundo es que los mismos desarrolladores puedan contar con una interfaz accesible para sus diseños.

Pauta 1. Apoyar prácticas de autor accesibles, como por ejemplo convertir documentos a marcas de contenido web (HTML).

Pauta 2. Generar marcas estándar para lograr la interoperabilidad en los componentes.

Pauta 3. Apoyar la generación de contenido web accesible mediante información bien estructurada e información alternativa equivalente.

Pauta 4. Proporcionar métodos para la corrección de contenido inaccesible.

Pauta 5. Integrar soluciones de accesibilidad al conjunto integrado por la apariencia y lo que se le presenta al usuario (“look and feel”).

Pauta 6. Promover la accesibilidad mediante documentación y ayuda a los autores no familiarizados con la accesibilidad web.

Pauta 7. Asegurar que la herramienta de autor sea accesible a los autores con discapacidad.

Con las pautas anteriores, los autores de contenidos web pueden lograr un camino tan seguro como es posible para hacer de la accesibilidad un canon que cubra todos los “momentos” del establecimiento de un recurso web.


ATAG 2.0[editar]

Las ATAG 2.0 se encuentran aún en desarrollo a pesar de que la actualización de su último borrador ha salido a la luz en noviembre de 2008, tienen la misma naturaleza, objetivos y destino que las ATAG 1.0, pero su alcance puede llegar a ser más amplio, pues se resumen en dos grandes partes, la parte A y la parte B. Cada una de dichas partes cuenta con una serie de principios cuya intención es que los agentes de usuario (softwares, servicios, productores de contenido, tecnologías asistivas, etc.) sean accesibles a todas las personas, especialmente a aquellas que están en condición de discapacidad. Las ATAG 2.0 se han diseñado para ser compatibles con las Pautas para la Accesibilidad de Contenidos Web WCAG 2.0 y dictan que un agente de usuario, en aras de conseguir o aumentar su accesibildad debe:

PARTE A. Hacer que la interfaz de herramienta de autor sea accesible.

Principio A.1. Las interfaces de herramientas de autor deben seguir las guías aplicables de accesibilidad.

Guía A.1.1. (Para interfaz de herramienta de autor). Asegurar que las funciones basadas en la web sean accesibles (vistas de edición, tutoriales, por ejemplo.)

Guía A.1.2.. (Para interfaz de herramienta de autor). Asegurar que las funciones no basadas en la web sean accesibles.

Principio A.2. Las vistas de edición deben ser perceptibles.

Guía A.2.1. (Para interfaz de herramienta de autor). Proporcionar alternativas equivalentes de acceso al contenido de las herramientas.

Guía A.2.2. (Para interfaz de herramienta de autor). Proporcionar acceso programático a toda la información contenida en las vistas de edición.

Guía A.2.3. Asegurar la independencia de las preferencias en la pantalla del autor.

Principio A.3. Las vistas de edición deben ser operables.

Guía A.3.1. (Para interfaz de herramienta de autor). Mejorar el acceso del teclado a las presentaciones de autor.

Guía A.3.2. (Para interfaz de herramienta de autor). Habilitar la interacción con independencia del tiempo (personas que tienen dificultades tecleando, manipulando el ratón o procesando información pueden ser protegidas de los límites de tiempo.)

Guía A.3.3. (Para interfaz de herramienta de autor). Ayudar a los autores a evitar destellos que puedan causar daño (en casos de epilepsia fotosensible, por ejemplo).

Guía A.3.4. (Para interfaz de herramienta de autor). Mejorar la navegación y la edición vía estructura de contenido (las personas que tienen dificultad al teclear o manipular el ratón se benefician cuando las herramientas de autor usan la estructura presente en el contenido para simplificar la navegación y la edición.

Guía A.3.5. (Para interfaz de herramienta de autor). Proporcionar búsqueda por medio de texto (debe existir la posibilidad de realizar búsquedas a sitios arbitrarios desde dentro de las vistas de edición, por ejemplo.)

Guía A.3.6. (Para interfaz de herramienta de autor). Proporcionar el manejo de la preferencias en la posición de íconos en la pantalla o configuraciones del teclado.

Guía A.3.7. (Para interfaz de herramienta de autor). Asegurar que las previsualizaciones son tan accesibles como los agentes de usuario.

Principio A.4. Las vistas de edición deben ser inteligibles.

Guía A.4.1. (Para interfaz de herramienta de autor). Ayudar a los usuarios a evitar y/o corregir errores de operación.

Guía A.4.2. (Para interfaz de herramienta de autor). Documentar la interfaz de usuario incluyendo las presentaciones de accesibilidad.

PARTE B. Apoyar la producción de contenido accesible.

Principio B.1. La producción de contenido accesible debe ser habilitada.

Guía B.1.1. Apoyar las tecnologías de contenido web que habilitan la producción de contenido accesible.

Guía B.1.2. Asegurar que las herramientas de autor conservan la iformación de accesibildad (que resisitan transformaciones y conversiones, etc. sin perder información, por ejemplo.)

Guía B.1.3. Asegurar que el contenido automáticamente generado es accesible.

Principio B.2. Los autores deben contar con apoyo en la producción de contenido accesible.

Guía B.2.1. Guíar a los autores para que produzcan contenido accesible.

Guía B.2.2. Asistir a los autores en la verificación de problemas de accesibilidad.

Guía B.2.3. Asistir a los autores en la corrección de problemas de accesibilidad.

Guía B.2.4. Asistir a los autores en el manejo, edición y reutilización de las alternativas equivalentes a los objetos no textuales.

Guía B.2.5. Asistir a los autores con plantillas accesibles y otros contenidos previos al autor mismo.

Principio B.3. Las soluciones de accesibilidad deben ser promovidas e integradas.

Guía B.3.1. Asegurar que se les dé importancia a las acciones accesibles de autoría.

Guía B.3.2. Asegurar que los procesos secuenciales de autor integren prácticas de autoría accesibles. (Si las consideraciones de accesibilidad son parte natural del flujo de trabajo, éstas se vuelven parte de la rutina de autoría.)

Guía B.3.3. Asegurar que estén disponibles las herramientas de autor que apoyan la producción de contenido accesible.

Guía B.3.4. Asegurar que estén documentadas las herramientas de autor que apoyan la producción de contenido accesible.

Guía B.3.5. Asegurar que cualquier práctica de autoría demostrada en la documentación es accesible.

Mediante las pautas anteriores los autores asegurarán que su componente, su parte en el establecimiento de un recurso web, es compatible con los demás componentes.


Pautas de Accesibilidad al Contenido Web (WCAG)[editar]

Las WCAG son un listado de pautas que sirven para que los contenidos web sean accesibles. La Iniciativa de Accesibilidad Web (WAI por las siglas en inglés Web Accesibility Iniciative) propone el TAW (Test de Accesibilidad Web), que pretende estandarizar todos los contenidos web de forma que eliminen las barreras para el acceso a la información para cualquier tipo de usuario sin ninguna discriminación frente a su capacidad física, la velocidad de conexión con la que cuente, el hardware al que tenga acceso o su idioma natal. El Consorcio World Wide Web ha desarrollado dos versiones de las WCAG en vista de los avances que, desde la publicación de las primeras en el año 2000, ha atravesado la web hasta el momento de la elaboración del presente artículo. Las dos versiones son las WCAG 1.0 y las WCAG 2.0. Siendo estas últimas publicadas apenas en noviembre de 2008, por lo que aún no ha sido actualizada la versión en español del documento. Cabe anotar que, pese a que las WCAG 2.0 ya fueron publicadas, el Consorcio World Wide Web no ha hecho una recomendación oficial del documento, por lo que el mismo organismo recomienda que las WCAG 1.0 continúen siendo un documento estable y de referencia. El grupo encargado del desarrollo de este documento es el Grupo de Trabajo de las Pautas de Accesibilidad al Contenido en la Web (WCAG WG por las siglas en inglés de Web Content Accessibility Guidelines Working Group.)


WCAG 1.0[editar]

Para que un contenido web sea accesible o aumente su accesibilidad puede valerse de las Pautas de Accesibilidad al Contenido Web 1.0 (WCAG 1.0) que sirven para guiar el diseño de un sitio web hacia tal canon. Son 14 en total las pautas que ha de cumplir un contenido web en su diseño y desarrollo, el Consorcio World Wide Web los cataloga así. Un contenido web, para llegar a cumplir el canon de accesibilidad, debe:

Pauta 1. Dar alternativas similares en el contenido visual y auditivo del contenido que se le presenta al usuario.

Pauta 2. No basarse en los colores. Asegurar que los gráficos y el texto puedan ser entendidos aún cuando el usuario no tenga acceso a una pantalla a colores.

Pauta 3. Utilizar marcadores y hojas de estilo y hacerlo apropiadamente. Esto es, marcar los contenidos con los elementos estructurales apropiados en lugar de elementos de presentación.

Pauta 4. Identificar el idioma usado mediante la utilización de marcadores que faciliten la pronunciación del texto abreviado o en idioma extranjero.

Pauta 5. Crear tablas que se transformen o modifiquen de forma correcta.

Pauta 6 Asegurar que las páginas que incorporan nuevas tecnologías se transformen correctamente.

Pauta 7 Asegurar que los objetos o páginas que parpadean, se mueven, se desplazan o se actualizan automáticamente puedan ser detenidos o parados.

Pauta 8. Asegurarse que la interface de usuario sigue los principios de un diseño accesible: funcionalidad de acceso independiente del dispositivo, teclado operable, voz automática, etc.

Pauta 9. Utilizar características que permitan la activación de los elementos de la página a través de diversos dispositivos de entrada.

Pauta 10. Utilizar soluciones de accesibilidad provisionales de forma que las ayudas técnicas y los antiguos navegadores operen correctamente.

Pauta 11. Utilizar tecnologías W3C (de acuerdo con las especificaciones) y seguir las pautas de accesibilidad. Donde no sea posible utilizar una tecnología W3C, o usándola se obtengan materiales que no se transforman correctamente, proporcionar una versión alternativa del contenido que sea accesible.

Pauta 12. Proporcionar información de contexto y orientativa para ayudar a los usuarios a entender páginas o elementos complejos.

Pauta 13. Proporcionar mecanismos de navegación claros y coherentes, (información orientativa, barras de navegación, un mapa del sitio, etc.) para incrementar la probabilidad de que una persona encuentre lo que está buscando en un sitio.

Pauta 14. Asegurar que los contenidos son claros y simples para que puedan ser más fácilmente comprendidos.


WCAG 2.0[editar]

Las Pautas de Accesiblidad al Contenido Web 2.0 (WCAG 2.0) han sido publicadas en noviembre de 2008 con un rango mucho más amplio que las WCAG 1.0, aunque éstas siguen siendo estables y de referencia en cuanto a sus especificaciones. El Consorcio World Wide Web sugiere que los diseñadores-desarrolladores de contenidos web sigan estas pautas para hacer que los recursos web sean accesibles a personas que tengan diversos tipos de discapacidad: ceguera y baja visión, fotosensibilidad y daltonismo, sordera y pérdida del oído, discapacidades en el aprendizaje, limitaciones cognitivas, movimientos limitados, dificultades en el habla e incluso combinaciones de diferentes tipos de discapacidad. Las WCAG 2.0 se resumen en 4 grandes guías (a diferencia de las WCAG 1.0 que ofrecían 14 guías particulares) y no pretenden dar indicaciones respecto del uso de tecnologías específicas. No obstante, las 4 guías se subdividen en otros lineamientos derivados de cada una de ellas, a estas guías el mismo consorcio ha decidido llamarlas principios.

Principio 1. Perceptibilidad. La información e interfaz del usuario deben presentarse a los usuarios de una forma en que ellos la puedan percibir.

Guía 1.1. Proporcionar alternativas de texto a todos los contenidos no textuales, de manera que todos éllos puedan ser cambiados, mediante tecnologías asistivas, por otras formas que la gente necesite (tales como aumentadores de texto, braile, lectores de pantalla, etc.)

Guía 1.2. Proporcionar alternativas a los media-contenidos basados en la imagen-movimiento (video) y en el texto-movimiento(audio). Cada media-contenido ha de poder tener una alternativa de accesibilidad equivalente (una alternativa de audio para el video, por ejemplo, y una alternativa de imagen para el audio.)

Guía 1.3. Crear contenido que pueda ser presentado de diversas formas (recurriendo a un diseño más simple, por ejemplo) sin que pierda su información o su estructura, es decir, que el contenido sea adaptable.

Guía 1.4. Hacer más fácil a los usuarios ver y oir el contenido, incluyendo la disernibilidad entre los objetos que se encuetran en el fondo y aquellos que se encuentran en primer plano mediante herramientas de interfaz de audio, máximos y mínimos de contraste, uso del color, adaptación del tamaño de los textos, imágenes de los mismos, eliminación o disminución de audio para los fondos de pantalla, etc.

Principio 2. Operabilidad. Los componentes de interfaz y navegación deben ser operables.

Guía 2.1. Teclado accesible. Hacer que la funcionalidad de los componentes estén disponibles desde el teclado.

Guía 2.2. Tiempo suficiente. Hacer posible que los usuarios tengan tiempo suficiente de leer u oír el contenido.

Guía 2.3. Ataques al usuario. No diseñar contenidos cuya presentación haga que el usuario se sienta “atacado”; por ejemplo imágenes que tiemblan o que presentan destellos.

Guía 2.4. Navegabilidad. Crear medios para que los usuarios puedan navegar, encontrar contenidos y saber en dónde se encuentran en el sitio web.

Principio 3. Inteligible. La operación y la información de la interfaz de usuario deben poder ser entendidas.

Guía 3.1. Hacer que los textos sean legibles y Inteligibles.

Guía 3.2. Hacer que la aparición y operación de los recursos web sean predecibles.

Guía 3.3. Hacer posible que los usuarios eviten o corrijan los errores que eventualmente cometan.

Principio 4. Robusto. El contenido debe tener la capacidad de ser interpretado por la más alta variedad de agentes de usuario en forma confiable, por ejemplo por tecnologías asistivas.

Guía 4.1. Maximizar la compatibilidad con los agentes de usuario actuales y futuros, lo que incluye a las tecnologías asistivas.

En el documento Web Content Accessibility Guidelines (WCAG) 2.0 cada guía cuenta con el enlace correspondiente a la explicación respectiva que, traduciendo, significa “entendiendo la guía -por ejemplo- 2.4”.


Los niveles de verificación de contenido web[editar]

Así mismo, el Consorcio World Wide Web propone 3 niveles de verificación con que se ha de contrastar cada una de las pautas anteriormente mencionadas. Esto significa que cada una de las pautas de accesibilidad mencionadas, tanto en las WCAG 1.0 como en las WCAG 2.0, debe contar con uno o varios niveles de adecuación. Dependiendo de dichos niveles en cada pauta, un recurso web podrá ser más o menos accesible.

Nivel 1 de prioridad: El diseñador y desarrollador del contenido web tiene que satisfacer este punto. De otra forma uno o más grupos de usuarios encontrarán imposible acceder a la información del documento. Satisfacer este punto de verificación es un requerimiento básico para que algunos grupos puedan usar los documentos Web.

Nivel 2 de prioridad: El diseñador y desarrollador de contenidos de páginas Web debe satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán dificultades en el acceso a la información del documento. Satisfacer este punto de verificación eliminará importantes barreras de acceso a los documentos Web.

Nivel 3 de prioridad: El diseñador y desarrollador de contenidos de páginas Web puede satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán alguna dificultad para acceder a la información del documento. Satisfacer este punto de verificación mejorará la accesibilidad de los documentos Web.

Podemos ejemplificar lo anterior para entender estas pautas en el criterio de accesibilidad web. Un objeto virtual cualquiera sigue la Pauta 2 de las WCAG 1.0 (no fiarse de los colores). Pero esta pauta debe ser satisfecha en el nivel de prioridad 1 en la totalidad de la información expuesta en el contenido a fin de que no resulte imposible el acceso a dicha información. El mismo objeto virtual también debe satisfacer el nivel de prioridad 2 para las imágenes (no deben depender de los colores), de otro modo quien se acerque a él encontrará dificultades en el acceso a la información y, por último, el mismo objeto ha de cumplir con el nivel de prioridad 3 para esta pauta (la número 2) en lo referente al texto, de otro modo el usuario encontrará ciertas dificultades a la hora de acceder a la información de dicho recurso.


Los tres niveles de adecuación del contenido web[editar]

Las pautas de accesibilidad y los tres niveles de verificación son los criterios que el Test de Accesibilidad Web (TAW) considera para la adecuación de un objeto virtual. Con esto, la estandarización web emite tres tipos de adecuación conformes a las pautas de accesibildad y niveles de prioridad con que un objeto virtual cumpla. Por eso exite la adecuación de nivel (A), que quiere decir que un objeto virtual, siguiendo las pautas de accesibilidad, satisface el nivel de prioridad 1 en todos sus puntos. En la adecuación de nivel (AA) se satisfacen todos los puntos de verificación en los niveles de prioridad 1 y 2. Y en la adecuación de nivel (AAA) se satisfacen todos los puntos de verificación en los niveles de prioridad 1, 2 y 3.

Lo anterior significa que un objeto virtual que, por ejemplo, cuente con la calificación (AAA) en su adecuación es un objeto virtual completamente accesible, pues sigue las 14 pautas de accesibilidad de las WCAG 1.0 (considerando que éstas continúan en vigencia) satisfaciendo los tres niveles de prioridad en su diseño y desarrollo. No obstante, las otras dos opciones de adecuación ((A) y (AA)) sirven como evaluador de objetos virtuales que cumplen parcialmente o no cumplen con las pautas de accesibilidad propuestas por el Consorcio World Wide Web.


Pautas de accesibilidad para los agentes de usuario (UAAG)[editar]

Las Pautas de Accesibilidad para los Agentes de Usuario (UAAG por las siglas en inglés de User Agent Accesibility Guidelines) están destinadas a los diseñadores y desarrolladores de estos componentes esenciales. La definición de “agente de usuario” es amplia, pues va desde los software diseñados para acceder a la Red Global Mundial (World Wide Web), como navegadores y buscadores, pasando por los mismos aparatos que tienen la facultad de acceder a conexiones de red (teléfonos móviles, por ejemplo), hasta las tecnologías asistivas diseñadas para la población con discapacidad, como navegadores braile, lectores de pantalla y demás tecnologías de apoyo.

El Consorcio World Wide Web ha desarrollado una serie de pautas de accesibilidad para los encargados de diseñar este tipo de tecnologías. Nuevamente, las UAAG cuentan con dos versiones, las UAAG 1.0 y las UAAG 2.0 (publicadas en marzo de 2008 y que no han sido recomendadas oficialmente por el Consorcio World Wide Web). Sin embargo, son las UAAG 1.0 las pautas estables y de referencia hasta el momento de elaboración de este artículo.

Las Pautas de Accesibilidad para los Agentes de Usuario (UAAG) también tienen como objetivo satisfacer las necesidades de usuarios más allá de aquellos con discapacidad, por ejemplo, los diseñadores de políticas públicas o aquellos que deseen sugerir dichas pautas a otro público relacionado con la accesibilidad y el diseño de software, como los mismos proveedores de agentes de usuario. Quienes se encargan del desarrollo de estas pautas son el Grupo de Trabajo de Pautas de Accesibilidad para Agentes de Usuario (UAWG por las siglas en inglés de User Agent Accessibility Guidelines Working Group.)


UAAG 1.0[editar]

Publicadas en diciembre de 2002, las UAAG 1.0 tienen 12 pautas que se establecen como principios de accesibilidad de agentes de usuario para reducur las barreras de accesibilidad web posibles en población con diferentes tipos de discapacidad. El documento de las UAAG 1.0 no sólo está destinado a desarrolladores de browsers HTML o de reproductores multimedia, también está destinado a los diseñadores y desarrolladores de tecnologías asistivas porque explica qué tipo de información y control puede esperar una tecnología tal de un agente de usuario adecuado. Así las cosas, los agentes de usuario deben:

Pauta 1. Apoyar la independencia de los dispositivos de entrada y de salida. Esto es, los desarrolladores deben asegurar que la interface de usuario se conforme de manera tal que el usuario pueda manejarla con varias alternativas de dispositivos (teclado, mouse, comandos de voz, dispositivos sensibles al tacto, al aire, etc.), y pueda percibir la información de diferentes formas (texto, imagen, audio, braile, etc.)

Pauta 2. Asegurar al usuario el accceso a todo el contenido. Esta pauta requiere dentro de sus puntos de validación que el agente de usuario proporcione acceso a todo el contenido mediante una serie de mecaniosmos complementario, de modo que si falla uno, otro pueda proporcionar cierto acceso en su defecto.

Pauta 3. Impedir que el contenido sea opacado por la configuración de otros contenidos que puedan confundir al usuario, como íconos que se presenten en destellos (contraproducentes para personas con epilepsia, por ejemplo), configuraciones que puedan distraer al usuario (contraproducentes para personas con discapacidad cognitiva, o déficit atencional), etc.

Pauta 4. Asegurar que el usuario pueda controlar la conversión de estilos. Esto es, que el usuario pueda elegir diferentes estilos en el contenido proporcionados por el agente de usuario (tipo de color, contraste, tamaño de los textos, etc.)

Pauta 5. Asegurar que el usuario tenga control sobre el comportamiento de la interfaz de usuario.

Pauta 6. Implementar interfaces de programación interoperables que se comuniquen y sean compatibles con otros softwares (como las tecnologías de apoyo, por ejemplo.)

Pauta 7. Cumplir las convenciones de ambientes operables (el ambiente que gobierna la operación del agente de usuario, si es un sistema operativo o un ambiente de lenguaje de programación como Java, por ejemplo) para las interfaces de usuario (botones, barras de herramientas, etc.), la documentación, configuración e instalación de los dispositivos de entrada (input devices).

Pauta 8. Implementar las especificaciones que beneficien la accesibilidad. Esto es, apoyar las presentaciones de accesibilidad de todas las especificaciones implementadas y recomendadas por el Consorcio World Wide Web cuando sea necesario para una labor específica (por ejemplo, que el agente de usuario se adapte al nivel A de adecuación en el acceso a un contenido).

Pauta 9. Proporcionar acceso al contenido mediante una gran variedad de mecanismos de navegación.

Pauta 10. Orientar al usuario proporcionando información que lo ayude a comprender el contexto de navegación (dónde se encuentra, cómo llegó hasta allí, a dónde puede ir, etc.)

Pauta 11. Permitir configuración y personalización por parte del usuario.

Pauta 12. Proporcionar documentación y ayuda accesible de los agentes de usuario. La documentación debe ser accesible, el usuario debe poder aprender sobre las presentaciones del software que benefician la acccesibilidad a partir del uso del mismo.


UAAG 2.0[editar]

Tienen la misma naturaleza, objetivo y destino que las UAAG 1.0 pero, como sucede en los otros conjuntos de pautas, se resumen en principios más generales, en este caso 5. Un agente de usuario que atienda a estos principios promoverá la accesibilidad a través de su propia interfaz y de otros componentes y habilidades de funcionamiento, incluyendo su comunicación y compatibilidad con otras tecnologías (especialmente las tecnologías asistivas). No solamente los usuarios con discapacidad encontrarán más usables estos agentes. Un agente de usuario, en aras de ser accesible o aumentar su accesibilidad debe:

Principio 1. Seguir las especificaciones y convenciones aplicables.

Principio 2. Facilitar el acceso por tecnologías asistivas.

Principio 3. Asegurar que la interfaz de usuario se puede percibir (alternativas de texto para contenidos no textuales, por ejemplo).

Principio 4. Asegurar que la interface de usuario es operable (acceso completo desde el teclado, dispositivos de comandos de vos, etc., por ejemplo.)

Principio 5. Asegurar que la interface de usuario es inteligible (ayudar a los usuarios a evitar o corregir errores de operación, por ejemplo).

Cada uno de los anteriores principios cuentan con protocolos de cumplimiento relacionados con los niveles de adecuación de accesibilidad (A, AA, o AAA) que pueden ser consultadas en el documento de las UAAG 2.0.


Véase también[editar]

Tecnologías W3C

Guías breves de tecnologías W3C

estándares internacionales de accesibilidad

accesibilidad

diseño universal

Guía Breve de Accesibilidad Web

Pautas de Accesibilidad al Contenido en la Web 1.0

Introducción a la Accesibilidad Web

Guía de recomendaciones de accesibilidad web

W3C - The World Wide Web Consortium

World Wide Web Consortium (Español)

Sitios Exitosos: De los Estándares Web a la Experiencia de Usuario

Estándares web y accesibilidad en Colombia


Enlaces de interés[editar]

Introducción a las Pautas de Accesibilidad para Herramientas de Autor (ATAG)

Introducción a las Pautas de Accesibilidad al Contenido en la Web (WCAG)

Introducción a las Pautas de Accesibilidad para Agentes de Usuario (UAAG)

Test de Accesibilidad Web (TAW)

Pautas de Accesibilidad al Contenido en la Web 1.0 (en español)

Web Content Accessibility Guidelines 1.0 (en inglés)

Web Content Accessibility Guidelines (WCAG) 2.0 (en inglés)

User Agent Accessibility Guidelines 1.0 (en inglés)

User Agent Accessibility Guidelines 2.0 (en inglés)

Authoring Tool Accessibility Guidelines 1.0 (en inglés)

Authoring Tool Accessibility Guidelines 2.0 (en inglés)

AUWG Authring Tool Accessibility Guidelines Working Group.

WCAG WG Web Content Accessibility Guidelines Working Group.

UAWG User Agent Accessibility Guidelines Working Group.