Accesibilidad web: Cómo funciona un lector de pantalla

Cómo funciona un lector de pantalla

Para aquellos usuarios que usan software de lectura de pantalla como JAWS, NVDA o VoiceOver para acceder a la información en la Web, la experiencia del usuario puede ser bastante diferente de la de quienes pueden ver visualmente el contenido.Pero la gente prefiere pasar directamente a los detalles técnicos:

  • ¿Qué teclas presionar?
  • ¿Con qué lector de pantalla debería probar?
  • ¿Qué navegador debería usar?

 

lector_de_pantalla

Si bien todas estas consideraciones son importantes, lo mejor es dar un paso atrás y preguntarnos:

¿Cómo es la experiencia y cómo puedo simular esa experiencia si puedo ver la pantalla?
Para ello, lo vamos a explicar con un ejemplo muy claro para que se entienda bien.

Una puerta abierta

Imagina que acabas de abrir una puerta y estás mirando una gran sala de conferencias.
En el centro de la sala hay una gran mesa de conferencias con 10 sillas (5 en cada lado de la mesa).

Sentados en la mesa hay 2 hombres y 2 mujeres. Las 4 personas están sentadas en el mismo lado de la mesa (están frente a la puerta en la que estás parado). En el otro extremo de la sala (detrás de la gente sentada en la mesa) hay 3 ventanas grandes que dan a un patio con bancos, flores y árboles pequeños.

En el lado derecho de la sala hay un mostrador con una cafetera y un microondas encima.

El lado izquierdo de la sala tiene un gran televisor de pantalla plana montado en la pared.

Suponiendo que no está familiarizado con el diseño de esta sala, ¿qué es lo primero que haría al abrir la puerta? Escanear visualmente la habitación de izquierda a derecha. Algunos la pueden escanear de derecha a izquierda. Otros pueden primero mirar la mesa en el centro y luego escanear el perímetro de la habitación.

Sin embargo, no importa cómo lo hagas, la mayoría escanearía la habitación de alguna manera con la vista para tener una idea rápida del diseño y el contenido de la sala.
El escaneo sólo puede tomar unos segundos y la mayoría ni siquiera se darán cuenta de que lo hicieron.

A continuación, nos podemos centrar en ciertos elementos de interés, como las personas sentadas en la mesa o en la televisión de pantalla plana.

Una habitación oscura

Ahora, imaginemos la escena y esta vez cuando abramos la puerta, la habitación estará completamente a oscuras. No hay luz y no se puede ver absolutamente nada a primera vista. Sin embargo, nos han dado una pequeña linterna y cuando la encendemos, la luz nos permite ver un área pequeña a la vez.

¿Cómo observarías ahora el contenido de la habitación?

Algunos pueden mover la luz de izquierda a derecha comenzando por los pies y alejándose.
También se puede empezar desde la parte posterior de la habitación y mover la linterna, mientras que otros pueden apuntar la linterna al azar en varios lugares de la habitación sin un patrón en particular. A medida que mueva la luz por la habitación, tendrá que construir un mapa mental o una imagen de lo que hay en la habitación y cómo está distribuida.
La construcción de este mapa mental llevará mucho más tiempo que el escaneo visual de la sala cuando todas las luces estaban encendidas.
A medida que movemos la linterna, tendremos que recordar cada cosa que hemos visto y cómo se relacionan todas juntas.

Si olvidamos dónde se encuentra algo, llevará más tiempo localizarlo:

¿el mostrador con la cafetera estaba en el lado derecho de la habitación o estaba en la parte de atrás? ¿Cuántas personas había en la mesa, 4 o 5?

Responder estas preguntas cuando puede ver toda la habitación a la vez requerirá poco esfuerzo, pero contestarlas cuando solo puede ver un área pequeña a la vez llevará mucho más tiempo.

Un escenario análogo

Este segundo escenario es análogo a cómo un usuario de lector de pantalla revisa una página web o una aplicación de móvil.

Si bien los comandos del teclado o los gestos táctiles pueden mover el software de lectura de pantalla alrededor de la página, solo es posible leer una cosa a la vez.
No hay forma de que el usuario con discapacidad visual tenga una visión general rápida (de 1 a 3 segundos) de la página, similar a lo que podría hacer alguien que pueda ver la pantalla.

Afortunadamente, si se utilizan técnicas de navegación de página accesibles como encabezados o regiones, esto puede ayudar a los usuarios del lector de pantalla a enfocarse en ciertas áreas de la página.

Volviendo a nuestro escenario de habitación oscura desde arriba, imagina que ahora hay pequeños puntos rojos de luz en los elementos clave de la habitación: como la mesa, el mostrador, la televisión y cada persona sentada en la mesa. Hay que usar la linterna para mirar alrededor, pero los puntos rojos le dan una idea de dónde se encuentran las cosas más importantes.

Otro desafío importante que pueden enfrentar los usuarios de lectores de pantalla es cambiar dinámicamente el contenido de una página.

Volviendo a los ejemplos de habitaciones claras y oscuras, imagina que uno de los hombres se levanta y se mueve al otro lado de la mesa.

Ahora hay 2 mujeres y 1 hombre en un lado de la mesa y 1 hombre en el otro lado.
En el ejemplo de la habitación iluminada, lo más probable es que notemos el movimiento mientras sucede. Incluso si no estuviéramos mirando directamente al hombre que se movió, probablemente notaríamos el movimiento por el rabillo del ojo y nos percatamos de lo sucedido.

En cuanto al ejemplo de la habitación oscura, sería muy difícil saber que algo sucedió a menos que tengas el haz de la linterna directamente sobre el hombre que se movió en el momento preciso.
Es más probable que nunca sepa que se movió hasta algún momento después, cuando mueve la luz sobre la silla que dejó libre.

En efecto, esto es lo que sucede cuando el contenido de la página cambia pero no alerta el software de lectura de la pantalla. Es posible que el usuario nunca sepa que algo cambió en la página a menos que se muevan a través de la nueva información y se den cuenta de que ahora es diferente.

Esto que he explicado se resuelve asegurando que con el contenido dinámico se usen técnicas como alertas o regiones en vivo que hacen que el software de lectura de pantalla anuncie la información actualizada al usuario.

En nuestro escenario de la habitación oscura, el hombre puede anunciar verbalmente que se está moviendo de un lado de la mesa al otro. Incluso si la luz no estuviera en él, escucharías el anuncio y entenderías mejor lo que está cambiando.

En una ilustración final, tomemos las ventanas que dan al patio. En el escenario de la habitación iluminada, se podrá ver rápidamente que las ventanas dan a un patio con bancos, flores y árboles. Sin embargo, en el ejemplo de la habitación oscura, incluso si apuntabas la luz hacia las ventanas, no podrías ver lo que estaba afuera.
Esto ilustra elementos visuales como imágenes que no tienen una etiqueta de texto asociada.
Por ejemplo, el software de lectura de pantalla puede identificar que una imagen está presente en una página, pero la única forma en que puede comunicar información sobre la imagen es a través del texto alternativo que se le asigna.
Sin la etiqueta de texto, el usuario del lector de pantalla no tendría idea de qué se muestra en la imagen. En el ejemplo de la habitación oscura, se podría colocar un letrero junto a las ventanas con una descripción de lo que aparece afuera. Cuando usemos la linterna, entonces podremos leer el letrero.

 

Usabilidad web: Pioneros y hacedores

Introducción

En esta entrada os voy a hablar del libro “Pioneros y hacedores”.

Pioneros y hacedores

El libro está compuesto por 19 capítulos de distintos autores, expertos en Arquitectura de Información, Diseño Centrado en el Usuario, Usabilidad y Accesibilidad, Ergonomía, Psicología, Diseño participativo y Co-desarrollo, oriundos de Centroamérica, Sudamérica, Norteamérica, Australia y Europa.

Los capítulos, tratan temas que van desde ergonomía física y cognitiva, al desarrollo de un videojuego y de un recurso educativo accesible; de métodos y dispositivos para evaluar la interacción con la nueva televisión interactiva a las técnicas de inspección e indagación heurística; de hacer páginas web accesibles y usables.

Capítulo 1: El botón de los $300, por Jared M.Spool

Nos cuenta el caso real de un e-commerce donde estudió la interacción de sus usuarios con los formularios de registro e ingreso. Finalmente, la modificación de un botón supuso un 45% más de usuarios que terminaban las compras y una ganancia adicional de 15 millones de dólares el primer mes tras el cambio, y 300 millones de dólares después del primer año.

Capítulo 2: Cómo usamos la web realmente, por Steve Krug

Steve Krug nos habla sobre las diferencias entre cómo creemos que la gente usa los sitios web y lo que sucede, y es que las páginas no se leen, se hojean; no tomamos óptimas decisiones, nos conformamos con lo suficiente; y no nos interesa averiguar el funcionamiento de las cosas, nos las arreglamos.

Si queréis más información sobre él, os dejo aquí las entradas en referencia a sus libros: “No me hagas pensar” y “Haz fácil lo imposible”

Capítulo 3: Mobile Sites vs. Full Site, por Jakob Nielsen

Defiende la necesidad de que los sitios web dispongan de una versión móvil. Nos habla de las buenas pautas a seguir en dicha versión y los desafíos que supone.

Capítulo 4: ¿Qué se mueve?, por Don Norman

Parte de una anécdota personal con un mando a distancia, que tenía solo dos botones y sin embargo los usuarios interpretaban de diferente manera, para reflexionar sobre la elección de las metáforas en un diseño adecuado de la interacción.

Capítulo 5: Diseño de interacción, prácticas de investigación y diseño en materiales digitales, por Jonas Löwgren

Presenta qué es el Diseño de Interacción y la naturaleza de la investigación actual en este campo, para desarrollar lo que podría (y quizás debería ser) el Diseño de Interacción.

Capítulo 6: Diseño participativo para la inclusión digital, por Stephen Grant, Laurel Evelyn Dyson y Toni Robertson

Ofrecen un panorama general del desarrollo histórico del proyecto llevado a cabo en la Universidad Tecnológica de Sydney (UTS) para aumentar la participación de los estudiantes aborígenes australianos en los cursos IT, y el modo en el que, gracias a su éxito, fue evolucionando hasta llegar a ser un programa permanente en la Facultad de Ingeniería y Tecnología Informática: el Programa de Participación Indígena en IT (IPIT).

Capítulo 7: Introducción a la Interacción Persona-Computadora, por Yusef Hassan Montero y Sergio Ortega Santamaría

Introducen y describen los conceptos y aspectos más relevantes de la disciplina Interacción Persona-Computadora, que estudia cómo las personas diseñan, implementan y usan sistemas informáticos interactivos, y cómo las computadoras influyen en las personas, las organizaciones y la sociedad. Aportan también una bibliografía para ampliar y profundizar en el conocimiento de la disciplina.

Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

Capítulo 8: Entre la Arquitectura y la Información, por Jorge Arango

Nos ofrece una introducción a la disciplina Arquitectura de Información, el área de práctica profesional que busca traer orden y coherencia a los medios digitales para lograr que la información sea más fácil de encontrar, navegar y entender a través de múltiples canales y dispositivos.

Capítulo 9: Accesibilidad y SEO, por Olga Carreras

Ya hice una entrada referente a este capítulo. Accesibilidad web: Cómo influye en el SEO

Capítulo 10: Desarrollo de un videojuego accesible, análisis del proceso de trabajo: El Caso Slalom, por Javier Mairena y Daniel Márquez

Nos habla de las claves y las dificultades para desarrollar un videojuego accesible, para lo cual será muy importante tener presente la accesibilidad desde el inicio del diseño hasta su publicación e implicar a todas las personas que forman parten del proyecto.

Los autores nos presentan un caso práctico, el desarrollo del videojuego Slalom (que se puede descargar gratis para Windows) Es un simulador del deporte “Slalom en Silla de Ruedas” practicado por personas con parálisis cerebral.

También nos ofrecen una bibliogafía muy interesante sobre recomendaciones publicadas por distintas entidades que pueden servir como guías para crear videojuegos más accesibles.

Capítulo 11: Lo que desconocemos que conocemos sobre accesibilidad y usabilidad, por Emmanuelle Gutiérrez y Restrepo

En este capítulo trata de acercar la accesibilidad a todo el mundo, mostrándola como algo más cercano al sentido común que a complicadas directrices que haya que seguir.

Mediante la comparación con las técnicas y prácticas habituales en la creación de documentos de texto, y siguiendo los tipos de contenido que suelen encontrarse en la mayoría de los sitios web hoy en día, especialmente aquellos que han sido creados mediante un gestor de contenidos, se analizan los criterios de conformidad que tienen su equivalente en dichas prácticas habituales y que, por tanto, todo desarrollador y diseñador conoce de antemano. Todos ellos tienen en realidad un conocimiento de accesibilidad y usabilidad que no sabían que tenían.

La autora nos muestra que con los conocimientos básicos para crear un documento de texto, bien formateado, legible y comprensible para nuestros destinatarios, conseguimos cumplir con 32 de los 61 criterios de conformidad de las WCAG 2.0. Es decir, cumplimos con el 52% de las pautas de accesibilidad para el contenido web. De los 25 criterios de conformidad de nivel A, cumplimos con 15, lo que significa cumplir con el 60% de ellos. De los 13 criterios de conformidad con nivel Doble A, cumplimos con 8, lo que significa cumplir con el 61,5% de ellos. De los 23 criterios de conformidad de nivel Triple A, cumplimos con 9, lo que significa cumplir con 39% de ellos.

Capítulo 12: Ergonomía física y cognitiva: los sistemas sensoriales humanos y la evaluación ergonómica de interfaces, por Sebastian Betti

Nos ofrece y explica una serie de criterios de conformidad para la evaluación ergonómica de las interfaces humano-computadora, que permiten reducir la carga del esfuerzo mental, visual y físico, y de este modo adaptarse mejor a las capacidades humanas.

Capítulo 13: Evaluación de la usabilidad con tecnología eye tracking. El caso de la TV conectada, por Mari Carmen Marcos y Verónica Mansilla

La tecnología Eye Tracking (ET) es una herramienta que complementa al test con usuarios para estudiar la usabilidad y la experiencia de usuario. La utilizaremos cuando nos interese conocer cómo miran los usuarios una interfaz cuando realizan determinada tarea.

Nos hablan de los modelos que existen, de los requisitos de los participantes y de la sala, de las métricas que obtendremos, de la calibración del ET o de los contratiempos que podemos encontrarnos. Otra parte importante del capítulo está dedicada al análisis de los datos obtenidos, que dependerá de si se ha hecho un análisis cuantitativo o cualitativo.

Nos presentan un caso de estudio concreto, aplicando la ET a la televisión conectada, que usa dos canales para recibir información, uno para los contenidos televisivos, y otro para los datos de Internet. Se estudió la interfaz de los menús, puesto que cada fabricante y cadena tienen su propia propuesta. Primero se hizo un test con usuarios en el que se detectaron muchos problemas de usabilidad. Uno de ellos era que los usuarios no lograban acceder con facilidad a un servicio concreto. Para profundizar en el motivo se llevó a cabo un test con ET. Nos cuentan los resultados y las dificultades del mismo.

Capítulo 14: Accesibilidad de un recurso educativo: El caso de la Mapoteca, por Manuel Razzari

Presenta como caso práctico la experiencia con el proyecto “Mapoteca” de educ.ar, una aplicación web para que estudiantes de nivel medio interactúen con mapas escolares. La aplicación sería distribuida en los 3.5 millones de netbooks de los alumnos de escuelas secundarias públicas.

Nos habla de los desafíos del proyecto, del marco de trabajo y de la importancia de elegir los componentes adecuados tanto en el back-end como en front-end, así como del testeo de la aplicación, tanto con usuarios reales como con herramientas de evaluación.

También nos describe los problemas detectados: los que habría sido necesario prever con suficiente antelación (como el uso del color); los que se podrían haber evitado formando adecuadamente a las personas que harán la carga de contenidos; los que son difíciles de imaginar hasta que se hace un test con usuarios; o los que simplemente no tienen una solución al alcance de todos, por ejemplo la solución de la aplicación de mapas de Apple 6, que no usa mosaicos de imágenes sino datos vectoriales, así VoiceOver te leerá las calles mientras desplazas el dedo, leyendo por tanto el contenido de cada zona del mapa.

Capítulo 15: Elaboración de una Normativa de Usabilidad y Accesibilidad Web: El caso de la web de la Ciudad de Buenos Aires, Verónica Traynor

La autora nos introduce en el Diseño Centrado en el Usuario, en una forma de trabajo evolutiva y en espiral que permite a los integrantes del equipo avanzar y aumentar la calidad de sus bocetos de un modo más certero; según los modelos mentales ya no de ellos mismos, sino de los usuarios finales. El eje pasa a ser el ser humano con sus necesidades de percepción, comprensión, operabilidad y aprendizaje. Todo gira en torno a la observación empírica y metodológica de personas aprendiendo e interactuando.

Nos habla de la observación como metodología: “existe una diferencia significativa entre lo que les sucede a los usuarios, lo que interpretan sobre lo ocurrido y lo que opinan que les sucedió” y de los colores como parte del diálogo: “dejamos de hablar de pintar un cuadro y pasamos a construir un semáforo. Bello, pero fundamentalmente claro”.

Por último incluye la normativa de Usabilidad y Accesibilidad Web, publicada en 2010, que deben cumplir los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

Capítulo 16: Internacionalización Web, por Claudio Segovia

Nos introduce en la internacionalización de un sitio web (que no se refiere simplemente a crear sitios multilingües) y por qué deberíamos tenerla en cuenta. Detalla diferentes aspectos a los que deberemos prestar atención.

Capítulo 17: Prácticas participativas en el Diseño de Interacción: El caso del Design Museum, por Mariana Salgado

Nos cuenta el proyecto “La vida secreta de los objetos” llevado a cabo en el Design Museum de Helsinki.

El eje de este proyecto fue que el contenido generado por los visitantes (in situ, online o en los talleres organizados) como comentarios, relatos, opiniones, poemas, recuerdos o sentimientos basados en los objetos expuestos (y que podían estar en forma de texto, sonidos, música, imágenes, vídeos, etc.) estuvieran también en la galería, a disposición de los visitantes y promoviendo su participación. Un nuevo concepto de museo abierto y participativo, donde el diálogo continúe después de la visita.

De esta manera se enriquecería la experiencia de la visita al museo por medio de la inclusión. Esta información subjetiva permitiría disfrutar de las obras expuestas de muchas maneras, dando lugar a un museo abierto, y por tanto más accesible e inclusivo de las diferentes voces de nuestra sociedad.

Capítulo 18: Diseño y desarrollo de un editor de texto accesible bajo modalidad open-source, por Nahuel González

El objetivo del proyecto fue desarrollar un editor de texto accesible open-source. Partiendo de una lista de necesidades que debería atender el software, el artículo describe todas las características de la aplicación final, que a la publicación del libro estaba en la versión 2.0 y que es utilizado por usuarios con diferentes tipos de discapacidad.

Capítulo 19: Las métricas de accesibilidad desde una perspectiva práctica: eXaminator, por Carlos Benavidez

Carlos Benavidez, el creador de la conocida herramienta de evaluación automática de accesibilidad eXaminator explica por qué eXaminator se planteó como una herramienta que ofreciera una puntación numérica de la accesibilidad de la página. Explica además cómo se calcula la puntuación que otorga así como las ventajas y las limitaciones de la herramienta.

Usabilidad web: Problemas con el editor Gutenberg

Introducción

Una de las partes más importantes de WordPress, aparte de todas las personas que trabajamos en ello, es el editor, ya que es donde escribes tus contenidos y puedes aportar y ayudar ofreciendo todo el conocimiento que tienes, con la idea de hacer un WordPress mejor para todos.

Pero desde que está la posibilidad de utilizar este editor, veo que aún le queda mucho por mejorar y, que usarlo así de primeras, el cambio impresiona bastante. Pero bueno, aún así intentaré mostrar los principales problemas que nos podemos encontrar.

Principalmente, si pensamos en personas con dificultades físicas y/o con dificultades visuales que usen el editor, el esquema mental que tenido en su mente durante tanto tiempo, en un segundo se desbarata. Con lo cual tiene que volver a empezar y adaptarse a un cambio tan brusco cuesta, como a todos, pero a ellos más aún, y claro, teniendo tantas cosas para mejorar, la frustración es aún mayor.

Problemas de usabilidad con Gutenberg

La primera impresión al usar Gutenberg hace ya unos cuantos meses, y reconozco lo que he usado poco, era que al existir la posibilidad de mover bloques, cualquier persona que use el teclado y le dé por error se puede llegar a confundir, sobre todo si es una persona con visión nula. Y para una persona con problemas físicos, lo que ocurre es que se aumenta la carga motora innecesariamente, al tener que volver a colocar el bloque en el lugar que le corresponde. Bueno, en este caso, no tanto.

Pero cuando tienes que modificar estilos, sí. Porque tienes que pasar los estilos en cada uno de los bloques para seguir, a menos que uses las flechas de dirección o usar los comandos de teclado asignados para ello. Que a fin de cuentas es lo que se hace con el editor actual, y no nos encontramos con el problema de que al usar el TAB hay que pasar por los bloques y cada una de las opciones que tiene, lo cual es bastante cansado.

Me falla la barra de herramientas fija en la parte superior

Sí, así, tal y como lo lees. ¿Por qué? Porque si nos fijamos bien en las diferentes opciones del bloque, en la primera de ellas que es “Cambiar tipo de bloque”. Según lo que quieras poner ya sea una lista, un encabezado o una cita, la mejor solución es usar el comando correspondiente, porque es un pérdida de tiempo usar la tecla TAB si el usuario se equivoca al elegir qué quiere.

Yo pregunto: ¿Es necesario pasar con el teclado todas las opciones que se ven al desplegar esa opción? NO. Esto puede ser muy cansado para el usuario. Es cierto que beneficia a las personas que usan el ratón y es bastante rápido, pero nos olvidamos de los usuarios que no pueden usar un ratón y el problema principal es que se aumenta la carga motora sin necesidad. No sólo con eso, sino con todo. Porque se tiene que usar constantemente para estar editando y modificando las cosas. Y, también, todo esto puede marear a un usuario ciego.

Pero investigando por estos lares, me he dado cuenta de que existe la opción de “Fijar la barra de herramientas”. En el menú de puntos de la esquina superior derecha, en Ajustes. 
Opción Fijar barra de herramientas

Inserción de imágenes

He creado esta imagen para hacer ver uno de los problemas principales de usabilidad, al menos para mí y para muchos usuarios.

Problema de usabilidad de Gutenberg

Y aquí me encuentro con otro problema: que una vez que insertas una imagen, le das a Intro, y te obliga a poner otra y no hay forma de salir de ahí, hasta que no pasas varias veces con el TAB. Te vuelves loca. ¿Y si yo quiero poner un párrafo o un encabezado inmediatamente después? Con lo cual esto es un problema grave de usabilidad. Te interrumpe cada vez que quieres hacer algo.

En las imágenes es importante añadir el texto alternativo para que las personas ciegas puedan hacerse una idea de cual es la información de la imagen. Una leyenda es añadir algo más de información cuando se trata de una información adicional de la propia imagen, como explicar un gráfico o una imagen compleja, por ejemplo.

Atajos de teclado

Cuando se va a buscar el menú de los atajos de teclado y quieres desplazarte hacia abajo para seguir viendo el resto de comandos, no se puede, es dependiente de ratón.

Y tampoco se sabe cuáles son los atajos para poner los encabezados, algo muy importante para llevar a cabo el orden necesario en cuanto a accesibilidad web, y por lo tanto para ayudar a las personas ciegas a navegar y a entender el contenido.

Inserción de Enlaces

A la hora de insertar un enlace también da problemas. Cuando insertamos un enlace, se inserta bien, pero no te deja abrirlo en una ventana nueva. Una vez lo pones, no puedes comprobar que funciona porque no te deja. Para comprobar que funciona nos tenemos que ir a la opción “Ver entrada” y ya sale, cuando debería dejar hacerlo desde el propio enlace.

Inserción de  vídeos y Opción Incrustados

Hay un problema de usabilidad bastante grande con la inserción de vídeos. Directamente, es que no se puede. Esto, desde un primer momento crea bastante confusión a los usuarios, porque por ejemplo, al insertar un vídeo usando la opción de Vídeo se espera eso, poder insertar un vídeo sin problemas.

En la pestaña Incrustados, que aparece en el menú de bloques de la esquina superior izquierda, en cuanto a los vídeos, me parece un error poner todo lo que corresponde a las redes sociales, vídeos, así como las diferentes plataformas de música y fotos. Hay que intentar ser coherentes con lo que estamos haciendo. Si ya tenemos la opción de Vídeo, que en un primer momento sirve para eso, no podemos confundir al usuario con la palabra Incrustados.

Es más, como sugerencia, diría que hasta podría clasificar las opciones en función de su finalidad: Fotos, audio, vídeos y Redes Sociales. Sería mucho más cómodo a la hora de hacer las búsquedas de lo que se necesite en el momento.

Además de esto, es muy posible que algunas de las opciones no sean accesibles y seguramente tendrán que mejorar muchísimo en cuestión de accesibilidad. Con lo cual, ese menú puede suponer una pérdida de tiempo para los usuarios.

Menú de bloques

En cuanto al menú de bloques, que está dividido en diferentes pestañas que su vez despliegan un menú con diferentes opciones, me quedaba con: Más utilizados, Bloques comunes, Formatos y Elementos de diseño. Incluso, me plantearía redistribuir los Elementos y eliminaría alguno que otro porque lo único que hace es entorpecer y complicar las cosas. De los Formatos en las tablas no se puede tabular y es dependiente de ratón, con lo cual es un problema grave de usabilidad.

Los Widgets están siempre y cuando se pueda añadir una barra lateral y al no poderse hacer, o al menos yo no lo he descubierto, no tiene mucho sentido.

Y la opción de Reutilizable no entiendo para qué sirve. No le encuentro ningún sentido.

Conclusiones

Para mi gusto y por facilidad a la hora de trabajar con Gutenberg, es mucho más cómodo trabajar como lo he explicado anteriormente, con la barra de herramientas fija en la parte de arriba.

Y yo pregunto: ¿Por qué no se añade directamente la barra de herramientas fija a la parte superior? Una funcionalidad tan importante como esta no debe pasar desapercibida para nadie y mucho menos estar escondida en un menú. Se debería incluir esta opción siempre y así no frustra tanto a los usuarios.

Por cierto, lo último que he visto ha sido dentro del menú de cada uno de los bloques, las opciones “Insertar antes” e “Insertar después”, lo cual está bastante bien y mejora algo las cosas cuando estamos editando.

Y para finalizar, comento lo que toda la comunidad de WordPress lleva diciendo desde hace ya algunos meses:

Gutenber no está preparado para implementarse, necesita mejorar mucho en accesibilidad y en usabilidad para que se asiente como editor de textos en WordPress.

Accesibilidad web: ¿Cómo hacer tablas accesibles?

Introducción

Las tablas son un elemento más que forman parte de los sitios web.

Para las personas videntes pueden resultar cómodas y fáciles de interpretar, pero para las personas que usen lectores de pantallas puede ser un problema de accesibilidad.

¿Para qué sirven las tablas?

Las tablas sirven para mostrar información tabular. La información tabular permite consultar y analizar datos. Las tablas no se deben utilizar para la presentación de los contenidos en la web y, por tanto, no se debe usar para la maquetación de nuestro sitio web.

¿Cómo hacemos nuestras tablas accesibles?

En las WCAG 2.0 en el Criterio de Conformidad 1.3.1 Información y relaciones, hay una serie de técnicas que tenemos que tener en cuenta cuando tengamos que insertar en nuestros contenidos una tabla de datos:

Es importante describir la tabla

Debemos proporcionar información adicional sobre la tabla. Así describiremos el propósito de la misma y también se recomienda informar de su estructura. Disponemos de dos métodos complementarios:

  • el atributo summary dentro de la etiqueta <table>
  • la etiqueta <caption> dentro de la tabla.

 

Así se informará a los usuarios de productos de apoyo, como los lectores de pantalla. Por ejemplo, si es un listado de notas, lo debemos indicar. Si en la misma página hay múltiples listados de notas, deberemos incluir en la descripción, la asignatura para permitir al que navega saltar todas las tablas que no le interesen.

Es como poner un título y una leyenda a la tabla para que los usuarios sepan cuál es la información de la tabla, algo que me recuerda al tema de los formularios con el uso de fieldset y la etiqueta <legend>

<table summary"Notas del curso 2015-2016">
<caption>Notas finales del curso de accesibilidad</caption>
</table>
  • En las tablas de maquetación no debemos incluir el atributo summary.
  • El elemento caption y el atributo summary se pueden usar conjuntamente y no deben tener el mismo contenido.

Las tablas deben ser uniformes

Las tablas deben ser uniformes, evitando dividir, combinar o vincular celdas, y por lo tanto tienen que tener el mismo número de filas por columna y el mismo número de columnas por fila.

Para mayor facilidad de de uso y compresión de las tablas se recomienda hacer tablas simples en vez de tablas complejas.

Uso de encabezados

Las tablas deben tener definidos correctamente los encabezados con la etiqueta <th>, ya sea horizontalmente como verticalmente.

Cuando la tabla tiene una disposición de agrupación de columnas o filas, hace mucho más complicado su consulta. Disponemos del atributo scope para poder indicar que el campo actual es la cabecera de la columna o fila que hay a continuación.

En esta primera tabla la cabecera superior se corresponde con la ordenación posterior de los datos. Por tanto en cada <th> incluiremos el atributo scope=”col”.

tabla1

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Nota</th>
</tr>
</thead>
<tbody>...</tbody>

Ahora vamos a trabajar con una segunda tabla, en la que tenemos una doble agrupación. En la fila superior dispondremos de <th> con el atributo scope=”col” como anteriormente, pero en la primera celda de cada fila tenemos un nuevo th en vez de td e indicaremos el atributo scope=”row”.

Hemos utilizado la técnica H63.

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Sesión 1</th>
...
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Marta</th>
<td>8</td>
<td>9</td>
<td>9</td> ...
</tr>
</tbody>

tabla2

Tablas de datos complejas

Para explicar cómo hacer hacer accesible una tabla compleja nada mejor que explicarlo con un ejemplo. Imaginemos que tenemos una tabla en la que se muestra un horario escolar.

Tabla compleja: horario escolar

Es una tabla de datos compleja porque para una celda de datos tiene asociados dos encabezados.  “Matemáticas” tiene dos encabezados: uno de columna “lunes” y uno de fila de las “8:00 a las 9:00.”

Mediante los atributos id y headers los lectores de pantalla serán capaces de informar a los usuarios sobre cuáles son los encabezados correspondientes a la celda actual, independientemente de la complejidad de la tabla:

  • id, se utiliza en las celdas de encabezado <th> para proporcionar un identificador que ha de ser único.
  • headers, se usa en las celdas de datos <td>, con el valor de los id correspondientes.

 

<table>
<caption>Horario de Primero A</caption>
</<tr>
<td>
</<th id=“l”>Lunes</th>
<th id=“m”>Martes</th>
<th id=“x”>Miércoles</th>
</tr>
<tr>
<th id=“h_1”>8:00-9:00h</th>
<td headers=“h_1 l”>Matemáticas</td>
<td headers=“h_1 m”>Inglés</td>
<td headers=“h_1 x”>Música</td>
</tr>
<tr>
<th id=“h_2”>9:00-10:00h</th>
<td headers=“h_2 l”>Lengua</td>
<td headers=“h_2 m”>E.Física</td>
<td headers=“h_2 x”>Lengua</td>
</tr>
</table>

Si examinamos el ejemplo anterior:

  • Para el encabezado lunes se ha definido un id con el valor l.
  • Para el encabezado martes se ha definido un id con el valor m.
  • Para el encabezado miércoles se ha definido un id con el valor x.
  • Para el encabezado de 8:00 a 9:00, un id con el valor h_1.
  • Para el encabezado de 9:00 a 10:00, id con el valor h_2.

Una vez determinados los identificadores a los encabezados vamos a relacionarlos con las celdas de datos, de la siguiente manera:

  • En la celda de datos matemáticas, el valor de headers será el id del encabezado de fila de la franja horaria de 8:00 a 9:00, h_1 y el del id del encabezado columna lunes, l.

De esta forma, se ha definido el valor de todos los headers para todas las celdas de datos de la tabla.

Resumen

  • Una tabla de datos simple es aquella en la que, una celda de datos sólo se relaciona con un encabezado o de fila o de columna, es suficiente el uso de th para identificarlos. Por lo tanto es suficiente con implementar la técnica anteriormente vista H51.
  • Una tabla de datos compleja, es aquella en la que una celda de datos se relaciona con más de un encabezado de fila y/o columna, y por tanto hemos de establecer la asociación entre las celdas de datos con sus celdas de encabezado, utilizando la técnica H63 o la técnica H43.

Accesibilidad web: Principio de mejora progresiva

¿Qué es el principio de mejora progresiva?

La “mejora progresiva” se basa en el principio básico de diseño y programación que hemos visto, la separación del contenido, la presentación y el comportamiento, que implementamos con javascript no intrusivo.
Y asimismo se basa en la mejora de la funcionalidad de nuestra página de forma progresiva.
Es decir, implementaremos las páginas como si no fueran a soportar javascript y sobre ellas añadiremos una capa de programación javascript no intrusivo como mejora.

Principio de mejora progresiva

¿En qué circunstancias o contextos no se van a ejecutar los scripts de mis páginas?

  • Si el navegador no soporta los scripts o su soporte es antiguo, por ejemplo en navegadores antiguos, especialmente de dispositivos móviles o navegadores para televisión, o en navegadores solo texto;
  • Si se ha desactivado por el usuario o, por ejemplo, por el firewall corporativo por motivos de seguridad;
  • Si se ha implementado de forma propietaria y no con funciones DOM, como vimos, y por tanto el navegador no comprende el script.

En todos estos casos, gracias a la “mejora progresiva”, se podrá acceder al contenido o navegar por la página, y un navegador con soporte para el script, además, proporcionará la funcionalidad añadida.

Aplicar el principio de “mejora progresiva” tiene diversos beneficios

  • Mejora la accesibilidad de la página porque el contenido y la funcionalidad estarán disponibles para todos los usuarios, independientemente del agente de usuario o producto de apoyo que utilicen, o de que tengan o no habilitado javascript.
  • Mejora el posicionamiento, como abordaremos con más detalle en lecciones posteriores, puesto que, como hemos adelantado, el contenido siempre está disponible para los buscadores y evita problemas de indexación.
  • Genera un código más limpio, más claro, más ligero y más semántico.

 

¿Cómo se hace?

Ejemplo 1
Para ejemplificar cómo se hace vamos a seguir el ejemplo disponible en la técnica SCR24.
Imaginemos un enlace “Ayuda” que abre un pop-up con una página de ayuda.

Esta sería la manera incorrecta de hacerlo:

<a href=“javascript:;“ onclick=“window.open(‘ayuda.html’)”>
Ayuda
</a>

Los visitantes que utilicen un agente de usuario que no soporte javascript o pop-ups (por ejemplo determinados dispositivos móviles) o que tengan javascript deshabilitado, o algunos robots de buscadores, no podrán acceder a la página de ayuda.

La forma correcta es implementar el enlace para que no dependa de javascript:

<script type="text/javascript" src="popup.js"></script>
…
<a href=“ayuda.html" id="newwin">Ayuda</a>

Tenemos un enlace estándar que puede ser seguido por todos los usuarios (incluidos los robots de los buscadores) en todos los contextos de uso.
Después, como mejora, añadimos una capa de comportamiento, de programación javascript no intrusivo, incluido en el fichero “popup.js”:

window.onload = addHandlers;
function addHandlers(){
var objAnchor = document.getElementById('newwin');
if (objAnchor) {
objAnchor.firstChild.data = objAnchor.firstChild.data + ' (se abre en ventana nueva)';
objAnchor.onclick = function(event){return launchWindow(this, event);}
objAnchor.onkeypress = function(event){return launchWindow(this, event);} }
}
function launchWindow(objAnchor, objEvent){
var iKeyCode, bSuccess=false;
if (objEvent && objEvent.type == 'keypress'){
if (objEvent.keyCode)
iKeyCode = objEvent.keyCode;
else if (objEvent.which)
iKeyCode = objEvent.which;
if (iKeyCode != 13 && iKeyCode != 32)
return true;
}
bSuccess = window.open(objAnchor.href);

if (!bSuccess)

return true;

return false;
}

Mediante javascript no intrusivo y funciones DOM asociamos al enlace los eventos “onclick” y “onkeypress” que abrirán el pop-up, controlando en este último caso qué tecla se ha pulsado.
Además se modifica el texto del enlace para que, en caso de que se soporte javascript, avise de que se abre en ventana nueva. En este caso el texto del enlace será “Ayuda (se abre en ventana nueva)”.

Si se soporta javascript, al pulsar el enlace se abrirá el pop-up anulando la navegación directa a la página, que era la acción por defecto del enlace. Esta anulación se consigue devolviendo “false” con la línea de código “return false”.

En caso contrario, si no se soporta el pop-up o el script, se mantendría la acción por defecto del enlace, abrir la página de ayuda en la misma ventana, gracias a que se devuelve “true” con la línea de código “return true”.

Ejemplo 2

Imaginemos que tenemos un acordeón de preguntas y respuestas que pueden plegarse y desplegarse. Una manera de implementarlo mediante el principio de mejora progresiva sería:

  • Las respuestas estarían en el código de la página.
  • Por defecto estarían todas las preguntas y respuestas desplegadas, y de este modo accesibles para los usuarios que no pueden ejecutar el script y para los robots de los buscadores;
  • Incluimos una capa de mejora, de programación javascript, que si javascript es soportado pliega las respuestas y asocia a cada pregunta, mediante javascript no intrusivo y funciones DOM, los eventos correspondientes para poderlas plegar y desplegar.

Es importante resaltar en este punto que existen diversas maneras de ocultar contenido en una página, y que habrá que seleccionar la correcta para que los usuarios que acceden con un lector de pantalla estén en las mismas condiciones que el resto de los usuarios:

  • Oculto visualmente y para los lectores de pantalla:
    o display:none
    o visibility:hidden
  • Oculto visualmente pero disponible para los lectores de pantalla:
    o text-indent:-999
    o técnica “clip”

“Mejora progresiva” versus “Degradación elegante”

Por último comentar que existe un enfoque alternativo a la “mejora progresiva”: la “degradación elegante”.
Pueden parecer similares o que logran el mismo objetivo, pero tienen diferencias importantes.
La degradación elegante parte de implementar la solución teniendo en cuenta a los usuarios con los dispositivos y navegadores más modernos, y pensar después hacia atrás, en dar una solución alternativa a los usuarios con navegadores más antiguos, para ofrecerles una funcionalidad mínima y suficiente.

El planteamiento del principio de mejora progresiva, como hemos visto, es hacerlo al revés. Se parte del nivel básico de experiencia para todos los navegadores y dispositivos y, sobre él, se construye la funcionalidad más avanzada, que estará disponible automáticamente para los agentes de usuario y dispositivos más modernos.

Ejemplo de aplicación del principio de degradación elegante

En el ejemplo 1 de aplicación del principio de mejora progresiva hemos visto cómo se implementa un enlace que abre un pop-up y que funciona aunque no se soporte o no se tenga activo javascript.

¿Cómo solucionaría el enfoque de “degradación elegante” nuestro enlace para abrir un pop-up en aquellas circunstancias en las cuales no se soporta javascript?

Partiendo de la opción avanzada, propondría una alternativa para el resto de usuarios, por ejemplo con la etiqueta <noscript>.

<a href=“javascript:;“ onclick=“window.open(‘ayuda.html’)”>Ayuda</a>
<noscript>
<p>Su navegador no admite javascript o lo tiene deshabilitado.

Acceda desde aquí a la <a href=“ayuda.html”>página de Ayuda</a></p>
</noscript>

En el caso de que no se soporte javascript, o esté deshabilitado, se mostraría el contenido incluido dentro la etiqueta <noscript>.
La solución que implementamos siguiendo el modelo de “mejora progresiva”, cuesta inicialmente más tiempo, pero:

  • es más elegante, tiene un código más limpio y más ligero
  • es más fácil de mantener
  • proporciona mejor experiencia de usuario
  • no presupone, por ejemplo, que la única razón por la cual no se ejecuta un script es que no se soporta o está deshabilitado.
    • Puede ser que el navegador no entienda parte del código, en cuyo caso no nos serviría la solución propuesta con <noscript> y sí la propuesta en la de “mejora progresiva”. <noscript> tampoco nos serviría si se soporta javascript y se tiene habilitado pero no se soportan los pop-ups.
      Por tanto se recomienda siempre el enfoque de “mejora progresiva”.

 

Podéis ampliar información en el artículo “Graceful degredation versus progressive enhancement” del W3C.

Accesibilidad web: Cómo utilizar JavaScript accesible.

En esta entrada vamos a hablar de cómo el código JavaScript que incluimos en los sitios no suponga una barrera de accesibilidad web.

JavaScript accesible

Compatible con la accesibilidad

Se dice que algo es “compatible con la accesibilidad” como ya dije en otra entrada, cuando la tecnología aplicada la soporta, y en caso de utilizar una tecnología no accesible hay que establecer una alternativa que sí sea accesible.

Por lo tanto, se puede decir que JavaScript es una tecnología compatible con la accesibilidad, y por consiguiente, con los productos de apoyo.

Para ello, hay una serie de pautas a llevar a cabo:

Independiente del dispositivo

Para que los scripts puedan ser operados desde cualquier dispositivo, no sólo por ratón sino también por teclado, es necesario usar correctamente los manejadores de eventos JavaScript.

Un evento es algo que ocurre en la página y que puede ser detectado.

Puede ser:

  • un evento disparado por una acción del usuario, por ejemplo, pulsar con el botón izquierdo del ratón
  • un evento disparado por el navegador, por ejemplo al cargarse la página.

 

Los manejadores de eventos nos permiten ejecutar unas instrucciones cuando un evento es disparado, por ejemplo ejecutar una validación del formulario antes de que se envíe dicho formulario:

<form onsubmit=“ValidarForm()” id="miForm" …>

O con javascript no intrusivo:

document.getElementById(‘miForm').onsubmit = validarForm

 

Manejadores lógicos

Hay manejadores lógicos, que no dependen de dispositivos concretos y reconocen eventos tanto del ratón como del teclado:

  • onsubmit, que hemos visto en el ejemplo anterior
  • onreset
  • onfocus
  • onblur
  • onload
  • onselect

 

Manejadores específicos de ratón

También hay manejadores específicos de ratón, solo se disparan ante una acción realizada con el ratón.

Estos manejadores de eventos tienen su equivalente para teclado:

  • onmousedown = onkeydown
  • onmouseup = onkeyup
  • onmouseover = onfocus
  • onmouseout = onblur

 

Si usamos eventos de teclado junto con eventos de ratón nos aseguramos de que se podrá interactuar con el contenido a través de una amplia variedad de dispositivos.

Podéis ver varios ejemplos en las técnicas SCR2 y SCR20 de las WCAG 2.0
Por ejemplo, en la técnica SCR20 se muestra el siguiente ejemplo, un enlace de imagen en el cual la imagen cambia cuando se coloca o no el cursor sobre la misma:

<a href="menu.php"
onmouseover="swapImageOn('menu')" 
onfocus="swapImageOn('menu')"
onmouseout="swapImageOff('menu_off')" 
onblur="swapImageOff('menu_off')">
<img id="menu" src="menu_off.gif" alt="Menu"/></a>

Para los usuarios que acceden con teclado una experiencia similar, la imagen también cambia cuando el usuario accede al enlace con el tabulador, utilizándose para ello los manejadores de evento de teclado equivalentes.

Evento “onclick”

El evento “onclick” merece una mención especial.
Puede parecer un manejador de evento de ratón, pero es el evento de acción por defecto de enlaces y botones y se activa por teclado y por ratón.

Con enlaces y botones

Por tanto, con los enlaces y botones no es necesario utilizarlo junto a “onkeypress”, que sería su evento de teclado equivalente.
Además, los enlaces y los controles de formulario, son los elementos que en HTML4 cogen el foco de forma nativa, por tanto podremos llegar hasta ellos por teclado, tabulando, para activarlos.

Con otros elementos

Sin embargo, cuando usamos “onclick” con otros elementos que no sean enlaces y botones (<div>, <img>, <td>, etc.), para que el código asociado al evento pueda ser invocado también por teclado, entonces sí deberá utilizarse junto a su evento equivalente de teclado “onkeypress”.

Siempre habrá que controlar qué tecla se ha pulsado para evitar problemas de tabulación.
Pero no sirve de nada incluir el evento de teclado “onkeypress” si estos elementos no pueden coger el foco por teclado, es decir, no se puede llegar a ellos con el tabulador y por tanto no pueden activarse por teclado.

Por ello, debe incluirse a estos elementos el atributo “tabindex”:

  • tabindex=”0” para que se pueda acceder a dicho elemento por el teclado, mediante el tabulador;
  • tabindex=”-1” cuando se quiere que el elemento pueda coger el foco por programación.

Por ejemplo,

<img src="arrow.gif" onclick="nextPage();"
onkeypress="nextPage();" tabindex="0" alt="Ir a la siguiente página” />

 

Se ha incluido el evento “onclick” a una imagen, por ello se utiliza junto al evento “onkeypress”, para que la acción se desencadene también al pulsar la imagen desde el teclado (con la tecla “enter” o la barra espaciadora).
Pero esto solo no sería suficiente, se ha incluido el atributo tabindex=”0” para que la imagen pueda coger el foco por teclado, que puedas tabular hasta ella, sino difícilmente vas a poder pulsarla con el teclado.
En cualquier caso, para implementar un botón siempre es mejor solución utilizar un elemento “button” o un “input” de tipo “image”, como comentamos en la entrada sobre formularios accesibles.

Se pueden consultar ejemplos en las técnicas SCR20 y SCR29 de las WCAG 2.0

Funciones DOM y contenido dinámico

En segundo lugar vamos a hablar de utilizar funciones DOM para insertar, eliminar o modificar contenido dinámicamente; explicaremos qué es DOM y qué tipo de funciones usar.
En el DOM (el Modelo de Objetos del Documento) se representan los documentos como una estructura de árbol.
Cada parte del documento (texto, elementos, atributos) está representada en los nodos del árbol.

Existen métodos que permiten obtener cualquier elemento y sus atributos, modificarlos, eliminarlos y crear nuevos nodos con nuevos elementos.

Es decir, usando DOM podemos manipular de forma dinámica el contenido estructurado de nuestros documentos y es el medio fundamental para la creación de scripts no intrusivos como luego veremos.
Al usar funciones DOM aumentamos la compatibilidad con los agentes de usuario y productos de apoyo ya que estas aplicaciones acceden al DOM para recuperar el contenido.

No debes usar el método
document.write, o las propiedades “innerHTML”, “outerHTML”, “innerText” u “outerText” para insertar o modificar contenido dinámicamente en el documento, ya que no son parte de la especificación DOM.

En el caso de “innerHTML” y “outerHTML” podrían serlo en un futuro inmediato ya que forman parte de un estándar candidato a recomendación del W3C.
En su lugar, usaremos funciones DOM para generar y manipular dinámicamente el contenido, de manera que los agentes de usuario y productos de apoyo puedan acceder al DOM para recuperar el contenido.
Deberemos insertar el contenido en el orden correcto y, en el caso de que sea contenido que puede coger el foco, comprobar que lo hace en un orden lógico.
Técnica de referencia de las WCAG 2.0: SCR21: Using functions of the Document Object Model (DOM) to add content to a page

Podéis ver ejemplos en las técnicas SCR26 y SCR27 de las WCAG 2.0

Javascript no intrusivo

Un principio básico de diseño y programación es la separación entre la presentación, el contenido y el comportamiento de la página.
Javascript no intrusivo nos va a permitir llevar a cabo la separación del comportamiento (de la programación de la página) de lo que es el contenido y la presentación.
En este ejemplo de javascript intrusivo, el comportamiento se mezcla con el contenido de la página:
<form onsubmit=“validarForm()” id=“miForm” …>

La forma no intrusiva y correcta es separar el comportamiento incluyendo toda la programación en ficheros JS.
El ejemplo anterior, implementado con javascript no intrusivo, sería:
En el fichero JS
document.getElementById(‘miForm').onsubmit = validarForm

En la página HTML

<form id=“miForm” …>

La implementación de javascript no intrusivo ayuda a la escalabilidad, mantenimiento y rediseño de los sitios.

El código HTML es más limpio, ligero y semántico y, junto al principio de “mejora progresiva”, nos va a ayudar a mejorar la accesibilidad de nuestras páginas.

Mejora progresiva

La “mejora progresiva” se basa en el principio básico de diseño y programación que hemos visto, la separación del contenido, la presentación y el comportamiento, que implementamos con javascript no intrusivo.
Y asimismo se basa en la mejora de la funcionalidad de nuestra página de forma progresiva.
Es decir, implementaremos las páginas como si no fueran a soportar javascript y sobre ellas añadiremos una capa de programación javascript no intrusivo como mejora. Más adelante abordaremos este principio con un ejemplo.

¿En qué circunstancias o contextos no se van a ejecutar los scripts de mis páginas?

  • Si el navegador no soporta los scripts o su soporte es antiguo, por ejemplo en navegadores antiguos, especialmente de dispositivos móviles o navegadores para televisión, o en navegadores solo texto;
  • Si se ha desactivado por el usuario o, por ejemplo, por el firewall corporativo por motivos de seguridad;
  • Si se ha implementado de forma propietaria y no con funciones DOM, como vimos, y por tanto el navegador no comprende el script.

En todos estos casos, gracias a la “mejora progresiva”, se podrá acceder al contenido o navegar por la página, y un navegador con soporte para el script, además, proporcionará la funcionalidad añadida.

Aplicar el principio de “mejora progresiva” tiene diversos beneficios

  • Mejora la accesibilidad de la página porque el contenido y la funcionalidad estarán disponibles para todos los usuarios, independientemente del agente de usuario o producto de apoyo que utilicen, o de que tengan o no habilitado javascript.
  • Mejora el posicionamiento, puesto que, como hemos adelantado, el contenido siempre está disponible para los buscadores y evita problemas de indexación.
  • Genera un código más limpio, más claro, más ligero y más semántico.

Accesibilidad web: Cómo hacer una navegación más accesible

En esta entrada voy a comentaros varios requisitos y técnicas de accesibilidad que nos ayudarán a tener una navegación más sencilla y más accesible.

Accesibilidad web: Cómo hacer una navegación más accesible

Cómo hacer una navegación accesible

Los requisitos a tener en cuenta son los siguientes:

  • Ofrecer varias vías de navegación para localizar el contenido
  • Facilitar la ubicación al usuario para que en ningún momento se sienta perdido
  • Mantener la consistencia lo largo del sitio

 

1. Múltiples vías  de navegación

Lo primero vamos a explicar es cómo establecer diferentes vías para mejorar la navegación de forma que los usuarios lo encuentren fácil y puedan satisfacer sus necesidades.

Para ello, tendremos en cuenta el criterio 2.4.5. “Múltiples vías: Se proporciona más de un camino para localizar una página web dentro de un conjunto de páginas web, excepto cuando la página es el resultado, o un paso intermedio, de un proceso. (Nivel AA)

Hay quienes prefieren usar el buscador a recorrer un menú de navegación largo. Otros prefieren usar tablas de contenidos o un mapa del sitios para navegar por el sitio

Por eso, las WCAG 2.0 establece que tenemos que aplicar dos o más técnicas para mejorar la navegación.

  • Mapa del sitio
  • Función de búsqueda
  • Enlaces a páginas relacionadas
  • Tabla de contenidos

 

Mapa del sitio

Es muy importante tener en cuenta la creación de un mapa web, que ayude a facilitar la comprensión del sitio web. Para ello, tenemos la técnica G63: Proporcionar un mapa del sitio y que debe cumplir una serie de requisitos:

  • Debe estar enlazado a todas las páginas, o desde cada una de las páginas que se listan en el mapa web.
  • Desde el mapa web se tiene que poder acceder a todas las páginas del sitio, directa o indirectamente. Por lo tanto, sus elementos deben ser enlaces.
  • La presentación y la estructura deben reflejar la orgnización del sitio, con elementos HTML, como son los encabezados y las listas.
  • El orden de lectura y de tabulación debe ser el correcto.
  • Se debe actualizar cada vez que se actualiza el sitio.

Función de búsqueda

Otra técnica a tener en cuenta es proporcionar una función de búsqueda en el sittio web, patra que los usuarios puedan acceder a buscar el contenido sin necesidad de entender el sitio o navegar por él. Es muy útil en sitios de gran tamaño.

La función de búsqueda se realizará mediando un campo de búsqueda que esté presente en las páginas del sitio. La técnica que habla de esto es la G161: Proporcionar una función de búsqueda para ayudar a los usuarios a encontrar contenido.

 

Enlaces a páginas relacionadas

Otra técnica que se puede emplear es enlaces a páginas relacionadas. De esta manera los usuarios ppueden encontrar información adicional. Técnica G125: Proporcionar enlaces para navegar a páginas relacionadas.

 

Tabla de contenidos

Otra técnica es utilizar una tabla de contenidos, que consiste en un índice con las secciones y subsecciones de una página, y que proporciona un acceso directo a una sección específica. Para más información sobre ello, se puede consultar la técnica G64: Proporcionar una tabla de contenidos.

Otras técnicas para sitios pequeños

Si el sitio es pequeño se pueden aplicar otras técnicas:

  • el menú de navegación incluye el acceso a todas las páginas del sitio.
  • todas las páginas están enlazadas desde la página de inicio.

Técnicas relacionadas:

 

Ubicación del usuario

Un requisito muy importante que hará que el sitio web sea más accesible es facilitarle la ubicación a los usuarios, proporcionarle inforción sobre dónde se encuentran.

Para ello, esta el criterio 2.4.8 Ubicación: se proporciona información acerca de la ubicación del usuario dentro de un conjunto de páginas web.

Hay varias técnicas para conseguir esto:

Migas de pan.

Las migas de pan van a ayudar a:

  • Comprender cómo se estructura el contenido de un sitio web.
  • Navegar por las páginas visitadas
  • Identificar la ubicación actual de una página dentro del sitio web.

¿Qué requisitos deben cumplir las migas de pan?

  • Deben estar siempre situadas en el mismo lugar en todas las páginas.
  • Maquetarlas mediante listas, aunque visualmente se presenten en línea.
  • Usar separadores visuales entre las mismas.
  • Deben ser enlaces.
  • Deben indicar el camino usado para llegar a la página actual o bien indicar su situación en la jerarquía u organización del sitio.

 

Indicar la situación actual en la navegación

Otra técnica para facilitar la ubicación del usuario es indicar la situación actual en menús, barras de navegación, pestañas o pasos en un proceso. Todo cambio que se produzca se debe comunicar a los usuarios.

Por eso, el menú o paso en el que nos encontramos no solo se debe indicar visualmente, sino también estructural y semánticamente o mediante texto si fuera necesario como establece el criterio 1.3.1 Información y relaciones. Se puede obtener más información sobre este requisito en la técnica G128: Indica la ubicación actual dentro de las barras de navegación.

 

Elemento <link>

Otra técnica es incluir navegación semántica a través del elemento link

<head><title>Capítulo 2</title>
<link rel="index" href="index.html“ title="Índice" />

<link rel="start" href=“intro.html“ title="Introducción" />

<link rel="next" href=“cap3.html“ title="Capítulo 3" />

En este ejemplo estamos indicando, dentro de una colección de páginas: el índice, la primera página de la colección y la siguiente.

La ventaja de usar <link> para establecer las relaciones es que este elemento se puede interpretar mediante software. Se puede ampliar información en la técnica H59: Uso del elemento de enlace y las herramientas de navegación.

 

Consistencia

Otro aspecto que hace más accesible la navegación es la consistencia, tanto en la presentación y maquetación de los mecanismos de navegación, como en la identificación de los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas

  • 3.2.3 – Navegación coherente
  • 3.2.4 – Identificación coherente

Navegación coherente

Si los mecanismos de navegación que se repiten en diferentes páginas de un conjunto (como el buscador, el menú de navegación, las migas de pan, etc), se presentan en el mismo orden en las diferentes páginas del conjunto, los usuarios pueden predecir dónde estarán en cada página y localizarlos con más facilidad. Para más información se puede consultar la técnica G61.

Identificación coherente

Tan importante es la navegación coherente, como la identificación coherente, porque si en un sitio web se usan diferentes etiquetas para una misma función se dificulta considerablemente la comprensión y la interacción con el sitio, y en definitiva su uso.

Identificación coherente quiere decir, en los enlaces, que aquellos que tienen un mismo destino tienen el mismo texto de enlace.

Por ejemplo, si el destino del enlace es la página de inicio del sitio, el texto del enlace no puede ser unas veces “Ir a la home”, en otras “Ir a la página de inicio” y en otras “Ir a la página principal”.

El texto del enlace además deberá ser consistente con el título de la página, el nombre con el que se identifica a la misma en las migas de pan o en el mapa del sitio.
En el caso de destinos similares, los textos de enlace deberán ser consistentes.

Por ejemplo, en un portal de noticias, el texto del enlace para ampliar información sobre cada noticia, no puede ser en un caso “Más información”, en otro “Leer más” y en otro “Más info”.

La identificación coherente también se aplica al texto alternativo de los elementos no textuales.
Por ejemplo, si se usa el mismo icono en diferentes páginas, se entiende que con la misma función, debe tener el mismo texto alternativo, si tenemos un icono para descargar un fichero, su texto alternativo no puede ser en unos casos “descargar”, en otros “guardar” y en otros “bajar”.

Y la identificación coherente se aplica también a las etiquetas de los campos de formulario: los mismos controles de formulario deben estar etiquetados igual.

Por ejemplo, no podemos etiquetar el campo contraseña en unos casos como “password”, en otros como “contraseña” y otros como “clave”.

 

Accesibilidad web: Requisitos de Accesibilidad de los Medios Audiovisuales

El objetivo de este artículo es explicar el documento del W3C: Requisitos de usuario para la Accesibilidad de los medios audiovisuales.

Introducción

Este documento explica los diferentes tipos de contenidos alternativos que se pueden ofrecer, a quiénes benefician y los requisitos que deben cumplir; recoge asimismo los que debería cumplir el sistema, abarcando el proceso de producción o los agentes de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia).

Requisitos de usuario para la accesibilidad de los medios audiovisuales

Estructura del documento

Se divide en cuatro grandes apartados:

  • Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de diversidad funcional.

En este apartado se proporciona una introducción a las necesidades de los usuarios con diversidad funcional, (ceguera, baja visión, daltonismo, diversidad funcional auditiva, sordoceguera, diversidad funcional motriz y diversidad funcional intelectual) en relación con el contenido audiovisual.

  • Tecnologías para proporcionar contenido alternativo.

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

  • Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente, desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción. Por ello, los requisitos listados en este apartado están en su mayoría más relacionados con las UAAG que con las WCAG.

  • Checklist “Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales”

 

Resumen de los requisitos de accesibilidad de los medios audiovisuales por tipo de diversidad funcional

En este apartado se proporciona una introducción a las necesidades de los usuarios con discapacidad para poder percibir, interactuar y comprender los contenidos audiovisuales.

Ceguera

Las personas ciegas no pueden acceder a la información visual presente en los vídeos, los controles de los reproductores o los indicadores de estado. Por ello necesitan que la información se presente de forma alternativa mediante texto o audio.

Hay que tener en cuenta que las personas ciegas utilizan un lector de pantalla y/o una línea braille, por tanto necesitan que los medios audiovisuales sean operables cuando se utilizan estos productos de apoyo.

Baja visión

Las personas con baja visión, en función de su capacidad visual, puede ser que tengan problemas específicos, como dificultad para discriminar la información de primer plano de la información de fondo, para discriminar colores, o les pueden deslumbrar los contenidos muy brillantes.

Por otra parte, quizás no puedan reaccionar rápidamente a la información que se presenta en pantalla durante un tiempo limitado. Pueden tener un ángulo de visión estrecho que no les permita detectar la información clave presentada temporalmente si no están mirando en esa dirección, o si el texto se está moviendo o desplazando.

Estas personas utilizarán probablemente un magnificador de pantalla, así que solo estarán viendo una parte de la pantalla, por ello se debe poder gestionar el contenido audiovisual a través de su producto de apoyo.

Las personas con baja visión pueden tener dificultad para leer el texto demasiado pequeño, con poco contraste, con un determinado tipo de fuente o con efectos. Por otra parte, si el texto es una imagen, se verá pixelada al ampliarse.

Pueden estar utilizando un producto de apoyo que modifique los colores, por ejemplo que los invierta, de modo que los contenidos audiovisuales deben ser visibles también en este contexto.

Por último, los usuarios con baja visión a menudo se benefician también de los textos e instrucciones que algunas veces los autores ocultan visualmente (por ejemplo colocándolos fuera de pantalla) dirigidos a los usuarios de lector de pantalla o línea braille.

Percepción del color

Las personas con problemas en la percepción del color (daltonismo) pueden tener dificultades para discriminar entre diferentes colores, o pueden perderse información clave cuando la información se proporciona solo mediante el color, por ejemplo en los controles del audio/vídeo o en las superposiciones de texto

Sordera

Las personas sordas no podrán escuchar el audio, por tanto será necesaria una alternativa, normalmente a través de subtítulos sincronizados y/o traducción en lengua de signos.

Problemas de audición

Las personas con problemas de audición podrían no ser capaces de discriminar cierto tipo de sonidos, y por tanto pueden perderse información presente en el audio si tiene frecuencias que no pueden oír, o bien a causa del ruido de fondo o la distorsión.

También pueden perderse información si el audio es demasiado bajo o de mala calidad, o si las personas hablan demasiado rápido y no se puede reproducir el audio más lento.

La información que se presenta mediante audio multicanal puede no ser percibida por las personas sordas de un oído.

Por último, las personas con un implante coclear pueden no tener problemas con el volumen del audio, pero la comprensión puede ser difícil si la experiencia multimedia es abrumadora.

Sordoceguera

Según su nivel de ceguera y sordera, las personas sordociegas podrían necesitar: subtítulos y la posibilidad de ampliarlos; cambiar a colores de alto contraste (u otra combinación de colores); subtítulos y/o descripción del vídeo expuestos por su producto de apoyo; o una transcripción que cada usuario pueda leer a su ritmo, es decir, que no esté basada en el tiempo.

Diversidad funcional motriz

Algunas personas con diversidad funcional motriz como aquellas con un control muscular limitado (temblores, falta de coordinación, parálisis), con dolor que les impida el movimiento o con la falta de alguna extremidad, no podrán utilizar el teclado o el ratón para interactuar con el contenido y los controles.

El reproductor de los contenidos audiovisuales tiene que poder ser operable solo con el teclado (sin ratón), lo cual incluye el acceso a todos los controles y métodos de selección del contenido alternativo.

Diversidad funcional cognitiva

Autismo, dislexia, discalculia, trastorno de déficit de atención, problemas de memoria, … la extensa gama de condiciones que abarca hace que los requisitos de accesibilidad también varíen ampliamente.

Algunas personas podrán procesar la información auditiva mejor que la lectura del texto, por tanto, la información que se presenta como texto embebido en el vídeo también deberá estar disponible como descripciones de audio.

Otras personas pueden necesitar reducir las distracciones o flashes en las presentaciones de vídeo.

En general, la experiencia multimedia para las personas con trastornos del espectro autista debe ser personalizable y estar bien diseñada para no resultar abrumadora.

Se debe tener cuidado en presentar la experiencia multimedia focalizada en el propósito del contenido y proporcionar alternativas al contenido de una manera clara y concisa.

Tecnologías para proporcionar contenido alternativo

En esta sección se explican los diferentes tipos de contenidos alternativos que se pueden proporcionar para ayudar a los usuarios con una discapacidad sensorial a acceder al contenido audiovisual. Por cada uno de ellos se incluye un listado de los requisitos que deben satisfacer en el contexto de un desarrollo HTML5 (pero no se entra en aspectos técnicos o de desarrollo concretos).

Audiodescripción

Una audiodescripción contiene una narración descriptiva de los elementos visuales clave para hacerlos accesibles a las personas ciegas o con una discapacidad visual. Se incluyen acciones, vestuario, gestos, cambios de escena o cualquier otra información visual relevante que alguien que no puede ver la pantalla podría perderse.

Las audiodescripciones son grabaciones de audio que se insertan en las pausas naturales del mismo.

Pueden ser de dos tipos:

  • Abiertas, se fusionan con la pista de audio y no pueden ser desactivadas por el usuario.
  • Cerradas, el usuario puede activarlas o desactivarlas.

Las audiodescripciones no solo benefician a las personas ciegas o con problemas de visión. Por ejemplo, pueden beneficiar a los estudiantes que lidian con materiales o conceptos difíciles, puesto que la audiodescripción puede dar información complementaria acerca de lo que se está viendo en pantalla (la estructura de una ecuación, la complejidad de una pintura, etc.).

Audiodescripciones en formato texto

Cuando la audiodescripción se proporciona en formato texto, en vez de en formato voz grabada, se presentan unos requisitos específicos.

Las audiodescripciones en formato texto (TVDs) se entregan al cliente como texto y son renderizadas localmente por los productos de apoyo (lector de pantalla o línea braille). Los ficheros de texto se proporcionan como archivos de texto que contienen los tiempos de comienzo de cada descripción. Las ventajas son que el usuario de lector de pantalla puede tener un control total sobre la voz, la velocidad del habla u otras opciones.

Audiodescripciones ampliadas

Las audiodescripciones se suelen introducir en las pausas naturales del diálogo o la narración. Pero en algunos casos no hay tiempo suficiente. Las audiodescripciones ampliadas (EVD) trabajan pausando el vídeo y el audio en momentos clave para reproducir la audiodescripción extensa, y una vez que termina reanudan la reproducción.

Las audiodescripciones ampliadas benefician por ejemplo a las personas con el síndrome de Asperger u otras personas con trastornos del espectro autista, ya que en ellas se puede explicar conexiones entre la causa y el efecto, se puede señalar lo que es más importante, o explicar los estados de ánimo.

Clean audio

Un desarrollo relativamente reciente en la accesibilidad en televisión es el concepto de “audio limpio”, que aprovecha el audio multicanal.

Beneficia especialmente a las personas con problemas de audición. Consiste en aislar el canal de audio que contiene los diálogos o la información relevante que así puede amplificarse (o modificarse de otro modo), mientras que los canales que tienen la música o los sonidos ambientales pueden atenuarse. Esto permite usar filtros y adaptar el audio a las necesidades del usuario, ya que la pérdida de audición es típicamente dependiente de la frecuencia.

La mayoría de los usuarios están familiarizados con el avance rápido y el rebobinado en el contenido audiovisual. Sin embargo, esta manera de explorar el contenido, basada en el tiempo, es bastante ineficaz y perjudica especialmente a las personas con discapacidad.

Afortunadamente, la mayoría de los contenidos tienen una estructura (los audiolibros tienen capítulos, las películas actos y escenas, los programas de televisión secciones, etc.). Un marcado adecuado puede exponer su estructura en los controles para avanzar y rebobinar.

Sin embargo, una navegación efectiva por la jerarquía de su estructura requeriría un control adicional que no suele estar disponible en los reproductores multimedia actuales. Este mecanismo (que llaman “granularity-level control”) permitiría al usuario ajustar el nivel de granularidad aplicado a los controles “siguiente” y “anterior”. La personalización sería necesaria porque puede ser muy engorroso acceder a todos los nodos de la jerarquía o insatisfactorio acceder solo a los del nivel superior de la jerarquía.

Se ponen varios ejemplos. Uno de ellos es el de un telediario. Las grandes secciones serían noticias, tiempo o deportes. El segundo nivel serían las noticias individuales de cada sección. Si dispusieras de este “granularity-level control” podrías ajustar el nivel de granularidad de los controles “siguiente” y “anterior” para saltar de sección en sección, o de noticia en noticia.

A continuación se habla de la navegación a través de contenidos auxiliares, como anuncios, resúmenes de noticias, notas al pie de un libro, etc. que interrumpen el “programa” primario, y que el usuario puede querer saltarlos (o tal vez ir directamente a ellos).

Subtítulos

Para las personas sordas o con problemas de audición, los subtítulos son la principal alternativa al audio.

A diferencia de los subtítulos para personas cuyo idioma no es el del contenido, el subtitulado para sordos (captioning) no solo debe transcribir el diálogo o la narración, sino también la información importante como efectos de sonido, risas, etc., y debe estar en el mismo idioma que la pista de audio principal.

Los subtítulos pueden ser cerrados, es decir, pueden ser activados o desactivados por el usuario; o abiertos, que están siempre visibles, fusionados con la pista de vídeo y no pueden desactivarse.

Aunque lo ideal es que sea una transcripción literal del audio, a veces se editan por adecuarlos, por ejemplo, a la velocidad de lectura. Si se editan debería indicarse y debería proporcionarse una versión textual completa.

No es estrictamente necesario que el texto del subtítulo coincida con el movimiento de la boca, a veces pueden adelantarse o extender un poco.

Cuando hablan varias personas, en el texto de los subtítulos se debe distinguir a los oradores, por ejemplo indicando el nombre de la persona (“Ana:”) antes del texto que representa lo que dice en el audio.

Los subtítulos también son muy útiles para que los clientes de bares, gimnasios, etc. sigan el programa en la televisión (yo añadiría que también para las personas que por el contexto no pueden activar o escuchar el audio y/o no tienen auriculares) o para las personas que no dominan el idioma. Por otra parte, los subtítulos tienen capacidad de búsqueda, lo que permite localizar un vídeo o un punto exacto del mismo.

Subtítulos enriquecidos

Pueden tenerse varias pistas de subtítulos, por ejemplo uno adecuado para cada rango de edad.

Los subtítulos también pueden enriquecerse con más información, por ejemplo con un glosario (podría ser un enlace que pausa el contenido principal y permite acceso al material explicativo). Proporcionar información relevante adicional permite mejorar la comprensión de los elementos esenciales tanto para los usuarios de productos de apoyo como para las personas con dificultad en la lectura.

Interpretación en lengua de signos

La lengua de signos no es universal, por tanto debe adecuarse a la audiencia. Es importante que la cara, los brazos, manos y gestos corporales se vean claramente, con suficiente resolución para que sean legibles. Por otra parte es preferible una persona que un avatar animado, al menos por el momento.

Igual que los subtítulos, pueden ser abiertos (siempre visibles) o cerrados (se puede activar/desactivar su visualización).

No todos los dispositivos podrán manejar múltiples flujos de vídeo, así que este debería ser un requisito del navegador. En las situaciones en las que no se soporte, por ejemplo en dispositivos móviles, los autores podrían ofrecer dos versiones, una de ellas con la interpretación en lengua de signos insertada en el vídeo. La selección de diferentes pistas de lengua de signos se haría de la misma manera que se manejan diferentes subtítulos.

Transcripciones

Hay personas a las que no les es posible o les resulta difícil seguir los subtítulos sincronizados, como las personas sordociegas, las personas con problemas cognitivos o con dificultad en la lectura. Incluso las personas que sí pueden seguirlos podrían perderse información al dividir la atención entre lo que ocurre en pantalla y el texto de los subtítulos.

Por tanto, la transcripción completa ayuda a las personas con diferentes necesidades y no es un sustituto de los subtítulos. La transcripción se puede presentar simultáneamente con el contenido audiovisual, pero debería estar también disponible independientemente.

El contenido que se incluye en la transcripción es tanto el de los subtítulos como el de la audiodescripción (y las opciones interactivas si tiene), y es por tanto una representación completa del material.

Requisitos del sistema

En este apartado se explica cómo las tecnologías para proporcionar contenido alternativo al vídeo y audio encajan en el panorama más amplio de la accesibilidad, tanto técnicamente desde de un punto de vista del agente de usuario (y que por tanto tiene que ver con los navegadores, los productos de apoyo o los reproductores multimedia) como desde un punto de vista del proceso de producción.

Acceso a los controles y menús interactivos

Todas las posibilidades de interacción deben estar disponibles para todos los usuarios. Por tanto deben ser independientes del dispositivo de entrada (teclado, ratón, habla, etc.) y ser expuestas a los productos de apoyo. Las posibilidades de interacción deben ser lo suficientemente ricas para un control detallado de la reproducción del contenido.

Control del nivel de granularidad para la navegación por la estructura del contenido

Los usuarios deben ser capaces de establecer el rango o alcance de los controles “siguiente” y “anterior” en tiempo real, ajustando en qué nivel de la estructura del contenido quieren navegar con dichos controles.

Modificación de la escala de tiempo

Por ejemplo en muchos reproductores de audiolibros, desde hace años, se puede acelerar o ralentizar la lectura del contenido sin alterar el tono del audio.

Requisitos de la producción y los resultados

En este apartado se habla del desafío que supone la falta de un sistema universal de acceso, la convivencia de sistemas incompatibles, o la falta de formatos comunes que permita el intercambio de datos. Trata también de los recursos que se aportan por separado, pues los contenidos alternativos son a menudo creados por entidades diferentes a las que crean el contenido audiovisual, así como de las posibilidades de edición.

Descubrimiento y activación/desactivación del contenido alternativo por parte del usuario

Se han descrito diferentes tipos de contenido alternativos que permitirán que las personas puedan percibir, interactuar y comprender el contenido audiovisual. Estas alternativas pueden ser parte del contenido, activarse o desactivarse o estar vinculadas al contenido original.

El usuario se enfrenta al reto de poder descubrir y reconocer que se proporcionan estos contenidos alternativos.

Requisitos relativos a hacer que las propiedades estén disponibles para la API de accesibilidad

Los usuarios necesitan acceder a los contenidos, controlar su reproducción y activar las opciones de accesibilidad. Para que los agentes de usuario apoyen la API de accesibilidad implementada para una plataforma, los controles del reproductor tienen que exponer la información, en caso contrario hay que proporcionar la información en formatos alternativos.

Por ello la existencia de pistas de contenido alternativo debe ser expuesta al agente de usuario y la API de accesibilidad debe tener acceso a las mismas.

Requisitos sobre el uso del visor de vídeo

El visor de vídeo juega un papel importante en lo que se refiere a los contenidos alternativos. Ofrece una caja delimitada para muchas de las alternativas que se ofrecen visualmente (subtítulos, lengua de signos, etc.), aunque no todas se basan en una ventana (como las transcripciones completas).

Hay que recordar que un tercio del vídeo será ocupado por el texto de los subtítulos. Los usuarios esperan encontrarlos en un lugar estándar y poder hacer movimientos oculares rápidos entre los mismos y el contenido del vídeo. Por tanto no se debe ocupar este espacio con otras cosas y se debe evitar la superposición con el contenido importante del vídeo.

Los requisitos de este apartado también hacen referencia a la relación entre el tamaño de la ventana de visualización, la posición de contenido audiovisual y la del contenido alternativo.

Por último se tratan las opciones de personalización por parte del usuario: del brillo y el contraste; de las características del texto (por ejemplo de los subtítulos) tamaño, color, etc.; o el ajuste del tamaño de visualización pero preservando la relación y evitando recortes.

Requisitos sobre las pantallas secundarias y otros dispositivos

El término “second screen” hace referencia a que cuando vemos o consumimos contenido (por ejemplo en la televisión), la información contextual adicional o el propio contenido se puede visualizar en un dispositivo complementario (como una tablet o un móvil). Se llama “second screen” a pesar de que puede haber más de dos y a pesar de que no todos los dispositivos secundarios son pantallas de vídeo.

Hay que asumir que muchos usuarios tendrán un dispositivo de visualización adicional y/o un dispositivo de audio adicional (como unos auriculares) conectado al dispositivo de visualización principal. Por tanto debe ser posible configurar ciertos tipos de contenidos para su presentación en dispositivos específicos.

Checklist de los Requisitos de Usuario para la Accesibilidad de los Medios Audiovisuales

Este es un apartado muy útil porque recoge la checklist con todos los requisitos listados en el documento.

La checklist está en formato tabla, con una fila para cada requisito y diversas columnas para indicar:

  • su categorización respecto a la tecnología (si ya está en la especificación de HTML 5, si es un nuevo requisito de la especificación, etc.)
  • su relación con criterios de conformidad de las WCAG y las UAAG. Cuando se incluye el signo “+” se está indicando que el requisito de este documento se define con más precisión que en las WCAG o en las UAAG. De hecho, el grupo de trabajo de las UAAG (se está trabajando en las UAAG 2.0 actualmente) ha indicado que revisarán algunos de sus requisitos en base a esta checklist.
  • su prioridad (Must, Should o May)

 

Actualmente, está en borrador una versión actualizada de este documento.

 

Accesibilidad web: Problemas con el foco de teclado

En esta entrada voy a hablar de un problema bastante habitual en los sitios web. Hay personas que navegan por un sitio web a través de teclado, porque no ven. Al carecer de visión no pueden llevar a cabo el manejo del ratón y la visualización de la pantalla para poder dirigir el puntero.

 

Accesibilidad web: Problemas con el foco de teclado

Navegación por el sitio web a través de teclado

Para muchas personas este el único medio que tienen poder acceder a los sitios web:

  • Personas que usan un lector de pantallas o teclado braille.
  • Personas con diversidad funcional física o motriz, que pueden usar:
    • teclados alternativos.
    • Licornios, punteros de cabeza o apuntadores de boca para interactuar con el teclado.
    • Pulsadores de soplado que simulan la navegación por teclado.
  • Usuarios expertos que se manejan más rápido por teclado que con el ratón.
  • Personas que usan un portátil, que prefieren la navegación por teclado, o cuando existe un problema que impide usar el ratón.

Accesibilidad por teclado

Las WCAG 2.0 tienen varios criterios que hacen referencia a la operabilidad de los sitios web mediante el teclado.

teclado

2.1 Accesible por teclado

  • 2.1.1 Teclado Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requiera una determinada velocidad para cada pulsación individual de las teclas, excepto cuando la función interna requiere de una entrada que depende del trayecto de los movimientos del usuario y no sólo de los puntos inicial y final. (Nivel A)
  • 2.1.3 Teclado (sin excepciones): Toda la funcionalidad del contenido se puede operar a través de una interfaz de teclado sin requerir una determinada velocidad en la pulsación de las teclas. (Nivel AAA)

 

Problemas con el foco de teclado

Hay varios problemas que impiden la navegación por los sitios web y que están relacionados con el foco de teclado. Estos problemas son:

  • El foco no está visible
  • El orden del foco no tiene sentido
  • Las páginas tienen trampas para el foco
  • Recibir el foco provoca automáticamente un cambio de contexto sin avisar al menos previamente al usuario.

1. El foco no está visible

Por defecto, cuando un enlace coge el foco aparece punteado alrededor.  O cuando un campo de formulario coge el foco también se aprecia visualmente, es decir, muestra un cursor parpadeando en su interior. El criterio de conformidad que recoge este problema es el 2.4.7 Foco visible.

El problema está en que hay sitios web en los que por razones estéticas, el foco no se encuentra visible, lo cual dificulta la navegación a muchos usuarios. Por lo tanto, el foco debe estar visible en todo momento.

El foco puede resaltarse con un borde más sólido y de color. Y usarse con la pseudoclase :hoveren la CSS y así resalta también con la interacción mediante ratón.

 

2. El orden del foco no tiene sentido

Otro de los problemas es que el orden del foco no tenga sentido. Por eso, es muy importante que el orden del foco sea el correcto, tal y como establece el criterio 2.4.3 de las WCAG 2.0.

Por ejemplo, si un enlace abre un menú desplegable, el siguiente elemento que debería coger el foco sería el primer elemento del menú.

No  sólo es necesario que el orden de lectura sea lineal y tenga sentido, sino también que el orden del foco por los elementos de interacción también lo tenga. De igual manera ocurre con el atributo global tabindex.

 

3. Trampas para el foco

El tercer problema que nos encontramos son las trampas para el foco. Son aquellas zonas a las que no podemos llegar mediante teclado, como son las ventanas modales o cuadros de diálogo, los controles de un reproducción de un vídeo o una animación en Flash. En estas interacciones sólo se puede volver atrás o ir a otra parte mediante el ratón.

Tal y como se puede leer en el criterio de conformidad 2.1.2 Sin trampas para el foco de teclado, vamos a seguir con el ejemplo del menú desplegable.

Si una vez que abrimos el menú, navegamos con la tecla TAB, y por cualquier razón no podemos volver a salir con el teclado, se consideraría una trampa para el foco.

 

4. Recibir el foco provoca un cambio de contexto

Otro de los problemas que se pueden dar es cuando se produce un cambio de contexto y reciben el foco sin advertir previamente al usuario.

Los cambios de contexto deberían producirse cuando el usuario realiza una acción, que normalmente se utilice para solicitar un cambio de contexto, como hacer clic en un enlace o un botón.

Los cambios inesperados en el contexto o que no puedan detectarlos pueden desorientar a los usuarios.

¿Qué es un cambio de contexto?

Es un cambio importante en el contenido de la página, que cuando se hace sin el consentimiento del usuario, puede desorientar a quienes no pueden ver la página o no pueden ver toda la página al mismo tiempo.

Esto incluye cambios en:

  • El agente de usuario. Como abrir un gestor de correo o un lector de PDF.
  • El foco: Mover automáticamente el foco a otro elemento. Una mala práctica muy habitual en los formularios es mover el foco de un control a otro automáticamente, por ejemplo al rellenar los campos de una cuenta bancaria. También es una mala práctica habitual utilizar  onfocus="blur()"para quitar el foco a un elemento cuando lo recibe.
  • El área de visualización del contenido: abrir otra ventana, otra pestaña o cambiar de marco.
  • El contenido. Cambios en el contenido que cambian el significado de la página: enviar un formulario, ir a otra página, o que lo parezca porque se cambia el orden del contenido de la misma.

Los criterios relacionados con este problema son:

3.2.1 Al recibir el foco

3.2.2 Al recibir entradas

3.2.5 Cambios a petición

 

Accesibilidad web: Las WCAG 2.1

El pasado 5 de junio, el W3C estableció como recomendación las WCAG 2.1, tras más de 10 de la publicación de las WCAG 2.0.

Accesibilidad web: WCAG 2.1

Introducción

Antes de empezar, me gustaría aclarar una cosa:

Un sitio web que aplique las WCAG 2.1 también cumple con las WCAG 2.0.

La novedad, es que los criterios ya no están ordenados por su nivel de conformidad. Para no cambiar el número de criterio a los criterios existentes, los nuevos siempre se han añadido al final de los actuales.

Para ello, hay una guía de referencia y ayuda, que permite filtrar los criterios por nivel, ya sea de las WCAG 2.0 o WCAG 2.1.

Filtro para los criterios en las WCAG 2.1

WCAG 2.1.

Como ya veníamos comentando desde hace unos meses, existen 17 nuevos criterios de conformidad, que son los siguientes:

 

Criterio 1.3.4: Orientación.

“El contenido no restringe su vista y funcionamiento a una única orientación de visualización, como vertical u horizontal, a menos que una orientación de visualización específica sea esencial.”

Este criterio hace referencia a que los sitios web deben admitir las dos orientaciones disponibles para que se pueda adaptar a todo tipo de usuarios, y asegurarse de que el contenido y la funcionalidad de la web estén disponibles. El contenido debe ser operable en todas las orientaciones de pantalla.

Criterio 1.3.5. Identificar el propósito de la entrada.

El propósito de cada campo que recoge información del usuario se puede determinar por software cuando:

  • el campo tiene un propósito identificado y concreto de los listados en el apartado 7. Input Purposes for User Interface Components (“name”, “country”, “postal-code”, etc.), cuya lista está basada en la de HTML 5.2 Autofill field section. Y
  • el contenido está implementado usando una tecnología con soporte para identificar el significado esperado del dato introducido en un campo de formulario.

Este criterio ayuda a que sea más fácil rellenar los campos de formularios, según las necesidades y las preferencias de los usuarios.

La técnica suficiente incluida es utilizar autocomplete con los atributos definidos en HTML 5.2 Autofill field section.

Criterio 1.3.6 Identificar el propósito.

“En el contenido implementado utilizando lenguaje de marcas, el propósito de los componentes de la interfaz de usuario, los iconos y las regiones se puede determinar mediante programación.”

Tiene el mismo objetivo que el criterio anterior en cuantro a las preferencias y necesidades de los usuarios. Por ejemplo, si se identifica que es un botón para enviar un email, este tipo de botón se podrá personalizar con un icono o un término comprensible para un usuario en particular; se podrá mostrar ayuda relacionada con esa función, renderizarlo más grande, etc.

Las técnicas suficientes que se incluyen son: agregar semántica a los elementos usando landmark roles ARIA.

Como técnicas recomendables se incluyen: el uso de los atributos ARIA aria-invalid y aria-required en los campos de formulario.

1.4.10 Reflow

“El contenido puede presentarse sin pérdida de información o funcionalidad y sin necesidad de hacer scroll en dos dimensiones*, para:

  • Contenido con desplazamiento vertical con un ancho equivalente a 320 píxeles CSS;
  • Contenido con desplazamiento horizontal con una altura equivalente a 256 píxeles CSS;

*excepto para partes del contenido que lo requieran para su uso o significado.

En las notas se indica que, 320 píxeles CSS es equivalente a un viewport width inicial de 1280 píxeles CSS con un zoom de 400%. Para el contenido diseñado para escrolar horizontalmente, 256 píxeles CSS es equivalente a un viewport height inicial de 1024px con un zoom de 400%.

Los contenidos que pueden requerir doble scroll son: imágenes, mapas, diagramas, vídeo, juegos, presentaciones, tablas de datos, o interfaces donde es necesario mantener las barras de herramientas a la vista mientras se manipula el contenido.

Este criterio asegura que se puede hacer zoom de 400% sin pérdida de contenido o funcionalidad y se evitan los dobles scroll (salvo en los casos citados), pues el impacto del desplazamiento horizontal aumenta el esfuerzo de lectura 40-100 veces.

Las técnicas suficientes que se incluyen son: usar media queries y CSS grids o CSS Flexbox para reajustar los contenidos. Y también, calcular por programación los tamaños y posiciones de los elementos de manera que escalen con el tamaño del texto.

Como técnicas recomendables se incluyen: ajustar el tamaño de las imágenes y las tablas al viewport; y dar un mecanismo que permita cambiar a la vista móvil en cualquier momento.

Como errores comunes se nombran: usar tamaños y posiciones fijas; impedir el zoom; y usar texto preformateado o tratarlo como una excepción.

1.4.11 Contraste no textual

“La presentación visual de los siguientes elementos tiene una ratio de contraste de al menos 3:1 respecto a los colores adyacentes:

  • Componentes de la interfaz de usuario: información visual utilizada para identificar los componentes de la interfaz de usuario y los estados, excepto para componentes inactivos o cuando la apariencia del componente es determinada por el agente de usuario y el autor no la modifica.
  • Objetos gráficos: partes de los gráficos necesarias para comprender el contenido, excepto cuando una presentación particular de los gráficos es esencial para la información que se transmite (esencial como por ejemplo en los logotipos o en las banderas, en una captura de un sitio que muestra cómo es su apariencia, en un mapa de calor, en un diagrama médico que usa los colores utilizados en biología, etc.)

 

El criterio 1.4.3 solo abarca “la presentación visual de texto e imágenes de texto” y por tanto el criterio 1.4.11 lo complementa, porque el contraste sería también necesario para:

  • los iconos (que no van con texto)
  • los gráficos, por ejemplo, cada una de sus líneas
  • el borde o límites visuales de un campo de formulario o botón, siempre que no estuviera disabled
  • el indicador visual del valor actual en un control deslizante
  • el indicador del foco
  • etc.

Las técnicas suficientes para las gráficas son: que el contraste entre los colores de las gráficas sea suficiente así como el contraste de las líneas entre colores adyacentes.

Las técnicas suficientes para los textos de las gráficas son: que se incluyan en las gráficas etiquetas y valores; que las imágenes que transmiten información y los textos de las gráficas tengan suficiente contraste; o que haya un control con suficiente contraste que permita a los usuarios cambiar a una presentación que utilice suficiente contraste.

Como técnica recomendable, en el caso de los enlaces y controles que solo se identifican por el color, sería un ratio de contraste de 4,5:1 con el texto de alrededor y pistas visuales adicionales.

1.4.12 Espaciado de texto

El contenido implementado con lenguaje de marcas que soporte las siguientes propiedades, no se pierde contenido o funcionalidad ni por configurarlas, ni por no cambiar ninguna otra propiedad de estilo:

  • altura de línea (espaciado entre líneas): al menos 1.5 veces el tamaño de fuente
  • espaciado debajo de los párrafos: al menos 2 veces el tamaño de fuente
  • espaciado de letras (tracking): al menos 0.12 veces el tamaño de fuente
  • espaciado de palabras: al menos 0.16 veces el tamaño de fuente

 

La técnica suficiente que se incluye es: el espaciado del texto se pueda cambiar, siendo un error habitual usar medidas fijas.

Como técnicas recomendables se indican: usar las propiedades CSS letter-spacing, line-height y definir el tamaño de los contenedores en em

1.4.13 Contenido en Hover o Foco

Cuando el contenido se hace visible/oculto porque un componente de la interfaz coge/pierde el foco, lo siguiente es verdad:

  • Dismissable. Hay un mecanismo disponible para descartar el contenido adicional sin mover el puntero o el foco del teclado, a menos que el contenido adicional comunique un error en la entrada de datos, o no tape o reemplace otro contenido.
  • Hoverable. Si el puntero del cursor puede activar el contenido adicional, entonces el puntero se puede mover sobre el contenido adicional sin que desaparezca el contenido adicional.
  • Persistent. El contenido adicional permanece visible hasta que la activación del hover/focus se elimine, el usuario lo descarte o su información ya no sea válida.

 

Algunos ejemplos de contenidos a los que SÍ se aplica este criterio son: tooltips personalizados, submenús, pop-ups no modales que se muestran en el hover o en el focus, etc.

Las técnicas suficientes que se incluyen son: el uso de las pseudo-clases hover y focus.

Como técnicas recomendables: no escondas los elementos que desencadenan los cambios; y no escondas los nuevos mensajes cuando se haga hover sobre ellos, o hasta que el usuario los descarte o sean incorrectos.

2.1.4 Atajos de teclado de caracteres

si se implementa un atajo de teclado en el contenido usando una letra (incluidas mayúsculas y minúsculas), signo de puntuación, número o símbolo, entonces al menos una de las siguientes afirmaciones es cierta:

  • Desactivar: hay un mecanismo para desactivar el atajo.
  • Reasignar: hay un mecanismo para reasignar ese atajo de teclado, usando uno o más caracteres de teclado no imprimibles (Alt, Ctrl,…)
  • Activo solo en el foco: el atajo de teclado de un componente de la interfaz solo está activo cuando ese componente tiene el foco.

 

Este criterio tiene relación con los atajos de teclado personalizado.

Beneficia a los usuarios que utilizan programas de reconocimiento de voz que pueden activar varios atajos accidentalmente cuando estos están asociados a una sola tecla.

También puede evitar errores. El usuario de teclado puede pulsarla sin querer, especialmente aquellos que tienen problemas de movilidad.

Las técnicas suficientes se incluyen son: que los usuarios tengan una forma de desactivar los atajos de teclado de un solo carácter, o que exista un mecanismo que permite a los usuarios modificar los atajos de teclado y reasignarlos a caracteres no imprimibles.

2.2.6 Tiempos de espera

Se debe advertir a los usuarios de la duración de cualquier inactividad del usuario que pueda causar la pérdida de datos, a menos que los datos se conserven durante más de 20 horas cuando el usuario no realiza ninguna acción.”

2.3.3 Animación de interacciones

“Las animaciones de movimiento desencadenadas por una interacción pueden ser deshabilitadas, a menos que la animación sea esencial para la funcionalidad o la información que se transmite.”

Este criterio se aplica cuando una interacción del usuario inicia una animación inesperadamente.

Esto puede provocar no solo distracción, sino incluso en algunos usuarios con desorden vestibular, nauseas y dolores de cabeza.

Las técnicas suficientes que se incluyen son: que los usuarios puedan definir en sus preferencias que no haya animaciones.

2.5.1 Gestos del puntero

“Toda funcionalidad que usa gestos multipunto o basados en una trayectoria, puede ser operada con un solo gesto de puntero (single pointer) sin depender de un gesto basado en una trayectoria, a no ser que sea esencial un gesto multipunto o basado en una trayectoria.”

iconos-del-gesto-fijados-para-los-dispositivos-móviles-del-tacto

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes que se incluyen son: no basar la interacción solo en recorridos gestuales o en varios toques, ofrecer controles alternativos que permitan realizar la misma función pero que no requieran gestos complejos.

2.5.2 Cancelación del puntero

“Para la funcionalidad que se puede operar con un puntero único, al menos una de las siguientes afirmaciones es verdad:

  • No Down-Event: el down-event del puntero no se usa para ejecutar ninguna parte de la función
  • Abort or Undo: la finalización de la función está en el up-event, y hay un mecanismo disponible para abortar la función antes de completarse o deshacer la función una vez completada
  • Up Reversal: el up-event invierte cualquier resultado del down-event anterior.
  • Essential: completar la función en el down-event es esencial

 

“Down-event”, es cuando se presiona el dedo contra la pantalla.

Este criterio se aplica al contenido web que interpreta las acciones del puntero, es decir, no se aplica a las acciones que se requieren para operar el agente de usuario o el producto de apoyo.

Las técnicas suficientes se incluyen son: la activación de los controles en el up-event en HTML, iOS y Android; y que los eventos táctiles solo son activados cuando el toque se retira del control.

Como error a evitar, no actives un control en un down-event si el evento up-event no coincide con la misma localización del puntero.

2.5.3 Etiqueta en Nombre

“Para los componentes de la interfaz de usuario con etiquetas que incluyen texto o imágenes de texto, el nombre accesible contiene el texto que se presenta visualmente. Y añade en una nota que una buena práctica es poner el texto de la etiqueta al comienzo del nombre.”

Si la etiqueta visible no es igual que la etiqueta no visible (el nombre accesible) los usuarios que acceden con programas de reconocimiento de voz pueden tener problemas. Hay que tener en cuenta que estos usuarios pueden decir el menú, el vínculo o la etiqueta del botón para activarlos.

Para los usuarios que utilizan un lector de pantalla pero visualizan la pantalla, también es mucho más claro que el nombre accesible que se les anuncia coincida con la etiqueta visual.

La técnica suficiente que se incluye es que las etiquetas visibles concuerden con los nombres accesibles.

Como técnica recomendable, si un icono no va acompañado de un texto, usa su texto “hover” como nombre accesible.

Los errores habituales que se listan:

  • El nombre accesible no contiene el texto visible de la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero las palabras de la etiqueta visible no están en el mismo orden.
  • El nombre accesible contiene el texto de la etiqueta visible, pero una o más palabras se entremezclan en la etiqueta.
  • El nombre accesible contiene el texto de la etiqueta visible, pero hay una o más palabras adicionales antes del texto de la etiqueta visible.

2.5.4 Actuación de movimiento

Toda funcionalidad que puede ser operada por el movimiento del dispositivo o por el movimiento del usuario, también puede ser operada mediante los componentes de la interfaz de usuario, y la respuesta al movimiento se puede desactivar para evitar el accionamiento accidental.

Incluye dos excepciones:

  • Supported Interface: el movimiento se utiliza para operar la funcionalidad a través de una interfaz compatible con la accesibilidad.
  • Essential: el movimiento es esencial para la función o si no se invalidaría la actividad.

Este criterio hace referencia a los sensores del dispositivo que detectan y responden a algún tipo de entrada del entorno físico. Por ejemplo, un movimiento como agitar el móvil, inclinar la tablet, etc.

Este criterio no se aplica a los sensores de geolocalización, ni a los movimientos que no sean movimientos intencionales del usuario, ni a los asociados al uso del teclado, el puntero o productos de apoyo.

Las técnicas suficientes que se incluyen son: proporcionar formas alternativas de introducir información cuando se usan los sensores de movimiento para activar funcionalidades y contenidos; y que el usuario pueda desactivar la actuación por movimiento.

2.5.5 Tamaño de la región de pantalla

Define que el tamaño mínimo del “target” (región de la pantalla que acepta la acción del puntero) debe ser 44×44 píxeles CSS.

Incluye ciertas excepciones:

  • Equivalent. Si el target está disponible a través de un enlace o un control equivalente, en la misma página, que tiene al menos 44×44 píxeles CSS.
  • Inline. Si el target está en una frase o en un bloque de texto.
  • User agent control. Si la apariencia del target es determinada por el agente de usuario y no es modificada por el autor.
  • Essential. Si una presentación particular del target es esencial para la información que se transmite.

 

El tamaño 44×44 que se define es el mínimo, pero se recomienda utilizar tamaños mayores, esto es especialmente importante en los siguientes casos:

  • El control se usa con frecuencia.
  • El resultado de la interacción no se puede deshacer fácilmente.
  • El control está situado en un lugar que será difícil de alcanzar o está cerca del borde de la pantalla.
  • El control es parte de una tarea esencial.

 

Las técnicas suficientes que se incluyen son: que las áreas interactivas tengan al menos 44*44px; y ofrecer un mecanismo que permita cambiar el tamaño de las áreas.

Como técnica recomendable, el área interactiva de un párrafo que es un enlace también tiene al menos 44*44px.

2.5.6 Mecanismos de entrada concurrentes

“El contenido web no restringe el uso de las modalidades de entrada (teclado, interfaz de teclado, ratón, pantalla táctil, habla, etc.) disponibles en una plataforma, excepto cuando la restricción es esencial, necesaria para garantizar la seguridad del contenido o respetar la configuración del usuario.”

En la mayoría de los dispositivos, es posible que los usuarios cambien entre diferentes medios de entrada de datos en la misma sesión (por ejemplo, entre pantalla táctil y teclado).

La aplicación o sitio web no debe asumir que el usuario siempre utilizará exclusivamente un mecanismo de entrada particular, y deberá permitir a los usuarios operar con cualquier mecanismo de entrada a su disposición.

Las técnicas suficientes que se incluyen son: usar solo manejadores de evento JS de alto nivel, independientes de la modalidad de entrada (focus, blur, click); o incluir manejadores de evento redundantes para las diferentes modalidades de entrada.

4.1.3 Mensajes de estado

“en el contenido implementado mediante lenguaje de marcas, los mensajes de estado pueden ser determinado por software a través de roles y propiedades, de modo que puedan ser presentados a los productos de apoyo sin recibir el foco.”

Se debe proporcionar una notificación para cada cambio del contenido de la página. No se trata tanto de que se vean esos mensajes, sino de que sean anunciados por el lector de pantalla. Esto se hace con el atributo aria-live de ARIA y sus roles específicos.

Los mensajes serán del tipo: “El formulario se ha enviado correctamente”

Las técnicas suficientes que se incluyen son:

  • Si el mensaje de estado advierte del éxito o el resultado de una acción o el estado de una aplicación: se usa role="status", informando de que el datos se ha enviado correctamente.
  • Si el mensaje de estado transmite una sugerencia o una advertencia ante la existencia de un error: se usa role=alert, en combinación con alguna de otras técnicas ya existentes como dar una descripción textual para identificar los campos requeridos no completados, así como los campos con valores o formatos no permitidos; permitir saltar a los errores; dar sugerencias de corrección o proporcionar una revisión ortográfica y sugerencias para la entrada de datos.
  • Si el mensaje de estado transmite información sobre el progreso de un proceso: se usa el role="log", role="progressbar" o role="status"

 

Nota adicional: 5.2.2 Páginas completas.

Este requisito de conformidad trata de que una página es conforme si es conforme en su totalidad, lo cual incluye las alternativas a las que enlaza (como por ejemplo una página con descripciones extensas de imágenes o con presentaciones alternativas de un vídeo).

Esta nota añade que las distintas variaciones de la página, como las generadas automáticamente para diferentes resoluciones de pantalla, también forman parte de esa página y deben ser conformes todas ellas.