Guía de accesibilidad web

Tecnologías de Asistencia 

De acuerdo con el W3C, las tecnologías de asistencia pueden ser un hardware o software que actúa como agente de usuario o interactúa junto con el agente de usuario para proveer funcionalidad y cumplir los requerimientos de usuarios con discapacidad.

La diferencia entre agentes de usuario y tecnologías de asistencia no es absoluta. Algunos agentes de usuario también ayudan a personas con discapacidad. La diferencia básica es que el agente de usuario va dirigido a una amplia y diversa audiencia, incluyendo personas con y sin discapacidad. Por otro lado, las tecnologías de asistencia van dirigidas a usuarios más específicos con ciertas discapacidades y la ayuda que ofrecen se adecúa más a las necesidades de dichos usuarios. La interacción de una tecnología de asistencia con el agente de usuario proporciona funcionalidades importantes y específicas. 

Para presentar mayor información de las tecnologías de asistencia nos apoyaremos en la clasificación de la versión oficial en español de la Norma Europea EN ISO 9999:2011 (que a su vez adopta la Norma Internacional ISO 9999:2011) llamada “Productos de apoyo para personas con discapacidad”. Dicha norma menciona la clasificación y terminología de todos los productos de apoyo existentes en el mercado actual para personas con discapacidad. 

A continuación, presentamos algunos ejemplos de productos relacionados con las tecnologías de la información y el uso de internet.

Dispositivos de entrada 

Teclados

Existen teclados alternativos a los tradicionales, entre ellos:

Teclado de gran tamaño para facilitar la pulsación de las teclas, recomendado para personas con problemas de movilidad y/o visión.

BJADAPTACIONES (2014). Teclado BigKeys LX Blanco Qwerty. Fotografía.
https://bjadaptaciones.com/teclados/191-teclado-bigkeys-plus-blanco-qwerty.html?search_query=teclados&results=15

Teclado inalámbrico con teclas de gran tamaño para facilitar su pulsación y un código de color que permite identificar los grupos de letras de forma sencilla y rápida.

BJADAPTACIONES (2014). Teclado Simplyworks. Fotografía.
https://bjadaptaciones.com/teclados/192-teclado-clevy.html?search_query=teclados&results=15

Teclado estándar con cobertor metálico que facilita la pulsación de las teclas evitando pulsaciones involuntarias, especial para personas con discapacidades motrices. Evita seleccionar teclas incorrectas y permite descansar las manos.

BJADAPTACIONES (2014). Teclado con cobertor metálico. Fotografía.
https://bjadaptaciones.com/teclados/180-teclado-con-cobertor-metalico.html?search_query=teclados&results=15

Teclado braille inalámbrico que permite escribir en PC o smartphone, representando caracteres mediante la pulsación simultánea.

Tecno Accesible (2011). Teclado Braille. Fotografía.
https://tecnoaccesible.net/content/bluetype

          Dispositivos de entrada alternativos

Algunos ejemplos de estos son escáneres ópticos, pantallas táctiles, guantes de datos, interfaces cerebro-computadora o unidades de reconocimiento de voz. Los programas de reconocimiento de voz permiten al usuario dar comandos e información a través de la voz, lo que hace posible crear documentos de texto, enviar correos electrónicos, realizar búsquedas en internet, etc. 

         Software de entrada 

Se incluyen, por ejemplo, controladores para un solo dedo y teclados virtuales en pantalla. Los teclados en pantalla proveen la imagen de un teclado que permite al usuario seleccionar las teclas con un mouse, con una pantalla táctil (touch screen), con una palanca de mando (joysticks), con un pulsador (switch), etc. También se incluye el software para el tratamiento del texto, programas de autoedición, procesadores de texto con acceso alternativo o accesorios para procesadores de texto y software para sistema braille. 

      - Productos de apoyo para posicionar el puntero y seleccionar elementos en la pantalla del ordenador. 

Existen alternativas que simulan la funcionalidad de un mouse estándar y se adaptan a las necesidades específicas del usuario. Por ejemplo, un mouse de bola que permite controlar el cursor con el movimiento de los dedos o una mano u otro mouse que permite el control con el movimiento de la cabeza, los labios o ligeros movimientos de dedo. Algunos ejemplos más detallados son los siguientes:

Dispositivo para usar el mouse con el mentón.

BJADAPTACIONES (2014). BJOY Chin Fotografía
https://bjadaptaciones.com/ratones-bjoy/211-bjoy-chin.html?search_query=BJOY&results=13

Dispositivo para acceder mediante sus ocho pulsadores a las funciones del mouse.

BJADAPTACIONES (2014). BJOY Button Fotografía.
https://bjadaptaciones.com/ratones-bjoy/212-bjoy-button.html?search_query=BJOY&results=13

Dispositivo para controlar la computadora con un ligero movimiento de los dedos.

BJADAPTACIONES (2014). BJOY Hand-A. Fotografía.
https://bjadaptaciones.com/ratones-bjoy/238-bjoy-hand-a.html?search_query=BJOY&results=13

Mouse (trackball) para personas con problemas de motricidad en las extremidades superiores que puedan controlar la palma de su mano, con un cobertor en metacrilato para reducir las pulsaciones involuntarias.

BJADAPTACIONES (2014). Cobertor para trackball de bola gigante. Fotografía
https://bjadaptaciones.com/cobertores-para-trackball/196-cobertor-para-trackball-de-bola-gigante.html

Dispositivo señalador con la cabeza que sustituye a un ratón convencional, pensado para personas con dificultades de movilidad en las extremidades superiores.

BJADAPTACIONES (2014). Tracker PRO. Fotografía.
https://bjadaptaciones.com/con-la-cabeza-boca-o-labios/225-tracker-pro.html?search_query=tracker&results=3

Dispositivo de señalamiento llamado apuntador de cabeza (head pointer) usado para controlar el cursor en la pantalla, sin el uso de las manos, en pantallas táctiles de celulares o tablets.

Zyteq Pty Ltd (2014). Head Pointers. Fotografía.
http://www.zyteq.com.au/products/pointers/head_pointers

También existen otras alternativas como palancas de mando (joysticks) manipulables con la mano, pie, etc., utilizadas por personas afectadas por parálisis cerebral o discapacidades motrices. Por ejemplo:

Mouse basado en un joystick con botones grandes y accesibles.

BJADAPTACIONES (2014). BJOY Stick-C. Fotografía.
https://bjadaptaciones.com/ratones-bjoy/217-bjoy-stick-c.html?search_query=stick&results=4

Joystick extra sensible para ser utilizado por personas con poca fuerza y/o movilidad en las manos.

BJADAPTACIONES (2014). Mouse tipo joystick: Optima. Fotografía.
https://bjadaptaciones.com/con-la-mano/210-mouse-tipo-joystick-n-abler.html?search_query=mouse&results=75

Otros ejemplos pueden ser interruptores o pulsadores (switches) y otros dispositivos de entrada que son utilizados por personas con discapacidad física para activar o desactivar funciones:

Pulsador con sistema de montaje adaptable a superficies planas o redondas.

AbleNet, Inc. (2014). Universal Mounting System. Fotografía.
https://www.ablenetinc.com/technology/mounting/gooseneck-mounting-system

Pulsador que puede ser activado con una ligera presión en cualquiera de sus puntos.

BJADAPTACIONES (2014). Conmutador Specs. Fotografía.
https://bjadaptaciones.com/precisos/7-conmutador-spec.html?search_query=conmutador&results=106

Pulsador que permite acceso con uno o dos conmutadores y se conecta a su dispositivo a través de Bluetooth

BJADAPTACIONES (2014). Blue2 Bluetooth Switch. Fotografía
https://bjadaptaciones.com/acceso-a-dispositivos-ios-apple/33-blue2-bluetooth-switch.html?search_query=blue2&results=1

Así mismo existen otros sistemas como el de aspirar y soplar (sip and puff) que permite activaciones al inhalar y exhalar.

BJADAPTACIONES (2014). Sip-n-Puff Behind-the-Neck USB Headset and Switches for PC/Mac/Wii/PS3. Fotografía.
http://www.broadenedhorizons.com/sip-n-puff-usb-neck-headset-switches

 

Dispositivos de salida

Existen presentaciones alternativas con el fin de mejorar la visualización del contenido. Por ejemplo, pantallas de visualización, impresoras, plotters y sintetizadores. 

Pantallas y accesorios visuales

Dispositivos que presentan visualmente la información de una computadora y accesorios para ampliar o mejorar el texto (cambio de tamaño del texto, del tipo de letra, de colores, contrastes, etc.) y las imágenes en la pantalla.

Se incluyen, por ejemplo, pantallas con caracteres grandes, pantallas para la reducción de reflejos y magnificadores de pantalla. 

Los magnificadores, aumentan o disminuyen un área en particular de la pantalla para mejorar la visibilidad del usuario.

También se incluyen indicadores luminosos (light signaler alerts) que alertan con señales de luz, movimientos vibratorios o sonido, cuando, por ejemplo, llega un nuevo correo o algún comando se realizó con éxito.

Harris Communications, Inc. (2014). Sonic Alert Sonic-Connect 2 Audible Message Alert. Fotografía.
http://www.harriscomm.com/index.php/sonic-connect2-message-alert-audible-alarm.html

 

           Dispositivos para la presentación táctil de información  

Se incluyen dispositivos que presentan la información de la computadora de manera táctil. Por ejemplo, líneas braille y pantallas gráficas táctiles.

Una línea braille (Refreshable Braille displays) es un dispositivo electrónico que provee salida de contenido en código braille. Dicho dispositivo sube y baja los puntos de las celdas que conforman los caracteres braille para que el usuario ciego o sordo-ciego pueda de forma táctil consultar la información. Dicho dispositivo, también cuenta con botones para moverse en el texto y refrescar la actualización de contenido.

          Impresoras

Se incluyen impresoras o plotters para braille. 

Una impresora braille es un dispositivo electrónico que sobresalta en papel los puntos de las celdas que conforman los caracteres braille, para ello existen programas de traducción de texto a braille.

       Dispositivos para la presentación sonora de la información

Dispositivos que presentan la información de un ordenador de manera audible mediante palabras u otros sonidos. 

Se incluyen procesadores de palabra que son programas que proveen el audio de las palabras escritas en la computadora a través de un sintetizador de voz, y que generalmente tienen funcionalidades para pausar, repetir y aumentar el tamaño del texto (para personas de baja visión).

School Health, enablemart. (2013). Talking Word Processor. Fotografía.
http://www.enablemart.com/talking-word-processor

 

También se incluyen, por ejemplo, sintetizadores de voz usados por personas con discapacidad cognitiva, de lenguaje y de aprendizaje, para convertir el texto en síntesis de voz como apoyo al aprendizaje de la pronunciación y ortografía. También ayuda a personas que no pueden comunicarse oralmente, pero sí pueden escribir. Una de las características de este dispositivo, es que puede transferir notas a la computadora para edición, respaldo e impresión.

RDG Kompagne. (2014). Allora 2. Fotografía.
http://www.rdgkompagne.nl/producten/Communicatiehulpmiddelen/Tekstsystemen/Allora-2

 

        Software de salida especial

Se incluyen, por ejemplo, software que amplía el texto y los gráficos mostrados en una pantalla de computadora (como lo vimos anteriormente), software que lee la pantalla y transforma lo leído en voz (lector de pantalla).

Lector de pantalla 

Es un software que convierte toda la información de la pantalla, incluyendo texto, botones, menús, etc. en una voz sintetizada. Es decir, un lector de pantalla transforma una interfaz gráfica en audio y es esencial para que personas ciegas puedan utilizar equipos de cómputo y navegar en internet, generalmente apoyándose en comandos propios del lector de pantalla. 

Los lectores de pantalla también son usados por personas con dificultades para leer, personas que comprenden mejor el texto cuando lo escuchan simultáneamente, personas que están aprendiendo un idioma, etc. 

Hoy en día existen diferentes lectores de pantalla en el mercado, cada uno tiene sus características de funcionamiento y configuración, así como sus ventajas y desventajas. A continuación, se mencionan algunas de las características de los lectores de pantalla más conocidos.

Non Visual Desktop Access (NVDA):

http://www.nvaccess.org/

Es un lector de pantalla gratuito desarrollado por NV Access para sistema operativo Windows y tiene las siguientes características:

• Soporta aplicaciones web, incluyendo navegadores (como Internet Explorer, Firefox y Chrome) y programas de Microsoft Office. 
• Se puede instalar directamente en la computadora o ejecutarse desde una memoria USB u otro medio portátil. 
• Es multilenguaje (44 idiomas). 
• Reporta el formato del texto cuando está disponible, como nombre del tipo de letra y tamaño, estilo y errores de ortografía. 
• Lee el texto que es señalado por el cursor con el mouse o el texto seleccionado con el teclado y opcionalmente indica la posición del mouse. 
• Cuenta con salida para utilizar líneas braille.
• Cuenta con instalador guiado con audio disponible.  
• Soporta interfaces de accesibilidad comunes, incluyendo Java Access Bridge. 
• Soporta Símbolo del sistema Windows y aplicaciones de consola. 

 

Job Access With Speech (JAWS):

http://www.freedomscientific.com/products/fs/JAWS-product-page.asp

Es un lector de pantalla desarrollado por Freedom Scientific para sistema operativo Windows. El costo de la licencia de JAWS Standard (sólo para ediciones de Windows “Home”) es de $895.00 USD, mientras el costo de JAWS Professional es de $1,095.00 USD. 

Adicional a los precios anteriores, por $200.00 USD más el usuario puede contratar el servicio de Acceso Remoto y/o por otros $200.00 UDS el Acuerdo de Mantenimiento de Software para recibir hasta el 50% de descuento en las siguientes dos actualizaciones. 

• Soporta el uso de programas, la edición de documentos y la navegación de sitios web.
• Es compatible con Lotus Symphony, Lotus Notes, Microsoft Office, MSN Messenger, Corel Wordperfect, Adobe Acrobat Reader, etc.
• Funciona en los navegadores Internet Explorer y Firefox. 
• Es multilenguaje (10 idiomas).  
• Cuenta con salida para utilizar líneas braille.
• Es configurable para adaptarse a las necesidades y preferencias del usuario. 
• Cuenta con instalador guiado con audio disponible.

Nota: Existe una versión de prueba gratuita que se puede usar los primeros 40 minutos. 

Window-Eyes:

http://www.synapseadaptive.com/gw/wineyes.htm

Es un lector de pantalla desarrollado por GWMicro para sistema operativo Windows, su precio online es de $895.00 USD y otros $300.00 USD por el Acuerdo de Mantenimiento de Software. O $39.00 USD por una prueba de 60 días. 

• Es compatible con Microsoft Office, Lotus Notes, Adobe Acrobat Reader, Flash, iTunes, entre otros. 
• Funciona en los navegadores Internet Explorer y Firefox. 
• Es multilenguaje (30 idiomas o más). 
• Cuenta con Acceso Remoto 
• Cuenta con salida para utilizar líneas braille.
• Soporta Java Access Bridge.
• Lee el texto que es señalado por el cursor con el mouse.
• Presenta la información en una página virtual diferente.
• Ofrece la opción de pago de la licencia mensual y sin necesidad de pago por actualizaciones.
• Está disponible gratuitamente en la compra de la licencia de Office 2010, 2013 o 365.

System Access:

http://www.serotek.com/systemaccess

Es un lector de pantalla desarrollado por Serotek para sistema operativo Windows. 

Los precios de la licencia van desde los $400.00 USD para la versión estándar o $500.00 USD para la versión móvil. También se cuenta con la disponibilidad de hacer pagos mensuales. 

• Cuenta con Acceso Remoto y una versión móvil.
• Es compatible con Microsoft Office, Internet Explorer, Outlook Express Email, Windows Mail, Skype, iTunes, etc.
• Cuenta con salida para utilizar líneas braille.
• Cuenta con variedad de configuraciones de acuerdo al presupuesto del usuario.
• Las actualizaciones no tienen costo. 

Voice Over:

http://www.apple.com/mx/accessibility/osx/voiceover/

Es un lector de pantalla integrado en todos los dispositivos Mac.

• Se encuentra disponible en más de 30 idiomas. 
• Ofrece compatibilidad plug-and-play para monitores braille. 
• Funciona con todas las apps incluidas en iOS, como Safari, Mail, App Store, iTunes, Música, Calendario, Recordatorios y Notas.

SuperNova:

http://www.yourdolphin.co.uk/productdetail.asp?id=5

Es un lector de pantalla para sistema operativo Windows desarrollado por Dolphin. El precio de la licencia es de $795.00 USD.

• Cuenta con salida para utilizar líneas braille.
• Funciona con aplicaciones como Microsoft Office, Internet Explorer, Windows Media Player, Skype, etc. 
• Es multilenguaje (20 idiomas o más). 
• Cuenta con una versión móvil.

Thunder:

http://www.screenreader.net/index.php?pageid=11

Es un lector de pantalla gratuito desarrollado por Sensory Software Ltd.

• Funciona correctamente en Internet Explorer (con ayuda de webbIE, su navegador de texto).
• Compatible con Outlook, Microsoft Word, Wordpad y bloc de notas.

WebAnywhere:

http://webanywhere.cs.washington.edu/beta/index.php?locale=es

Es un lector de pantalla gratuito para navegar en internet que funciona preferentemente en Firefox usando la versión más reciente de Adobe Flash. El usuario entra a la liga de WebAnywhere, selecciona el idioma de su preferencia y como resultado obtiene una barra de direcciones en la parte superior de su navegador (adicional a la que existe normalmente). En la nueva barra de direcciones, el usuario ingresa la dirección URL y navega sobre la página mientras el lector menciona al usuario todos los contenidos. 

BrowseAloud:

http://www.browsealoud.com/

Es un lector de pantalla y otras herramientas de apoyo para la lectura de contenidos de páginas web desarrollado por Text Help. BrowseAloud es un javascript que se instala en los sitios web para que la página pueda tener las funcionalidades que ofrece, no tiene costo para el usuario final que navega en la página, pero sí para los dueños del sitio, quienes deben de pagar por el servicio. 

• Funciona en los navegadores Internet Explorer, Firefox, Chrome y Safari. 
• Resalta con colores cada palabra que lee para la mejor comprensión del usuario. 
• Tiene la funcionalidad (opcional) de traducir la página web.
• Tiene la funcionalidad (opcional) de simplificar la vista.
• Tiene la funcionalidad de aumentar el tamaño del texto que se está leyendo.
• Cuenta con otras configuraciones personalizadas para cambiar de colores y/o tamaños de texto. 
• Tiene la opción para generar archivos .mp3 del texto seleccionado.
• No funciona en páginas que utilizan frames o flash. 

ChromeVox:

https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmljglcjbhoiplfn

Es una extensión de Chrome que integra un lector de pantalla en dicho navegador. 

Talkback:

http://developer.android.com/design/patterns/accessibility.html

Es un lector de pantalla integrado en los dispositivos Android. 

       vi. Máquinas lectoras de caracteres

Dispositivos para leer y transformar texto escrito en forma visual, sonora y táctil, los cuales se pueden almacenar en una computadora en formato de texto o audio.

Tiflo-Tecnológica. (2014). Máquina parlante portátil de lectura de textos EYE PAL OCR. Fotografía.
http://www.tecno-ayudas.com.ar/novedades.html

 

      Teléfonos para redes estándar 

Se incluyen, por ejemplo, teléfonos fijos con o sin auriculares portátiles, teléfonos manos libres, teléfonos visuales y video-teléfonos, teléfonos con señales de aviso integradas, teléfonos con internet, smartphones, etc.

Nota: Hoy en día los smartphones tienen funcionalidades de accesibilidad como aumento del tamaño de letra, zoom, cambio de colores, contrastes, reconocimiento de voz, lector de pantalla, etc.

     Teléfonos de texto

Se incluyen, por ejemplo, teléfonos móviles de texto y teléfonos con entrada/salida braille, así como teléfonos personalizados que pueden ofrecer al usuario teclas en sistema braille.

 

OWNFONE. (2014). Braille Buttons. Fotografía.
https://ownfone.myownfone.com/make-your-ownfone

 

Como podemos observar, existe una gran variedad de tecnologías de asistencia y productos en apoyo a la inclusión de personas con discapacidad y adultos mayores, lo cual debe complementarse con esfuerzos por parte de las empresas, gobiernos, organizaciones e individuos para implementar e informar a los usuarios sobre las páginas web accesibles e incluyentes. 

Cada año, empresas especializadas en tecnología ofrecen nuevos productos que ayudan a las personas con discapacidad. A continuación, presentamos algunas fotografías del año 2016, tomadas en el salón de exhibiciones de CSUN Conference (International Technology and Persons with Disabilities Conference) en San Diego. 

 

 

(2016) Volantes con freno y acelerador integrado para que personas con discapacidad motriz puedan manejar.

(2016) Teclados Braille de diferentes tamaños.

(2016) Tablet de Google configurada con dos switches que simulan la tecla de tabulador y enter.

(2016) Teléfonos para personas sordas que convierten voz a texto.

(2016) BrainPort, tableta flexible (con estimuladores) que se pone junto con unos lentes que captan figuras, las cuales se transmiten al cerebro por medio de la lengua.

(2016) Magnificador de documentos impresos, que además de zoom, ofrece cambios en colores y contrastes.

(2016) Impresoras Braille.

(2016) Phoenix Embosser, impresora de gráficos táctiles y PIAF Tactile Image Maker, que resalta contornos en color negro.

Estándares internacionales de accesibilidad

En la siguiente tabla, se muestra la clasificación de estándares internacionales de accesibilidad definidos por el W3C. Dichos estándares se dividen en cuatro principios fundamentales y cada principio tiene sus pautas de accesibilidad web. A lo largo de la guía veremos las diferentes pautas y los requerimientos (criterios) que deben ser cumplidos exitosamente para tener un sitio accesible ya sea nivel A, AA o AAA. 

Principios y Pautas de Accesibilidad

Principio	Pauta
1. Perceptible	1.1. Alternativas textuales
	1.2. Alternativas al contenido basado en el tiempo
	1.3. Adaptable
	1.4. Distinguible
2. Operable	2.1. Accesibilidad mediante el teclado
	2.2. Suficiente tiempo
	2.3. Evite convulsiones
	2.4. Navegable
3. Comprensible	3.1. Legibilidad
	3.2. Predecible
	3.3. Asista a la introducción de datos
4. Robusto	4.1. Compatible

Adicional a los requerimientos se harán algunas recomendaciones, las cuales son opcionales y su cumplimiento no es obligatorio para el estándar. Para su mejor comprensión también existen algunos enlaces que relacionan los requerimientos con referencias a las pautas internacionales WCAG 2.0.

A lo largo de la guía, se ofrecen algunos casos de páginas web reales que cumplen exitosamente con el criterio que se quiere ejemplificar. También se presentarán otros ejemplos de manera independiente, que no necesariamente son parte de un sitio web. 

Finalmente, tome en consideración que algunos escenarios o criterios podrán tener sus excepciones, las cuales se determinarán en cada caso. 

Principio: Perceptible

La información del contenido web debe estar disponible para los sentidos (vista, audición o tacto), ajustándose a distintas discapacidades.

Pauta: Alternativas textuales

Ofrezca alternativas textuales para todo contenido no textual.

Las alternativas textuales son importantes para hacer accesible la información que es presentada en contenidos no textuales, por ejemplo, en contenidos visuales o auditivos. 

Para esto es fundamental que el texto alternativo sea equivalente o suficiente para transmitir el contenido no textual; ya sea una imagen, una gráfica, un diagrama, un ícono, un enlace, una animación, un audio pregrabado, un video pregrabado, etc.

El texto puede convertirse mediante ayuda de otros instrumentos como las tecnologías de asistencia, en otras modalidades sensoriales: visual, auditiva o táctil. Por ejemplo, la alternativa textual puede ser presentada en audio a través de lectores de pantalla o en braille por medio de un dispositivo especializado. 

Nota: Actualmente se están realizando investigaciones para la traducción automática de texto a lenguaje de señas.

Los textos alternativos además de ayudar a personas con discapacidad, traen otros beneficios de accesibilidad a la información. Por ejemplo, usuarios con lenta conexión a internet (insuficiente para cargar las imágenes) o usuarios con navegadores de sólo texto (Lynx).

1.1.1 Escenario: Contenido no textual

Excepto si el contenido no textual es una prueba o ejercicio que sería inválida presentada en forma textual o si el contenido no textual pretende recrear una experiencia sensorial específica. En estos casos, puede sólo explicarse de manera textual las razones por las cuales no hay un texto equivalente a transmitir. 

Excepto también, si el contenido no textual ya es una alternativa al contenido textual. 

R 1.1    Requerimiento:

• Todas las imágenes que transmitan contenidos deberán tener un texto alternativo adecuado que cumpla su propósito.  (Nivel A, 1.1.1 WCAG 2.0)

Nota: Se recomienda que el texto alternativo tenga una longitud menor a 90 caracteres.Ejemplo: 

En una página donde el usuario debe elegir el color, pero no se puede ver la imagen o distinguir el color, el nombre del color está incluido en el atributo alt de la imagen.

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de alternativas textuales</title>

</head>

<body>

<p>Da clic en el color de tu preferencia:</p>

<a href="img/amarillo.PNG"><img src="img/amarillo.PNG" alt="Amarillo"></a>

<a href="img/azul.PNG"><img src="img/azul.PNG" alt="Azul"></a>

<a href="img/rojo.PNG"><img src="img/rojo.PNG" alt="Rojo"></a>

</body>

</html>

 

Adicionalmente se puede usar el atributo title para ofrecer información complementaria. Sin embargo, no se debe evitar por ningún motivo el uso de alt, ni depender del atributo title (que a pesar de ser un buen apoyo en interfaz) no es reconocido por todos los lectores de pantalla. Evite también poner exactamente el mismo contenido en alt y title debido a que (si el title es reconocido por el lector), se repetirá dos veces lo mismo. 

Otro ejemplo de descripción textual en alt es: 

 

<html> 

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplos de imagen de animales</title>

</head>

<body>

<img src="img/perico.PNG" alt="Perico">

<img src="img/conejo.PNG" alt="Conejo"> 

</body>

</html> 

 

Para mapas de imagen (imagen donde se puede dar clic en algúna área), se debe definir con el atributo alt la descripción principal o general de la imagen y en cada área también se debe usar el atributo alt. 

Ejemplo: 

Los círculos del siguiente mapa de imagen son enlaces y cada uno tiene su descripción.

<html> 

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de mapas de imagen</title>

</head>

<body>

<p>Da clic en el curso que desees:</p>

<img src="img/Trippo.jpg" width="420" height="270" alt="Cursos de Verano" usemap="#cursosmap">

<map name="cursosmap">

  <area shape="circle" coords="71,92,50" href="math.html" alt="Matemáticas" >

  <area shape="circle" coords="185,95,51" href="music.html" alt="Música" >

  <area shape="circle" coords="300,92,52" href="physic.html" alt="Física" >

</map>

</body>

</html>

R 1.2 Requerimiento:

• Si las imágenes son decorativas, no transmiten contenidos o cuentan con el contenido ya presenté como texto podrán ser ignoradas al tener el texto alternativo vacío (alt="") o aplicarse como fondos de imagen CSS. (Nivel A, 1.1.1 WCAG 2.0)

Este requerimiento es para las imágenes de contenido decorativo o estético.

Nota: En estos casos el alt se debe incluir, pero vacío. De no incluirlo, el lector intentará reconocer la imagen leyendo el texto incluido en el src y sabemos que dicho texto con la ruta o el nombre del archivo podría confundir al usuario.

Ejemplo:

Imagen decorativa en un blog con el atributo alt vacío.

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de imagen decorativa</title>

</head>

<body>

<img src="img/blog.PNG" alt="">

<h1>Blog<h1>

<h2>Bienvenidos a mi blog personal....<h2>

</body>

</html>

O ejemplo de bullets decorativas con alt vacío:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de imagen decorativa</title>

</head>

<body>

<p>Sitios para comprar online:</p>

<p>

<a href="http://www.amazon.com/"><img src="img/bullet.PNG" alt="">Amazon</a><br />

<a href="http://www.ebay.com/"><img src="img/bullet.PNG" alt="">Ebay</a><br />

<a href="http://www.dx.com/"><img src="img/bullet.PNG" alt="">Dealextreme</a><br />

</p>

</body>

</html>

Aún mejor, cuando las imágenes son decorativas se recomienda incluirlas en hoja de estilo:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo imagen decorativa con CSS</title>

<style>

table{

background: url(img/verde.PNG) no-repeat;

width: 700px;

height: 135px;

}

td{

font-size: 35px;

font-weight: bold;

text-align: center;

text-decoration-color: #CCCCCC;

}

</style>

</head>

<body>

<table>

<tr>

<td>Bienvenidos a nuestro portal</td>

</tr>

</table>

</body>

 

Nota: Las imágenes con información relevante no deben estar en la hoja de estilo.

R 1.3 Requerimiento:

• Todas las imágenes enlazadas o enlaces contarán con un texto descriptivo. (Nivel A, 1.1.1 WCAG 2.0, 2.4.4 WCAG 2.0)

Ejemplo:

Si una imagen es un enlace, una breve descripción del destino del enlace debe incluirse en el atributo alt de la imagen.

https://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de enlace de imagen</title>

</head>

<body>

<a href="http://hearcolors.com.mx">

<img src="img/logo_transparente.jpg" width="180" height="98" alt="Página inicial de

HearColors">

</a>

</body>

</html>

Cuando se tienen imágenes en la hoja de estilo que son enlaces, una opción para introducir el texto alternativo sin que se vea en interfaz o afecte el diseño deseado es el siguiente ejemplo (display: block; text-indent: -9999px;).

Nota: Para mayor practicidad del ejemplo el estilo está dentro del HTML, sin embargo en el diseño de su página deberá crear hojas de estilo propias.

logoTwitter

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Imágen con texto oculto</title>

<style>

a{

background: url(img/twitter.png) no-repeat;

display: block;

text-indent: -9999px;

width: 118px;

height: 115px;

}

</style>

</head>

<body>

<a href="https://twitter.com/@Hear_Colors">Siguenos en Twitter de Hearcolors</a>

</body>

</html>

Nota: esta opción volverá accesible la imagen para usuarios con lector de pantalla ya que el lector reconocerá el texto del enlace, sin embargo, no es una solución universal para todos.

Como buena práctica, las imágenes en hojas de estilo solo deben ser decorativas. Esto debido a que hay usuarios con baja visión que no utilizan lector de pantalla, pero si cambian la configuración de su navegador para invertir o modificar los colores de las páginas web que visitan y al activar esta funcionalidad, el navegador (Firefox o Internet Explorer) desaparece de interfaz las imágenes que se encuentran en la hoja de estilo. Por ello no se debe depender de imágenes que transmiten contenidos en la hoja de estilo, ya que en este caso muy particular (de usuarios que invierten colores en su navegador) estas imágenes desaparecerán y quedarán completamente inaccesibles.

En conclusión, esta opción de agregar texto descriptivo de la imagen y ocultarlo, solo debe usarse en casos especiales y no en todo el sitio, lo ideal es que las imágenes que transmiten contenidos se encuentren en el html con su alt correspondiente.

Otra alternativa para ofrecer el texto descriptivo de la imagen sin utilizar css es:

<a href="vista.html" aria-label="El sentido de la vista"></a>

Si quiere desaparecer el elemento por completo en interfaz, pero seguir siendo accesible para lectores de pantalla, puede utilizar (position: absolute; left: -9999px;):

<html>

<head>

<title>Elemento oculto</title>

<style>

a{

background: url(img/vista.PNG) no-repeat;

display: block;

position: absolute;

left: -9999px;

width: 230px;

height: 165px;

}

</style>

</head>

<body>

<a href="vista.html">El sentido de la vista</a>

</body>

</html>

Nota: Los siguientes mecanismos para esconder contenido no son accesibles, debido a que el lector de pantalla los ignora.

• visibility: hidden;
• display: none;
• height: 0;
• width: 0;
• overflow: hidden;

Nota: en general evite esconder contenido en la página debido a que (si se hace en exceso) puede existir un riesgo en la optimización y posicionamiento en buscadores. Aunque en teoría solo se penalizan los sitios que lo hacen de forma maliciosa. Para mayor información visite la siguiente liga: https://support.google.com/webmasters/answer/66353?hl=en

El texto descriptivo de imágenes, botones o íconos siempre debe ser equivalente de acuerdo al contexto de la página o al objetivo de la información que se quiere transmitir.

Por ejemplo: Este ícono significa “Contáctanos” y de nada serviría ponerle una alternativa textual que diga “ícono de sobre” ya que el usuario no entendería claramente el propósito.

Otro ejemplo: En una página de Agencia de viajes la siguiente imagen puede ser un enlace con el texto alternativo “Viajes internacionales”, mientras que en la página de una Universidad, la misma imagen puede tener el texto alternativo “Campus internacionales”.

Por otro lado, los enlaces de texto deben de ser claros y descriptivos para el usuario.

Por ejemplo:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Enlaces con texto</title>

</head>

<body>

Consulte el detalle del <a href="http://www.meteored.mx//">clima de la Ciudad de M&eacute;xico.</a><br/>
Más información sobre <a href="/products.html"> nuestros productos. </a><br/>
Leer un artículo fascinante sobre los microbios residentes <a href="http://tinyurl.com/c3z77jt"> en el cuerpo humano </a>
</body>
</html>

Nota: en los enlaces, el desarrollador debe considerar que si en todo el sitio existen múltiples enlaces que llevan a la misma página, el texto o diseño de esos enlaces deberá ser el mismo, de tal forma que sea fácil de identificar para el usuario que dichos enlaces comparten el mismo destino.

Nota: para que los enlaces sean adecuadamente reconocidos por tecnologías de asistencia, siempre utilice el tag <a><a/> con el atributo href y su destino válido correspondiente (dirección URL).

El uso de javascript: directo en href en diferentes variantes como son:
<a href="javascript:void(0)" onclick="enviar()">Enviar</a>
<a href="javascript:enviar()">Enviar</a>
<a href="javascript:;" onclick="enviar()">Enviar</a>
<a href="javascript:;" onclick="enviar()" onkeypress="enviar()">Enviar</a>
No es accesible porque depende de que el navegador admita javascript y lo tenga activo, y en caso contrario no
funcionarán.
Utilice enlaces para llevar a páginas y botones para hacer acciones.
Evite usar enlaces para hacer acciones, ya que depende de que el navegador admita javascript y lo tenga activo, en caso contrario no funcionarán.

R 1.4 Requerimiento:

• Para las imágenes complejas será necesario que su descripción detallada se ofrezca referenciada mediante un enlace a otra página. (Nivel A, 1.1.1 WCAG 2.0).

En casos de imágenes complejas (diagrama de flujo, mapa, gráfica, obra de arte, etc.) donde una breve descripción no es suficiente, se puede referenciar mediante un enlace a una descripción más detallada.

<httml>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo de imagen compleja</title>
</head>
<body>
<p>
<img src="img/grafica.PNG" alt="Gráfica que muestra mensualmente las ventas del año 2015 y
2016"><br>
<a href="desc_textual_tabla_compleja.html">Descripción textual de la gráfica</a>
</p>

</body>
</html>

La liga que contiene la descripción larga es la siguiente:
http://www.hearcolors.com.mx/Ejemplos_Guia/desc_textual_tabla_compleja.html

En este caso tendremos dos descripciones una breve (alt) y una detallada en la dirección referenciada del enlace. En la descripción detallada se deberá describir el título, tipo de gráfica, las variables, los resultados numéricos, las tendencias y todos sus elementos. Posiblemente se pueda transmitir la información más fácilmente con una tabla que contenga los datos estadísticos, los lectores de pantalla sí pueden interpretar tablas.
En este ejemplo, la imagen es el enlace que lleva a una descripción textual y auditiva.
http://www.artbeyondsight.org/mei/verbal-description-training/samples-of-verbal-description/

Otra opción para incluir la descripción larga es longdesc. Por ejemplo, en el siguiente infographic (imagen). En este caso el lector de pantalla JAWS en Internet Explorer, primero menciona la descripción del atributo alt y luego dice “pulse Alt + Enter para descripción larga”. Si el usuario presiona dichas teclas se abrirá la página web referenciada en longdesc con la descripción textual.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo de longdesc</title>
</head>
<body>
<img src="img/Marketing.jpg" alt="Process of communicating the value of a product or service
to customers, for the purpose of selling that product or service."
longdesc="descmarketing.html">
</body>
</html>

Nota: El atributo longdesc no es soportado por cualquier navegador y/o tecnología de asistencia.
El texto equivalente de una imagen cumple su propósito cuando se transmite la información de lo que representa. Las siguientes preguntas pueden servir de apoyo:

• ¿De qué es la imagen?
• ¿Qué se aprecia en la imagen?
• ¿Qué elementos contiene?
• ¿Qué propósito tiene la imagen dentro de su contexto?
• ¿La página tiene sentido sin la imagen?

Si la imagen contiene:

• Texto - Repita las palabras
• Información visual - Explíquela
• Información sensorial - Descríbala
• Nada nuevo - Ignórela

Nota: Las imágenes de alta resolución permiten consultarlas con mayor zoom, ayudando a los usuarios con problemas de visión.

R 1.5 Requerimiento:

• Los elementos de formularios de entrada de datos deberán tener etiquetas textuales (label) asociadas. (Nivel A, 1.1.1 WCAG 2.0)

Para que un usuario que navega con tecnologías de asistencia pueda saber de qué es cada entrada de datos, se debe utilizar label y relacionarse con su input.
Texto
Nótese en el siguiente ejemplo como los valores de for e id son iguales para que la etiqueta sea accesible cuando el
usuario navegue con tecla Tab y lector de pantalla.
Al incluir estos valores, cuando el lector de pantalla tenga el foco del teclado en el campo, el usuario escuchará: “Nombre: cuadro de edición” y no solamente “Cuadro de edición”. Adicionalmente al texto de la etiqueta se le podrá hacer clic para que el foco se vaya al input.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo de entrada de texto</title>
</head>
<body>
<label for="nombre">Nombre:</label>
<input type="text" id="nombre" class="form-control"/>
</body>
</html>

Nota: evite esconder la etiqueta de la interfaz de usuario.
Nota 2: evite utilizar placeholder como indicación principal o relevante de la entrada de datos (ya que desaparece al
recibir el foco y el color es muy tenue). Para ello se debe usar label, mientras que placeholder se debe utilizar solo para información complementaria que ayude al usuario.

Textarea

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de entrada de texto</title>
</head>
<body>
<label for="comenta">Comentario:</label>
<textarea id="comenta" rows="5" cols="20" class="form-control"></textarea>
</body>
</html>

 

Checkboxes
No es lo mismo que el usuario forzosamente tenga que dar clic dentro del recuadro a poder seleccionar toda la etiqueta . El uso de etiquetas también los vuelve accesibles para lectores de pantalla. Visite la siguiente liga para ver su funcionamiento:
http://www.hearcolors.com.mx/EjemplosAccesiblesHC/Check/form_check.html
Nota: Adicionalmente se recomienda un cambio de color y subrayado al colocar el mouse sobre la etiqueta y al recibir el foco para visualmente decir que se puede hacer clic.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo Foco Checks</title>
</head>
<script>
/*Funciones para obtener el evento focus*/
function parentFocus( event ) {
var e = event || window.event;
if( e.target )
e.target.parentNode.className = "focus";
else

e.srcElement.parentNode.className = "focus";
}
function parentBlur( event ) {
var e = event || window.event;
var node;
if( e.target )
e.target.parentNode.className = "";
else
e.srcElement.parentNode.className = "";
}
</script>
<style>
fieldset{
-webkit-border-radius: 8px;
-moz-border-radius: 8px;
border-radius: 8px;
width: 290px;
}
legend.label {
margin: 0;
padding: 0;
margin-left: 20px;
font-size: 100%;
font-weight: bold;
}
ul.checkbox {
margin: 0;
padding: 0;
margin-left: 20px;
list-style: none;
}
ul.checkbox li input {
margin-right: .25em;

}
ul.checkbox li {
border: 1px transparent solid;
}
ul.checkbox li:hover,
ul.checkbox li.focus,
ul.checkbox li.active {
background-color: lightyellow;
border: 1px gray solid;
width: 10em;
text-decoration:underline;
}
</style>
<body>
<fieldset>
<legend>Selecciona tu actividad favorita</legend>
<ul class="checkbox">
<li>
<input type="checkbox" id="dep" onfocus="parentFocus(event)" onblur="parentBlur(event)">
<label for="dep">Deportes</label>
</li>
<li>
<input type="checkbox" id="leer" onfocus="parentFocus(event)" onblur="parentBlur(event)">
<label for="leer">Lectura</label>
</li>
<li>
<input type="checkbox" id="inv" onfocus="parentFocus(event)" onblur="parentBlur(event)">
<label for="inv">Investigación</label>
</li>
<li>
<input type="checkbox" id="viaj" onfocus="parentFocus(event)" onblur="parentBlur(event)">
<label for="viaj">Viajar</label>

</li>
</ul>
</fieldset>
</body>
</html>

Combobox

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo de ConboBox</title>
</head>
<body>
<label for="nac">Entidad Federativa de Nacimiento:</label>
<select id="nac" class="form-controlcombo">
<option value>Seleccione una entidad</option>
<option>AGUASCALIENTES</option>
<option>BAJA CALIFORNIA</option>
<option>BAJA CALIFORNIA SUR</option>
<option>CIUDAD DE MÉXICO</option>
<option>JALISCO</option>
<option>MÉXICO</option>
</select>
</body>
</html>

Si las opciones son demasiadas o se desean clasificar, se pueden agrupar con optgroup para mejorar la usabilidad.

Nota: No todos los lectores de pantalla soportan optgroup, si este es el caso sólo se ignora.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplo con optgroup</title>
</head>
<body>
<label for="favmovie">Pel&iacute;cula de preferencia: </label>
<select id="favmovie" name="favmovie">
<optgroup label="Misterio">
<option value="1">Oblivion</option>
<option value="2">Black swan</option>
<option value="3">Tren de noche a Lisboa</option>
<option value="4">Sin escalas</option>
</optgroup>
<optgroup label="Comedia">
<option value="5">American pie</option>
<option value="6">Scary movie</option>
<option value="7">Como Dios</option>
<option value="8">Forrest Gump</option>
</optgroup>
<optgroup label="Drama">
<option value="9">El padrino</option>

<option value="10">El caballero oscuro</option>
<option value="11">La lista de Schindler</option>
<option value="12">El sexto sentido</option>
</optgroup>
<optgroup label="Deportes">
<option value="13">Rocky</option>
<option value="14">Titanes</option>
<option value="15">Million dollar baby</option>
<option value="16">Karate kid</option>
</optgroup>
</select>
</body>
</html>

Archivos adjuntos

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Subir Archivo</title>
</head>
<body>
<label for="archi">Seleccione un archivo</label>
<input type="file" id="archi" class="form-control1">
</body>
</html>

Hasta ahora hemos visto cómo se relacionan adecuadamente las etiquetas con las entradas de datos. Esta forma es la más compatible con navegadores y tecnologías de asistencia.
Sin embargo, para casos de entradas de datos más complejas deberemos utilizar otro método que nos permitan tener mayor flexibilidad, esto se puede lograr con etiquetas de ARIA (Accessible Rich Internet Applications Suite).

• ARIA es una iniciativa de la W3C que define cómo hacer accesibles contenidos dinámicos para las personas con discapacidad.
• Creada para complementar características de accesibilidad en el HTML y aplicaciones web dinámicas (sobre todo con javascript).
• Permite especificar nombres, roles, valores y propiedades para contenido estático o dinámico.
• Comunica a lectores de pantalla información relevante sobre los componentes.
• Ejemplo y características de aria-label
  • Invisible en interfaz
  • Reemplaza el texto original del elemento
  • No hace el texto clickable

Ejemplo de múltiples campos relacionados con solo un solo label:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo aria-label</title>
</head>
<body>
<label for="cel">Teléfono celular</label>
<input type="text" size="3" maxlength="3" id="cel" aria-label="Teléfono celular, tres
dígitos del prefijo" class="form-controltel"> -
<input type="text" size="10" maxlength="10" aria-label="diez dígitos del celular"
class="form- controltel">
</body>
</html>

Como se puede observar, se respeta la forma tradicional de relacionar una etiqueta (por lo que el texto sigue siendo clickable) y se agrega aria-label para complementar. En el caso del primer input, los lectores de pantalla, reconocerán dos label´s pero le dan prioridad al aria-label. Por ello la importancia de poner completa la información en el primer aria-label.

• Ejemplo y características de aria-labelledby
  • Se relaciona el id de otro elemento.
  • Se pueden relacionar múltiples id’s de elementos.
  • El o los textos relacionados (normalmente) están visibles en la página.
  • Reemplaza el texto original del elemento (en teoría).

Ejemplo de tabla con aria-labelledby, en donde los inputs deben relacionarse con múltiples encabezados y los encabezados a su vez con múltiples inputs:

Boletos de cine

Tipo de entrada	Individual	Pareja
Compra en efectivo
Compra con TC

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Ejemplo Tabla usando aria-labelledby</title>
</head>
<body>
<table role="presentation" border="1" cellpadding="5" cellspacing="2">
<caption>Boletos del cine</caption>
<tr>
<th scope="col"><span id="prog">Tipo de entrada</span></th>
<th scope="col"><span id="ind">Individual</span></th>
<th scope="col"><span id="par">Pareja</span></th>
</tr>
<tr>
<th scope="row"><span id="compra_ef">Compra en efectivo</span></th>
<td><input type="checkbox" name="3" aria-labelledby="ind compra_ef"></td>
<td><input type="checkbox" name="4" aria-labelledby="par compra_ef"></td>
</tr>
<tr>
<th scope="row"><span id="compra_tc">Compra con <abbr title="Tarjeta de crédito">
TC</abbr></span></th>
<td><input type="checkbox" name="5" aria-labelledby="ind compra_tc"></td>
<td><input type="checkbox" name="6" aria-labelledby="par compra_tc"></td>
</tr>
</table>
</body>
</html>

• Ejemplo y características de aria-describedby
  • Se relaciona el id de otro elemento.
  • Proporciona información adicional a la del elemento.

Ejemplo de instrucciones para contraseña con aria-describedby

<html lang="es">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo Usando aria-describedby</title>
</head>
<body>
<fieldset style="width:30em;">
<legend>Registrarse:</legend>
<label for="nom">Nombre:</label>
<input type="text" maxlength="15" name="imeiNumber" id="nom" class="form-controllabel"><br
/><br />
<label for="imeiNum">* Contraseña (requerido):</label>
<input type="text" aria-describedby="info" maxlength="15" name="imeiNumber" id="imeiNum" class="formcontrollabel">
<span id="info"><br>La contraseña debe cumplir lo siguiente:<br />
Incluir caracteres en mayúscula y en minúscula.<br />
Incluir al menos un número o un símbolo.<br />
Tener al menos 8 caracteres.</span><br />
<input type="button" value="Enviar" id="btnConsulta" class="btnexam btn-primaryexam">
</fieldset>
</body>
</html>

R 1.6 Requerimiento:

• Los botones de los formularios tendrán nombres (value) descriptivos. (Nivel A, 1.1.1 WCAG 2.0)

Los botones siempre deben indicar la acción.
En el caso de html4, el texto del atributo value debe ser lo suficientemente claro para el usuario, ya que es lo que leerá la tecnología de asistencia.
Por ejemplo:

<html lang="es">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo de Botones</title>
</head>
<body>
<input type="submit" value="Enviar" class="btnexam btn-primaryexam">
</body>
</html>

Si el botón es una imagen, recuerde agregar su texto alternativo:

<html lang="es">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo de Botones</title>
</head>
<body>
<input type="image" src="img/search-148820_640.png" alt="Buscar en este sitio">
</body>
</html>

En el caso de html5, el texto del tag button, es lo que reconocerá la tecnología de asistencia:

<html lang="es">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Ejemplo de Botones</title>
</head>
<body>
<button class="btnexam btn-primaryexam">Anterior</button>
<button class="btnexam btn-primaryexam">Siguiente</button>
</body>
</html>

R 1.7 Requerimiento:

• Los elementos multimedia incrustados (object) se identificarán mediante textos que describan el contenido. (Nivel A, 1.1.1 WCAG 2.0)

Se puede usar el elemento object como solución universal para incluir objetos, ya que es soportado en los navegadores Internet Explorer, Firefox, Chrome, Safari y Opera. La descripción textual en este elemento es necesaria para usuarios que no tienen los medios necesarios para reproducir el contenido o personas con discapacidad que utilizan tecnologías de asistencia. Dicha descripción (breve o larga) dependerá del contenido que se quiera transmitir.
Nota: Para incluir imágenes (que también se puede hacer con object) recomendamos que prevalezca el uso de img.
A continuación, veremos algunas opciones:
Ejemplos con descripción textual dentro del elemento object.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Ejemplos de object</title>
</head>
<body>
<object width="300" height="300" data="flash/elefante.swf">
Animación de un elefante caminando
</object>
</br>
<!--Ejemplo de enlace-->
<object width="300" height="300" data="flash/recycling.swf">

<a hreflang="en" href="descrecycling.html">Text description of Recycling presentation.</a>
</object>
</body>
</html>

Nota: Observe en el ejemplo, como se muestra también el cambio de lenguaje del enlace.
Dicha descripción se muestra en interfaz si el contenido multimedia no se ejecuta:

Nota: Independientemente de su ejecución, dicha descripción es reconocida por algunas tecnologías de asistencia como lectores de pantalla (aunque depende del navegador utilizado).
A continuación, vemos la imagen de los elementos multimedia ejecutándose:

Nota: La mejor solución de alternativa textual es un simple enlace en interfaz (junto al contenido multimedia) que direccione a una descripción más detallada del objeto.

R 1.8 Requerimiento:

• Los marcos (frames o iframes) tendrán un título apropiado. (Nivel A, 2.4.2 WCAG 2.0)

Para frames de html4, agregar el título ayuda a usuarios que navegan con lectores de pantalla para saber su ubicación en la página.
Al utilizar iframes para insertar redes sociales, mapas de Google o videos, el title sirve para informar al usuario el contenido. Aunque no todos los lectores reconocerán el texto del title del iframe, éste debe ofrecerse.
Ejemplo de frame:

<html>
<head>
<title>Ejemplo de frame</title>
</head>
<frameset cols="10%, 90%">
<frame src="nav.html" title="Menú Principal" />
<frame src="doc.html" title="Documentos" />
<noframes>
<body>
...
</body>
</noframes>
</frameset>
</html>

<html lang="es">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Video en Iframe</title>
</head>
<body>
<iframe width="560" height="315" src="https://www.youtube.com/embed/eZQyuXmQyfg" frameborder="0" allowfullscreen title="Accesibilidad en celulares: Iphone, Android y Windows"></iframe></body>
</html>

Principio: Perceptible

La información del contenido web debe estar disponible para los sentidos (vista, audición o tacto), ajustándose a distintas discapacidades.

Pauta: Alternativas al contenido basado en el tiempo

Ofrezca alternativas para los contenidos basados en el tiempo.
Video, audio y multimedia
Excepto si el audio, vídeo o multimedia ha sido designado como una alternativa al contenido textual, entonces el contenido web ya funciona como alternativa (esta excepción aplica solo en nivel A).

Escenario: Solo audio o solo video pregrabado

Requerimiento:

• Se ofrecerá una transcripción únicamente para audio y otra solo para video, una alternativa de audio o una transcripción. (Nivel A, 1.2.1 WCAG 2.0)

Ofrecer una transcripción del audio beneficia a personas con sordera o problemas de audición. Dicha transcripción puede estar disponible en la misma pantalla donde se encuentra el audio o en un enlace.
Ejemplo:
En un portal religioso (https://www.lds.org/general-conference/sessions/2012/10?lang=spa) el usuario puede consultar las conferencias y sesiones realizadas, ya sea audio o transcripción.

Si el usuario da clic en el ícono de obtiene el audio o si prefiere puede consultar la transcripción de la conferencia en el ícono de iconoImpresora.
Nota: La transcripción debe ser literalmente todas las palabras habladas, siempre identificando a la persona que habla, ya sea una o varias. Adicionalmente, todos los sonidos relevantes como aplausos, risas, ruidos, música, etc.

En otros casos la transcripción puede venir en un documento PDF accesible. Tome en cuenta que si va a crear contenidos de audio se recomienda lo siguiente:

• Que los sonidos de fondo sean muy bajos, ya sea música o ruido (viento, lluvia, tráfico, aplausos, conversaciones, etc.).
• Que no haya sonidos de fondo o solo cuando nadie habla.
• Que solo hable una persona a la vez.

La página de la Universidad de Washington www.washington.edu/doit/videos/?vid=60, cuenta con una colección de videos con transcripción:

Si el usuario da clic en el enlace llamado Transcript, lo lleva al texto del video:

En este transcript es interactivo, el usuario puede dar clic en la parte del texto deseado y como resultado, el video (que adicionalmente tiene subtítulos) comienza a reproducirse a partir de la sección seleccionada:

Es muy importante siempre tomar en cuenta la creación de vídeos accesibles, con lo que se tendrá un mayor alcance. Adicionalmente, en este ejemplo se tiene la opción de verlo en YouTube.

Escenario: Audio pregrabado en multimedia (Leyendas)

Requerimiento:

• Se ofrecerán leyendas (Captions) para el contenido de audio pregrabado en multimedia sincronizado. (Nivel A, 1.2.2 WCAG 2.0)

Nota: de acuerdo con la W3C, “multimedia sincronizado” se refiere al audio o video sincronizado con otro formato para presentar información y/o con componentes interactivos basados en el tiempo.

 

Las leyendas benefician a personas con discapacidad auditiva, ya que pueden recibir la información sincronizadamente.
La diferencia entre subtítulos y leyendas (Captions) es que las leyendas describen no sólo los diálogos, sino otros efectos de sonido como la música de fondo, risas, persona que habla, etc. Adicionalmente, si se habla de “Closed Caption” significa que estas leyendas son opcionales para el usuario, es decir se pueden activar o desactivar. “Open Caption” no se pueden desactivar.
Nota: Las leyendas no funcionarán para personas sordociegas, la única forma que tienen ellos de consultar el contenido es a través de una transcripción.

En las siguientes ligas puede obtener mayor información sobre la manera de agregar leyendas:

• Cómo añadir subtítulos en Youtube

https://support.google.com/youtube/answer/2734796?hl=es&ref_topic=3014331

• DIY (Do It Yourself) Resources for closed captioning and transcription

http://www.3playmedia.com/2014/08/25/diy-resources-closed-captioning-transcription/?utm_content=buffer302f5&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

En videos de Youtube se pueden agregar, editar o eliminar subtítulos. También existe la funcionalidad de subtítulos
automáticos, la cual utiliza una tecnología de reconocimiento de voz (y aunque la calidad puede variar, estos se pueden editar).
Nota: los subtítulos agregados en YouTube pueden ser reconocidos por algunas tecnologías de asistencia. Por ejemplo: lectores de pantalla (como JAWS o NVDA) mencionan los subtítulos del video (siempre y cuando estén activados).
Adicionalmente Youtube ofrece al usuario otras opciones de configuración para los subtítulos como colores, tipo de letra, activar o desactivar, etc.
Por ejemplo, vea el video “Blind Skier's Edge” https://www.youtube.com/watch?v=ZpGLy-FyOc0:

 

Otro ejemplo: “No excuses for athlete going blind and deaf”
https://www.youtube.com/watch?v=hHWPOV81Hh4

 

Escenario: Video pregrabado en multimedia (Transcripción o audiodescripción)

Requerimiento:

• Se ofrecerá una transcripción o audiodescripción del contenido de video pregrabado en multimedia sincronizado. (Nivel A, 1.2.3 WCAG 2.0)

En el caso de la transcripción, como ya hemos visto se requiere proporcionar en formato de texto la información completa (tanto visual como auditiva) y con la misma secuencia del multimedia sincronizado, puede ser un guión o un libro.

Nota: Si la presentación del multimedia sincronizado requiere de interacción del usuario (por ejemplo: presione ahora para contestar la pregunta), la transcripción deberá proveer de enlaces o lo que sea necesario para obtener la misma
funcionalidad.

La audiodescripción es una narración agregada al audio para describir detalles visuales importantes que complementan lo que no puede ser comprendido por el audio principal.
En la audiodescripción estándar, cuando existen pausas en el diálogo los guionistas aprovechan para ofrecer una narración explicando lo que pasa visualmente: acciones físicas, personajes, expresiones faciales, vestuarios, cambios de escenas y textos en pantalla que son importantes y no se describen en la pista de sonido principal.
Nota: En la audiodescripción extendida se pausa el video para tener tiempo suficiente de agregar las descripciones
adicionales, pero esto es un nivel más avanzado de accesibilidad (AAA).

Este criterio beneficia a personas con discapacidad visual para que puedan tener acceso a la información presentada visualmente.
Visite la siguiente liga con ejemplos de video con audiodescripción: 

http://www.audiodescribe.com/samples/

https://www.youtube.com/watch?v=O7j4_aP8dWA

https://www.youtube.com/watch?v=B8BD9txkGL4

Otro ejemplo del cumplimiento del presente criterio puede ser una película o un documental con audiodescripción, de tal manera que las personas ciegas también puedan disfrutar del contenido. 

En las siguiente ligar puede obtener mayor información sobre audiodescripciones:

• Standard techniques in audio description:
  http://joeclark.org/access/description/ad-principles.html
• The audio description project:
  http://www.acb.org/adp/guidelines.html

Existen reproductores de vídeo que ofrecen las audiodescripciones opcionales para el usuario, es decir que se pueden activar o desactivar. Por ejemplo (observe el ícono "AD"): 

AccessibilityOZ::
http://www.accessibilityoz.com/ozplayer/#ozp-demo

Kaltura (en su versión accesible "Section 508"
http://corp.kaltura.com/Products/Features/Video-Player

Nota: los anteriores requerimientos no son obligatorios si los contenidos de audio, video o multimedia son una alternativa adicional a la información principal que ya está presente como texto. 

Escenario: Audio en vivo en multimedia (Leyendas) 

Requerimiento: 

• Leyendas (Captions) para todo el audio en vivo en multimedia sincronizado. (Nivel AA, 1.2.4 WCAG 2.0) 

El objetivo es que las personas sordas o con problemas de audición puedan entender presentaciones en tiempo real. 

Un ejemplo es cuando se transmite un seminario web en vivo (webinar), en donde mientras el presentador habla y muestra la presentación, otra persona escribe las leyendas en tiempo real.

Nota: si el webinar se graba, después se pueden ofrecer las leyendas como transcripción de la grabación del video (como en el siguiente ejemplo).

 

Consulte la siguiente liga:
http://www.3playmedia.com/how-it-works/webinars/html5-08-27-2015/?mkt_tok=3RkMMJWWfF9wsRoiv6jMZKXonjHpfsX57ugkUaK2lMI%2F0ER3fOvrPUfGjI4CTctjI%2BSLDwEYGJlv6SgFTbTBMbVk1bgLUhY%3D

Escenario: Video pregrabado en multimedia (Audiodescripción) 

Requerimiento

• Audiodescripción obligatoria para el video pregrabado en multimedia sincronizado. (Nivel AA, 1.2.5 WCAG 2.0) 

Previamente hemos hablado de la audiodescripción, dicha audiodescripción en un nivel AA es obligatoria para el video pregrabado en multimedia sincronizado. Mientras que en un nivel A permanece opcional. 

Escenario: Audio pregrabado en multimedia (Lengua de señas) 

Requerimiento: 

• Se debe proporcionar una interpretación a lengua de señas para todo audio pregrabado en multimedia sincronizado. (Nivel AAA, 1.2.6 WCAG 2.0) 

Escenario: Todo el contenido pregrabado en multimedia y solo video pregrabado (Transcripción) 

Requerimiento: 

• Se debe proporcionar una transcripción para el contenido multimedia sincronizado pregrabado y para el solo video pregrabado. (Nivel AAA, 1.2.8 WCAG 2.0) 

Escenario: Solo audio en vivo (Transcripción)

Requerimiento: 

• Se debe proporcionar una transcripción para el contenido de solo audio en vivo. (Nivel AAA, 1.2.9. WCAG 2.0) 

Insertar Audio o Video

Al insertar audios o videos, resolver problemas de compatibilidad puede ser bastante complejo al tomar en cuenta los diferentes navegadores y las tecnologías de asistencia. 

En cuanto a la accesibilidad, hay que tomar en cuenta la navegación con teclado (tecla Tab) en los controles del audio o del video: Pausa, Reproducir, aumentar o disminuir el Volumen, Silencio, Adelantar y Regresar. 

Al incrustar un video de manera independiente con el tag object, iframe, embed o video se pueden presentar problemas no solo de accesibiliad con teclado, sino para cargar el video. Por lo que se recomienda siempre hacer pruebas con teclado y lector de pantalla para verificar la correcta navegación. 

El uso del tag video de HTML5

Visite la siguiente liga, en donde se muestra un ejemplo que busca ser accesible y compatible con diferentes navegadores y lectores de pantalla:
http://www.hearcolors.com.mx/EjemplosAccesiblesHC/videoHTML5/index.html

Para ello, se necesitan los siguientes formatos: 

• .mp4
• .webm
• .swf
• .ogg
• .jpg (para usarse como póster) 
• .vtt (si el video tiene subtítulos) 

Se pueden apoyar con el uso del programa Easy HTML Video 3.2 descargable de la página http://easyhtml5video.com/es/ el cual convierte el video a los formatos requeridos.

Adicionalmente, se recomienda ofrecer al usuario dos alternativas accesibles: un enlace para reproducir el video en el programa default de la computadora (o descargar el archivo) y otra alternativa textual que describa el contenido del video (ya sea en un enlace o en la misma página). 

Puede también revisar la liga original del equipo de Paypal con el video accesible:  https://github.com/paypal/accessible-html5-video-player 

En las siguientes ligas puede consultar información para insertar audio y video accesible: 

https://w3c.github.io/webvtt/

http://mediaelementjs.com/

http://terrillthompson.com/tests/html5-audio.html

Incrustar video de YouTube

Al utilizar de manera independiente el iframe para insertar videos de YouTube podrían presentarse algunos problemas de accesibilidad dependiendo del navegador y lector utilizado. Sin embargo, se ha notado un gran avance en los navegadores y lectores de pantalla al interpretar los controles del video, por lo que los botones de Pausar, Reproducir, Compartir y Ver más tarde, si son accesibles. Puede realizar pruebas en la siguiente liga:
http://www.hearcolors.com.mx/Ejemplos_Guia/iframe.html

Principio: Perceptible

La información del contenido web debe estar disponible para los sentidos (vista, audición o tacto), ajustándose a distintas discapacidades.

Pauta: Adaptable

Cree contenido que pueda ser presentado de diferentes maneras sin perder la información o estructura. 

1.3.1 Escenario: Información y estructura 

R 1.19 Requerimiento: 

• Si el contenido tiene como propósito confirmar que el acceso ha sido realizado por un humano y no por una computadora (CAPTCHA), alternativas que se adapten a diferentes sentidos deberán presentarse. (Nivel A, 1.1.1 WCAG 2.0)

Sabemos que CAPTCHA es un test utilizado en computación que consiste en que el usuario compruebe que es un humano y no una computadora. Sin embargo, la mayoría de los CAPTCHA son completamente visuales, donde normalmente el usuario debe ingresar correctamente un conjunto de caracteres que son mostrados en una imagen distorsionada. 

El problema con la imagen distorsionada es que es completamente inaccesible para personas con discapacidad cognitiva o intelectual (como la dislexia), personas de la tercra edad que pueden fallar en la interpretación y personas con problemas de visión o ciego que utilizan lectores de pantalla, ya que estos no pueden interpretar la imagen. 

Nota: No aplica la alternativa textual ya que podría ser leída por una computadora e invalidaría el objetivo del CAPTCHA. 

Por estas razones se solicitan alternativas de CAPTCHA que se adapten a otros sentidos, como mínimo dos modalidades de CAPTCHA. 

Ejemplo de CAPTCHA con solo una modalidad (no accesible): 

Para crear una cuenta en la página de Wikipedia no se cuenta con una alternativa adicional (https://es.wikipedia.org/w/index.php?title=Especial:Entrar&returnto=Wikipedia%3APortada&type=signup&fromhttp=1) , solo imagen. 

Existen también otros CAPTCHA que, a pesar de su originialidad, no son accesibles. 

Por ejemplo: CAPTCHAS de arrastar y soltar o CAPTCHASde deslizamiento. 

Para hacer un CAPTCHA accesible, la alternativa más común a la imagen es el audio, que permite escuchar la prueba. Cuando el CAPTCHA incluye ambas modalidades (imagen y audio) se vuelve mucho más accesible. 

Por ejemplo: 

Al abrir una cuenta de correo de Microsoft se muestra un CAPTCHA con opción a sonido (puede probarlo en la siguiente lilga https://signup.live.com/). 

En el caso de Google, al abrir una cuenta también se muestran ambas opciones (puede probarlo en la siguiente liga https://accounts.google.com/).

En este ejemplo, incluso se puede seleccionar el checkbox para omitir la verificación de CAPTCHA y un posible servicio al cliente vía telefónica:

En ambas opciones (Microsoft y Google) se puede alternar de Imagen a Audio o cambiar de CAPTCHA cuantas veces lo desee el usuario. 

Nota: Algunos CAPTCHA de audio también presentan sus inconvenientes, como la distorsión del sonido, lo cual puede complicar al usuario su entendimiento si no se encuentra en un ambiente silencioso. Adicionalmente, el navegador del usuario debe tener ciertos complementos instalados para reproducir el audio. Lamentablemente hoy en día no existe el CAPTCHA perfecto que cubra a todas las discapacidades. 

Como alternativa para solucionar este requerimiento, se puede utilizar el nuevo "reCAPTCHA", un servicio gratuito y accesible que utiliza avanzadas técnicas de análisis (como movimiento del mouse, dirección IP o cookies) que le dan pistas al reCAPTCHA para determinar si es un humano o un robot. Para la mayoría de los usuarios se reduce a un checkbox (reconocido por tecnologías de asistencia) que debe ser activado. 

 

En caso de duda o riesgo, al activar el checkbox el "reCAPTCHA" solicitar la prueba de texto o imagen, las cuales siempre tendrán la opción del audio. 

Nota: esta segunda prueba puede llegar a tener algunos problemas de accesibilidad. 

A pesar de que Google ha mejorado significativamente su accesibilidad y para la mayoría de los usuarios es posible completar la prueba, se encuentran todavía algunos problemas de accesibilidad. Para mayor información visite la siguiente liga: http://terrillthompson.com/blog/682

Si desea mayor información sobre otras alternativas de CAPTCHA, visite:https://www.visionaustralia.org/business-and-professionals/digital-access-consulting/resources/blog---accessibility-and-assistive-technology-blog/blog/accessibility-blog/2014/12/09/effective-alternatives-to-inaccessible-captchas

En la siguiente liga (https://www.google.com/recaptcha/intro/index.html) se indica paso a paso la configuración del "reCAPTCHA".  Recuerde implementarlo en el idioma correcto. 

Dentro de la pauta Adaptable también se presentan los requerimientos que explicaremos a continuación, que benefician principalmente a personas con discapacidads cognitivas y de aprendizaje. 

El diseñador o programador debe contribuir utilizando su lógica y sentido común para realizar un diseño estructurado y secuencia ordenada que permita al usuario navegar y consultar el contenido fácilmente, mejorando no solo la accesibilidad, sino la usabilidad. 

R 1.20 Requerimiento:

• El marcado semántico deberá usarse apropiadamente de acuerdo a la estructura (Nivel A, 1.3.1 WCAG 2.0, 1.3.2 WCAG 2.0)

Los lectores de pantalla pueden mostrar listas de enlaces, encabezados, campos de formularios, botones y puntos de referencia (landmarks). Los usuarios conocen el atajo de teclado del lector de pantalla para obtener estas listas de elementos y navegar más fácilmente. 

Para apoyar a la estructura se ofrecen las siguientes recomendaciones: 

Utlizar roles de ARIA que describen la estructura y organizan el contenido en una página. 

role="article"

role="columnheader"

role="definition"

role="directory"

role="document"

role="group"

role="heading"

role="img"

role="list"

role="listitem"

role="math"

role="note"

role="presentation"

role="region"

role="row"

role="rowgroup"

role="rowheader"

role="separator"

role="toolbar"

Utilizar roles de ARIA creados para dividir la página en regiones que serán los puntos de referencia (landmarks) para el usuario. 

Nota: pueden venir combinados con etiquetas de html5 o versiones anteriores. 

<header role="banner"></header>

<aside role="complementary"></aside>   

<footer role="contentinfo"></footer>

<main role="main"></main>   

<nav role="navigation"></nav>

  

role="application"

role="form"

role="search"

Por ejemplo, una página web con estructura simple, podría estructurarse de la siguiente manera:

<header role="banner"></header> 

<nav role="navigation"></nav>  

<main role="main"></main>   

<section>                   

<article role="article"></article> 

</section>      

<aside role="complementary"></aside>   

<footer role="contentinfo"></footer>

También otros elementos de HTML  apoyan a la estructura, los cuales indicarán al usuario con lector de pantalla si se trata de un encabezado, lista, etc. Por ejemplo: 

Encabezados (h1 a h6) anidados apropiadamente. Los lectores de pantalla leen el nivel de encabezado (nivel 1, nivel 2, etc), por o que es una buena práctica utilizar al menos un encabezado h1 (no más de dos elementos h1) y los encabezados posteriores que sean necesarios de acuerdo al contenido. 

Nota: la especificación de HTML4 exige el uso de solo un elemento h1 por página, mientras que la especificación de HTML5 permite el uso de múltiples elementos h1, siempre que estos se encuentren dentro de elementos <article> o <section>. 

Nota: Se recomienda que el encabezado sea conciso y menor a 65 caracteres. 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo encabezados</title>

</head>

<body>

<h1>Encabezado h1: Lo m&aacute;s importante</h1>

<h2>Encabezado h2</h2>

<h3>Encabezado h3</h3>

<h4>Encabezado h4</h4>

<h5>Encabezado h5</h5>

<h6>Encabezado h6: Lo menos importante</h6>

</body>

</html>

El uso de listas también ayuda a dar estructura. 

Nota: las listas no necesariamente deben lucir como listas, se pueden usar hojas de estilo para cambiar la presentación. Por ejemplo, para crear un menú con submenús. 

Usar ul con li para listas sin orden. Algunos lectores de pantalla reconocen las listas (incluso listas dentro de listas), otros lo leen sólo como texto. La mayoría anuncian que hay una lista con el número de los elementos dentro de la lista. 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de lista sin orden</title>

</head>

<body>

   <h1>Lista de Reptiles</h1>

    <ul>

        <li>Serpientes

          <ul>

            <li>Boa</li>

              <li>Cascabel</li>

            <li>Mamba</li>

          </ul>

        </li>

        

        <li>Iguanas</li>    

        <li>Tortugas</li>

    </ul>

</body>

</html>

Usar ol con li para listas con orden.

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de lista con orden</title>

</head>

<h1>Días de la semana</h1>

<body>

<ol>

   <li>Lunes</li>

   <li>Martes</li>

   <li>Mi&eacute;rcoles</li>

   <li>Jueves</li>

   <li>Viernes</li>

   <li>S&aacute;bado</li>

   <li>Domingo</li>

</ol>

</body>

</html>

Usar dl para listas con descripciones, utilizando dt para definir nombre y dd para definir su descripción. 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo de lista con descripciones</title>

</head>

 

<body>

 

<dl>

  <dt>Caf&eacute;</dt>

        <dd> Bebida que se obtiene a partir de las semillas tostadas y molidas</dd>

  <dt>T&eacute;</dt>

        <dd> Infusi&oacute;n de hojas y brotes de la planta</dd>

</dl>

</body>

</html>

También es importante que los elementos de la página sean consistentes, de tal manera que permanezcan faciles de entender para los usuarios. Esto beneficia principalmente a usuarios con discapacidad cognitiva y visual (que usan lectores de pantalla o magnificadores). 

En cuanto al menú de la página, asegure que la organización de la información se presente en sentido lógico y simple. Y si cuenta con submenús indique de manera visual al usuario que hay un submenú. Adicionalmente, tanto en el menú como en el submenú verifique la accesibilidad con teclado y con lector de pantalla. 

R 1.21 Requerimiento: 

• Las tablas podrán tener título (caption) y las celdas de datos (td) se podrán asociar con sus encabezados (th). (Nivel A, 1.3.1 WCAG 2.0)

Los lectores de pantalla reconocerán las tablas de datos. Generalmente, al inicio leerán el título (caption), el número de filas, el número de columnas y posteriormente el contenido fila por fila. 

El título (caption) es muy importante porque brinca información sobre el contenido de la tabla. Y en caso de existir más de una, gracias al título el usuario ciego puede distinguirlas. 

Nota: evite siempre el uso de tablas para dar diseño, ya que se puede desorientar al usuario con lector de pantalla, el cual reconocerá la tabla y dará información innecesaria sobre el número de filas y columnas o lectura de celdas de datos vacías (en caso de que se hayan utilizado para dar espacios en blanco). 

En teoría, las tablas sólo deben usarse para celdas de datos, en donde es necesario relacionar celdas de datos con su o sus encabezados correspondientes. En cuyo caso, el lector va a leer los encabezados antes de proporcionar la información de cada celda relacionada. 

Nota: de preferencia, siempre mantenga la tabla lo más simple posible. 

Para tablas sencillas y sin celdas combinadas se puede utilizar scope para relacionar encabezados con celdas de datos. Ejemplo: 

<html>

<head>

<title>Tabla con scope</title>

</head>

<body>

<table width="250" border="1">

<caption>Ejemplo de tabla con scope</caption>

  <tr>

    <th width="50" scope="col">Curso</th>

    <th width="50" scope="col">Horario</th>

    <th width="50" scope="col">Salón</th>

  </tr>

  <tr>

    <th scope="row">CSS</th>

    <td>07 horas </td> 

    <td style="text-align:center;">A</td> 

  </tr>

  <tr>

    <th scope="row">HTML</th>

    <td>09 horas </td>

    <td style="text-align:center;">B</td> 

  </tr>

  <tr>

    <th scope="row">JAVA</th>

    <td>13 horas </td>

    <td style="text-align:center;">C</td> 

  </tr>

  <tr>

    <th scope="row">Dreamweaver</th>

    <td>15 horas </td>

    <td style="text-align:center;">D</td> 

  </tr>

</table>

</body>

</html>

En el siguiente ejemplo, debido a que la tabla tiene celdas combinadas y diferentes niveles de encabezados la solución para volverla accesible ese hacer la relación de encabezdos y celdas de datos con id y headers. 

Nota: No todos los lectores de pantalla y navegadores interpretan de la misma forma las tablas. Este ejemplo se puede probar de manera adecuada con el uso de NVDA y Firefox.

<html>

<head>

<title>Ejemplo de tabla con id y headers</title>

</head>

<body>

  <table border="1">

  <caption>Porcentajes para obtener calificación semestral</caption>

   <tr>

     <th rowspan="2" id="h">Tarea</th>

     <th colspan="3" id="e">Examen</th>

     <th colspan="3" id="p">Proyecto</th>

   </tr>

   <tr>

     <th id="e1" headers="e">Primer Parcial</th>

     <th id="e2" headers="e">Segundo Parcial</th>

     <th id="ef" headers="e">Final</th>

     <th id="p1" headers="p">Primer Parcial</th>

     <th id="p2" headers="p">Segundo Parcial</th>

     <th id="pf" headers="p">Final</th>

   </tr>

   <tr style="text-align:center;">

    <td headers="h">15%</td>

    <td headers="e e1">15%</td>

    <td headers="e e2">15%</td>

    <td headers="e ef">20%</td>

    <td headers="p p1">10%</td>

    <td headers="p p2">10%</td>

    <td headers="p pf">15%</td>

   </tr>

  </table>

</body>

</html>

Este método puede implicar bastante inversion de tiempo en una tabla todavía más compleja, a veces la solución está en dividir la tabla compleja en varias tablas simples, pero dependerá de la estructura. También se debe evitar anidar tablas dentro de tablas ya que el lector de pantalla no podrá interpretarlas adecuadamente. 

En ambos ejemplos observe como los th se muestran en negritas, pero al final la tabla puede ser modificada con css para obtener el diseño deseado. 

Cuando la tabla tiene una estructura todavía más compleja, se puede ofrecer un resumen con una breve explicación sobre la información y/o sus tendencias. 

Nota: el atributo summary de table es obsoleto, se puede utilizar otra alternativa como caption o aria-describedby.

<p id="desc-tabla">Esta tabla muestra los resultados de la encuesta sobre niveles de vida en el mundo...</p>

 

<table aria-describedby="desc-tabla">

  <caption>Niveles de vida</caption>

  <!--filas de la tabla-->

</table>

 

R 1.22 Requerimiento: 

Los elementos de los formularios que estén relacionados se agruparán mediante fieldset y legend. (Nivel A,1.3.1 WCAG 2.0) 

Algunos lectores de pantalla (dependiendo del navegador) mencionarán el texto del legend antes de la primera entrada de datos. Otros mencionarán, por ejemplo: "Agrupación, Datos Personales". Lo cual ayuda a que las personas con discapacidad visual se creen una estructura mental del formulario. 

Nota: el diseño del fieldset y legend se puede cambiar con css. Por ejemplo, si desea eliminar la línea del fieldset o cambiarle el color, etc. Únicamente verifique que el diseño sea en beneficio del usuario, ya que para algunos posiblemente sea de utilidad reconocer visualmente qué campos están agrupados. 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Formulario fieldset y legend</title>

</head>

 

<body>

 

<form action="" method="post">

 <fieldset>

  <legend>Datos Personales:</legend>

   <table role="presentation" width="299" border="0" name="Datos Personales">

    <tr>

     <td width="134"><label for="nombre">Nombre:</label></td>

     <td width="155"><input type="text" name="nombre" id="nombre" /></td>

    </tr>

    <tr>

     <td><label for="ape_pat">Apellido Paterno:</label></td>

     <td><input type="text" name="ape_pat" id="ape_pat" /></td>

    </tr>

    <tr>

     <td><label for="ape_mat">Apellido Materno:</label></td>

     <td><input type="text" name="ape_mat" id="ape_mat" /></td>

    </tr>

    <tr>

     <td><label for="mail">Correo Electr&oacute;nico:</label></td>

     <td><input type="text" name="email" id="mail" /></td>

    </tr>

   </table>

 

</fieldset>

</form>

</body>

</html>

Nota: también es posible anidar fieldsets, ya dependerá de la estructura del formulario. 

Nota 2: en este caso agregamos role="presentation" para que el lector no reconozca el formato de tabla, ya que no es una tabla de datos. En general, no se recomienda utilizar estructura de tablas para dar diseño o estructurar la página, ya que el lector de pantalla reconocerá la tabla e informará al usuario el número de filas y columnas. Sin embargo, como solución rápida a este problema se puede agregar a la tabla el atributo de ARIA role="presentation" que hará que no se reconozca la estructura de tabla. 

Principio: Perceptible

La información del contenido web debe estar disponible para los sentidos (vista, audición o tacto), ajustándose a distintas discapacidades.

Pauta: Distinguible

Facilita a los usuario ver y escuchar el contenido, separando entre primer plano y fondo. 

Escenario: Uso de colores 

 Excepto si la utilización de colores está relacionada con la actividad específica. 

El color es fundamental en el diseño de una página web, los contrastes (entre primero y segundo plano) y las combinaciones de colores pueden hacer el sitio no sólo agradable a la vista, sino también pueden facilitar la navegación y agilizar la consulta de información. 

No obstante, las personas con problemas de visión pueden tener deficiencias que afectan la interpretación de los colores. 

Adicionalmente personas que utilizan tecnologías de asistencia como pantallas de sólo texto, colores limitado o monocromáticos pueden beneficiarse de las alternativas adicionales al color. 

Nota: No se pretende desalentar el uso de color en una página web, sino complementar con otras alternativas de distinción.

Requerimiento:

• No use el color como único método para distinguir elementos visuales. (Nivel A, 1.4.1 WCAG 2.0) 

Si se utiliza el color para distinguir elementos visuales (como transmitir información o solicitar una respuesta) se debe utilizar una alternativa adicional de distinción para asegurar que todos los usuarios puedan reconocer la diferencia. 

Ejemplos (no accesibles) del uso exclusivo del color: 

• Mostrar los campos requeridos en rojo.
• Mostrar el error en rojo. 
• Presentar gráficas que se basan en el color para diferenciar la información. 
• Mostrar en color amarillo los campos de un formulario para indicar que se han quedado vacíos. 

Ejemplo (accesible) de alternativas al color: 

En formulario de contacto de la página http://www.whitehouse.gov/contact/submit-questions-and-comments de "The White House" del gobierno de Estados Unidos se muestra una leyenda que indica los campos requeridos. Además, cuando el usuario quiere enviar el formulario sin el campo requerido, se muestra en rojo el recuadro y la leyenda especificando que ese campo es obligatorio. 

Otras alternativas adicionales al color pueden ser cambiar el tamaño, el tipo de letra o el formato de texto (negrita, cursiva, contorno del texto, etc.)

Nota: Las tecnologías de asistencia reconocen el estado de los elementos desactivados en los formulario (por lo que son ignorados). En interfaz ayuda el hecho de no recibir el foco y mostrarse en color gris. 

Otro ejemplo, es una gráfica de pastel que no debe depender del color para transmitir información, ya que un usuario con alguna discapacidad visual como ceguera de color no podrá percibir la información adecuadamente. 

Adicional al color se puede utilizar, por ejemplo: etiquetas textuales, formas o texturas diferentes para diferenciar contenido o líneas que lleven al texto relacionado. 

Compare las siguientes gráficas: 

• Gráfica no accesible 

Nota: observe que, si un usuario no puede distinguir adecuadamente los colores o el tamaño de la figura, no será posible que sepa qué sección pertenece a determinado producto. 

• Gráfica accesible 

Requerimiento 

• Utilice una forma adicional al color para diferenciar los enlaces de los elementos y texto alrededor. (Nivel A, 1.4.1 WCAG 2.0)

El subrayado es la manera más accesible y universal de presentar un enclace, ya que cualquier usuario de internet lo reconoce. 

Adicionalmente muchos desarrolladores utilizan un cambio de color cuando el mouse se encuentra sobre el enlace. Sin embargo, adicional a esto se recomienda ofrecer otro cambio que no dependa sólo del color y que el usuario pueda visualizar más fácilmente. 

Por ejemplo: 

<html>

    <head>

        <title>Ejemplo de enlace subrayado</title>

        <meta charset="UTF-8">

        <meta name="viewport" content="width=device-width, initial-scale=1.0">

        <style>

            .contenido {

                 color:#20399D;

                 text-decoration: underline; 

                 padding: 1px;

            }

            .contenido:hover {

                 color:#BF1722;

                 border: solid 1px; 

                 text-decoration: underline;

                 background-color:#ffffcc;

 

            }

            p {

                    border:0; 

                    margin:15px 0; 

                    padding:0;

                    font-family:Arial;

                    font-size:12px;

            }

        </style>

    </head>

    <body>

        <p>

<a href="prueba.php" class="contenido"><strong>Ejemplo de enlace subrayado</strong></a></p>

    </body>

</html>

Nota: recuerde también la importancia del alto contraste entre texto y fondo. 

Escenario: Audio 

Requerimiento: 

• Si debido al contenido de la página se tienen disponibles sonidos por más de tres segundos, se deberá ofrecer un mecanismo para poder controlarlo: pausar, parar o ajustar el volumen. (Nivel A, 1.4.2 WCAG 2.0)

Nota: Se requiere un ajuste de volumen e independientemente al ajuste de volumen del sistema operativo que se está utilizando, es decir la página web deberá tener su propio mecanismo de volumen. Dicho ajuste debe poder bajarse hasta cero. 

Este requerimiento aplica para audios que se escuchan tanto automáticamente (al cargar una página) como audios que se escuchan al activarlos de forma manual. Sin embargo, recomendamos que se evite reproducir audio automáticamente (al cargar una página o al realizar cierta acción) porque puede causar confusión al usuario que navega con lector de pantalla, ya que escuchará ambos sonidos al mismo tiempo. 

Personas con problemas auditivos, también se benefician si el sitio cuenta con el mecanismo para ajustar el volumen ya que pueden ajustarlo de acuerdo a sus necesidades. 

Por ejemplo: en la página https://www.newmusicusa.org el audio no se reproduce automáticamente al cargar la página y se ofrecen botones de control como Play, Pausa y Ajuste de Volumen. 

Escenario: Contraste mínimo

De conformidad con la W3C, los contrastes de color se evalúan a partir de un nivel AA de accesibilidad web. Dichos contrastes no sólo benefician a personas con discapacidad visual, sino a cualquier usuario. La diferencia entre nivel AA y AAA, es que en un nivel AAA se pide un contraste mayor al del nivel AA. 

El diseñador o desarrollador puede evaluar los contrastes que está utilizando en texto y fondo para corroborar que cumplan con el presente criterio. En el capítulo de Herramientas de Evaluación se presentan algunos validadores de contrastes de colores. 

Nota: se considera gran tamaño al menos 18 puntos o 14 puntos en negritas. 

Requerimiento: 

• Contraste mínimo 4.5:1 para la presentación visual de texto e imágenes de texto excepto: 

• Los textos de gran tamaño e imágenes de gran tamaño (estos requieren un contraste mínimo de 3:1) 
• Texto e imágenes de texto que son componentes inactivos de la interfaz de usuario, los que son pura decoración, los que no son visibles o los que son parte de una imagen cuyo contenido significativo es otro contenido (no tienen requerimiento de contraste). 
• Texto que es parte de un logo o nombre de marca (no tiene requerimiento de contraste).           (Nivel AA, 1.4.3 WCAG 2.0)

Escenario: Tamaño de letra 

Requerimiento. 

• El tamaño de letra debe poder crecer sin perder contenido o estructura. (Nivel AA, 1.4.4 WCAG 2.0) 

 Excepto subtítulos e imágenes con texto. 

Este criterio beneficia a usuarios con problemas de visión o personas de la tercera edad, facilita la lectura y el acceso al contenido. Consideramos que para ver la letra más grande el usuario tiene las siguientes opciones: 

1. Aumentar o disminuir el texto o el zoom ( de toda la página) en el navegador. 
2. Apoyarse de alguna tecnología de asistencia para aumentar el tamaño. 
3. Aumentar o disminuir el tamaño del texto con alguna funcionalidad de la página. 

Nota: La letra debe poder aumentarse hasta un 200% (se entiende como tamaño de letra estándar entre 11 y 12 px), siempre considerando que no se pierda contenido o estructura. 

Para facilitar la lectura se puede utilizar un tipo de letra legible como Arial o Helvética que son de estilo sencillo. Adicionalmente se recomienda que el tamaño de la tipografía se use en unidades relativas (em 0 %). 

Escenario: Imágenes de texto 

Requerimiento: 

• Si con las tecnología empleadas se puede lograr la presentación visual deseada, se debe usar texto en lugar de imágenes de texto. (Nivel AA, 1.4.5. WCAG 2.0)

Excepto cuando la imagen de texto sea personalizable de acuerdo a los requisitos del usuario o cuando la presentación de un texto en específico sea esencial para la información (por ejemplo:logos). 

A pesar de que en un nivel A es suficiente ofrecer una descripción alternativa para imágenes que transmitan contenido, en un nivel AA esto ya no es suficiente. En este nivel ya no se permiten imágenes con texto. Por ejemplo: en lugar de ofrecer una imagen con texto, se deberá ofrecer el texto en html y css ( si desea darle la misma presentación visual). 

Visite la siguiente liga y vea el código del infographic llamado "Web Accessibility for Designers": http://throup.org.uk/infographic/

Escenario: Contraste aumentado

Requerimiento: 

• Contraste mínimo 7:1 para la presentación visual de texto e imágenes de texto excepto: 

• Los textos de gran tamaño e imágenes de gran tamaño (estos requieren un contraste mínimo de 4:5:1)
• Texto o imágenes de texto que son componentes inactivos de la interfaz de usuario, los que son pura decoración, los que no son visibles o los que son parte de una imagen cuyo contenido significativo es otro contenido (no tienen requerimiento de contraste).
• Texto que es parte de un logo o nombre de marca (no tiene requerimiento de contraste)                    (Nivel AAA, 1.4.6 WCAG)

Escenario: Presentación Visual 

Requerimiento: 

• Para las presentaciones visuales de bloques de texto, se debe proporcionar un mecanismo para cumplir lo siguiente: 

• El usuario puede seleccionar los colores de primer plano y fondo. 
• El ancho de la línea no puede ser mayor a los 80 caracteres. 
• El texto no debe estar justificado. 
• Espaciado entre líneas (altura) al menos un espacio y medio en el interior de los párrafos, y el espacio entre párrafos al menos 1.5 mayor al espaciado entre línea. 
• El texto puede aumentarse hasta un 200% sin que el usuario se tenga que despalzar en una barra de scroll para leer la línea.
  (Nivel AAA, 1.4.8 WCAG 2.0)

Escenario: Imágenes de texto (sin excepción) 

Requerimiento: 

• Las imágenes de texto serán utilizadas solo para pura decoración o cuando la presentación de un texto en específico sea escencial para la información (por ejemplo: logos).
  (Nivel AAA, 1.4.9 WCAG 2.0)

Principio: Operable

Los elementos de la interfaz deben facilitar la interacción y operabilidad. 

Pauta: Accesibilidad mediante el teclado

Permitir la navegabilidad web con el teclado. 

Escenario: Teclado 

Requerimiento: 

•  El usuario deberá poder moverse por todos los elementos navegables (en orden lógico e intuitivo) y realizar todas las funcionalidades de la página utilizando el teclado. (Nivel A, 2.1.1 WCAG2.0, 2.4.3 WCAG 2.0)  

Excepto cuando la función subyacente requiere entradas que dependan de una trayectoria del movimiento del usuario y no solo puntos finales. 

Al ofrecer una página navegable con sólo el teclado (generalmente con la tecla Tab, Enter o Flechas) en orden lógico e intuitivo, se beneficia a personas que no pueden utilizar el mouse. Principalmente personas con discapacidad motriz, personas ciegas que navegan con lectores de pantalla, personas con discapacidades cognitivas, discapacidades de aprendizaje o personas que tienen dificultades para coordinar la vista con la mano. Adicionalmente, al volver la página navegable con teclado, se facilita la navegación con tecnologías de asistencia (como switches) que simulan el movimiento de la tecla Tab o Enter. 

Así mismo, se debe considerar que por ningún motivo deben existir trampas de teclado (Nivel A, 2.1.2 WCAG 2.0) en donde la ubicación del foco no pueda salir. Es decir, si un elemento puede recibir el foco, este debe de poder salir y si para ello se requiere el uso de alguna tecla en específico, esto de debe de informar al usuario. 

Nota: para información sobre algunos objetos de Flash que pueden atrapar el foco del usuario visite la siguiente liga. http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/FLASH17.html%20

De acuerdo con las especificaciones en WCAG 2.0, en un nivel A el requerimiento es la navegación con teclado, mientras que en un nivel AA se requiee también la visualización del foco. Aunque ambas son de suma importancia para la accesibilidad y usabilidad del sitio. 

tabindex 

Como sabemos, elementos como enlaces o elementos de formulario reciben el foco por default y su orden secuencial es determinado por el orden de los elementos dentro del código fuente. En estos casos, el foco del teclado y la navegación con tecla Tab la ofrece automáticamente el navegador. 

Nota: tenga cuidado con las hojas de estilo que utilice para dar diseño (por ejemplo, position: absolute, position: relative, float: left, float: right). El lector de pantalla siempre leerá la información basándose en la ubicación de los elementos en el código fuente.

Por otro lado, es posible utilizar el atributo tabindex si desea recibir el foco en algún elemento que no recibe el foco por default, por ejemplo: a, area, button, input, object, select y textarea (o em HTML5 a cualquier elemento). También se puede utilizar tabindex si se desea un orden de tabulación específico. 

• tabindex=0

Inserta el elemento dentro del orden de tabulacón default con base en su ubicación en el código fuente. Si está readaptando un elemento como  <span>, <div> o <p>, con tabindex=0 se podrá recibir el foco sin afectar el orden de tabulación de los otros elementos. 

• tabindex=-1

Cuando tabindex es negativo el elemento recibirá el foco, pero no se incluirá en flujo normal de tabulación de la página. Es decir, no puede ser alcanzado por el usuario al navegar con la tecla Tab, pero puede recibir el foco mediante un lenguaje de programación. Por ejemplo: recibir el foco por medio de javascript en una lista de errores que ha validado un formulario o recibir el foco al abrir un modal window. 

• tabindex=1 

Cuando tabindex es positivo se impondrá un orden de tabulación (el tabindex=1 será el primer elemento en recibir el foco (posteriormente sus siguientes valores). Evite utilizar números positivos para evitar comportamientos inesperados que pueden confundir al usuario o complicar la navegación. 

Requerimiento

• Los access keys del sitio deberían evitarse. 

Los access keys (o shortcuts) en una página web pueden entrar en conflicto con el sistema operativo, con el navegador y/o con tecnologías de asistencia como lectores de pantalla que se administran con comandos previamente establecidos. 

Por lo que nuestra recomendación es no utilizarlos, ya que pueden tener un resultado contraproducente y confundir o desorientar al usuario. 

Para mayor información puede visitar las siguientes ligas: 

3.2.6 Author-Defined Keyboard Short-Cuts or Minemonics http://www.w3.org/WAI/PF/aria-practices/

Keyboard Accessibility 

http://webaim.org/techniques/keyboard/accesskey

Keyboard Accessible 

http://webaim.org/standards/wcag/checklist

Nota: en caso de utilizarlos se debe probar su compatibilidad con múltiples navegadores y lectores de ´pantalla. Además, se recomendaría ofrecer un aviso o nota disponible para informar al usuario cómo utilizarlos. 

Escenario: Teclado (Sin excepción)

Requerimiento: 

• Todas las funcionalidades del sitio deben ser operables con teclado sin límite de tiempo para pulsar las teclas. 

Principio: Operable

Los elementos de la interfaz deben facilitar la interacción y operabilidad. 

Pauta: Suficiente tiempo

Ofrezca a los usuarios sufciente tiempo para leer y usar el contenido. 

Escenario: Límite de tiempo 

R 2.36 Requerimiento: 

• Si una página tiene un límite de tiempo para realizar una tarea, este se debe poder apegar, ajustar o extender. Para casos de tiempo real y absolutamente necesario, se deberá informar al usuario sobre tiempo límite y restante para realizar la actividad (Nivel A, 2.2.1 WCAG 2.0)

En general, se recomienda diseñar contenidos que no contemplen la funcionalidad de límite de tiempo, pero si a pesar de esto el sitio ofrece funcionalidades dependientes del tiempo (que no son precisamente de tiempo real y absolutamente necesarios), se debe ofrecer alguna de las siguientes opciones: 

• Apagar o pausar el límite de tiempo. 
• Ajustar el límite de tiempo, al menos diez veces más del tiempo configurado por default. 
• Extender el tiempo a través de una advertencia mostrada mínimo 20 segundos antes de expiar el tiempo (con una acción simple como presionar la barra espaciadora) disponible al menos diez veces. 

Ejemplo de extender el tiempo: En el portal bancario de Grupo Financiero Banamex https://boveda.banamex.com.mx/ llamado "BancaNet" (donde el usuario puede consultar su estado de cuenta, realizar transferencias, pagos, etc.), por su seguridad en cierto periodo de inactividad (dos minutos en este caso) el sitio muestra un mensaje de advertencia donde se ofrece la opción de extender el tiempo de sesión al dar clic en "Continuar". 

Adicionalmente, en dicha advertencia se muestra un cronómetro que marca el tiempo restante previo a finalizar automáticamente la sesión del usuario, en caso de no recibir respuesta. 

Las excepciones pueden ser: 

• En casos de tiempo real en donde el límite de tiempo es absolutamente necesario, por ejemplo: una subasta. 
• En casos de límite de tiempo esencial, donde extenderlo invalidaría la actividad. 
• Cuando el tiempo límite es mayor a 20 horas. 

En dichos casos es necesario que se informe al usuario los tiempos límite y restante. 

Otro ejemplo: En la página de Ticketmaster http://www.ticketmaster.com.mx/ se realizar la venta de boletos para conciertos, teatro, eventos deportivos, etc. El proceso es el siguiente: el usuario selecciona el evento, la fecha, elige sus asientos y confirma dando clic en el botón de "Comprar" . Como resultado se muestra un CAPTCHA (visual y auditivo). 

Una vez resuelto el CAPTCHA, el usuario continúa el proceso con cuatro etapas dependientes del tiempo: Revisión, Entrega, Entra y Pago. En cada etapa (en un cronómetro en la parte inferior derecha) se advierte el tiempo restante que tiene el usuario para concluir con dicha etapa. 

Nota: Para volver ideal este ejemplo se debería mencionar también el tiempo límite y no solo el restante. 

En todos los casos de tiempo real se recomienda dejar fuera del tiempo crítico la mayor parte posible del proceso. Como en el presente ejemplo, donde el usuario tiene la opcón de capturar previamente los datos requeridos para la compra (datos personales, información de tarjeta(s) de crédito, etc.) en el perfil o cuenta de usuario. 

Por otro lado, en este ejemplo si el tiempo expira y el usuario no pudo completar la actividad, puede volver a intentarlo. 

El objetivo del requerimiento es asegurar que las personas con discapacidad tengan noción del tiempo disponible para interactuar con el contenido y realizar la tarea de manera independiente. Personas con discapacidades cognitivas, visuales, de aprendizaje, personas con dificultad para la lectura y/o personas de la tercera de edad serán beneficiadas al poder prevenir y considerar el límite de tiempo; aunque habrá casos de discapacidad grave en lo que se necesitará la ayuda de un tercero. 

Escenario: Contenidos en movimiento y/o actualizados automáticamente. 

Contenidos en movimiento y/o actualizados automáticamente, pueden ser una barrera para personas que utilizan lectores de pantalla, personas con discapacidad intelectual o para personas que tienen dificultades para leer rápidamente o seguir el movimiento de determinado contenido. Así mismo, personas con déficit de atención pueden tender a distraerse y encontrar dificultades para concentrarse en otra parte de la página, por lo que se debe evitar distraer a los usuarios. 

R 2.37 Requerimiento: 

Todo contenido en movimiento, parpadeo o desplazamiento automático de más de cinco segundos y que se presente paralelamente a otro contenido deberá poderse pausar, parar o esconder por el usuario. (Nivel A, 2.2.2 WCAG 2.0) 

Excepto cuando el movimiento sea esencial para la actividad y exista un contenido textual para explicar el propósito del movimiento. 

Algunos ejemplos de contenidos que transmiten una sensación de movimiento son: películas, presentaciones de medios sincronizadas, animaciones, avisos, promociones, juegos en tiempo real o desplazamiento de un ticker de noticias. 

Nota: Si el movimiento, parpadeo o desplazamiento dura menos de cinco segundos puede usarse para llamar la atención del usuario o destacar un contenido y puede ser una técnica efectiva. 

Ejemplos del cumplimiento del requerimiento para contenidos de más de cinco segudnos: 

• Una animación que explica un proceso que ofrece un botón de Pausa o Play 
• Una publicidad que parpadea que ofrece un botón para salir o esconder. 
• Una animación se ejecuta en la parte superior de la página, pero tiene un botón de Stop. 

Nota: El contenido que es pausado puede reanudarse (en casos de tiempo real) o continuar con el punto en el que se pausó. 

Otro ejemplo: En la página de la Bolsa Mexicana de Valores http://www.bmv.com.mx/ se muestra el desplazamiento de un ticker que tiene el botón de Pausa y Play.

Ejemplo de pausar en un carrusel de imágenes:

En el caso de los carruseles de imágenes se debe de cumplir lo siguiente: 

• Control para pausar, parar o esconder. Pausar es lo más común.  
• Dicho control para pausar y en algunos casos los botones de anterior o siguiente deben ser accesibles con teclado y lector de pantalla. 
• La navegación debe ser en orden lógico e intuitivo. 
• Lo que reciba el foco (imagen, botón o incluso enlaces) debe visualizarse en interfaz justo en el momento en el que está recibiendo el foco y debe tener su texto descriptivo. 

En este ejemplo de Deque Systems observamos la navegación con teclado y el botón de pausar. Para evitar tener dos versiones accesibles de lo mismo (imágenes de arriba y de abajo), se oculta la parte de arriba con aria-hidden="true" y se dejan accesibles los enclaces de abajo que están relacionados directamente con las imágenes de arriba (las cuales tienen su texto alternativo). 

Vea su funcionamiento en la siguiente liga:    http://hearcolors.com.mx/ejemplosaccesibleshc/Ejemplo_Carrusel/index.html

Nota: los casos de gif's animados deben de dejar de parpadear después de "n" ciclos dentro de los primeros cinco segundos.

R 2.39 Requerimiento: 

• El contenido actualizado automáticamente y que se presente paralelamente a otro contenido deberá poderse pausar, parar o esconder por el usuario. (Nivel A, 2.2.2 WCAG 2.0) 

Excepto cuando la actualización automática sea esencial para la actividad y exista un contenido textual para explicar el propósito del movimiento.

Se refiere a contenido que se actualiza o desaparece basándose en intervalos del tiempo presente. Algunos ejemplos son audio, información del clima actualizada automáticamente, noticias, actualización de los precios de las acciones del mercado financiero, reproducción automática de presentaciones, videos, mensajes inmediatamente después de finalizar la reproducción del contenido anterior (avance automático), etc. 

Otro ejemplo es el de la página http://www.bbc.co.uk/travelnews/london/roads/unplanned de BBC Travel NEws London en donde se muestra un mapa con incidente en tiempo real. Como se puede observar en la imagen, la actualización automática puede parar.

R 2.40 Requerimiento:

• El contenido web no deberá tener movimiento mientras el usuario mueve el mouse o cursor. (Nivel 
  A, 2.2.2 WCAG 2.0) 

Los movimientos, sensaciones de movimiento o cambios inesperados al mover el mouse o cursor confunde ó desorientan al usuario, por lo que debe evitarse. 

Ejemplo: 

Cuando el usuario mueve el mouse sobre las líneas verticales de la parte inferior en la página http://blacknegative.com/#!/home/, el sitio cambia de lugar las líneas diagonales e imágenes. A pesar de su originial diseño, el sitio se vuelve poco accesible y comprensible. 

Escenario: Sin tiempo 

R 2.41 Requerimiento: 

• El tiempo no debe se esencial para el evento o actividad presentada en el contenido. Excepto para el contenido multimedia sincronizado no interactivo y para los eventos de tiempo real. (Nivel AAA, 2.2.3 WCAG 2.0)

Escenario: Interrupciones 

R. 2.42 Requerimiento

• El usuario debe poder posponer o eliminar las interrupciones. Excepto interrupciones relacionadas con una emergencia. (Nivel AAA, 2.2.4. WCAG 2.0) 

Escenario: Re-autentificar sesión 

R 2.43 Requerimiento: 

• Cuando la sesión autentificada expira, el usuario debe poder poner continuar la actividad sin la pérdida de datos después de re-autentificar su sesión. (Nivel AAA, 2.2.5 WCAG 2.0) 

Principio: Operable

Los elementos de la interfaz deben facilitar la interacción y operabilidad. 

Pauta: Evite Convulsiones

No diseñe contenidos que puedan provocar ataques o convulsiones. 

Escenario: Tres destellos por segundo (flashes) 

Requerimiento: 

• No deberá crear contenidos que destellen (con alto contrsate y rojo) más de tres veces por segundo o el destello deberá estar por debajo del umbral. (Nivel A, 2.3.1 WCAG 2.0) 

Personas con epilepsia fotosensitiva o con enfermedades neurológicas pueden resultar gravemente afectadas si son susceptibles a ataques o convulsiones originados por estímulos visuales, tales como luces intensas e intermitentes. Este parpadeo también puede afectar a otras personas con síntomas menos graves como molestia visual, percepciones anómalas o migrañas. 

Por ejemplo: 

 En 1997 un capítulo llamado Electric Soldier Porygon de la serie Pokémon fue censurado por mandar al hospital a casi 700 personas por causar mareos, vómitos y ataques epilépticos. 

 

 

La animación con cambios intermitentes de luz y colores en un video con el logo de las olimpiadas de Londres 2012 fue retirada de la página ya que provocaba ataques epilépticos. 

 

La película Amanecer (Breaking Down) contiene una escena con flashes rojos que causó ataques epilépticos a personas que la fueron a ver al cine. 

Por estas razones debe evitarse contenido (animación, banner dinámico, imagen en movimiento, video, etc.) que destelle tres o más veces por segundo. 

Nota: Algunas personas son aún más sensibles a los flashes de color rojo, que a otros colores. 

Existe una herramienta gratuita llamada Photosensitive Epilepsy Analysis Tool (PEAT) que ayuda a identificar si animaciones o videos tienen contenido que pueda poner en riesgo la salud o casuar ataques, especialmente aquellos contenidos dinámicos con flashes y transiciones rápidas entre fondos luminosos y obscuros: http://trace.wisc.edu/peat/ 

Requerimiento: 

• No deberá crear contenidos que destellen (con alto contraste y rojo) más de tres veces por segundo. (Nivel AAA, 2.3.2 WCAG 2.0) 

Principio: Operable

Los elementos de la interfaz deben facilitar la interacción y operabilidad. 

Pauta: Navegable

Ofrezca formas que ayuden al usuario a navegar, encontrar el contenido y determinar dónde se encuentra. 

El mapa de sitio y el título de la página ayudan al usuario a navegar, encontrar el contenido y conocer su ubicación actual. 

Escenario: Mapa de Sitio 

Recomendación: 

• La página web deberá tener un mapa de sitio accesible y comprensible. (Nivel AA, 2.4.5 WCAG 2.0)

El mapa de sitio es importante para poder conocer de manera general la estructura de la página, por lo que se recomienda ofrecerlo en el encabezado. Algunos desarrolladores ofrecen los enclaces principales del sitio en el pie de página, en cuyo caso se recomienda poner en interfaz y con un encabezado el título "Mapa de Sitio". 

Nota:  El mapa de sitio también debe de ser navegable con teclado. 

Para mayor información visite la siguiente liga: 

https://www.w3.org/TR/WCAG20-TECHS/G63.html

Ejemplo, el mapa de sitio del Instituto Federal de Telecomunicaciones: 

http://www.ift.org.mx/sitemap

Escenario: Título de la página

Requerimiento: 

• La página web deberá tener un título descriptivo de la misma. (Nivel A. 2.4.2 WCAG 2.0) 

El título de la página utilizando el tag title debe de identificar y describir brevemente el contenido. 

Deben evitarse títulos que fuera de contexto no tienen significado, por ejemplo: Introducción. 

Nota: Se recomienda que el título tenga una longitud menor a 64 caracteres. 

Ejemplo: 

En una página de cocina internacional (http://www.lidl-recetas.es/recetas/comida-griega) el usuario consulta la liga de "Recetas de Comida Griega" con su correcto título de página (<title>Recetas de Comida griega</title>).

Cuando el usuario da clilc en el nombre de la receta específica, el sitio lo lleva a una página con la receta y su correcto título (<title>Terciopelo de berenjena | Verduras y hortalizas</title>).

Si el desarrollador desea poner en todos los títulos de página un nombre genérico o principal del sitio web, este deberá ir después del título específico, por ejemplo: 

http://www.ift.org.mx/conocenos/estructura/organigrama

 <title>Organigrama | Instituto Federal de Telecomunicaciones</title>

Escenario: Bloques 

Requerimiento: 

• En caso de contenidos repetitivos en múltiples páginas, se requiere un mecanismo disponible para omitir bloques. (Nivel A, 2.4.2 WCAG 2.0)

Generalmente las páginas tienen contenidos que se repiten en otras páginas. 

Por ejemplo: enlaces de navegación (menú), gráficos de encabezados, marcos de publicidad, etc. 

La solución para este criterio es un enlace al inicio de la página que lleve al contenido principal. Por ejemplo (donde el enlace no es visible al menos que se navegue con tecla tab): 

 http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip

Nota: No es suficiente un ancla, generalmente se debe implementar un javascript para crear la funcionalidad de leer el contenido principal que realmente funcione con lectores de pantalla. 

Si dicho enlace no existiera el usuario con lector o magnificador de pantalla o el que navega con tecla Tab se verá forzado a pasar por la cantidad de enlaces, imágenes u otros tipos de contenido repetitivo.

Escenario: Múltiples formas de búsqueda 

Requerimiento: 

Múltiples formas o más de una manera disponible para encontrar una página web en conjunto de páginas. (Nivel AA, 2.4.5 WCAG 2.0) 

Excepto cuando esa página es el resultado de algo o un paso del proceso. 

El criterio se refiere a que el sitio debe cumplir con al menos dos opciones que ayuden a encontrar una página web. Puede ser un mapa de sitio, un mecanismo de búsqueda, enlaces de "forward" o "backward", tabla de contenidos, enlaces a todas las páginas del sitio en la página de inicio, etc. 

Por ejemplo: que una página ofrezca un buscador y un mapa de sitio para ayudar a los usuarios a encontrar contenido. 

Escenario: Encabezados y etiquetas 

Requerimiento: 

• Uso de encabezados y etiquetas para describir el tema o el propósito (no limitado a label de html)  (Nivel AA, 2.4.6 WCAG 2.0)

Así como la estructura de encabezados es adecuada, las descripciones de los encabezados o las etiquetas deben ser suficientes para que el usuario tenga un panorama adecuado del contenido y su organización. Por ejemplo: 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

<title>Ejemplo encabezados</title>

</head>

<body>

<h1>Encabezado principal</h1>

 <h2>T&iacute;tulo</h2>

  <h3>Subtítulo</h3>

 <h2>T&iacute;tulo </h2>

  <h3>Subtítulo</h3>

</body>

</html>

 

Escenario: Foco visible 

Requerimiento: 

• El usuario deberá poder moverse por todos los elementos navegables (en orden lógico e intuitivo) y realizar todas las funcionalidades de la página utilizando el teclado.  (Nivel A, 2.1.1. WCAG 2.0, 2.4.3 WCAG 2.0) 

Como se mencionó anteriormente, la navegación con teclado de todo el sitio es requerida para un nivel A, pero la visualización del foco en dicha navegación pertenece a un nivel AA. Por default los navegadores muestran una línea punteada o un marco azul cuando los elementos reciben el foco, lo cual es suficente para cumplir el requerimiento, por ejemplo: 

Chrome:  

Firefox:

Sin embargo, el desarrollador puede utilizar las hojas de estilo de su preferencia para cambiar la presentación default de los elementos al recibir el foco, por un diseño más visible. Se recomienda utilizar estilos iguales para a:hover y a:focus que beneficien tanto a usuarios con mouse como a usuario con teclado. Algunos incluso utilizan el mismo estilo para a:active, lo cual es una buena práctica. 

Nota: Nunca utilice outline:none, al menos que lo vaya a reemplazar por un estilo mucho más visible. 

Ejemplo: de navegación con teclado: 

En la página del Centro de Investigación de Diseño Incluyente de OCAD University en Canadá http://idrc.ocad.ca/, el usuario puede navegar con la tecla Tab.  Primero en la columna izquierda, después de la columna derecha y finalmente la columna central. Adicionalmente el sitio realta la ubicación del foco con un diseño de color azul. 

Escenario: Ubicación

Requerimiento: 

• Se debe proporcionar información al usuario sobre la ubicación dentro del sitio. Por ejemplo: la ruta que indique los enlaces que fue seleccionando el usuario hasta su ubicación actual. (Nivel AAA, 2.4.8 WCAG 2.0) 

Escenario: Propósito del enlace (solo enlace)

Requerimiento: 

• Se debe ofrecer un mecanismo que permita identificar el propósito de cada enlace con el uso exclusivo del tecto del enlace. 

Nota: excepto cuando el propósito del enlace es ambiguo para los usuarios en general. (Nivel AAA, 2.4.9 WCAG 2.0)

Escenario: Secciones de encabezado 

Requerimiento: 

• Se deben emplear encabezdos (títulos) de sección para organizar el contenido. 

Nota: Este requerimiento aplica cuando el sitio está organizado en secciones, por ejemplo: capítulos, subtemas, subtemas divididos en secciones, secciones en párrafos, etc. en cuyo caso se deben utilizar los encabezados para introducirlas. (Nivel AAA, 2.4.10 WCAG 2.0) 

Principio: Comprensible

La información y la operación de la interfaz deben entenderse fácilmente. 

Pauta: Legibilidad

Escenario: Idioma de la página 

Requerimiento: 

•  Los idiomas de la página deberán estar identificados utilizando el atributos lang de HTML.              (Nivel A, 3.1.1. WCAG 2.0) 

El idioma de la página se debe identificar con el atributo lang y el código del idioma y/o dialecto. Por ejemplo: "en-GB" o "en-US"  para inglés británico o americano. 

Normalmente se determina sólo el idioma. Por ejemplo:  <html lang="es"> para español. 

Si una página tiene la misma versión en otro idioma, este también se debe identificar. 

Los lectores de pantalla pueden alternar de lenguaje para utilizar la pronunciación correcta del idioma. Imaginemos un lector de pantalla en español leyendo un texto en inglés o viceversa, la voz sintetizada y artificial del lector de pantalla no pronunciará correctamente el texto y el audio se volverá confuso. Debido a esto es necesario avisarle a la tecnología de asistencia en que idioma está el texto para que pueda utilizar las reglas correctas de pronunciación. 

El atributo lang también se utiliza para determinar: El idioma de los enlaces (hreflang), los diferentes idiomas en los contenidos de la misma página o dentro de un mismo texto, aunque la evaluación del uso de lang en estos casos, no es hasta en un nivel de accesibilidad más avanzado. Independientemente de los usuarios (multilingües o no) a los que esté destinada una página, la recomendación es usar un idioma por página. 

Nota: No se debe especificar el idioma con el elemento meta, ya que puede declarar varios idiomas al mismo tiempo y no cumple con el propósito de la especificación del idioma. Además, algunas tecnologías de asistencia no lo reconocen. Ejemplo incorrecto:  <meta http-equiv="Content-Language" content="en, es, fr">. 

Recomendación: 

• Para sitios multi idioma, las opciones de idioma deberán ser presentadas claramente en imagen y/o texto. 

Se deben ofrecer claramente las opciones de idioma en interfaz, ya sea en imagen o texto (preferentemente en la parte superior). Esto beneficia a personas de la tercera edad, personas con discapacidades cognitivas y con discapacidades de aprendizaje. 

Por ejemplo, la página de UNICEF http://www.unicef.org/

Escenario: Idioma de partes 

Requerimiento: 

• Diferenciar el idioma de cada pasaje o frase.  (Nivel AA, 3.1.2 WCAG 2.0) 

Excepto para nombres propios, términos técnicos, palabras en un lenguaje indeterminado o palabras y frases que han llegado a ser parte de la lengua vernácula incorporadas al texto. 

En un nivel AA, no es suficiente declarar el idioma principal de la página (como en el nivel A), también es necesario que si existe contenido en otro idioma se especifique. Esto le dirá al lector de pantalla que alterne de idioma para que utilice la pronunciación adecuada: 

<p lang="fr">

<span lang="zh">

<a lang="en">

Nota: el atributo hreflang sirve para definir el idioma del destino de un enlace. 

Escenario: Palabras inusuales 

Requerimiento: 

• Se debe ofrecer un mecanismo para identificar definiciones específicas de palabras o frases empleadas de una manera inusual o restringida, incluyendo modismos y jerga. Por ejemplo: agregar un glosario al sitio (con el enclace de la palabra por definir) y ofrecer la definición en la parte de abajo de la página. 

Nota: inusual o restringida se refiere a palabras utilizadas de tal manera que requieren que el usuario sepa exactamente cuál definición aplicar para entender adecuadamente el contenido. La definición apropiada puede determinarse de acuerdo al contexto. 

Nota2: modismo se refiere a frase cuyo significado no puede deducirse de las palabras que lo componen. 

Nota3: juerga se refiere a palabras que se emplean de una manera determinada por personas que pertenecer a un determinado grupo, profesión u oficio. (Nivel AAA, 3.1.3 WCAG 2.0) 

Escenario: Abreviaciones 

Requerimiento: 

• Se debe ofrecer un mecanismo para identificar la forma expandida o significado de las abreviaciones. 

Por ejemplo: proveer entre paréntesis la abreviación justo después de la forma expandida, enlaces a la definición, usar el abbr element de html, usar un tooltip, etc. (Nivel AAA, 3.1.4 WCAG 2.0)

Escenario: Nivel de lectura 

Requerimiento: 

• Cuando se requiera una habilidad de lectura más avanzada que la que proporciona el nivel de educación secundaria (eliminando nombre propios y títulos) se debe ofrecer contenido complementario o una versión del texto que no exija mayor habilidad que la que proporciona el nivel de educación secundaria. 

Por ejemplo: ofrecer un resumen de un artículo complejo para la audiencia en general, ilustraciones visuales, fotos, y símbolos para explicar las ideas eventos y procesos, etc. (Nivel AAA, 3.1.5 WCAG 2.0)

Escenario: Pronunciación 

Requerimiento: 

• Se debe ofrecer un mecanismo para identificar la pronunciación específica de palabras cuando el significado en contexto pueda ser ambiguo sin conocer su pronunciación. 

Por ejemplo: ofrecer un audio de la pronunciación, ofrecer información de la pronunciación en el glosario, etc.  (Nivel AAA, 3.1.6 WCAG 2.0)

Principio: Comprensible

La información y la operación de la interfaz deben entenderse fácilmente. 

Pauta: Predecible

Cree páginas web que se muestren y operen de forma previsible. 

El diseño y presentación de páginas web cuya apariencia, operación y navegación sea predecible y consistente evita confundir al usuario. Por esta razón, no se deben crear contenidos inesperados que desorienten principalmente a personas con discapacidades visuales, cognitivas o motoras. 

Escenario: Al recibir el foco 

Requerimiento: 

• No debe iniciarse un cambio en el contexto de la página cuando un elemento reciba el foco. (Nivel A, 3.2.1. WCAG 2.0)  

Cualquier elemento de la interfaz que desencadene un evento cuando recibe el foco no debe cambiar el contexto. 

Los cambios de contexto deben desencadenarse únicamente por una acción específica del usuario, como dar Enter  en el botón que indique la acción a realizar. 

Nota: Se entiende por cambio en el contexto, un cambio importante en el contenido de una página que (sin advertirle) puede desorientar al usuario. 

Ejemplos de cambio en el contexto: 

• Envío automático de formularios cuando un componente recibe el foco. 
• Abrir una nueva ventana cuando el elemento recibe el foco. 
• El cambio de foco a otro componente, cuando un componente inicial recibe el foco. 

Escenario: En entrada de datos 

Un cambio en la configuración de cualquier elemento de la interfaz no debe causar un cambio automático del contexto, al menos que se advierta al usuario con antelación. (Nivel A, 3.2.2. WCAG 2.0) 

Los cambios automáticos del contexto pueden confundir o distraer a usuario que no perciben fácilmente los cambios, como personas con discapacidad visual o cognitiva. Por lo que, en dicho caso se debe advertir con antelación y aclarar el cambio en el contexto que sucederá en respuesta a una específica acción del usuario. 

El objetivo es minimizar la confusión y asegurar que las entradas de datos o la selección de controles (como checkboxes) de formularios tengan efectos predecibles. 

En los formularios, siempre debe prevalecer una secuencia lógica al recorrer las entradas de datos. Si en un formulario existen opciones dinámicas (es decir que las opciones de respuesta dependan de la selección previa) estos cambios no deben afectar el contexto o el entendimiento lógico e intuitivo del usuario al menos que se le advierta. 

Por ejemplo: una serie de radio buttons al inicio de la página incluyen las opciones de: Alemán, Francés y Español. Instrucciones antes de los botones deben advertir al usuario que el idioma cambiará al seleccionar una opción. 

Escenario: Navegación Constante 

Requerimiento: 

• Mecanismos de navegación repetidos en múltiples páginas apareciendo en el mismo orden relativo. Al menos que se dé un cambio iniciado por el usuario. (Nivel AA, 3.2.3 WCAG 2.0) 

Nota: puede ser un campo de búsqueda en el mismo lugar de cada página, menús y submenús, enlace de saltar al contenido principal al inicio de cada página, etc. 

El objetivo es hacer el contenido fácil de usar al ubicar los componentes repetitivos de forma predecible. 

Un ejemplo es un encabezado que tiene el logo de la empresa, el título, el campo de búsqueda y un menú en el mismo orden relativo en cada página donde estos componentes se repiten. Incluso, si en alguna página falta el campo de búsqueda, los otros componentes se muestran en el mismo orden. 

Escenario: Identificación Constante 

Requerimiento: 

• Identificación constante de componentes con la misma funcionalidad. (Nivel AA, 3.2.4. WCAG 2.0) 

Las etiquetas, nombres o textos alternativos que tengan la misma funcionalidad deben de ser siempre constantes, aunque no necesariamente idénticos. 

Nota: Pueden ser el ícono de un documento para su descarga con su texto alternativo (descargar_nombre_del_documento), un ícono de marca de verificación que en una página funciona como "aprobado"  pero en otra "incluido" (como diferente funcionalidad tienen texto alternativo diferente), etiquetas constantes de "página 1", "página 2", "página 3", etc. íconos  con las mismas funcionalidades, el mismo botón de "guardar" en todas las páginas para la misma funcionalidad, etc. 

En el siguiente ejemplo podemos observar enlaces con una estructura similar. Primero se informa el formato (en  imagen y con su alterno correspondiente), posteriormente el nombre del documento y al final el año. Estrucutra que debe permanecer en cualquier enlace que lleve a documentos en  otro formato. 

<html>

<head>

<meta charset="utf-8">

<title>Ejemplo Tabla</title>

<style type="text/css">

a:hover, a:active, a:focus {

    color: #7A79BC;

    border-width: 25px;

    text-decoration:none;

    }

</style>

</head>

 

<body>

 

<table width="400" border="0" role="presentation">

<caption>Informes Anuales</caption>

    <tr>

      <th>Informes Anuales Word</th>

      <th>Informes Anuales Excel</th>

    </tr>

    <tr>

      <th><a href=""><img src="word.PNG" alt="Word"> Informe anual 2014</a></th>  

      <th><a href=""><img src="excel.PNG" alt="Excel"> Informe anual 2014</a></th>

    </tr>

    <tr>

      <th><a href=""><img src="word.PNG" alt="Word"> Informe anual 2015</a></th>  

      <th><a href=""><img src="excel.PNG" alt="Excel"> Informe anual 2015</a></th>

    </tr>

</table>

 

</body>

</html>

 

Escenario: Cambio a petición 

Requerimiento: 

• Los cambios de contexto deben iniciarse sólo a petición del usuario o se debe ofrecer un mecanismo para desactivar dichos cambios. 

Por ejemplo: ofrecer un botón de "Actualizar ahora"  (Nivel AAA, 3.2.5 WCAG 2.0)

Principio: Comprensible

La información y la operación de la interfaz deben entenderse fácilmente. 

Pauta: Asista en la introducción de datos

Ayude a los usuarios a evitar y corregir errores. 

Escenario: Etiquetas e instrucciones 

Requerimiento: 

• Ofrezca instrucciones o etiquetas cuando se requiera entrada de datos por parte del usuario. (Nivel A, 3.3.2 WCAG 2.0) 

La prevención de errores beneficia a personas con discapacidades cognitivas, de aprendizaje y de lenguaje. También a cualquier usuario que se encuentre capturando datos, ya que se le notifica qué tipo de información se está esperando recibir. 

El objetivo es proporcionar al usuario suficiente información para capturar los datos correctamente y cumplir la tarea con éxito desde el primer intento. Se debe asegurar también que dichas instrucciones estén cerca de las entradas de datos a las que corresponda para que el usuario de magnificadores de pantalla no se pierda dicha información. 

Ejemplos pueden ser: 

• Un campo de fecha que especifique el formato correcto de fecha a capturar 
• Un campo que especifique Apellido Paterno y otro Apellido Materno 

Si la instrucción es más compleja, se puede hacer por medio de mensajes textuales. Por ejemplo: Campos obligatorios, formato, valor o longitud específica. 

En el caso de mensajes de texto asegúrese que el usuario pueda conocer las instrucciones en el momento indicado.

Por ejemplo: En un formulario un ciego que navega con lector de pantalla utilizará la tecla Tab para navegar de campo en campo y si los mensajes de instrucción están en un  <p>, <span> o <div> estos nos recibirán el foco por default y es poco probable que el usuario los encuentre. Para solucionarlo podría agregar  tabindex=”0”.

Una opción tradicional y sencilla para notificar los campos obligatorios es incluir el texto (requerido) dentro del elemento label: 

<label for="Nombre">Nombre (requerido):</label>

<input type="text" name="nombre" id="Nombre" />

Otro ejemplo para indicar los campos requeridos podría ser (al inicio) un mensaje de texto con imagen: "Los campos con * son obligatorios". 

Y en cada campo obligatorio poner la imagen * dentor del label.  Recuerde poner siempre el texto alternativo en la imagen: 

 alt="Requerido".

Nota: si la instrucción es más larga, se puede incluir en un span modificado con css para que visualmente tenga otra presentación, pero si el span permanece dentro del label, este será leído en el momento indicado por el lector de pantalla. 

Dependerá del desarrollador, la presentación de las instrucciones de su formulario y la forma de validar, pero siempre se debe de considerar la accesibilidad con el teclado y lectores de pantalla. 

El uso de required de HTML5 

Evite utilizar únicamente required  de HTML5, en su lugar use su propia función de javascript para la validación (una que cumpla con los requerimientos de accesibilidad). Aunque required (en la mayoría de los navegadores) evita el envío del formulario cuando el campo está vacío, muestra un mensaje de error genérico (lo cual no es accesible, sobre todo si hay múltiples entradas de datos). Además, visualmente no indica que el campo es requerido (lo cual no es accesible para usuario que sí pueden ver la interfaz). 

El uso de aria-required="true" es valido y accesible, pero únicamente es informativo para tecnologías de asistencia y visualmente tampoco indica que el campo es requerido. 

Tome en consideración que para ofrecer instrucciones no solo de formularios sino para entender y operar contenido en general, no se debe de depender de características sensoriales como forma, tamaño, ubicación visual, orientación o sonido. (Nivel A, 1.3.3 WCAG 2.0) 

Escenario: Identificación de errores 

Requerimiento: 

• Si se detecta un error por medio de validaciones, se debe identificar ese error y notificar al usuario con mensaje de texto para que pueda ser corregido. (Nivel A, 3.3.1 WCAG 2.0)

La facilidad de corrección de errores beneficia a personas con discapacidades visuales, cognitivas, de aprendizaje o lenguaje. 

Algunos ejemplos de errores de usuario:

• Ingresar en el campo de código postal, uno inexistente. 
• Ingresar una fecha de nacimiento del futuro. 
• Ingresar letras en un campo numérico o viceversa 

La intención de este requerimiento es asegurar que el usuario pueda determinar la información incorrecta, por lo que el mensaje de error de cualquier validación debe cumplir lo siguiente: 

1. Ser claro y específico. 
2. Recibir el foco para que pueda ser leído por tecnologías de asistencia. 
3. Se debe ofrecer un enlace o redirección al campo de error. De no hacerlo, el usuario tendría que volver a navegar de toda la página o formulario para encontrar el campo. 

Nota1 : Recuerde no depende solo de los colores para la identificación de campos con error. 

Nota2: Si hay un campo erróneo al validar, el usuario no debe de tener que volver a escribir los campos que sí contestó correctamente. 

Nota3: Si el usuario contestó incorrectamente varios campos, estos deben de validarse en pantalla al mismo tiempo. Para que no tenga que estar enviando el formulario varias veces, solo para descubrir que sigue teniendo errores . 

Nota4: En las entradas de datos, evite cambiar el foco automáticamente. Un usuario con lector de pantalla podría confundirse o saltarse campos. También evite el envío automático de formularios. 

Escenario: Sugerencias de errores 

Requerimiento: 

• Sugerencias apropiadas para la corrección tras errores de entradas de datos. Al menos que se ponga en riesgo la seguridad o el propósito del contenido. (Nivel AA, 3.3.3 WCAG 2.0)

En un nivel AA no es suficiente que se muestre el mensaje de validación accesible (como en el nivel A). En este nivel, dicho mensaje también debe venir acompañado de sugerencias para la corrección de errores. Por ejemplo: 

• En el campo de nombre es obligatorio. Por ejemplo: Luis Hernández 
• El campo de dirección de correo electrónico es obligatorio. Por ejemplo: correo@dominio.com 
• El campo asunto es obligatorio. Ejemplo: Solicitud de información. 

Este criterio beneficia principalmente a personas con discapacidad cognitiva o de aprendizaje, quienes pueden tener dificultades para saber cómo corregir el error. Con estas sugerencias, es más seguro que el usuario pueda completar el formulario de éxito. 

Escenario: Prevención de errores (Legal, Finanzas, Datos) 

Requerimiento: 

   -   Para páginas web de compromisos legales o transacciones económicas que editen o eliminen datos aportados por el usuario en sistemas de almacenamiento de datos o que envíen respuestas de usuario a algún tipo de prueba se debe cumplir algunos de los siguientes casos: 

• Envíos reversibles. 
• Comprobación de datos y oportunidad de corregirlos. 
• Mecanismo para revisar, confirmar y corregir la información antes del envío final. (Nivel AA, 3.3.4 WCAG 2.0)

El objetivo es evitar serias consecuencias tras cometer errores al llenar formulario y realizar una acción que no es reversible. Sobre todo, en compras o transacciones inmediatas que no pueden ser cambiadas y que, en caso de error, pueden generar alto costo al usuario. Del mismo modo, se intenta prevenir que el usuario cometa errores en la edición o eliminación involuntaria de datos.

Por ejemplo, un sitio en donde el usuario realiza una compra, al enviar dicha solicitud de compra, se muestra una pantalla de "Confirmación de orden" en donde se revisa el detalle de la solicitud (artículos, cantidad, dirección de envío, forma de pago, etc.) para que el usuario pueda verificar y con base en esa información, pueda confirmar o realizar cambios. 

Otro ejemplo es en el de un sitio web de facturación electrónica https://factura.interjet.com/, en donde el usuario captura los datos da clic en Guardar, pero antes del envío final, se muestra al usuario una pantalla con los datos capturados, ya sea para Modificar o Facturar. 

Escenario: Ayuda 

Requerimiento: 

• Se deben ofrecer textos de ayuda que proporcionen información relacionada a la funcionalidad que se está realizando. (Nivel AAA, 3.3.5 WCAG 2.0) 

Escenario: Prevención de errores (Todo) 

Requerimiento: 

• Para páginas web que requieren que el usuario envíe información se debe cumplir alguno de los siguientes casos:

      

• Envíos reversibles. 
• Comprobación de datos y oportunidad de corregirlos. 
• Mecanismo para revisar, confirmar y corregir la información antes del envío final. (Nivel AAA, 3.3.6 WCAG 2.0)

Principio: Robusto

El contenido debe ser confiable para permitir su uso con una variedad de agentes de usuario. 

Pauta: Compatible

Maximice la compatibilidad con los agentes de usuario, incluidas las tecnologías de asistencia. 

Escenario: Análisis de sintaxis 

Requerimiento: 

• En contenidos implementados con lenguaje de marcado, los elementos deben contar con etiquetas completas de apertura o cierre, deben anidarse de acuerdo a las especificaciones, no deben contener atributos duplicados y cualquier ID debe ser único (excepto cuando la especificación permita estas características). (Nivel A, 4.1.1 WCAG 2.0)

Nota: Las etiquetas de apertura o cierre que carecen de algún carácter crítico en su formación (como paréntesis angular de cierre o comillas incopatibles) no se consideran completas. 

El lenguaje de marcado debe utilizar la sintaxis apropiada, cumpliendo con las especificaciones de gramática correspondientes de tal forma que facilite la accesibilidad a los agentes de usuario (incluyendo las tecnologías de asistencia). Si el contenido no está correctamente estructurado, los agentes de usuario pueden presentarlo diferente o, pero aún, ser incapaces de interpretarlo. 

Con el objetivo de cumplir con las especificaciones de gramática correspondientes, el desarrollador puede utilizar validadores automáticos para la tecnología en específico que se desea verificar. Por ejemplo: para HTML puede usar https://validator.w3.org/

Escenario: Nombre, rol o valor

Requerimiento 

Para todos los componentes de la interfaz de usuario (incluyendo, pero no limitando a: elementos de formulario, enlaces, y componentes generados por medio de scripts), el nombre y el rol pueden ser programablemente determinados; los estados, propiedades y valores que pueden ser establecidos por el usuario pueden ser programablemente configurados; y los cambios en tales ítems se notifican a los agentes de usuario, incluyendo a las tecnologías de asistencia. (Nivel A, 4.1.2. WCAG 2.0)

Nota: Este requerimiento va dirigido principalmente a desarrolladores web que programen sus propios componentes de interfaz de usuario. Por ejemplo: Los estándares de HTML automáticamente cumplen este requerimiento cuando se emplean de acuerdo a su especificación. 

El objetivo es asegurarse que las tecnologías de asistencia pueden recabar información, activar o estar al día  con los estatus de los controles de la interfaz de usuario. Cuando se utilizan los controles estándar de las tecnologías accesibles este proceso es sencillo.  Si los elementos de la interfaz son usados de acuerdo a las especificaciones, se cumple el requerimiento. 

Si se crean controles personalizados o los elementos de la interfaz son programados (en código o script) para tener un valor diferente y/o función de lo habitual, se deberán tomar medidas adicionales para asegurar que los controles proveen información importante a las tecnologías de asistencia y permitirse así mismo ser controlados por dichas tecnologías. 

Un estado particular importante de la interfaz de usuario es si recibe o no el foco. El estado del foco de un control puede ser programablemente determinado, y notificaciones sobre un cambio en el foco se envían a los agentes de usuario o tecnologías de asistencia. Otro ejemplo del estado de control en la interfaz de usuario es si el checkbox o radiobutton ha sido seleccionado o no; o si una lista desplegable se ha expandido o contraído. 

Nota: Se requiere un nombre programablemente determinado para todos los componentes de la interfaz de usuario. Los nombres pueden ser visibles o invisibles en interfaz (pero siempre esta´ran disponibles para tecnologías de asistencia). En ocasiones el nombre deber ser visible, en cuyo caso se identifica con etiqueta. 

Proveer información sobre el rol, estado y valor a todos los componentes de la interfaz permite la compatibilidad con las tecnologías de asistencia, como lectores de pantalla, magnificadores de pantalla o reconocimiento de voz. 

Ventana modal

El uso de ventanas modales (formularios de contacto, encuestas, imágenes, alertar, notificaciones, etc.) debe cumplir con ciertos requerimientos de tal manera que sea accesible y no una barrera para el usuario con discapacidad, especialmente los que usan lectores de pantalla o magnificadores. 

Antes que todo, reflexiones si la ventana modal es realmente necesaria para el sitio. Si no es indispensable, evítela. En caso afirmativo se deben cumplir los siguientes requerimientos: 

• Al abrir la ventana modal, la ubicación del foco debe pasar a dicha ventana. Esta ubicación dependerá del contenido de la ventana modal, pero el foco no debe quedarse en la ventana madre. 
• En la ventana modal, se debe poder navegar con la tecla Tab en los elementos. Y el foco debe permanecer dentro del modal hasta que se cancele, se salga del modal o se envíe/confirme la información. 
• La ventana modal debe tener el botón de cerrar y se debe de poder salir con la tecla Esc. 
• Al salir de la ventana modal, la ubicación del foco debe regresar al último lugar donde se quedó antes de abrirla. 

Por ejemplo:

Para ver su funcionamiento en línea y consultar el código visite la siguiente página:
http://hearcolors.com.mx/ejemplosaccesibleshc/DialogModal/index.html

También puede visitar el siguiente ejemplo:
http://www.hearcolors.com.mx/EjemplosAccesiblesHC/modalaccessibleOverlay/index.html

Para mayor información sobre técnicas en diferentes escenarios aprobadas por el Web Content Accessibility Guidelines Working Group para el cumplimiento de este requerimiento, visite la página:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

En caso de aplicaciones web complejas o con contenidos dinámicos se pueden utilizar roles, estados y propiedades de ARIA que van a comunicar a los lectores de pantalla lo que está pasando en la interfaz. 

Visite las páginas:
http://www.w3.org/WAI/intro/aria.php

Nota: ARIA se puede usar en HTML4 o HTML5 pero si no queremos que el validador de sintaxis de la W3C dé errores se requiere especificar el DTD de la página. 

Para HTML4: 

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/shemate/html4-aria-1.dtd">

HTML5 no lo necesita ya que en esta versión si se tiene soporte. 

Herramientas de evaluación automáticas

Actualmente existen diferentes herramientas de evaluación automática de accesibilidad web, sin embargo, existen algunos requerimientos basados en los estándares de accesibiliad que son imposibles de evaluar de manera automática, por lo que se necesitan evaluar de forma manual. 

Nota: esta evaluación debe hacerse desde el inicio del desarrollo, en ambiente test. No se esperen hasta el final porque les tomará más tiempo corregir cosas que pudieron haber quedado desde el principio (sobrbe todo si utilizaron la misma lógica en múltiples páginas). 

La evaluación puede realizarse de forma manual y el desarrollador puede apoyarse de herramientas automáticas que le ayudarán a evaluar o filtrar información más rápido para encontrar errores. Por ejemplo: una herramienta auotmática puede filtrar todos los textos alternativos de las imágenes de la página (para verificar si todas tienen un texto alternativo), pero solo un humano puede terminar si esos textos son adecuados a las imágenes. 

A continuación, recomendamos algunas herramientas automáticas de apoyo: 

• Validación automática de código HTML, XHTML, etc.  W3C Markup Validation Service:
  http://validator.w3.org/
  

• Validación automática de CSS. CSS Validation Service:
  http://jigsaw.w3.org/css-validator/
  

• Web Accesibility Evaluation Tool WAVE:
  http://wave.webaim.org/
  

En una extensión de Chrome que te permite evaluar la web. 

• Functional Accessibility Evaluator    FAE Tool:
   http://fae20.cita.illinois.edu/
  

• Web Accessibility Checker   AChecker:
  http://achecker.ca/checker/index.php
  

• Analizador de normas WCAG 2.0 versión beta TAW Validador online accesibilidad web:
  https://www.tawdis.net/
  

• Validación Sección 508 de HiSoftware® Cynthia Says™:
  https://www.st-andrews.ac.uk/itsold/web/accessibility/cynthia_validator.shtml
  

• HTML CodeSniffer version 2.1.1.:
    http://squizlabs.github.io/HTML_CodeSniffer/
  

En una secuencia de comandos del lado del cliente que comprueba el código de fuente html, viene con estándares que hacen cumplir los tres niveles de conformirdad de las "Pautas de Accesibilidad al Contenido de la Web (WCAG 2.0)"

• Analizador de contrastes de color.

- Colour Contrast Check:
http://snook.ca/technical/colour_contrast/colour.html

Esta herramienta de Contraste de Color permite especificar un primer plano y un color de fondo, para poder determinar si se ofrecen suficientes contrastes. También indicará si los colores pasan la nueva fórmula WCAG 2.0 la cual diferencía entre texto de menos de 18 puntos por encima de 18 puntos (o texto en negrita) y mayor a 14 puntos. 

Para el cumplimiento de AA, el texto debe tener una proporción de al menos 4,5:1 (texto más grande, al menos 3:1). 

Para nivel AAA el texto debe tener una proporción de al menos 7:1 (texto más grande, al menos 4,5:1)

- Contrast A:
http://contrast-a.dasplankton.com/

- Colour Contrast Analyser:
http://www.paciellogroup.com/resources/contrastanalyser/

- WebAIM Contrast Checker:
http://webaim.org/resources/contrastchecker/

- Artistic Adobe Color Contrast Checker:
http://artisticabode.com/accessibility/color-contrast/#text=575757,link=7DB194,bg=FFFFFF

- Conversión a modo de texto (Lynx)
http://www.vordweb.co.uk/standards/download_lynx.htm es un navegador web en modo texto.

Nivel de visibilidad con eDseigner

- ADesigner Software:
http://www.eclipse.org/actf/downloads/tools/aDesigner/index.php Es una herramienta para asegurar que las páginas web sean usables y accesibles para personas con discapacidad visual. Muestra la página en dos modalidades, solo texto (para simular lectores de pantalla) y baja visión.

- W3C Nu Markup Checker (experimental):
http://validator.w3.org/nu/

- Accessibility Viewer inspection tool - aViewer:
http://www.paciellogroup.com/resources/aviewer/

También son importantes las pruebas con tecnologías de asistencia como lectores de pantalla (con JAWS se recomienda su uso en Internet Explorer y con NVDA se recomienda su uso en Firefox). Así como el uso de diferentes navegadores (Internet Explorer, Chrome, Firefox, Safari, Opera, etc.) y sus complementos, por ejemplo: 

 

Internet Explorer: 

• DebungBar, para analizar el código:
  http://www.my-debugbar.com/wiki/Doc/DebugbarInstall
  
• Web Accessibility Toolbar, para evaluar accesibilidad la cual solo es compatible en el navegador IE
   http://www.paciellogroup.com/resources/wat/  
  
• Jim Thatchers Favelets, para evaluar accesibilidad
   http://jimthatcher.com/favelets/
  

Firefox: 

• Firebug, para analizar el código.
  https://addons.mozilla.org/es/firefox/addon/firebug/
  
  Firebug marcó el comienzo de la era de la Web 2.0 que llegó a su fin en el 2017 pero sigue vivo en Firefox developer Tools.
• Web Developer, que brinda utilidades de edición y depuración para desarrollo es un complemento de Firefox y es soportada hasta la versión de Firefox Quantum.
  https://addons.mozilla.org/es/firefox/addon/web-developer/

• Accessibility Evaluation Toolbar, para evaluar accesibilidad, también es un complemento de Firefox y es compatible hasta la versión 47
  https://addons.mozilla.org/es/firefox/addon/accessibility-evaluation-toolb

• Deque aXe, para evaluar accesibilidad, también es una extensión de Chrome
  https://addons.mozilla.org/en-us/firefox/addon/axe-devtools/?src=search&utm_campaign=aXe%20The%20Accessibility%20Engine&utm_content=aXe%20for%20Firefox&utm_medium=Hyperlink&utm_source=Website
• Jim Thatchers Favelets, para evaluar accesibilidad.
  http://jimthatcher.com/IBM/js/FaveletToolbar.xpi
• Juicy Studio Accessibility Toolbar, para evaluar accesibilidad (WAI-ARIA), tablas y contrastes.
  https://addons.mozilla.org/es/firefox/addon/juicy-studio-accessibility-too/
• User Agent Switcher, para evaluar en sitios responsivos.
  https://addons.mozilla.org/es/firefox/addon/user-agent-switcher/developers
• WCAG Contrast checker, para evaluar contrastes (visión normal y otros estados), para Firefox 59
  https://addons.mozilla.org/en-US/firefox/addon/wcag-contrast-checker/?src=search
   

• ColorZilla 3.3
  Complemento para Firefox que ayuda a los desarrolladores web y diseñadores gráficos con tareas relacionadas al color. Con este complemento se puede obtener una lectura de colores desde cualquier punto de su navegador.
  http://www.colorzilla.com/
  
• Fangs, para visualizar el texto que simula el uso de un lector de pantalla.
  https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/
• DOM inspector, para inspeccionar el Document Object Model tree, no es compatible con Firefox versión 59
  https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/

• AInspector Sidebar, no es compatible con Firefox 59
  https://addons.mozilla.org/es/firefox/addon/ainspector-sidebar/

Chrome:

• Web Developer
  http://chrispederick.com/work/web-developer/
• Deque aXe, para evaluar accesibilidad.
  https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

• Jim Thatchers Favelets, para evaluar accesibilidad.
  http://jimthatcher.com/favelets/
• Accesibility Developer Tools
  https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb
• ARIA validator , para validar la implementación de ARIA en el HTML.
  https://chrome.google.com/webstore/detail/aria-validator/oigghlanfjgnkcndchmnlnmaojahnjoc
• Chrome Daltonize , para simular y comprender problemas de visión como Protanopía, Deuteranopía o Tritanopía.
  https://chrome.google.com/webstore/detail/chrome-daltonize/efeladnkafmoofnbagdbfaieabmejfcf
  • Vista normal:
    
  • Protanopía:
    
  • Tritanopía:
    

• WAVE Toolbar , para evaluar accesibilidad:
  https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh
• NoCoffee
  Extensión de Chrome que simula discapacidades visuales.
  
• Funkify
  Extensión para Chrome que te ayuda a experimentar la web y las interfaces a través de los ojos de usuarios extremos con diferentes habilidades y discapacidades. Es creada por un equipo experto en usabilidad y accesibilidad en Suecia.
  https://www.funkify.org/
  

Pruebas de evaluación para accesibilidad

Desde el diseño y las primeras estapas del proyecto, se debe considerar la accesibilidad. En cada etapa del proceso y antes de salir a producción, el equpo de desarrollo debe de hacer pruebas con validadores automáticos que detecten incumplimientos de los estándares internacionales y de forma manual. 

Cuando ya se cuenta con un ambiente test, lo primero que se evalúa es la página inicial del sitio. En la página inicial normalmente se muestra contenido que se repetirá en otras páginas del mismo sitio, por ejemplo: el encabezado, el menú, el pie de página y sección izquierda o derecha. Si el contenido es el mismo, solo se requiere evaluar una vez. 

En todas las páginas y principalmente los componentes como menú y submenú, acordeón, tabpanel, carrusel, canvas, svg, etc. se debe verificar la navegación y correcta funcionalidad tanto con mouse como con teclado. Ya que algunas personas con discapacidad solo utilizan el teclado y algunas tecnologías de asistencia simulan el efecto del mouse, por lo que ambas opciones de navegación son importantes. 

Nota: para la prueba con teclado, por ningún motivo debe utilizarse el mouse (guárdenlo en una cajita o tápenlo). Unicamente teclas como Tab, Shift+Tab (para regresar), flechas, enter, etc. 

Se recomienda realizar pruebas con al menos dos lectores, entre los más utilizados se encuentran: 

• Lector de pantalla JAWS descarga JAWS
• Lector de pantalla NVDA descarga NVDA

Combinaciones recomendadas para garantizar mejor compatibilidad: 

• JAWS con Internet Explorer
• NVDA con Firefox
• VoiceOver con Safari

Se recomienda también incluir en el equipo de desarrollo a personas con discapacidad, quienes ofrecen una perspectiva diferente. Si dichos usuarios tienen conocimiento de los estándares internacionales y conocimientos de desarrollo, su retroalimentación será mucho más efectiva.

Nota: existen algunos criterios que no podrán ser evaluados por una persona con discapacidad visual, por ejemplo: una persona ciega no podrá evaluar contrastes de color. Sin embargo, existen muchos criterios que, sí pueden evaluar una persona con discapacidad visual, en lo cuales se deberá enfocar. Por ejemplo: las validaciones de un formulario de contacto. Ya que dichas validaciones pueden ser accesibles a la vista, pero no mediante un lector de pantalla.

Nota: considerar a las personas con discapacidad tiene efectos positivos en el proyecto, los desarrolladores se van sensibilizando sobre la importancia de la accesibilidad y van aprendiendo temas específicos de programación que deben considerar para hacer accesibles los elementos de la página.

Al navegar con teclado y lector de pantalla, el tester debe verificar varios puntos: 

• Que los elementos que deben recibir el foco (enlaces, entradas de datos o botones), si reciban el foco. 
• Que se visualice la ubicación del foco. 
• Que el lector de pantalla anuncie etiquetas o textos alternativos adecuados.  
• Que se pueda navegar o realizar correctamente las funcionalidades de componentese como menú y submenú, acordeón, tabpanel, carrusel, etc. En dichos componentes también debe verificarse que se anuncien los roles y estados. 

Nota: debido a los diferentes tipos de navegadores y lectores de pantalla (o versiones de los mismos), los resultados de las pruebas pueden variar. Si el sitio se desempeña mejor en ciertos navegadores o con ciertos lectores de pantalla, se debe informar al usuario la combinación recomendada. 

El tester deberá identificar en sus resultados dos puntos importantes: 

• Problemas de accesibilidad
• Resultados accesibles óptimos

En ambos casos debe identificarse en que navegadores o con que lectores de pantalla se obtuvieron dichos resultados. 

Dichos resultados se pueden documentar en matrices de pruebas o en texto, dependerá de la complejidad del sitio y de los resultados. En caso de incumplimiento del estándar o cualquier retroalimentación, es importante que se proporcione suficiente información del elemento y ubicación del problema presentado, de tal manera que el desarrollador pueda identificar el obstáculo y corregirlo. 

En dichas evaluaciones pueden surgir problemas de usabilidad y de accesibilidad, ambos deben identificarse y solucionarse. 

El equipo de desarrollo debe considerar la retroalimentación o recomendaciones obtenidas en las pruebas para realizar las mejoras necesarias. Y repetir estos pasos las veces que sea necesario. Al salir a producción, cualquier usuario final debe poder navegar de manera efectiva en todo el sitio. De hecho, si se trata de algún proceso o tienda en línea, el usuario debe poder cumplir los objetivos de manera independiente. 

Importante: la accesibilidad debe mantenerse con el paso del tiempo, sobre todo en sitios que se actualizan constantemente. 

En conclusión, la accesiblidad siempre debe estar presente. 

Trabajar en la accesibiliad implica mayor esfuerzo, pero el usuario al final te lo agradecerá. 

Tu trabajo puede tener un impacto positivo en la vida de los demás.

Las pequeñas decisiones de diseño o desarrollo que tomas todos los días pueden tener un potencial enorme y eliminar las barreras que enfrentan las personas con discapaciadad en el mundo digital.

Fuente de imagen "Are you ready for Prime Time" 

Administración en organizaciones

Tanto en el sector público como en el privado, las empresas, instituciones, organizaciones, etc. deben incentivar, promover y apoyar la accesibilidad. 

Normalmente el gobierno o las empresas se preocupan por la accesibilidad física, sin tomar en cuenta la accesibilidad digital. Ambos escenarios son de suma importancia y de eso depende que las personas con discapacidad tengan o no acceso equitativo. 

En el caso de la accesibilidad digital, lo primero en lo que se debe de trabajar es en la concientización y sensibililzación en el tema en todos los niveles y en todas las áreas. Si las personas que conforman la organización no están en la misma frecuencia, será muy difícil para unos cuantos implementar y mantener la accesibilidad. 

Una vez que se reconoce la necesidad de abordar el tema y realizar mejoras, pueden exisitr diversas soluiciones, por ejemplo: 

• Que el equipo de desarrollo decida realizar cambios y mejoras sobre la página web o sistema con el que cuentan actualmente. 
• Que decidan iniciar desde cero y trabajar en una nueva versión o en un nuevo proyecto. 
• Que, a partir del día de hoy, en actualizaciones y nuevos proyectos, se tomará en cuenta la accesibilidad. 

Cada una de estas opciones puede tener sus ventajas o desventajas. El equipo debe evaluar los problemas del sitio y tomar la mejor decisión. 

Por ejemplo: 

• En algunos casos corregir errores puede llevar mucho tiempo, sobre todo si es un sitio muy complejo o dinámico y con muchos problemas de accesibilidad. Pero posiblemente sea más viable que crear un sistema completamente nuevo. 
• En proyectos pequeños tal vez sea mejor publicar una nueva página tomando en cuenta la accesibilidad desde el principio, posiblemente sea más rápido y económico que corregir el actual. 
• En otros casos, después de la evaluación del sitio o auditoría,  el equipo se puede dar cuenta de que ya cumplen algunos criterios y que son pocos los cambios que se deben realizar para ser accesibles. Si el sitio es estático, la mayoría de los criterios no aplican para su cumplimiento, por ejemplo: si el sitio no tiene video, audio, límites de tiempo, contenido en movimiento o actualizado automáticamente,etc. 
• Otra opción es definir prioridades en los problemas de accesibilidad, para implementar las mejoras poco a poco . 

Los tiempos también pueden variar, dependiendo de los conocimientos técnicos en accesibilidad del equipo y si dichas personas están dedicando su trabajo 100% a la accesibilidad o si la accesibilidad es solo una más de sus múltiples responsabilidades. 

En cualquiera de los casos, una vez que se ha trabajado en la accesibilidad, esta debe mantenerse y no olvidarse en las actualizaciones o nuevas publicaciones.

Para que este cambio tenga éxito, a los procesos de desarrollo se les debe incluir la accesibilidad de manera permanente, desde la planeación, el diseño, el desarrollo y el testing. 

Se necesitan equipos comprometidos con la accesibilidad. Si es posible un equipo dedicado 100% a la accesibilidad o al menos una persona que se encargue de líderear, sensibilizar y coordinar que la accesibilidad se tome en cuenta en los proyectos. 

Incluir a personas con discapacidad es la manera más efectiva para que los equipos de trabajo entiendan la importancia y el impacto positivo que puede tener la accesibilidad o el impacto negativo si no se considera. De hecho, uno de los beneficios de la accesibilidad es que personas con discapacidad puedan tener un empleo digno, no solo en el área de desarrollo o en el equipo de accesibilidad, si no en cualquier área de la organización. 

El equipo debe fijar los objetivos a cumplir, por ejemplo: ¿Cuál estándar o legislación se desea cumplir? ¿Qué nivel de accesibilidad? ¿Cuáles son los recursos para lograrlo? 

Si no se cuenta con el expertise internamente, se puede contratar a un proveedor, al menos al inicio. Lo ideal es que cada organización cuente con personal capacitado para lograr estas metas. Pueden contratar a personas especializadas en accesibilidad o pueden capacitar al personal actual, después de la curva de aprendizaje todo será más fácil. Se recomienda también que en las nuevas contrataciones se soliciten conocimientos en el tema. 

Si las organizaciones empiezan a demandar profesionistas con conocimientos en accesibilidad, los estudiantes se tendrán que capacitar y el cambio a nivel social y económico puede ser muy grande. Los estudiantes empezarían a solicitar a las universidades dicha capacitación. Así mismo, si una organización contrata a un proveedor para crearles una página web o sistema, esta organizzación debe incluir dentro de sus requerimientos la accesibilidad, de tal forma que otras empresas empiecen a capacitarse y crear desarrollo accesibles, ofreciendo un valor agregado a sus clientes. 

Todo lo anterior, debe ser apoyado por niveles directivos de la organización. Adicionalmente, por ser un tema de impacto social, se puede declarar en medio de comunicación y redes sociales, el compromiso en favor de las personas con discapacidad. 

La accesibilidad es un tema serio que amerita el esfuerzo y compromiso de todos. 

El objetivo principal es que la accesibilidad sea "como de costumbre".

Bibliografía

"Web Content Accessibility Guidelines (WCAG) 2.0
Ben Caldwell, Trace R&D Center, University of Wisconsin-Madison
Michael Cooper, W3C
Loretta Guarino Reid, Google, Inc.
Gregg Vanderheiden, Trace R&D Center, University of Wisconsin-Madison
http://www.w3.org/TR/WCAG20/

 

“Techniques for WCAG 2.0
Michael Cooper, W3C
Andrew Kirkpatrick, Adobe Systems Inc.
Joshue O Connor, NCBI Centre for Inclusive Technology (CFIT)
http://www.w3.org/TR/WCAG20-TECHS/

 

Traducción al español del documento Web Content Accessibility Guidelines (WCAG) 2.0:
"Pautas de Accesibilidad de Contenido Web 2.0
Saúl González Fernández
http://www.codexexempla.org/traducciones/pautas-accesibilidad-contenido-web-2.0.htm

 

Lista de principios y técnicas de las WCAG 2.0: "Guías Prácticas para Profesionales Web:
Puntos de verificación de las Pautas de Accesibilidad al Contenido Web (WCAG) 2.0
Quevedo Santana
http://qweos.net/blog/2009/01/28/guias-practicas-para-profesionales-web-puntos-de-verificacion-de-las-pautas-de-accesibilidad-al-contenido-web-wcag-20/

 

The world´s largest web development site
http://www.w3schools.com/

 

Deque University
https://dequeuniversity.com/

 

The Paciello Group Blog
http://www.paciellogroup.com/blog/

 

PayPal Open Source projects
http://paypal.github.io/

 

Web accessibility Tutorials: Guidance on how to create websites that meet WCAG
http://www.w3.org/WAI/tutorials/

 

Accessible Rich Internet Applications (WAI-ARIA) 1.0
http://www.w3.org/TR/wai-aria/

Web Content Accessibility Guidelines (WCAG 2.1) Introducción

Para la realización de esta guía se tomaron como base de las Pautas de Accesibilidad para el Contenido Web en su versión 2.1 (WCAG 2.1) del World Wide Web Consortium (W3C) dichas pautas cubren una amplia gama de recomendaciones para hacer que el contenido Web sea más accesible. 

Estas pautas están abordando la accesibilidad del contenido web en computadoras de escritorio, computadoras portátitles, tabletas y dispositivos móviles. Siguiendo las pautas también hará que el contenido web sea más usable para los usuarios en general. 

El contenido que cumple con WCAG 2.1 también se ajusta a WCAG 2.0. La publicación de WCAG 2.1 no desaprueba ni sustituye a WCAG 2.0 y sigue siendo una recomendación de la W3C que aconseja el uso de la WCAG 2.1 para maximizar la aplicabilidad futura de los esfuerzos de accesibilidad. 

Las Pautas de Accesibilidad para el contenido Web (WCAG) 2.1 definen cómo hacer que el contenido web sea más accesible para las personas con discapacidad que incluye (discapacidades visuales, auditivas físicas, del habla, cognitiva, del lenguaje, del aprendizaje y neurológicas). Aunque estas pautas cubren una amplia gama de cuestiones no pueden abordar las necesidades de las personas con diferentes tipos, grados y combinaciones de discapacidad. Estas pautas también hacen que el contenido web sea más útil para personas mayores, mejorando la usabilidad para los usuarios en general. 

WCAG 2.1 se basa en WCAG 2.0, que a su vez se basa en WCAG 1.0 y está diseñado para aplicarse ampliamente a diferentes tecnologías web ahora y en el futuro. 

Para satisfacer diferentes necesidades la W3C proporcionó varias capas de orientación que incluyen: 

1. Principios Generales: En la parte superior hay 4 principios que proporcionan la base para el acceso a la Web, los cuales son Perceptible, Operable, Comprensible y Robusto. 
2. Pautas: Bajo los principios son pautas, que son 13 directrices que proporcionan lo objetivos básicos que los autores deben trabajar para hacer que el contenido sea más accesible para los usuarios con diferentes discapacidades. Las pautas no son verificables, pero brindan el marco y los objetivos generales para ayudar a los autores a comprender los criterios de éxtio y a implementar mejoras en las técnicas.  
3.  Criterios de Éxtio: Para cada directriz se proporcionan criterios de éxtio verificables para permitir que la WCAG 2.0 se use cuando los requisitos y las pruebas de conformidad son necesarios, como en las especificaciones del diseño, compras, regulación y acuerdos contractuales. Por lo cual para satisfacer las necesidades de diferentes grupos y situaciones que se definen en 3 niveles de conformidad: A (más bajo), AA y AAA (más alto). 
4. Técnicas de asesoría suficiente:  Las técnicas son informativas y se dividen en dos categorías: las que no son suficientes para cumplir los criterios de éxito y las que son de carácter consultivo. 

Todas estas capas de orientación trabajan juntas para proporcionar orientación sobre cómo hacer el contenido sea más accesible. 

WCAG 2.1 cumple con un conjunto de requisitos, que a su vez hereda los requisitos de la WCAG 2.0, los cuales estructruan el marco general de directrices y garantzian la compatibilidad con versiones anteriores. 

La WCAG 2.1 se inició con el objetivo de mejorar la orientación de accesibilidad para tres grupos de usuarios con discapacidades las cuales son: cognitivas o de aprendizaje, usuarios con baja visión y usuarios con discapacidades en dispositivos móviles. Los requerimientos para la WCAG 2.1 avanzan progresivamente de orientación de accesibilidad del contenido de la web para todas estas áreas, pero subraya que no todas las necesidades del usuario se cumplen con estas directrices. 

WCAG 2.1 se basa y es compatible con versiones anteriores de WCAG 2.0, lo que significa que las páginas web que cumplen con WCAG 2.1 también se ajustan con WCAG 2.0. Los sitios que requieran cumplir con WCAG 2.0 podrán actualizar el contenido a WCAG 2.1 sin perder conformidad con WCAG 2.0 y de deben tener en cuental as siguientes diferencias: 

WCAG 2.1 amplía WCAG 2.0 al agregar nuevos criterios de éxito, este enfoque ayuda a dejar en claro que los sitios que se ajustan a WCAG 2.1 también se ajustan con WCAG 2.0. Los sitios que requieran cumplir con WCAG 2.0 

Nuevos criterios en WCAG 2.1

Los siguientes criterios de éxito son nuevos en WCAG 2.1: 

Escenario: Orientación

R 1.3.4 Requerimiento: 

• El contenido no restringe su vista y funcionamiento a una única orientación de visualización como vertical u horizontal, a menos que una orientación de visualización específica sea escencial. (Nival AA, 1.3.4. WCAG 2.1)

La intención de este criterio de conformidad es garantizar que el en contenido que se muestra en la orientación (vertical u horizontal) preferida por el usuario. Algunos sitios web y aplicaciones configuran y restringen automáticamente la pantalla a una orietnación de visualización en particular y esperan a que los usuarios respondan girando su dispositivo para que coincida, pero esto puede crear problemas, por ejemplo: 

Stephen Hawking quedó en una situación de discapacidad de causa de esta enfermedad denominada esclerosis lateral amitrófica. Desde 1985 utilizó un sintetizador de voz para comunicarse, con el tiempo fue perdiendo uso de sus extermidades, incluyendo la fuerza del cuello para mantener la cabeza erguida. La silla de ruedas que usaba estaba controlada por un ordenador que manejaba a través de leves movimientos de cabeza y ojos. 

Por lo tanto, lo sitios web y las aplicaciones deben admitir ambas orientaciones. El objetivo de este criterio de conformidad es que los creadores nunca deben restringir la orientación del contenido, garantizando así que siempre coincida con la orientación de la visualización del dispositivo. 

Beneficios: 

• Los usuarios con impedimentos de destreza que tengan un dispositivo montado podrían usar el contenido de su orientación fija.
• Los usuarios con baja visión podrán ver el contenido en la orientación que mejor funcione para ellos, por ejemplo (aumenta el tamaño del texto al ver el contenido en horizontal). 

Ejemplos: 

• Un sitio web de videos en línea (Un vídeo se muestra en vertical o en paisaje según la orientación elegida por el usuario) 
• En aplicaciones web eReader se pueden mostrar los contenidos de un libro  en orientación (vertical u horizontal)

Técnicas suficientes: 

• Usar una regla de Css para configurar la orientación para permitir tanto el paisaje como el relato. 
• Uso de los controles show/hide para permitir el acceso al contenido en diferentes orientaciones. 

Fallas:

•  Bloquear la orientación es decir dejarla en una posición fija. 

Escenario: Identificar el propósito en entradas de datos 

R 1.3.5 Requerimiento: 

• El propósito de cada campo de entrada que recopila información sobre el usuario se puede determinar mediante programación (Nivel AA, 1.3.5. WCAG 2.1) 

La intención de este criterio de conformidad ayuda a personas a reconocer y entender el propósito de los campos de entrada de formulario web, esperamos que proporcione información acerca de ellos en varios campos, por ejemplo: nombre, apellido, domicilio, email. Lo que se requiere es especificar que tipo de datos se espera en un campo particular para facilitar el llenado de formularios, especialmente para personas con discapacidad cognitiva. 

El propósito de cada campo que recoge información del usuario se puede determinar cuándo: 

1. El campo tiene un propósito identificado y concreto. 
2. El contenido está implementado usando una tecnología con soporte para identificar el significado esperado del dato introducido en un campo del formulario. 

Gracias a esta información en los formularios se puede proporcionar correctamente la función al hacer uso del atributo autocomplete el cual ayuda a rellenar los formularios de forma más rápida, sencilla y evita cometer errores. 

Beneficios: 

• Las personas con discapacidades o discapacidad relacionada con el lenguaje y la memoria que les afecta en la toma de decisión se benefician del hecho de que el naveador autocomplete la información, lo que significa que no es necesario ingresar información mediante el teclado. 
• Las personas con discapacidad motriz también se benefician al reducir la necesidad de introducir información de foma manual .

Ejemplos:

• Un formulario de contacto con autocompletar es decir que rellena de forma automática los campos de nombre, calle, CP, ciudad, e-mail, teléfono de los valores autocompletar almacenados en el navegador del usuario. 

Técnicas suficientes: 

• Se requiere identificar el propósito de las entradas utilizando los valores del atributo autocomplete.

 

Escenario: Identificar el propósito

R 1.3.6 Requerimiento: 

• Crear contenido que pueda presentarse de diferentes formas sin perder información o estructura en componentes de interfaz, iconos y regiones (Nivel AAA, 1.3.6 WCAG 2.1)

El objetivo de este criterio es apoyar a la personalizacion y las preferencias para que más personas puedan usar la web, comunicarse e interactuar con la sociedad. Los términos y símbolos familiares son clave para que los usuarios con un vocabulario limitado puedan usar la web, sin embargo, lo que es familiar para algunos usuarios no lo es para otros. 

Para este criterio de éxito se requiere que se agregue el contexto, la propuesta y el significado de símbolos, regiones, botones, enlaces y campos para que las tecnologías de usuario sepan lo que hacen y puedan adaptarlo para la comprensión del usuario, el cual se logra agregando semántica o metadatos que proporcionan el contexto. 

Beneficios: 

El grupo de personas que se beneficiaran son las que tienen discapacidades cognitivas diferentes como son (pérdida de memoria, enfoque y atención) y también ayudará a los usuarios que necesitan un soporte adicional incluyendo (símbolos y gráficos, atajos de teclado, menos funcionees y menos sobrecarga cognitiva). 

Ejemplos: 

Un sitio web que utiliza puntos de referencia (landmark) ejemplo: https://www.hearcolors.com.mx/

<div role="navigation">

<div role="contentinfo">

Técnicas suficientes: 

• Hacer uso de landmark de forma correcta. 
• Proporcionar semántica que permita símbolos sobre el contenido clave. COGA (Cognitive and Learning Disabilities Accessibility Task Force

Escenario: Flujo de información

R 1.4.10 Requerimiento: 

• El contenido se puede presentar sin pérdida de información o funcionalidad y sin necesidad de desplazarse en dos dimensiones (Nivel AA, 1.4.10 WCAG 2.1)

El objetivo de este criterio de conformidad es apoyar a las personas con baja visión que necesitan ampliar el texto y leerlo en una sola columna, cuando el zoom del navegador se usa para escalar el contenido al 400%, se vuelve a refluir es decir se presenta en una columna por lo que no es necesario desplazarse en más de una dirección. 

El respaldo de reflujo de contenido también se conoce como "diseño web receptivo" y está habilitado por las consultas de medios de CSS que re-formatean el contenido web para diferentes anchos de vistas, con el fin de proporcionar diseños optimizados para dispositivos móviles como tabletas o teléfonos inteligentes, tomando en cuenta: 

• El contenido con desplazamiento vertical con un ancho equivalente a 320pxCSS
• El contenido con desplazamiento horizontal con altura equivalente a 256px CSS

Este requerimiento está muy relacionado con el actual criterio 1.4.4 "Cambio de tamaño del texto: A excepción de los subtítulos y las imágenes de texto, todo el texto puede ser ajustado sin ayudas técnicas hasta un 200% sin que se pierda el contenido o la funcionalidad Nivel (AA)" el cual habla de la opción de los navegadores de aumentar el tamaño de letra, eso se centra en la opcóin de zoom, que es el método predeterminado de los navegadores para aumentar el tamaño del  contenido, lo que ayuda a personas con problemas de visión. Este nuevo requerimiento lo complementa porque una proporción significativa de personas con baja visión necesita un aumento superior al 200% (el 25% de los usuarios con baja visón de la encuesta de Webaim indicaron que necesitan una ampliación de 400% o más). 

Este requerimiento requiere que se asegure que se puede hacer zoom de 400% sin pérdida de contenido o funcionalidad y se eviten los dobles scroll. 

Beneficios: 

• Una vista de columna en diseño receptivo: 

Un sitio usa diseño receptivo. Cuando una persona amplía el zoom más de 300% el diseño se vuelve a transferir a una columna y esto beneficia al usuario ya que podrá leer el contenido fácilmente y no tiene que desplazarse hacia los lados para leer.

• PDF que ofrece reflow

En un PDF creado para ajustarse a un PDF/Accesibilidad Universal (ISO 14289), el contenido se puede volver a enfocar y ampliar para hacer posible la lectura para una persona con baja visión. 

Técnicas suficientes incluye usar: 

Media Queries, permite cargar dinámicamente las diferentes CSS que hemos definido en función del tamaño de pantalla, su resolución o su orientación. 

<link rel="stylesheet" type="text/css" href="style2col.css" media="all and (min-width: 400px) and (max-width: 800px)" />

En este ejemplo se especifica la regla de CSS a utilizar (layout de 2 columnas) con un viewport (la parte de pantalla donde se representa el documento) de una anchura entre 400px y 800px. 

Media Queries son recomendación del W3C desde junio 2012. 

También se puede usar CSS grids o CSS Flexbox para reajustar los contenidos, calcular por programación los tamaños y posiciones de los elementos de manera que escalen con el tamaño del texto. 

Fallas: 

• Errores comunes, usar tamaños y posiciones fijas, impedir el zoom y usar texto preformateado. 

Escenario: Contraste no textual

R 1.4.11 Requerimiento :

Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo (Nivel AA, 1.4.11 WCAG 2.1). 

La intención de este criterio de conformidad es garantizar que las personas con visión moderadamente baja distinguen los componentes activos de la interfaz de usuario es decir los controles y los gráficos significativos. 

Los controles de bajo contraste son más difíciles de percibir y las personas con discapacidad visual pueden pasar por alto completamente, si se necesita un gráfico para comprender el contenido o la funcionalidad de la página web, entonces debería ser perceptible para personas con baja visión u otras deficiencias sin la necesidad de tecnología asistencial que mejore el contraste.

El indicador de enfoque visual para un componente debe tener suficente contraste contra el fondo adyacente cuando el componente está enfocado, excepto cuando el agente del usuario determina la apariencia del componente y no lo modifica el autor. 

Un control activo sin un límite visual, pero con el indicador de enfoque cuando está enfocado. 

Los criterios de éxito de uso del color abordan el cambio solo del color de un objeto o texto sin alterar la forma del objeto. Si un indicador de control de estado, por ejemplo, fondo del botón varía solo por color lo cual es aceptable si la relación de contraste de luminosidad entre los colores de los estados difiere al menos 3:1 o si hay otro indicador de estado. 

Ejemplos: 

Para diseñar indicadores de enfoque, indicadores de selección y componente de interfaz de usuario que necesitan ser percibidos claramente, los siguientes ejemplos que tiene suficiente contraste: 

Tipos de Texto

Tipo	Descripción	Ejemplos
Texto del enlace	El texto del enlace predeterminado está en el alcance de contraste mínimo y el subrayado es suficiente para indicar el enlace.
Estilo de enfoque predeterminado	Se requiere que los enlaces tengan un indicador de enfoque en enfoque visible. Cuando el estilo de enfoque del agente de usuario no se ajusta en controles interactivos como enlaces, campos de formulario o botones, el estilo de enfoque es suficiente.
Botones o botones con estilo	Cuando los enlaces o botones han sido diseñados (incluido el indicador de enfoque), estos deben cumplir con la relación de contraste 3:1
Entrada de texto (mínima)	Cuando una entrada de texto tiene un indicador, como un borde inferior, ese indicador debe cumpllir con la relación de contraste 3:1
Entrada de texto	Cuando una entrada de texto tiene un indicador, como un borde inferior, ese indicador debe cumplir con la relación de contraste 3:1
Estilo de enfoque de entrada de texto	Se requiere agregar un indicador de enfoque, y debe cumplir con la relación de contraste 3:1
Entrada de tecto usando color de fondo	La entrada de texto utiliza un color de fondo diferente para indicar la entrada, no se requiere ningún borde para indicar el cuadro de entrada.
Entrada de texto usando el estilo de enfoque de color de fondo	Cuando un estilo de foco creado por el autor se aplica a un fondo oscuro, debe tener un contraste 3:1 con el entrono y/o la entrada.

 

Ejemplos para objetos gráficos: 

• Un gráfico utliza un fondo claro y asegura que los colores de cada línea tengan relación de contraste 3:1 con el fondo. 

Los gráficos circulares son un buen estudio de caso para gráficos que forman parte de nuesetros criterios de éxito 

Beneficios: 

• Las personas con baja visión a menudo tienen dificultades para percibir gráficos que no tienen suficiente contrastes. Se requiere proporcionar una luminancia relativa de 3:1 o superior para que estos elementos sean más distuinguibles cuando la persona no ve una gama completa de colores. 

Fallas: 

• El error se deberá a los contornos y bordes del elemento de estilo de una manera que elimina o hace que el indicador de enfoque visual no sea visible. 

Escenario: Espaciado de texto

R 1.2.12 Requerimiento:

• El contenido implementado utilizando lenguaje de marcado que admite las siguientes propiedades de estilo de texto, no se produce pérdida de contenido o funcionalidad al configurar todo lo siguiente y al no cambiar ninguna propiedad de estilo (Nivel AA, 1.4.12 WCAG 2.1).

La intención de este criterio de conformidad es garantizar que las personas puedan anular el espacio de texto para mejorar su experiencia de lectura.  Cada uno de los siguientes requisitos estipulados en las siguientes viñetas ayudan a garantizar que el usuario pueda adaptar el estilo de texto a sus necesidades. 

• Espacio entre líneas: al menos 1.5 veces el tamaño de la fuente. 
• Espacio párrafos: al menos 2 veces el tamaño de la fuente. 
• Espaciado entre letras (tracking): al menos 0.12 veces el tamaño de la fuente. 
• Espaciado entre palabras (kerning): al menos 0.16 veces el tamaño de la fuente. 

El cual se centra en la capacidad de aumentar el espacio entre líneas, palabras, letras y párrafos. Cualquier combinación de estos puede ayudar a leer el texto de manera efectiva y además asegurarse de que el usuario pueda cambiar a una familia de fuentes (tipo de letra) más amplia que la que el autor ha configurado para leer el texto de manera efectiva. 

No significa que el texto deba tener esos espaciados, sino que debes comprobar que con esos espaciados no se produzcan solapamientos, textos cortados o desbordados que provoquen pérdida de contenido o funcionalidad y esto no se aplica ni a las imágenes de texto ni a los subtítulos. 

Este criterio asegurará que la distancia entre las líneas, los párrafos, las palabras o los caracteres seguirá siendo adecuada para la lectura, aunque se modifique la presentación. 

Técnica suficiente que se incluye es: el espaciado del texto se pueda cambiar, siendo un error habitual usar medidas fijas. 

Técnicas recomendables: usar las propiedades CSS letter-spacing, line-heigh y definir el tamaño de los contenedores en unidades de medida em. 

Beneficios: 

• Las personas con baja visión que requieren un mayor espacio entre líneas, palabras y letras son capaces de leer el texto.
• Las personas con dislexia pueden aumentar el espacio entre líneas, palabras y letras para aumentar la velocidad de lectura. 
• Aunque no es requerido para este requerimiento, el espacio en blanco entre bloques de texto puede ayudar a las personas con discapacidades cognitivas a discernir secciones y llamar cajas. 

Escenario: Contenido en Hover o Focus

R 1.4.13 Requerimiento:

• Cuando la recepción y luego la eliminación del puntero o el foco del teclado desencadena un contenido adicional para ser visible y luego oculto se debe: (Nivel AA, 1.4.13 WCAG 2.1)

• Ofrecer un mecanismo disponible para descartar el contenido adicional sin mover el puntero o el foco del teclado, a menos que el  contenido adicional comunique un error en la entrada de datos. 
• Si el puntero del crusor puede activar el contenido adicional el puntero se debe poder mover sobre el contenido. 
• El contenido adicional debe permanecer visible hasta que se elimine el activador o enfoque. 

El contenido adicional que aparece y desaparece en coordinación con el foco del teclado o el puntero a menudo conduce a problemas de accesibilidad, las razones son: 

• El usuario puede no haber tenido la intención de desencadenar la interacción. 
• El usuario puede no saber que ha aparecido nuevo contenido.

 

Beneficios:

• Los usuarios con baja visión que ven contenido bajo ampliación podrán ver mejor el contenido o el foco sin reducir el aumento deseado. 
• Los usuarios que aumentan el tamaño de los cursores del mouse a través de la configuración de la plataforma o la tecnología de asistencia podrán utilizar una técnica para ver el contenido oculto. 
• Los usuarios con baja visión o discapacidad cognitiva tendrán el tiempo adecuado para percibir el contenido adicional que aparece al pasar el mouse. 

Ejemplo:

Se muestra información debajo del botón LVTF al pasar el mouse, sin embargo, oculta el contenido debajo, para cumplir el requerimiento el usuario puede presionar la tecla Esc esto ocultará la información sin mover, como se muestra en la siguiente imagen.

Técnicas suficientes:

• Hacer uso del atributo de ARIA role="tooltip"
• Uso de pseudo clases para hover y focus en la regla de CSS

Escenario: Atajos de teclado Shortcuts de caracteres

R 2.1.4 Requerimiento::

• Si se implementa un atajo de teclado en contenido, utilizando solo letras (incluidas letras mayúsculas y minúsculas) signos de puntuación, números o símbolos se requiere: (Nivel A, 2.1.4 WCAG 2.1).
• Apagar: Agregar un mecanismo disponible para desactivar el acceso directo. 
• Remapear: Agregar un mecanismo disponible para re-asignar el atajo para usar uno o más caracteres del teclado (por ejemplo: Cltr, Alt, etc). 
• Solo este activo cuando tenga el foco

Los atajos de teclas de caracteres funcionan bien para muchos usuarios de teclado, pero son inapropiados y frustrantes para los usuarios de entrada de voz, cuyos medios de entrada son cadenas de caracteres y para usuarios de teclado son propensos a tocar accidentalmente las teclas.  Como resultado los usuarios deben poder desactivar o re-configuar accesos directos por una tecla de carácter, o dos o más teclas de caracteres sucesivas. 

Este criterio de éxito se está volviendo cada vez más importante en el ámbito móvil ya que cada vez más aplicaciones habilitan controles del teclado.

Beneficios: 

• Los usuarios de voz podrán desactivar los accesos directos de una sola tecla para evitar el disparo accidental.  Esto permitirá a los usuarios de voz hacer un uso completo de los programas que ofrecen accesos directos de una sola tecla a los usuarios de teclado.
• Los usuarios que utilizan únicamente el teclado, que tienen desafíos de destreza también pueden ser propensos a golpear accidentalmente las teclas. Esos usuarios podrían evitar accesos directos problemáticos de un solo carácter al desactivarlos o modificarlos para incluir al menos una clave que no sea de carácter. 

Técnicas suficientes:  que se incluyen son que los usuarios tengan una forma de desactivar los tajos de teclado de un solo carácter; o que exista un mecanismo que permite a los usuarios modificar los atajos de tecaldo y re-asignarlos a caracteres no imprimibles. 

Escenario: tiempos de espera: mul

R 2.2.6 Requerimiento: 

• Se advierte a los usuarios de la duración de cualquier inactividad del usuario que pueda causar la pérdida de datos, a menos que los datos se conserven durante más de 20 horas cuando el usuario no realice ninguna acción. (Nivel AAA, 2.2.6 WCAG 2.1). 

El objetivo es garantizar que cuando se utiliza un tiempo de espera los usuarios sepan que por duración de inactividad se perderán datos. El uso de eventos temporizados puede presentar barreras significativas para los usuarios con discapacidades cognitivas ya que estos usuarios pueden necesitar más tiempo para leer contenido o realizar funciones como completar un fomurlario en línea. 

Beneficios: 

 Este Criterio de Éxito ayuda a los usuarios al garantizar que se les notifique sobre los tiempos de espera relacionados con la inactividad. 

Cuando un usuario sabe cuánto tiempo tiene permitido para una tarea, sabrá si puede tomar un descanso necesario y reanudar su trabajo sin necesidad de volver a comenzar. Esto permite a muchos usuarios completar tareas en línea que de otro modo no podrían realizarlas. 

 Si existe una situación en la que es necesario un tiempo de espera, se advierte al usuario al inicio de la tarea sobre la duración de la inactividad que generaría un tiempo de espera excedido. El usuario puede decidir si puede o no administrar esta tarea en el tiempo dado, o si necesita preparar materiales antes de comenzar un proceso. Esto reducirá la frustración de perder trabajo debido a un tiempo de espera. 

Este Criterio de Conformidad ayuda a personas con muchas discapacidades cognitivas como son: 

• discapacidades relacionadas con el lenguaje;
• discapacidades relacionadas con la memoria; 
• discapacidades relacionadas con el enfoque y la atención ; y 
• discapacidades que afectan la función ejecutiva y la toma de decisiones. 

Técnicas suficientes: 

• Establecer un tiempo de espera de sesión que se produce después de al menos 20 horas de inactividad . 
• Almacenar datos de usuario por más de 20 horas. 
• Proporcione una advertencia de la duración de la inactividad del usuario al comienzo de un proceso. 

Escenario: Animación de interacciones

R 2.3.3 Requerimiento: 

• La animación de movimiento desencadena por la interacción puede desactivarse, a menos que la animación sea esencial para la funcionalidad o la información que se transmite (Nivel AAA, 2.3.3 WCAG 2.1) .

El objetivo es permitir que los usuarios eviten que la animación se muestre cuando se scrolle la página, ya que algunos usuarios experimentan distracción o náuseas por el contenido animado. 

• Gx: permite a los usuarios establecer una preferencia que impide animación. 
• CSS: la consulta de medios CSS del usuario reduce el movimiento para evitar la animación para las personas que la configuran. 

Escenario: Gestos de Punteo

R 2.5.1 Requerimiento: 

• Facilitar el uso de las funcionalidades a través de varias modalidades de introducción de datos más allá del teclado. Esta pauta agrupa los nuevos criterios sobre la interacción táctil por puntero, por voz u otras que puedan surgir en el futuro. (Nivel A, 2.5.1 WCAG 2.1). 

Este criterio se relaciona con las pantallas táctiles y cómo se opera con ellas.

La intención de este criterio es garantizar que el contenido pueda ser operado utilizando entradas simples en una amplia gama de dispositivos señaladores. Esto es importante para los usuarios que no pueden realizar gestos complejos, como los gestos multipunto o basados en rutas. 

Algunos ejemplos de gestos basados en ruta incluyen deslizar, arrastrar o dibujar una ruta compleja. Dichos caminos se pueden dibujar con un dedo o un lápiz óptico en una pantalla táctil, en una tableta gráfica o en un panel táctil o con un mouse, joystick o dispositivo de puntero similar. Un usuario puede encontar difícil o imposible lograr esto si tiene un control motor fino deteriorado, o si usa un dispositivo de puntero similar. Un usuario puede encontrar difícil o imposible lograr esto si tiene un control motor fino deteriorado, o si usa un dispositivo de entrada especializado o adaptado tal como un puntero de cabeza, sistema de mirada fija o emulación de mouse controlada por voz. 

Los ejemplos de gestos multipunto incluyen un zoom de dos dedos con pellizco, un grifo dividido donde un dedo descansa sobre la pantalla y un segundo toque con el dedo, o un toque con el dedo, o un toque de dos o tres dedos o deslizar. A un usuario puede resultarle difícil o imposible de lograr si escribe y señala con un solo dedo o un palo, además de cualquiera de las causas enumeradas anteriormente. 

Los autores deben asegurarse de que su contenido pueda ser operado sin tales gestos complejos. Cuando implementan gestos multipunto o basados en rutas, deben asegurarse de que la funcionalidad también se pueda operar a través de la activación de un solo punto. Los ejemplos de activación de un solo punto en una pantalla táctil o touchpad incluyen toques, doble toque y pulsaciones largas. Los ejemplos de mouse, trackpad, head-puntero o dispositivo similar incluyen clics individuales, click-and-hold y doble clic. 

Beneficios: 

• Los usuarios que no pueden (con precisión) realizar gestos de puntero complejos trandrán medios alternativos para operar el contenido. 
• La disponibilidad de los elementos de la interfaz de usuario proporcionados como respaldo para los gestos complejos ayuda a los usuarios que a menudo pueden desconocer el soporte para los gestos de punteros complejos. Esto puede ser beneficioso especialmente para usuarios con discapacidades cognitivas o de aprendizaje. 

Técnicas suficientes: 

• No confíes en gestos basados en ruta. 
• No confíes en los gestos multipunto. 
• Proporciona controles que no requieren gestos complejos y realizan la misma función que los gestos complejos. 
• Activación de un solo punto para el posicionamiento espacial y la manipulación. 

Escenario: Cancelación de Punteo 

R 2.5.2 Requerimiento: 

• Indica que para la funcionalidad que se puede operar con un "simple pointer", debe haber al menos una de las siguientes afirmaciones verdaderas: (Nivel A, 2.5.2 WCAG 2.1). 
• No Down-Event: el down-event del puntero no se usa para ejecutar ninguna parte de la función. 
• Abort or Undo: la finalización de la función está en el up-event y hay un mecanismo disponible para aborat la función antes de completarse o deshacer la función una vez completada. 
• Up Reversal: el up-event invierte cualquier resultado del down-event anterior. 
• Essential: completar la función en el down-event es esencial.

Up-event sería el "mouseup" o, en una interacción táctil, cuando se levanta el dedo al final del toque. 

Down-event al revés, es el "mousedown" o, en una interacción táctil, cuando se presiona el dedo contra la pantalla. 

El objetivo de este criterio de éxito es facilitar a los usuarios evitar entradas de puntero accidentales o erróneas. Las personas con diversas discapacidades pueden inadvertidamente inicar eventos táctiles o de mouse con resultados no deseados. 

Beneficios: 

• Hace que sea más fácil para todos los usuarios recuperarse de golpear el objetivo equivocado.
• Ayuda a las personas con discapacidades visuales, cognitivas y motoras reduciendo la posibilidad de que un control se active accidentalmente o una acción ocurrir inesperadamente, y también asegura que cuando se activen controles complejos, se encuentre disponible un medio para deshacer o abortar la acción. 
• Las personas que no pueden detectar los cambios de contexto tienen menos probabilidades de desorientarse mientras navegan por un sitio. 

Técnicas suficientes: 

• Activando un control usando up-Event en HTML, iOS y Android
• Los eventos táctiles solo se activan cuando se elimina el tacto de un control 

Escenario: Etiqueta en Nombre

R 2.5.3 Requerimiento: 

• Para los componentes de interfaz de usuario con etiquetas que incluyan texto o imágenes de texto, el nombre accesible contiene el tecto que se presenta visualmente. (Nivel A, 2.5.3 WCAG 2.1). 

El objetivo de este Criterio de Conformidad es ayudara garantizar que las personas con discapacidad que confían en las etiquetas visuales también puedan usar esas etiquetas mediante programación. Los usuarios de texto a voz también tendrán una mejor experiencia si el texto que oyen coincide con el texto que ven en pantalla. 

Imaginemos un botón de imagen en cuya imagen pone "Aceptar" peor que su texto alternativo que es "OK". Cuando el usuario que utiliza voz como medio de entrada dice el nombre del botón, dirá "Aceptar", pero no se activará porque su nombre accesible es "OK",por el contrario, puede estar activando otro botón diferente de la página cuyo nombre accesible si sea "Aceptar" (aunque esta no sea su etiqueta visible). 

Beneficios: 

• Los usuarios de entrada de voz pueden activar controles directamente en una página con menos cambios sorpendentes de enfoque. 
• Los usuarios de texto a voz tendrán una mejor experiencia porque las etiquetas que escuchan coinciden con las etiquetas de texto visibles que ven en la pantalla. 

Técnicas suficientes: Asegurar que las etiquetas visibles coincidan con sus nombres accesibles. Los errores habituales que se listan:

• El nombre accesible no contiene el texto visible de la etiqueta. 
• El nombre accesible contiene el texto de la etiqueta visible, pero las palabras de la etiqueta visible no están en el mismo orden. 
• El nombre accesible contiene el texto de la etiquera visible, pero una o más palabras se entremezclan en la etiqueta. 
• El nombre accesible contiene el texto de la etiqueta visible, pero hay una o más palabras adicionales antese del texto de la etiqueta visible. 

Escenario: Acción de Movimiento

R 2.5.4 Requerimiento: 

• Toda funcionalidad que puede ser operada por el movimineto del dispositivo o por el movimiento del usuario, también puede ser operado mediante los componentes de la interfaz de usuario y la respuesta se puede desactivar para evitar el accionamiento accidental. (Nivel A, 2.5.4 WCAG 2.1)  

Este criterio hace referencia a los sensores del dispositivo que detectan y responden a algún tipo de entrada del entorno físico. Por ejemplo, en un móvil i tablet, un movimiento como agiat el móvil, inclinar la tablet, etc. 

No todos los dispositivos tendrán estos sensores, y aunque así fuera, no todos los usuarios pueden ser capaces de utilizarlos o hacerlo con la suficiente precisión. Por tanto, la funcionalidad deber ser implementada de tal manera que se puede activar por otros medios. Este criterio no se aplica a los sensores de geolocalización, ni a los movimientos que no sean movimientos intencionales del usuario, ni a los asociados al uso del teclado, el puntero o productos de apoyo. 

Las técnicas suficientes que se incluyen son: no usal el evento devicemotion para activar funcionalidades o contenidos; proporcionar formas alternativas de introducir información cuando se usan los sensores de movimiento para activar funcionalidades y contenidos; y que el ususario, pueda desactivar la actuación por movimiento. 

Escenario: Tamaño Objetivo

R 2.5.5 Requerimiento: 

• Definir el tamaño mínimo del "target" (región de la pantalla que acepta la acción del puntero) debe ser 44x44 pixeles para regla de CSS (Nivel AAA, 2.5.5 WCAG 2.1).   

Incluye cietas excepciones: 

• Equivalent: Si el target está disponible a través de un enlace o un contro lequivalente, en la misma página, que tiene al menso 44x44 píxeles de CSS. 
• Inline. Si el target está en una frase o en ubloque de texto. 
• User agent control. Si la apariencia del target es determinada por el agente de usuario no es modificada por el autor. 
• Essential. Si una presentación particualr del target es esencial para la información que se transmite. 

El objetivo de este criterio de éxito es garantizar que los tamaños de destino sean lo suficientemente grandes para que los usuarios los activen fácilmente, incluso el usuario está accediendo al contenido en un pequeño dispositivo portátil de pantalla táctil, tiene destreza limitada o tiene problemas para activar objetivos pequeños por otros motivos. Por ejemplo, los ratones y dispositivos señaladores similares pueden ser difíciles de usar para estos usuarios, y un objetivo más grande les ayudará a activar el objetivo. 

Beneficios: 

Los usuarios que usan un dispositivo móvil donde la pantalla táctil es el modo primario de interacción; 

• Usuarios con impediemntos de movilidad tales coo temblores de manos;
• Los usuarios que usan un dispositivo móvil en entornos donde están expuesetos a temblores, como el transporte público. 
• Usuarios que tienen dificultad con movimientos motorese finos. 
• Usuarios que acceden a un dispositivo usando una mano, 
• Usuarios con dedos grandes, o que están operando el dispositivo con solo una parte de su dedo o nudillo, 
• Los usuarios con baja visión pueden ver mejor el objetivo. 

Técnicas suficientes: 

Seleccione la situación a continuación que coincida con su contenido. Cada situación incluye técnicas o combinaciones de técnicas o combinaciones de técnicas que se conocen y documentan cómo suficentes para esa situación.

• Garantizando que los objetivos tácticles sean al menos 44 por 44 píxeles CSS. 
• Proporcionar un mecanismo para cambiar el tamaño del objetivo independientemente de la ampliación. 

Cómo técnica recomendable, el área interactiva de un párrafo que es un enlace también tiene al menos 44*44px

Escenario: MEcanismo de Entrada Simultáneo: 

R 2.5.6 Requerimimento: 

• El contenido web no restringe el uso de las modalidades de entradas disponibles en una plataforma, excepto cuando las restricción sea esencial y necesesairap ara garantizar la seguridad. (Nivel AAA, 2.5.6 WCAG 2.1). 

La intención de este criterio es garantizar que las personas puedan usar y cambiar entre diferentes modos de entrada cuando interactúan con contenido web. Pueden ser una combinación de mecanismos como un teclado o interfaces similares a un telcado y dispositivos de puntero como un mouse, un lápiz óptico o una pantalla táctil. 

Aunque un dispositivo puede tener un mecanismo de entrada principal, el usuario puede optar por emplear mecanismo de entrada alternativos cuando interactúa con el dispositivio. 

Por ejemplo, el mecanismo principal para télefonos móviles y tabletas es la pantalla táctil. El usuario de estos dispositivos puede optar por utilizar un mouse emparejado o un teclado externo como alternativa al uso de la pantalla táctil. 

Los usuarios deberían poder cambiar los mecanismo de entrada en cualquier momento si el usuario determina que ciertas tarea e interacciones se realizan más fácilmente utilizando un mecanismo de entrada alternativo. El contenido no debe limitar la interacción del usuario a ningún mecanismo de entrada en particular a menos que la restricción sea esencial o que se requeiras para garantizar la seguridad del contendio o respetar la configuración del ususario. 

Nota: una aplicación web de mecanografía, que enseña a los usuario a tocar en un teclado y/o mide su competencia y velocidad, sería un ejemplo de una limitación esencial para un mecanismo de entrada en particular. 

Las técnicas suficientes que se incluyen son: usar solo manejadaores de evento JS de alto nivel, independientemente de la modalidad de entrada (focus,blur,click); o incluir manejadores de evento redundantes para las diferentes modalidades de entrada. 

Escenario: Mensajes de Estado

R 4.1.3 Requerimiento: 

• El contenido implementado mediante lenguaje de marcas, los mensjaes  de estado puede ser determinado por software a través de rolese y propiedades. (Nivel AA, 4.1.3 WCAG 2.1). 

Se debe proporcionar una notificación para cada cambio del contenido de la página. no se trata tanto de que se vean esos mensajes, sino de que sean anunciados por el lector pantalla. 

Esto se hace con el atributo aria-live de ARIA y sus roles específicos.  Estos mensajes serán breves: "Su carrito se ha actualizado con 5 elementos"; "El formulario se ha enviado correctamente"; "Hay tres errores en este formulario", "El contenido se está actualizando, espere unos segundos", etc. 

Este criterio no afecta a informaciones importantes que se presentan en diálogos modales, y que deben ser reconocidos por el ususario de forma inmediata. 

Las técnicas suficientes que se incluyen son: 

• Si el mensaje de estado advierte del éxito o el resutlado de una acción o el estado de una aplicación: se usa role="status", informando de que el dato se ha enviado correctamente. 
• Si el mensjae de estado transmite una sugrencia o una advertencia ante la existencia de un error: se usa role=alert, en combinación con alguna de otras técnicas ya existentes como dar una descripción textual para identificar los campos requeridos no completados, así como los campos con valores o formatos no permitidos; permitir saltar a los errores; dar sugerencias de corrección o proporcionar una revisión otrográfica y sugerencias para la entrada de datos. 
• Si el mensaje de estado transmite información sobre el progreso de un proceso: se usa el role="log", role="progressbar" o role="status"

 

Como técnicas recomendadas están: el uso de otros roles (role="marquee", role="timer"); el uso de aria-live; mover el foco al nuevo contenido usando role="alertdialog" o role="dialog"; y ofrecer al usuario la posibilidad de definir sus preferencias sobre el contenido que se actualiza automáticamente.

Como errores a evitar está el uso de role="alert" o aria-live="assertive" para contenido que no es importante; o usar el evento visibilitychange para ocultar o mostrar un documento sin cambiar las live regions del documento a activas o inactivas.

Los requisitos estructurales heredados de las WCAG 2.0, han llevado, en resumen, las novedades de las WCAG 2.1 son 17 criterios nuevos

• 5 de nivel A;
• 7 de nivel AA;
• 5 de nivel AAA;