Guía de Accesibilidad Web México, D.F. agosto de 2018 Contenido
Web Content Accesibility Guidelines 2.0 6 I. Introducción 6 II. Tecnologías de Asistencia 11 III. Estándares internacionales de accesibilidad 32 1. Principio: Perceptible 32 1.1. Pauta: Alternativas textuales 33 1.1.1. Escenario: Contenido no textual 33 1.2. Pauta: Alternativas al contenido basado en el tiempo 60 Video, audio y multimedia 60 1.2.1. Escenario: Solo audio o solo video pregrabado 60 1.2.2. Escenario: Audio pregrabado en multimedia (Leyendas) 63 1.2.3. Escenario: Video pregrabado en multimedia (Transcripción o audiodescripción) 65 1.2.4. Escenario: Audio en vivo en multimedia (Leyendas) 68 1.2.5. Escenario: Video pregrabado en multimedia (Audiodescripción) 71 1.2.6. Escenario: Audio pregrabado en multimedia (Lengua de señas) 71 1.2.7. Escenario: Video pregrabado en multimedia (Audiodescripción extendida) 71 1.2.8. Escenario: Todo el contenido pregrabado en multimedia y solo video pregrabado (Transcripción) 71 1.2.9. Escenario: Solo audio en vivo (Transcripción) 72 1.3. Pauta: Adaptable 73 1.3.1. Escenario: Información y estructura 73 1.4. Pauta: Distinguible 90 1.4.1. Escenario: Uso de colores 90 1.4.2. Escenario: Audio 94 1.4.3. Escenario: Contraste mínimo 95 1.4.4. Escenario: Tamaño de letra 96 1.4.5. Escenario: Imágenes de texto 96
2
1.4.6. Escenario: Contraste aumentado 98 1.4.7. Escenario: Sin audio de fondo o audio bajo 99 1.4.8. Escenario: Presentación Visual 99 1.4.9. Escenario: Imágenes de texto (sin excepción) 99 2. Principio: Operable 100 2.1. Pauta: Accesibilidad mediante el teclado 100 2.1.1. Escenario: Teclado 100 2.1.2. Escenario: Teclado (Sin excepción) 102 2.2. Pauta: Suficiente tiempo 103 2.2.1. Escenario: Límite de tiempo 103 2.2.2. Escenario: Contenidos en movimiento y/o actualizados automáticamente. 106 2.2.3. Escenario: Sin tiempo 109 2.2.4. Escenario: Interrupciones 109 2.2.5. Escenario: Re-autentificar sesión 110 2.3. Pauta: Evite Convulsiones 110 2.3.1. Escenario: Tres destellos por segundo (flashes) 110 2.4. Pauta: Navegable 112 2.4.1. Escenario: Mapa de sitio 112 2.4.2. Escenario: Título de la página 113 2.4.3. Escenario: Bloques 114 2.4.4. Escenario: Múltiples formas de búsqueda 115 2.4.5. Escenario: Encabezados y etiquetas 116 2.4.6. Escenario: Foco visible 116 2.4.7. Escenario: Ubicación 118 2.4.8. Escenario: Propósito del enlace (solo enlace) 118 2.4.9. Escenario: Secciones de encabezado 119 3. Principio: Comprensible 119 3.1. Pauta: Legibilidad 119 3.1.1. Escenario: Idioma de la página 119 3.1.2. Escenario: Idioma de partes 120 3.1.3. Escenario: Palabras inusuales 121
3
3.1.4. Escenario: Abreviaciones 121 3.1.5. Escenario: Nivel de lectura 121 3.1.6. Escenario: Pronunciación 122 3.2. Pauta: Predecible 122 3.2.1. Escenario: Al recibir el foco 122 3.2.2. Escenario: En entrada de datos 123 3.2.3. Escenario: Navegación Constante 123 3.2.4. Escenario: Identificación Contante 124 3.2.5. Escenario: Cambio a petición 125 3.3. Pauta: Asista en la introducción de datos 126 3.3.1. Escenario: Etiquetas e instrucciones 126 3.3.2. Escenario: Identificación de errores 128 3.3.3. Escenario: Sugerencias de errores 129 3.3.4. Escenario: Prevención de errores (Legal, Finanzas, Datos) 129 3.3.5. Escenario: Ayuda 130 3.3.6. Escenario: Prevención de errores (Todo) 130 4. Principio: Robusto 131 4.1. Pauta: Compatible 131 4.1.1. Escenario: Análisis de sintaxis 131 4.1.2. Escenario: Nombre, rol o valor 132 IV. Herramientas de evaluación automáticas 134 V. Pruebas de evaluación para accesibilidad 155 VI. Administración en organizaciones 158 VII. Bibliografía 160 Web Content Accebility Guidelines (WCAG 2.1) 162 I. Introducción 162 Escenario: Orientación 163 Escenario: Identificar el propósito en entradas de datos 165 Escenario: Identificar el propósito 166 Escenario: Flujo de información 167 Escenario: Contraste no textual 169
4
Escenario: Espaciado de texto 172 Escenario: Contenido en Hover o Focus 173 Escenario: Atajos de teclado Shortcuts de caracteres 175 Escenario: Tiempos de espera 175 Escenario: Animación de interacciones 177 Escenario: Gestos de Punteo 177 Escenario: Cancelación de Punteo 179 Escenario: Etiqueta en Nombre 180 Escenario: Acción de Movimiento 181 Escenario: Tamaño Objetivo 181 Escenario: Mecanismos de Entrada Simultaneo 183 Escenario: Mensajes de Estado 183 II. Contacto 186
5
Dirigido a Diseñadores, desarrolladores, líderes de proyecto / project managers, analistas de negocio, directores de sistemas, responsables de control de calidad y testing, productores o editores de audio / video o cualquier persona interesada en aprender los estándares internacionales de accesibilidad web para crear sitios accesibles a personas con discapacidad y adultos mayores.
Objetivo La enseñanza de los criterios de accesibilidad web, la comprensión básica de las distintas discapacidades y sus tecnologías de asistencia; así como el estatus de la legislación nacional e internacional actual y el conocimiento de herramientas que ayudan al desarrollo y evaluación de páginas web accesibles. Web Content Accesibility Guidelines 2.0 I. Introducción Para la realización de esta guía se tomaron como base las Pautas de Accesibilidad para el Contenido Web en su versión 2.0 (WCAG 2.0) del World Wide Web Consortium (W3C). Dicho documento describe los 3 niveles de accesibilidad A, AA y AAA, siendo el A el nivel básico y el AAA el más avanzado.
Antes de hablar de accesibilidad web, es necesario conocer de manera general las discapacidades:
• Discapacidad Visual: Disminución significativa de la agudeza o campo visual del ojo que afecta la participación en actividades de la vida diaria. Se divide en baja visión (discapacidad visual de moderada a grave) y ceguera. • Discapacidad Auditiva: Pérdida de la percepción auditiva superficial, moderada o profunda (sordera) que afecta la comunicación de las personas. • Discapacidad Motora: Afectación de la habilidad en el control del movimiento, equilibrio y coordinación del cuerpo. • Discapacidades Cognitivas y Neurológicas: Son las que afectan zonas del cerebro encargadas de actividades mentales (la memoria, el aprendizaje o el habla), motoras y sensoriales.
¿Qué es accesibilidad web? Es el grado en el que todos los usuarios incluyendo a los adultos mayores y personas con discapacidad pueden navegar en el sitio web en condiciones de igualdad.
La accesibilidad web se logra cumpliendo los estándares internacionales definidos por el W3C, los cuales se pueden evaluar manualmente o de manera automática con herramientas creadas para determinar su cumplimiento. Si los criterios de accesibilidad se consideran desde el
6
principio del proyecto, será mucho más sencilla su implementación. Si se considera a la mitad o al final, se tendrá que invertir mayor tiempo en realizar cambios a elementos o componentes que probablemente no son accesibles. Hoy en día, herramientas de gestión de contenidos como Word Press, Drupal o Joomla pueden evitar que el diseñador trabaje directamente con el código de la página. Sin embargo, a pesar de los beneficios en tiempo de diseño, mantenimiento y flexibilidad, el diseñador debe contemplar el tema de accesibilidad para realizar los ajustes necesarios, incluso con el uso de estas herramientas, aunque para ello deberá tener conocimientos básicos de programación, HTML, CSS y JavaScript.
¿Qué es usabilidad? Se refiere a la facilidad que tiene el usuario para el acceso a los contenidos o el cumplimiento de objetivos como pueden ser la compra, instalación, búsqueda, descarga, envío, registro, etc.
A diferencia de la accesibilidad web, la usabilidad es más compleja de evaluar ya que el testing (pruebas) del sitio es lo que va a dar la información o retroalimentación sobre la interacción y experiencia del usuario. Dicha experiencia debe ser efectiva, eficiente, fácil y clara. Entre más amigable e intuitivo sea el sitio, se obtendrá mayor satisfacción del usuario. En dicho testing se debe incluir también a usuarios con discapacidad y personas de la tercera edad, lo que nos lleva a la accesibilidad.
La usabilidad (al igual que la accesibilidad) se diseña desde el día uno del proyecto y no es algo que se agregue fácilmente, además de que podría ser costoso un rediseño.
¿Qué significa ser accesible? Es contar con un sitio web que cumpla con los estándares internacionales de accesibilidad para que las personas con discapacidad puedan consultar exitosamente la información de medios electrónicos.
Ser accesible es poner como prioridad la correcta estructura y presentación de la página, dando como resultado el acceso equitativo de la información, independientemente de las capacidades físicas del usuario o tecnología de asistencia que se utilicen.
Beneficios de la accesibilidad web • Mejora la calidad de vida de las personas con discapacidad. o En la educación, en el empleo, en la inclusión social, en su independencia, en la seguridad, etc. • En el sector público o privado: o Mejora la percepción del público en general o Mejora el posicionamiento SEO del sitio web o Mejora la compatibilidad de dispositivos o Aumenta la cartera de clientes
7
o Aumenta la competitividad al tener como ventaja la accesibilidad o Evita quejas o demandas de usuarios con discapacidad • En general, mejora la accesibilidad para TODOS
Legislación internacional La “Convención sobre los Derechos de las Personas con Discapacidad” de la ONU define el acceso a la información y a las tecnologías de la comunicación y de la información, como parte integral del derecho de accesibilidad de las personas al igual que la accesibilidad al ambiente físico y al transporte.
A través de internet los usuarios pueden participar remotamente en un rango de actividades profesionales y de consumo, así como a un número creciente de servicios de gobierno, salud, educación etc. A través de la red se amplían, las oportunidades de participación social como en redes sociales, grupos de interés digitales, video, audio, comunicación a través de texto e interacción multimedia. Para personas con discapacidad estos servicios y contenidos están disponibles a través de aplicaciones de la computadora o de la red como lectores de pantalla, sistemas de reconocimiento de voz, comunicación a través de video, así como asistencia visual.
Europa El 3 de diciembre de 2012, la Comisión Europea liberó una propuesta de accesibilidad de sitios web públicos dirigida a páginas de sectores como servicios municipales, declaraciones de impuestos, servicios para búsqueda de empleos, educación, servicios relacionados con la salud, etc.
En la Agenda Digital para Europa, uno de los puntos estratégicos para el 2020 es la accesibilidad a la red, de tal forma que las páginas que ofrezcan servicios básicos a los ciudadanos fueran totalmente accesibles para el 2015.
En 2007, el Gobierno Danés firmó junto con los gobiernos locales y las regiones un acuerdo para utilizar estándares abiertos para el software del sector público. El acuerdo establece que las autoridades públicas utilicen 7 estándares de WCAG 2.0 al crear sus soluciones de IT.
Por ejemplo, en Grecia, el portal de E-Gobierno para personas con discapacidad incluye aplicaciones como:
• Portal de Servicios de Adultos Mayores donde se puede obtener información de otros cuerpos administrativos. • Servicios de búsqueda de empleo. • Librerías digitales.
8
En España, se publicó en 2004 la Norma UNE 139803 sobre aplicaciones informáticas para personas con discapacidad, requisitos de accesibilidad para contenidos Web basada en las Directrices de Accesibilidad de los Contenidos web de WAI (WCAG) en su versión 1.0.
En Italia existe una directiva para que cualquier ciudadano pueda reportar sitios de gobierno que no sean accesibles. Y cada país de Europa cuenta con legislación a nivel nacional para que los sitios web sean accesibles.
América En Estados Unidos, existen tres leyes importantes relacionadas con la accesibilidad y la no discriminación:
• Americans with Disabilities Act (ADA), que prohibe la discriminación. • “Section 508” (Rehabilitation Act), que obliga a organismos federales que conviertan toda la información electrónica accesible. Así como también, exige la compra de productos y servicios accesibles (lo cual tiene un impacto a proceedores de gobierno en el sector privado). • 21st Century Communications and Video Accessibility Act (CVAA), que solicita (entre otros temas) que los programas de televisión ofrezcan captions (leyendas). • Air Carrier Access Act (ACAA), que (entre otros temas) exige a las aerolíneas nacionales e internacionales (que vuelan y venden en Estados Unidos) a que sus sitios web sean accesibles. Por ejemplo, compras en línea, consulta de intinerarios, etc.
En Canadá, el gobierno de Ontario introdujo en los 2010 cinco estándares de accesibilidad enfocados a lograr niveles substancialmente mayores de accesibilidad. De igual forma elaboró un estudio para medir el impacto de accesibilidad a nivel individual, en los mercados y en unidades sociales. El estudio concluyó que existen claras oportunidades de mejora en los tres niveles al incluir a un mayor número de ciudadanos a participar en la economía de la provincia. La ganancia más significativa es a nivel laboral y educativo. La inclusión a la fuerza laboral de personas con discapacidad no solamente ayuda al incremento del ingreso familiar, sino que además contribuye al crecimiento del PIB per cápita en Ontario.
En México, la Reforma de “LEY FEDERAL DE TELECOMUNICACIONES Y RADIODIFUSIÓN” (publicada el 14 julio 2014) incluye un capítulo sobre los derechos de las personas con discapacidad. En ese capítulo se reconocen los derechos de los usuarios con discapacidad a tener acceso a los servicios de telecomunicaciones en igualdad de condiciones con los demás usuarios. También obliga a los portales de internet de las dependencias de la administración pública, tanto federal como estatal a contar con sitios accesibles.
Título Noveno - Capítulo II De los Derechos de los Usuarios con Discapacidad (Art. 199 a 203)
9
• Art. 199 El Ejecutivo Federal y el Instituto promoverán que las personas con discapacidad tengan acceso a los servicios de telecomunicaciones en igualdad de condiciones • Art. 201 Sitios web accesibles de: • Dependencias de la Administración Pública Federal • Organismos públicos descentralizados • Empresas de participación estatal • Del Congreso de la Unión • Del Poder Judicial de la Federación • De los órganos constitucionales autónomos • Dependencias de la Administración Pública • De los poderes legislativo y judicial de las entidades federativas • Del Distrito Federal
También existe un ACUERDO - Disposiciones generales de accesibilidad web que deben observar las dependencias y entidades de la Administración Pública Federal y las empresas productivas del Estado (publicado el 3 de diciembre 2015).
Que establece los principios y criterios técnicos en materia de accesibilidad Web y contenido digital. Define que corresponde a la Secretaría de la Función Pública, por conducto de la Unidad de Gobierno Digital de la Secretaría, la supervisión y evaluación de la implementación de sitios web accesibles.
Las Instituciones deberán considerar la Accesibilidad Web en los aplicativos tecnológicos para sus sitios de Internet y en sus contenidos digitales de acuerdo a WCAG 2.0 AA y los sitios deberán tener una Declaración de Accesibilidad.
Nota: dicho acuerdo define el contenido digital como todo aquel recurso digital en sus diferentes formatos: fotografía, video, texto, audio o cualquier otro en formato digital que pueda ponerse a disposición del público a través de Internet.
También existe otro ACUERDO - Los lineamientos generales para las campañas de comunicación social de las dependencias y entidades de la Administración Pública Federal para el ejercicio fiscal 2016 (publicado el 30 de diciembre 2015).
• CAPÍTULO XII - MEDIOS DIGITALES • Art. 60 Las Dependencias y Entidades deben incluir medios digitales en sus Programas anuales de comunicación social, promoción y publicidad, de acuerdo con los criterios de la Coordinación de Estrategia Digital Nacional. • Deben verificar que los medios digitales a contratar cuenten con (entre otros temas), plataformas digitales accesibles para personas con discapacidad y con formatos responsivos para los distintos dispositivos de consulta.
10
Por último, los LINEAMIENTOS GENERALES DE ACCESIBILIDAD A LOS SERVICIOS DE TELECOMUNICACIONES PARA USUARIOS CON DISCAPACIDAD (aún no publicados en el Diario Oficial de la Federación). Que indican (en resumen) lo siguiente:
Art. 1 Promover en el ámbito de competencia del IFT que los usuarios con discapacidad tengan acceso a los servicios de telecomunicaciones (dichos lineamientos son de observancia obligatoria para los concesionarios y autorizados). Art. 5 Ofrecer medios de comunicación para quejas por discriminación a personas con discapacidad Art. 6 Ofrecer planes y paquetes diseñados para personas con discapacidad Art. 7, 8, 9, 10 Ofrecer contratos, promociones, facturas, etc. publicados en internet (en formato accesible) Art. 11 Lo anterior también disponible en sus centros de atención al público (en formato accesible, por ejemplo: en sistema Braille) Art. 12 El IFT realizará verificaciones Art. 15, 16 Contar con catálogo de equipos de telefonía fija y móvil con funcionalidades de accesibilidad Art. 22 Ofrecer accesibilidad física en centros de atención al público Art. 29 Contar con personal capacitado para atender a personas con discapacidad Art. 34 Contar con portales de internet accesibles (WCAG 2.0 AA) Art. 38 Ofrecer que personas con discapacidad puedan realizar trámites: contratación, cambios de domicilio, titularidad y/o modalidad, cancelaciones, aclaraciones de forma remota (vía telefónica o por internet). II. 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
11
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. a) Dispositivos de entrada
i. 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]. Recuperado de 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.
12
BJADAPTACIONES (2014). Teclado Simplyworks [fotografía]. Recuperado de 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]. Recuperado de 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]. Recuperado de https://tecnoaccesible.net/content/bluetype
ii. 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.
13
iii. 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.
iv. 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]. Recuperado de 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.
14
BJADAPTACIONES (2014). BJOY Button [fotografía]. Recuperado de 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]. Recuperado de 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.
15
BJADAPTACIONES (2014). Cobertor para trackball de bola gigante [fotografía]. Recuperado de 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]. Recuperado de 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]. Recuperado de 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:
16
Mouse basado en un joystick con botones grandes y accesibles.
BJADAPTACIONES (2014). BJOY Stick-C [fotografía]. Recuperado de 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]. Recuperado de 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.
17
AbleNet, Inc. (2014). Universal Mounting System [fotografía]. Recuperado de 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]. Recuperado de 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]. Recuperado de https://bjadaptaciones.com/acceso-a-dispositivos-ios-apple/33-blue2-bluetooth- switch.html?search_query=blue2&results=1
18
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]. Recuperado de http://www.broadenedhorizons.com/sip-n-puff-usb-neck-headset-switches
b) 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.
i. 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.
19
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]. Recuperado de http://www.harriscomm.com/index.php/sonic-connect2-message-alert-audible-alarm.html
ii. 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.
20
iii. 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.
iv. 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]. Recuperado de 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
21
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]. Recuperado de http://www.rdgkompagne.nl/producten/Communicatiehulpmiddelen/Tekstsystemen/Allora-2
v. 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).
22
• 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 Word Perfect, 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.
23
• 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.
VoiceOver: 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.
24
• 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.
25
Tiflo-Tecnológica. (2014). Máquina parlante portátil de lectura de textos EYE PAL OCR [fotografía]. Recuperado de http://www.tecno-ayudas.com.ar/novedades.html
vii. 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.
viii. 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]. Recuperado de 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
26
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.
27
(2016) Teclados Braille de diferentes tamaños.
28
(2016) Tablet de Google configurada con dos switches que simulan la tecla de tabulador y enter.
29
(2016) Teléfnos 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.
30
(2016) Impresoras Braille.
(2016) Phoenix Embosser, impresora de gráficos táctiles y PIAF Tactile Image Maker, que resalta contornos en color negro.
31
III. 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.
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 en 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. 1. Principio: Perceptible La información del contenido web debe estar disponible para los sentidos (vista, audición o tacto), ajustándose a distintas discapacidades.
32
1.1. 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.
33
Da clic en el color de tu preferencia:
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:
34
Para mapas de imagen (imagen donde se puede dar clic en algún á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.
Da clic en el curso que desees:
35
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.
Blog Bienvenidos a mi blog personal....
Bienvenidos a mi blog personal....
O ejemplo de bullets decorativas con alt vacío:
36
Sitios para comprar online:
Aún mejor, cuando las imágenes son decorativas se recomienda incluirlas en hoja de estilo:
| Bienvenidos a nuestro portal |
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.
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;).
38
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.
Siguenos en Twitter de Hearcolors
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.
39
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:
Si quiere desaparecer el elemento por completo en interfaz, pero seguir siendo accesible para lectores de pantalla, puede utilizar (position: absolute; left: -9999px;):
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;
40
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:
Más información sobre nuestros productos.
Leer un artículo fascinante sobre los microbios residentes en el cuerpo humano
41
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 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:
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. tml>
Descripción textual de la gráfica
42
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.
43
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:
44
• 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.
Nota: evite esconder la etiqueta de la interfaz de usuario.
45
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
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.
46
48
Combobox
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.
49
50
Archivos adjuntos
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
51
• Ejemplo y características de aria-label o Invisible en interfaz o Remplaza el texto original del elemento o No hace el texto cliqueable
Ejemplo de múltiples campos relacionados con solo un solo label:
-
Como se puede observar, se respeta la forma tradicional de relacionar una etiqueta (por lo que el texto sigue siendo cliqueable) 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 o Se relaciona el id de otro elemento o Se pueden relacionar múltiples id’s de elementos o El o los textos relacionados (normalmente) están visibles en la página o Remplaza 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:
52
| Tipo de entrada | Individual | Pareja |
|---|---|---|
| Compra en efectivo | ||
| Compra con TC |
• Ejemplo y características de aria-describedby o Se relaciona el id de otro elemento o Proporciona información adicional a la del elemento
Ejemplo de instrucciones para contraseña con aria-describedby
53
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.
54
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:
Si el botón es una imagen, recuerde agregar su texto alternativo:
En el caso de html5, el texto del tag button, es lo que reconocerá la tecnología de asistencia:
55
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.
56
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:
57
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, este debe ofrecerse.
Ejemplo de frame:
58
Ejemplo de iframe:
59
1.2. 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).
1.2.1. Escenario: Solo audio o solo video pregrabado
R 1.9 Requerimiento: › Se ofrecerá una transcripción para el solo audio y para el solo 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 .
60
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 cuenta con una colección de videos con transcripción: http://www.washington.edu/doit/videos/index.php?vid=60
61
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:
62
Es muy importante siempre tomar en cuenta la creación de videos accesibles, con lo que se tendrá un mayor alcance. Adicionalmente, en este ejemplo se tiene la opción de verlo en YouTube.
1.2.2. Escenario: Audio pregrabado en multimedia (Leyendas)
R 1.11 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 solo 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:
63
• 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.co m&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
64
1.2.3. Escenario: Video pregrabado en multimedia (Transcripción o audiodescripción)
R 1.12 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 guion 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/
65
https://www.youtube.com/watch?v=O7j4_aP8dWA
https://www.youtube.com/watch?v=B8BD9txkGL4
66
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 siguientes ligas 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 video que ofrecen las audiodescripciones opcionales para el usuario, es decir se pueden activar o desactivar. Por ejemplo (observe el ícono “AD”):
AccesibilityOz http://www.accessibilityoz.com/ozplayer/#ozp-demo
Kaltura (en su versión accesible “Section 508”) http://corp.kaltura.com/Products/Features/Video-Player
67
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.
1.2.4. Escenario: Audio en vivo en multimedia (Leyendas)
R 1.13 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.
68
69
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:
70
http://www.3playmedia.com/how-it-works/webinars/html5-08-27- 2015/?mkt_tok=3RkMMJWWfF9wsRoiv6jMZKXonjHpfsX57ugkUaK2lMI%2F0ER3fOvrPUfGjI 4CTctjI%2BSLDwEYGJlv6SgFTbTBMbVk1bgLUhY%3D
1.2.5. Escenario: Video pregrabado en multimedia (Audiodescripción)
R 1.14 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.
1.2.6. Escenario: Audio pregrabado en multimedia (Lengua de señas)
R 1.15 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)
1.2.7. Escenario: Video pregrabado en multimedia (Audiodescripción extendida)
R 1.16 Requerimiento: › Cuando las pausas no sean suficientes para permitir que la audiodescripción transmita el contenido del video, se debe proporcionar audiodescripción extendida para el video pregrabado en multimedia sincronizado. (Nivel AAA, 1.2.7 WCAG 2.0)
1.2.8. Escenario: Todo el contenido pregrabado en multimedia y solo video pregrabado (Transcripción)
R 1.17 Requerimiento:
71
› 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)
1.2.9. Escenario: Solo audio en vivo (Transcripción)
R 1.18 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: Pausar, 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 accesibilidad con teclado, sino para cargar del 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 poster) • .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.
72
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 puebas en la siguiente liga: http://www.hearcolors.com.mx/Ejemplos_Guia/iframe.html
1.3. 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 una computadora (CAPTCHA1), 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
1Completely Automated Public Turing test to tell Computers and Humans Apart
73
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 tercera edad que pueden fallar en la interpretación y personas con problemas de visión o ciegos 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&t ype=signup&fromhttp=1), solo imagen.
Existen también otros CAPTCHA que, a pesar de su originalidad, no son accesibles. Por ejemplo: CAPTCHAS de arrastrar y soltar o CAPTCHAS de deslizamiento.
74
Para hacer un CAPTCHA accesible, la alternativa más común a la imagen es el audio, que permite escuchar la prueba. Cando 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 liga 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/).
75
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 casos 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.
76
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
77
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 discapacidades 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.
78
79
Para apoyar a la estructura se ofrecen las siguientes recomendaciones:
80
Utilizar 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.
Por ejemplo, una página web con estructura simple, podría estructurarse de la siguiente manera:
81
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 del encabezado (nivel 1, nivel 2, etc.), por lo 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
Encabezado h1: Lo más importante
Encabezado h2
Encabezado h3
Encabezado h4
Encabezado h5
Encabezado h6: Lo menos importante
El uso de listas también ayuda a dar estructura.
82
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.
Lista de Reptiles
- Serpientes
- Boa
- Cascabel
- Mamba
- Iguanas
- Tortugas
Usar ol con li para listas con orden.
83
Días de la semana
- Lunes
- Martes
- Miércoles
- Jueves
- Viernes
- Sábado
- Domingo
Usar dl para listas con descripciones, utilizando dt para definir nombres y dd para definir su descripción.
84
- Café
- Bebida que se obtiene a partir de las semillas tostadas y molidas
- Té
- Infusión de hojas y brotes de la planta
También es importante que los elementos de la página sean consistentes, de tal manera que permanezcan fácil 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 brinda 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 solo 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 el o los encabezados antes de proporcionar la información de cada celda relacionada. Nota: de preferencia, siempre mantenga la tabla lo más simple posible.
85
Para tablas sencillas y sin celdas combinadas se puede utilizar scope para relacionar encabezados con celdas de datos. Ejemplo:
| Curso | Horario | Salón |
|---|---|---|
| CSS | 07 horas | A |
| HTML | 09 horas | B |
| JAVA | 13 horas | C |
| Dreamweaver | 15 horas | D |
86
En el siguiente ejemplo, debido a que la tabla tiene celdas combinadas y diferentes niveles de encabezados la solución para volverla accesible es hacer la relación de encabezados 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.
| Tarea | Examen | Proyecto | ||||
|---|---|---|---|---|---|---|
| Primer Parcial | Segundo Parcial | Final | Primer Parcial | Segundo Parcial | Final | |
| 15% | 15% | 15% | 20% | 10% | 10% | 15% |
87
Este método puede implicar bastante inversión 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.
Esta tabla muestra los resultados de la encuesta sobre niveles de vida en el mundo...
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) mencionaran 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 de 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 que campos están agrupados.
88
89
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.
1.4. Pauta: Distinguible Facilita a los usuarios ver y escuchar el contenido, separando entre primer plano y fondo.
1.4.1. 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 limitados o monocromáticos pueden beneficiarse de las alternativas adicionales al color. Nota: No se pretende desalentar el uso del color en una página web, sino complementar con otras alternativas de distinción.
R 1.23 Requerimiento: › No use el color como el ú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:
90
× 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 del texto (negrita, cursiva, contorno del texto, etc.).
Nota: Las tecnologías de asistencia reconocen el estado de los elementos desactivados en los formularios (por lo que son ignorados). En interfaz ayuda el hecho de no recibir el foco y mostrarse en color gris.
91
Otro ejemplo, es una gráfica de pastel que no debe depender del color para transmitir información, ya que usuarios con alguna discapacidad visual como ceguera de color no podrán 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 que sección pertenece a determinado producto.
92
• Gráfica accesible
R 1.24 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 enlace, 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:
93
Nota: Recuerde también la importancia del alto contraste entre texto y fondo. 1.4.2. Escenario: Audio R 1.25 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)
94
Nota: Se requiere un ajuste de volumen independiente 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.
1.4.3. 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.
R 1.26 Requerimiento: › Contraste mínimo 4.5:1 para la presentación visual de texto e imágenes de texto excepto:
95
o Los textos de gran tamaño e imágenes de gran tamaño (estos requieren un contraste mínimo de 3:1) o 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). o Texto que es parte de un logo o nombre de marca (no tiene requerimiento de contraste). (Nivel AA, 1.4.3 WCAG 2.0)
1.4.4. Escenario: Tamaño de letra
R 1.27 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. Consideremos 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 o %).
1.4.5. Escenario: Imágenes de texto
R 1.28 Requerimiento:
96
› Si con las tecnologías 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 Accesibility for Designers”: http://throup.org.uk/infographic/
97
1.4.6. Escenario: Contraste aumentado
R 1.29 Requerimiento: › Contraste mínimo 7:1 para la presentación visual de texto e imágenes de texto excepto: o Los textos de gran tamaño e imágenes de gran tamaño (estos requieren un contraste mínimo de 4.5:1) o 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
98
de una imagen cuyo contenido significativo es otro contenido (no tienen requerimiento de contraste) o Texto que es parte de un logo o nombre de marca (no tiene requerimiento de contraste) (Nivel AAA, 1.4.6 WCAG 2.0)
1.4.7. Escenario: Sin audio de fondo o audio bajo
R 1.30 Requerimiento: › Para el audio pregrabado que contenga principalmente una locución, que no sea un CAPTCHA y que no sea una vocalización cuya interpretación es principalmente una expresión musical (como canto o rap) se debe cumplir alguno de los siguientes casos: o El audio no debe contener sonidos de fondo o El sonido de fondo se puede apagar o El sonido de fondo debe de ser cuatro veces más tenue (bajo) que la locución principal (Nivel AAA, 1.4.7 WCAG 2.0)
1.4.8. Escenario: Presentación Visual
R 1.31 Requerimiento: › Para las presentaciones visuales de bloques de texto, se debe proporcionar un mecanismo para cumplir lo siguiente: o El usuario puede seleccionar los colores de primer plano y fondo o El ancho de la línea no puede ser mayor a los 80 caracteres o El texto no debe estar justificado o 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 o El texto puede aumentarse hasta un 200% sin que el usuario se tenga que desplazarse en una barra de scroll para leer la línea (Nivel AAA, 1.4.8 WCAG 2.0)
1.4.9. Escenario: Imágenes de texto (sin excepción)
R 1.32 Requerimiento:
99
› 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 esencial para la información (por ejemplo: logos). (Nivel AAA, 1.4.9 WCAG 2.0)
2. Principio: Operable Los elementos de la interfaz deben facilitar la interacción y operabilidad.
2.1. Pauta: Accesibilidad mediante el teclado Permitir la navegabilidad web con el teclado.
2.1.1. Escenario: Teclado
R 2.33 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)
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 se 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.
100
http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/FLASH17.html
Nota: No se pretende desalentar o prohibir las configuraciones destinadas al uso del mouse, sino complementarlas con la navegación de teclado. 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 requiere también la visualización del foco. Aunque ambas son se 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: absoulte, position: relative, float: left, float: rigth). 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 se 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 en 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 tabulación default con base en su ubicación en el código fuente. Si está readaptando un elemento como , , 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 101 números positivos para evitar comportamientos inesperados que pueden confundir al usuario o complicar la navegación. R 2.34 Recomendación: › Los accesskeys del sitio deberían evitarse. Los accesskeys (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 Mnemonics 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. 2.1.2. Escenario: Teclado (Sin excepción) R 2.35 Requerimiento: › Todas las funcionalidades del sitio deben ser operables con teclado sin límite de tiempo para pulsar las teclas. 102 2.2. Pauta: Suficiente tiempo Ofrezca a los usuarios suficiente tiempo para leer y usar el contenido. 2.2.1. 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 apagar, ajustar o extender. Para casos de tiempo real y absolutamente necesario, se deberá informar al usuario sobre el 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 expirar 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 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. 103 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 realiza 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. 104 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 opció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 del usuario. Por otro lado, en este ejemplo si el tiempo expira y el usuario no pudo completar la actividad, puede volver a intentarlo. 105 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 edad serán beneficiadas al poder prevenir y considerar el límite de tiempo; aunque habrá casos de discapacidad grave en los que se necesitará la ayuda de un tercero. 2.2.2. 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 otras partes 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 el 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 segundos: • 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. 106 Nota: El contenido que es pausado puede reanudarse (en casos de tiempo real) o continuar en 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 con 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 enlaces 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 107 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 en el 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 incidentes en tiempo real. Como se puede observar en la imagen, la actualización automática se puede parar. R 2.40 Requerimiento: 108 › 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 confunden o 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 original diseño, el sitio se vuelve poco accesible y comprensible. 2.2.3. Escenario: Sin tiempo R 2.41 Requerimiento: › El tiempo no debe ser 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) 2.2.4. Escenario: Interrupciones R 2.42 Requerimiento: › El usuario debe poder posponer o eliminar las interrupciones. 109 Excepto interrupciones relacionadas con una emergencia. (Nivel AAA, 2.2.4 WCAG 2.0) 2.2.5. Escenario: Re-autentificar sesión R 2.43 Requerimiento: › Cuando la sesión autentificada expira, el usuario debe poder 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) 2.3. Pauta: Evite Convulsiones No diseñe contenidos que puedan provocar ataques o convulsiones. 2.3.1. Escenario: Tres destellos por segundo (flashes) R 2.44 Requerimiento: › No deberá crear contenidos que destellen (con alto contraste 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 que fue censurado por mandar al hospital a casi 700 personas por causar mareos, vómitos y ataques epilépticos. 110 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 Dawn) contiene una escena con flashes rojos que causo 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 causar ataques, especialmente aquellos contenidos dinámicos con flashes y transiciones rápidas entre fondos luminosos y obscuros: http://trace.wisc.edu/peat/ 111 R 2.45 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) 2.4. 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. 2.4.1. Escenario: Mapa de sitio R 2.46 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 se 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 enlaces principales del sitio en 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 112 Ejemplo, el mapa de sitio del Instituto Federal de Telecomunicaciones: http://www.ift.org.mx/sitemap 2.4.2. Escenario: Título de la página R 2.47 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 la página ( 113 Cuando el usuario da clic en el nombre de la receta específica, el sitio lo lleva a una página con la receta y su correcto título ( Si el desarrollador desea poner en todos los títulos de la página el 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 2.4.3. Escenario: Bloques R 2.48 Requerimiento: › En caso de contenidos repetitivos en múltiples páginas, se requiere un mecanismo disponible para omitir bloques. (Nivel A, 2.4.1 WCAG 2.0) 114 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.hearcolors.com.mx/EjemplosAccesiblesHC/Salto_Bloques/SaltoBloques.html 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. 2.4.4. Escenario: Múltiples formas de búsqueda R 2.49 Requerimiento: › Múltiples formas o más de una manera disponible para encontrar una página web en un 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 se 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. 115 2.4.5. Escenario: Encabezados y etiquetas R 2.50 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: 2.4.6. Escenario: Foco visible R 2.51 Requerimiento: 116 › 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 menciona anteriormente, la navegación con teclado de todo el sitio es requerimiento 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 suficiente 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 usuarios 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 la columna derecha y finalmente la columna central. Adicionalmente el sitio resalta la ubicación del foco con un diseño de color azul. 117 2.4.7. Escenario: Ubicación R 2.52 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) 2.4.8. Escenario: Propósito del enlace (solo enlace) R 2.53 Requerimiento: › Se debe ofrecer un mecanismo que permita identificar el propósito de cada enlace con el uso exclusivo del texto 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) 118 2.4.9. Escenario: Secciones de encabezado R 2.54 Requerimiento: › Se deben emplear encabezados (títulos) de sección para organizar el contenido. Nota: Este requerimiento aplica cuando el sitio este 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) 3. Principio: Comprensible La información y la operación de la interfaz deben entenderse fácilmente. 3.1. Pauta: Legibilidad Cree contenidos legibles y fáciles de entender. 3.1.1. Escenario: Idioma de la página R 3.55 Requerimiento: › Los idiomas de la página deberán estar identificados utilizando el atributo 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: para español. Si una página tiene la misma versión en otro idioma, éste 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 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 un nivel de accesibilidad más 119 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: . R 3.56 Recomendación: › Para sitios multiidioma, 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/. 3.1.2. Escenario: Idioma de partes R 3.57 Requerimiento: › Diferenciar el idioma de cada pasaje o frase. (Nivel AA, 3.1.2 WCAG 2.0) Excepto para nombre 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. Por ejemplo: 120 Nota: el atributo hreflang sirve para definir el idioma del destino de un enlace. 3.1.3. Escenario: Palabras inusuales R 3.58 Requerimiento: › Se debe ofrecer un mecanismo para identificar definiciones específicas de palabras o frases empleadas de una manera inusual o restringida, incluyendo modismos o jerga. Por ejemplo: agregar un glosario al sitio (con el enlace 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 cual definición aplicar para entender adecuadamente el contenido. La definición apropiada puede determinarse de acuerdo al contexto. Nota 2: modismo se refiere a frase cuyo significado no puede deducirse de las palabras que lo componen. Nota 3: juerga se refiere a palabras que se emplean de una manera determinada por las personas que pertenecen a un determinado grupo, profesión u oficio. (Nivel AAA, 3.1.3 WCAG 2.0) 3.1.4. Escenario: Abreviaciones R 3.59 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) 3.1.5. Escenario: Nivel de lectura R 3.60 Requerimiento: › Cuando se requiera una habilidad de lectura más avanzada que la que proporciona el nivel de educación secundaria (eliminando nombres 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) 121 3.1.6. Escenario: Pronunciación R 3.61 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) 3.2. 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. 3.2.1. Escenario: Al recibir el foco R 3.62 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 de 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. 122 3.2.2. Escenario: En entrada de datos R 3.67 Requerimiento: › 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 usuarios 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 que 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. 3.2.3. Escenario: Navegación Constante R 3.68 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. 123 Incluso, si en alguna página falta el campo de búsqueda, los otros componentes se muestran en el mismo orden. 3.2.4. Escenario: Identificación Contante R 3.69 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 2”, 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. Estructura que debe permanecer en cualquier enlace que lleve a documentos en otro formato. 124 3.2.5. Escenario: Cambio a petición 125 R 3.70 Requerimiento: › Los cambios de contexto deben iniciarse solo 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) 3.3. Pauta: Asista en la introducción de datos Ayude a los usuarios a evitar y corregir errores. 3.3.1. Escenario: Etiquetas e instrucciones R 3.71 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 usuarios con magnificadores de pantalla no se pierdan de dicha información. Ejemplos pueden ser: Un campo de fecha que especifique el formato correcto de la 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 asegurese 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 , o 126 Una opción tradicional y sencilla para notificar los campos obligatorios es incluir el texto (requerido) dentro del elemento label: 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 dentro del label. Recuerde poner siempre el texto alternativo a 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 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 requrimientos 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 usuarios que si pueden ver la interfaz). El uso de aria-required="true" es válido y accesible, pero únicamente es informativo para tecnologías de asistencia y visualmente tampoco indica que el campo es requerido. 127 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). 3.3.2. Escenario: Identificación de errores R 3.72 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 del error. De no hacerlo, el usuario tendría que volver a navegar en toda la página o formulario para encontrar el campo. Nota 1: Recuerde no depender de solo los colores para la identificación de campos con error. Nota 2: Si hay un campo erróneo al validar, el usuario no debe de tener que volver a escribir los campos que si contestó correctamente. Nota 3: 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. Nota 4: 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. 128 3.3.3. Escenario: Sugerencias de errores R 3.73 Requerimiento: › Sugerencias apropiadas para la corrección tras errores en 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: • El campo de nombre es obligatorio. Por ejemplo: Luis Hernandez • El campo de dirección de correo electrónico es obligatorio. Por ejemplo: [email protected] • 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 podrá completar el formulario con éxito. 3.3.4. Escenario: Prevención de errores (Legal, Finanzas, Datos) R 3.74 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 del usuario a algún tipo de prueba se debe cumplir alguno de los siguientes casos: o Envíos reversibles o Comprobación de datos y oportunidad de corregirlos o 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 formularios 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 un 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. 129 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 y 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. 3.3.5. Escenario: Ayuda R 3.75 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) 3.3.6. Escenario: Prevención de errores (Todo) 130 R 3.76 Requerimiento: › Para páginas web que requieran que el usuario envíe información se debe cumplir alguno de los siguientes casos: o Envíos reversibles o Comprobación de datos y oportunidad de corregirlos o Mecanismo para revisar, confirmar y corregir la información antes del envío final (Nivel AAA, 3.3.6 WCAG 2.0) 4. Principio: Robusto El contenido debe ser confiable para permitir su uso con una variedad de agentes de usuario. 4.1. Pauta: Compatible Maximice la compatibilidad con los agentes de usuario, incluidas las tecnologías de asistencia. 4.1.1. Escenario: Análisis de sintaxis R 4.77 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 caracter crítico en su formación (como paréntesis angular de cierre o comillas incompatibles) 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 peor 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/. 131 4.1.2. Escenario: Nombre, rol o valor R 4.78 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 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 puedan recabar la 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 provean 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 radio button 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 estarán disponibles para las tecnologías de asistencia). En ocasiones el nombre debe ser visible, en cuyo caso se identifica como 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. 132 Ventana modal El uso de ventanas modales (formularios de contacto, encuestas, imágenes, alertas, 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, reflexione si la ventana modal es realmente necesaria para el sitio. Si no es indispensable, evítela. En caso afirmativo se debe cumplir los siguientes requerimientos: • Al abrir la ventana modal, la ubicación del foco debe de 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 de 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: 133 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 el 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 está pasando en interfaz. Visite las páginas http://www.w3.org/WAI/intro/aria.php y http://www.w3.org/TR/wai-aria/. 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: HTML5 no lo necesita ya que en esta versión si se tiene soporte. IV. 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 accesibilidad 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á mas tiempo corregir cosas que pudieron haber quedado desde el principio (sobre 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 automá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 determinar si esos textos son adecuados a las imágenes. 134 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 Accessibility Evaluation Tool WAVE: http://wave.webaim.org/ 135 Es 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 136 • Analizador de normas WCAG 2.0 versión beta TAW Validador online de 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 137 • HTML CodeSniffer version 2.1.1.: http://squizlabs.github.io/HTML_CodeSniffer/ Es una secuencia de comandos del lado del cliente que comprueba el código fuente htm, viene con estándares que hacen cumplir los tres niveles de conformidad de las “Pautas de Accesibilidad al Contenido de la Web (WCAG 2.0)” • Analizador de contrastes de color. o Colour Contrast Check: http://snook.ca/technical/colour_contrast/colour.html 138 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 indicara si los colores pasan la nueva formula WCAG 2.0 la cual diferencia 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 menor 4,5:1 (texto más grande, al menos 3:1). Para el nivel AAA el texto debe tener una proporción de al menor 7:1 (texto más grande, al menos 4,5:1) o Contrast A: http://contrast-a.dasplankton.com/ 139 o Colour Contrast Analyser: http://www.paciellogroup.com/resources/contrastanalyser/ o WebAIM Contrast Checker: http://webaim.org/resources/contrastchecker/ 140 • Artistic Adobe Color Contrast Checker http://artisticabode.com/accessibility/color- contrast/#text=575757,link=7DB194,bg=FFFFFF 141 • Conversión a modo de texto (Lynx) Lynx: http://www.vordweb.co.uk/standards/download_lynx.htm Es un navegador web en modo texto. 142 • Nivel de visibilidad con aDesigner 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/ 143 • 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: o DebugBar, para analizar el código. http://www.my-debugbar.com/wiki/Doc/DebugbarInstall 144 o Web Accessibility Toolbar, para evaluar accesibilidad la cual solo es compatible en el navegador IE http://www.paciellogroup.com/resources/wat/ o Jim Thatchers Favelets, para evaluar accesibilidad. http://jimthatcher.com/favelets/ Firefox: o Firebug, para analizar el código. https://addons.mozilla.org/es/firefox/addon/firebug/ 145 Firebug marcó el comienzo de la era de la Web 2.0 llega a su fin en el 2017 pero sigue vivo en Firefox developer Tools. o 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 Firefox Quantum https://addons.mozilla.org/es/firefox/addon/web-developer/ o 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/ o 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=W ebsite o Jim Thatchers Favelets, para evaluar accesibilidad. http://jimthatcher.com/IBM/js/FaveletToolbar.xpi 146 o Juicy Studio Accessibility Toolbar, para evaluar accesibilidad (WAI-ARIA), tablas y contrastes. https://addons.mozilla.org/es/firefox/addon/juicy-studio-accessibility-too/ o User Agent Switcher, para evaluar en sitios responsivos. https://addons.mozilla.org/es/firefox/addon/user-agent-switcher/developers o 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 147 o 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/ 148 o 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/ o DOM inspector, para inspeccionar el Document Object Model tree, no es compatible con Firefox versión 59 149 https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/ o AInspector Sidebar, no es compatible con Firefox versión 59 https://addons.mozilla.org/es/firefox/addon/ainspector-sidebar/ 150 Chrome: o Web Developer. http://chrispederick.com/work/web-developer/ o Deque aXe, para evaluar accesibilidad. https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpoke jbdd?hl=en-US 151 o Jim Thatchers Favelets, para evaluar accesibilidad. http://jimthatcher.com/favelets/ o Accessibility Developer Tools. https://chrome.google.com/webstore/detail/accessibility-developer- t/fpkknkljclfencbdbgkenhalefipecmb o ARIA validator , para validar la implementación de ARIA en el HTML. https://chrome.google.com/webstore/detail/aria- validator/oigghlanfjgnkcndchmnlnmaojahnjoc 152 o 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: 153 Tritanopía: o WAVE Toolbar , para evaluar accesibilidad. https://chrome.google.com/webstore/detail/wave-evaluation- tool/jbbplnpkjmmeebjpijfedlgcdilocofh 154 o NoCoffe extensión de Chrome que simula discapacidades visuales. o V. Pruebas de evaluación para accesibilidad Desde el diseño y las primeras etapas del proyecto, se debe considerar la accesibilidad. En cada etapa del proceso y antes de salir a producción, el equipo 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 155 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). Únicamente teclas como Tab, Shift + Tab (para regresar), flechas, enter, etc. Se recomienda realizar pruebas con al menos dos lectores de pantalla, 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 mas 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, si puede evaluar una persona con discapacidad visual, en los cuales de 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 156 • Que el lector de pantalla anuncie etiquetas o textos alternativos adecuados • Que se pueda navegar o realizar correctamente las funcionalidades de componentes 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 accesibilidad siempre debe estar presente. Trabajar en la accesibilidad implica mayor esfuerzo, pero el usuario final te lo agradecerá. Tu trabajo puede tener un impacto positivo en la vida de los demás. 157 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 discapacidad en el mundo digital. Fuente de imagen "Are you ready for Prime Time" VI. 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 sensibilizació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 existir diversas soluciones, 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 158 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 talvez 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 de 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 mas 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? ¿Que nivel de accesibilidad? ¿Cuáles son los recursos para lograrlo? 159 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 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, 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 organización debe incluir dentro de sus requerimientos la accesibilidad, de tal forma que otras empresas empiecen a capacitarse y a crear desarrollos accesibles, ofreciendo un valor agregado a sus clientes. Todo lo anterior, debe ser apoyado por los niveles directivos de la organización. Adicionalmente, por ser un tema de impacto social, se puede declarar en medios 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”. VII. 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 160 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" José Ramón 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/ 161 Web Content Accebility Guidelines (WCAG 2.1) I. Introducción Para la realización de esta guía se tomaron como base 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átiles, tabletas y dispositivos moviles. 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 recomendacione 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á útil para personas mayores, mejorando la usabilidad para los usuarios en general. WCAG 2.1 se basa en WCAG 2.0, que asu vez se basa en WCAG 1.0 y está diseñado para aplicarse ampliamente a diferentes tecnologías web ahora y en futuro. Para satisfacer diferentes necesidades la W3C proporciono varias capas de orientaciónque incluyen: 1.- Principios Generales: En la parte superios 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 los 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 éxito y a implementar mejora las técnicas. 3.- Criterios de Éxito: Para cada directriz se proporcionan criterios de éxito verificables para permitir que la WCAG 2.0 se use cuando los requisitos y las pruebas de conformidad son 162 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 diferentes se definen 3 niveles de conformidad: A (más bajo), AA y AAA (más alto). 5. Técnicas de asesoría suficientes: Las técnicas son informativas y se dividen en dos categorías: las que 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 proporciona orientación sobre cómo hacer que el contenido sea más accesible. WCAG 2.1 cumple con un conjunto de requesitos, que a su vez hereda los requisitos de la WCAG 2.0, los cuales estructuran el marco general de directrices y garantian la compatibilidad con versiones nateriores. 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 podran actualizar el contenido a WCAG 2.1 sin perder conformidad con WCAG 2.0 y se deben tener en cuenta las 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 a WCAG 2.0 Los siguientes criterios de éxito son nuevos en WCAG 2.1: Escenario: Orientación R 1.3.4 Requerimiento: › El contenido no restringue 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 especifica sea esencial.(Nivel AA, 1.3.4 WCAG 2.1) 163 La intención de este criterio de conformidad es garantizar que el contenido que se muestra en la orientación (vertical u horizontal) preferida por el usuario. Algunos sitios web y aplicaciones configuran y restringuen automáticamente la pantalla a una orientació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: Algunos usuarios tienen sus dispositivos montados en una orientación fija, como en el brazo de una silla de ruedas eléctrica, por ejemplo: Stephen Hawking quedó en una situación de discapacidad a causa de esta enfermedad denominada escleorisis lateral amiotrófica. Desde 1985 utilizo un sintetizador de voz para comunicarse, con el tiempo fue perdiendo el uso de sus extremidades, 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, los sitios web y las aplicaciones deben admitir ambas orientaciones. El objetivo de este criterio de conformidad es que los creadores nunca deben restingir la orientación del contenido, garantizando así que siempre coincida con la orientación de visualización del dispositivo. Benerficios: • Los usuarios con impedimentos de destreza que tengan un dispositivo montado podrán usar el contenido en 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 video se muestra en vertical o en paisaje según la orientación elegida por el usuario). 164 • 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 retrato. • Uso de 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 usaurio se puede determinar mediante programación (Nivel AA, 1.3.5 WCAG 2.1). La intención de este criterio de conformidad ayuda a las personas a reconocer y entender el propósito de los campos de entrada de formularios, cuando una persona completa un formulario web, esperamos que proporcione información acerca de ellos mismos en varios campos, por ejemplo: nombre, el apellido, domicilio, email. Lo que se requiere es especificar que tipo de dato 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 caundo: 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 de 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: 165 • Las personas con discapacidades o discapacidad relacioanda con el lenguaje y la memoria que les afecta en la toma de decisión se benefician del hecho de que el navegador 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 beneficiam al reducir la necesidad de introducir información de forma manual. Ejemplos: • Un formulario de contacto con autocompletar es decir que rellena de forma automática los coampo 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 utilizanso 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 la personalización 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 usaurios con un vocabulario limitado puedan usar la web, sin embargo, lo que esa 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 caul se logra agregando semántica o metadatos que proporcionen el contexto. Beneficios: • Al grupo de personas que se beneficiaran son las que tienen discapacidades cognitivas diferentes como son (perdida de memoria, enfoque y atención) y también ayudara a los usuarios que necesitan un soporte adicional incluyendo (símbolos y graficos, atajos de teclado, menos funciones y menos sobre carga cognitiva). 166 Ejemplos: • Un sitio web que utiliza puntos de referencia (landmark) ejemplo: https://www.hearcolors.com.mx/ Encabezado principal
Título
Subtítulo
Título
Subtítulo
Informes Anuales Word Informes Anuales Excel Informe anual 2014 Informe anual 2014 Informe anual 2015 Informe anual 2015