Usabilidad web: 100 tips de diseño UX para la experiencia de usuario

Introducción

En este artículo titulado Top 100 UX Design Tips from a User Experience Master se nos facilita 100 tips relacionados con la experiencia de usuario. Los resumiré y los organizaré en diferentes secciones aprovechando la clasificación que el mismo autor ha realizado en su artículo.

Es un artículo muy interesante escrito por Andrew Kucheriavy, un reconocido visionario con experiencia funcional en desarrollo web, marketing, e-commerce y desarrollo de negocios.

100 tips de diseño para la experiencia de usuario

Flujo

1. Mover a los usuarios de una sección a la siguiente sin problemas. Para ello es necesario comprender sus objetivos y sus necesidades.

2. Los usuarios son más propensos a notar los elementos cerca de la partesuperior de la página en orden de importancia. Por lo que debemos situar ahí lo que queremos que antes llegue a la persona usuaria.

3. Las interfaces web consistentes y fáciles de usar ayudan a los usuarios a concentrarse en el contenido y moverse a través de él.

4. Evita crear páginas sin salida en sitios web. Causan confusión y crean trabajo adicional para los usuarios.

5. Usar patrones e interfaces de sitios web comunes. Siempre puede ser más arriesgado que las personas usuarias tengan que aprender algo nuevo.

Scrolling

6. Las personas usuarias se desplazarán hacia abajo en la página web, siempre que quede claro que hay información relevante adicional más abajo, por lo tanto,

7. El sitio web deberá proporcionar una fuerte indicación visual de la dirección del desplazamiento y si hay más contenido disponible.

8. Cuanto más larga es la página del sitio web, menos probable es que alguien se desplace hacia abajo hasta el final.

9. El scroll en las páginas web es agradable porque siempre es más rápido que hacer clic. Pero hay que tener cuidado y no hacer que las páginas sean demasiado largas.

Contraste y color

10. Diseño para usuarios con daltonismo. Convierta sus diseños a escala de grises para garantizar que todos los usuarios puedan leer información importante Haga clic para tuitear

11. No use el color azul para ningún texto en sitios web que no sean enlaces.

12. Sé consciente del contraste en los sitios web móviles. El brillo de la pantalla puede inutilizar su sitio web.

13.
Reserve un color para las llamadas a la acción en su sitio web y no lo use para nada más.

14. Los colores cálidos y brillantes se acercan y los colores fríos y oscuros permanecen en el fondo.

Tiempo de carga

15. Asegúrese de que los usuarios del sitio web puedan completar su objetivo principal de forma rápida y sencilla.

16. Lo que más importa a los usuarios es que su sitio web se sienta rápido (incluso si es solo su percepción)

17. La percepción de la velocidad del sitio web se basa en el tiempo de carga, el comportamiento de la carga, los tiempos de espera y la suavidad de las animaciones.

18. Muestre un esqueleto de los elementos del sitio web para comunicar el diseño cuando se está cargando

19. El texto del sitio web debe cargarse antes de las imágenes para que los usuarios puedan comenzar a leer antes de que se cargue el resto del sitio.

20. Los retrasos de más de varios segundos a menudo harán que los usuarios abandonen el sitio web.

Móvil

21. Los elementos de la interfaz móvil son difíciles de tocar con precisión si son pequeños o están juntos.

22. El tamaño mínimo para un objetivo táctil en los móviles debe ser de 1 cm x 1 cm con el relleno adecuado.

23. Alguien que usa un dedo meñique en el sitio web o la aplicación móvil significa que los objetivos de la interfaz son demasiado pequeños.

24. Al sostener una tableta, los lados y la parte inferior de la pantalla se alcanzan más fácilmente con el pulgar.

25. No requiere deslizar verticalmente para nada que no sea el desplazamiento normal de la página.

26. No uses dobles toques en dispositivos móviles. Asegúrate de que los usuarios puedan interactuar con un solo toque.

27. Determine si los usuarios usarán dispositivos con una mano o con dos al diseñar diseños móviles.

Navegación

28. Siempre tenga una forma obvia de acceder al menú de navegación en su sitio web Haga clic para twittear

29. Si la jerarquía de su sitio web tiene más de 3 a 4 niveles de profundidad, es hora de rediseñar.

30. Considere utilizar menús fijos, especialmente en páginas web más largas o cuando se necesite un acceso rápido.

31. La buena navegación del sitio web no está en el camino, desaparece en el fondo.

32. Haz que tu navegación sea consistente; No debería cambiar en todo el sitio web.

33. Haga que las etiquetas de navegación sean específicas, de no más de 2 o 3 palabras y comience con la mayor cantidad de información que contenga la palabra.

34. Permita que los usuarios sepan dónde se encuentran en el sitio web mediante el uso de rutas de navegación

35. Navegación móvil: muestra las opciones más utilizadas y oculta las demás en un menú de hamburguesas.

36. Los menús de hamburguesas en los escritorios son menos perceptibles, menos familiares, aumentan los costos de interacción y disminuyen el olor de la información.

37. Para la navegación secundaria en dispositivos móviles, utilice las páginas de aterrizaje, submenús o menús de la página.

38. Los menús desplegables del menú deben ser verticales, no horizontales; Es mucho más difícil desplazarse horizontalmente.

39. Megamenus debe ser más angosto que la página para que sea fácil «hacer clic» en ellos.

40. Si usa megamenus, organice los enlaces en grupos y distinga entre elementos en los que se puede hacer clic y no en los que se puede hacer clic.

41. No esconda las funciones de inicio de sesión o búsqueda dentro de los menús del sitio web.

Formularios

42. Alinee las etiquetas de formulario y los campos en una sola línea vertical para permitir un escaneo rápido.

43. Las etiquetas de los campos deben estar fuera del campo de texto, no adentro, para que los usuarios no los pierdan.

44. Divida las secciones con separadores para hacer que los formularios web largos sean más fáciles de usar.

45. Coloque los errores de formulario junto a los campos que causan errores en todos los formularios web.

46. ​​Los mensajes de error deben ser útiles, utilizables, concisos y fáciles de entender.

47. Muestre todos los campos que causan errores a la vez, al lado de cada campo problemático para que los usuarios móviles no se pierdan la advertencia

Enlaces

48. Los enlaces en los sitios web deben sobresalir: use el texto en azul y / o el subrayado para indicar los hipervínculos.

49. Los enlaces siempre deben verse como enlaces.

50. Un usuario no debería tener que hacer clic en un enlace para averiguar a dónde conduce. El texto del enlace debe indicarles a dónde van.

51. No use texto azul ni subrayado para elementos no vinculados en sitios web o aplicaciones.

52. Una referencia a una URL completa en cualquier parte de un sitio web siempre debe enlazar a esa página.

53. Ciertos elementos, como imágenes de productos o reseñas, siempre se espera que se puedan hacer clic.

54. Use un color diferente para los enlaces visitados en los sitios web para reducir la carga de memoria de los usuarios.

Botones

55. Los botones de los sitios web deben tener un aspecto seleccionable y tener suficiente espacio para que los usuarios hagan clic o toquen cómodamente.

56. Las acciones frecuentes en sitios web o aplicaciones deben ser botones grandes, colocados en zonas de fácil acceso.

57. Los colores de fondo, los bordes y las etiquetas orientadas a la acción en un sitio web indican a los usuarios que se puede hacer clic en un elemento.

58. Para diseños planos, asegúrese de que los botones de acción se realicen en un color de contraste con una etiqueta orientada a la acción.

59. Un sitio web debe tener una indicación visual de que el clic del botón se realizó correctamente a los 0,1 segundos de la interacción.

60. Los botones que cambian o eliminan datos en los dispositivos móviles deben requerir un mayor esfuerzo para tocar y evitar tocar accidentalmente.

Búsqueda

61. A menos que tenga un sitio web muy pequeño con poco contenido, siempre tenga un campo de búsqueda

62. El campo de búsqueda siempre debe verse como un cuadro de texto en un escritorio. El ícono de búsqueda está bien para usar en dispositivos móviles

63. Haz que el campo de búsqueda sea fácil de encontrar. Los usuarios suelen buscarlo en la esquina superior derecha.

64. Al buscar búsquedas en sitios web, los usuarios suelen buscar un «pequeño cuadro para escribir».

65. Los campos de búsqueda en los sitios web deben ser lo suficientemente amplios como para ver la consulta de búsqueda completa.

Carruseles

66. Evite los carruseles: cada nueva diapositiva borra la memoria de la diapositiva anterior. Los usuarios solo pueden centrarse en una cosa a la vez.

67. Es difícil ver los puntos en los carruseles en los sitios web móviles. Usa imágenes que se asoman desde la izquierda y la derecha.

68. En lugar de las flechas de navegación del carrusel, use etiquetas descriptivas para que los usuarios sepan qué esperar en la siguiente diapositiva.

69. Solo alrededor del 1% de los usuarios hacen clic en diapositivas de carrusel en sitios web, así que no confíe en esos clics.

70. Los carruseles de sitios web que se deslizan automáticamente deben cambiar al manual una vez que los usuarios interactúen con ellos.

Acordeones

71. Use acordeones para comprimir el contenido extenso de los sitios web móviles.

72. Al usar acordeones, ofrezca una forma de contraer cualquier contenido expuesto una vez que el usuario lo haya expandido.

73. Ventajas del uso de acordeones en sitios web para dispositivos móviles: las páginas más cortas son más fáciles de usar que los enlaces de salto en la página.

74. Contras de usar acordeones en sitios web móviles: aumento del costo de interacción; Fuera de la vista está fuera de la mente.

Ayuda

75. El propósito principal de cada página web debe ser obvio para el usuario.

76. Los usuarios son reacios a utilizar la Ayuda en su sitio web. Póngalo en contexto y ofrezca asistentes y preguntas frecuentes cuando sea apropiado Haga clic para twittear

77. Muestre sugerencias sobre sitios web y aplicaciones en contexto y solo cuando sea necesario Haga clic para twittear

78. La ayuda y las instrucciones deben ser breves y visualmente diferentes de otros elementos de la interfaz.

79. Solo presente una sugerencia a la vez en sitios web y aplicaciones móviles. Esto reduce la carga de memoria.

Iconos

80. Los iconos deben describir visualmente su función y propósito. Haz que sean simples, familiares y significativos.

81. Los iconos solo deben usarse cuando sea necesario. Evite abusar de ellos y no los use simplemente como decoración.

Contenido

82. La información más importante en su página web siempre debe destacarse como la más visible visualmente.

83. Poner la información clave primero. Los usuarios comienzan en la parte superior izquierda y las primeras 2-3 palabras son las que más se escanean.

84. Coloque el contenido de alta prioridad en la parte superior de la página del sitio web. Use la analítica para determinar las prioridades en diferentes dispositivos.

85. Use el contraste de color y tamaño en su sitio web para diferenciar la información principal de los detalles de apoyo.

86. Las prioridades, como el contexto, la ubicación y la información de emergencia, son más importantes para los usuarios móviles.

87. Prioridades para dispositivos móviles: ubicación, eventos, número de teléfono, información de emergencia, información sensible al tiempo e información necesaria sobre la marcha.

88. Los términos simples y obvios son mejores que la jerga de la industria o los términos modernos para la navegación de sitios web.

Legibilidad

89. La mayoría de los usuarios escanean primero y leen después. Use variedad visual y texto significativo para facilitar el escaneo.

90. La legibilidad no se trata solo de si puedes leer algo, sino también de si quieres leerlo.

91. Use un mayor espacio entre las listas con viñetas, listas numeradas, líneas y párrafos para mejorar la legibilidad.

92. Al elegir la fuente de un sitio web, considere su legibilidad, legibilidad, pesos y estilos.

93. En sitios web y aplicaciones móviles, considera aumentar la altura x de una fuente para mejorar su legibilidad.

94. Evite las fuentes pequeñas en todos los dispositivos, especialmente para copias de formato largo. No use fuentes condensadas en el texto del cuerpo.

95. Asegúrese de que el tamaño del texto de los titulares en un sitio web móvil sea tan receptivo como el resto del contenido.

96. Aumente el tamaño de la fuente en los sitios web para dispositivos móviles: siempre escale el tamaño de la fuente al tamaño de la pantalla.

97. Ceguera a los banners: los usuarios se esfuerzan por no mirar nada que se parezca a los banners publicitarios.

98. Haga que los bloques de texto largos sean más fáciles de leer al incluir solo una idea por párrafo.

99. El texto en cursiva es más difícil de leer, especialmente para los lectores disléxicos.

100. NO USE TODAS LAS CAPS EN SUS TITULARES Y TAGLINES. Es mucho más difícil de leer.

Accesibilidad en videojuegos: Problemas y mejoras

Introducción

Hoy voy a hablar un poco de cómo está el campo de la accesibilidad en los videojuegos. Aunque es un campo relativamente reciente, la tecnología abre muchos caminos y es un campo que va a permitir que muchas personas con diversidad funcional puedan disfrutar del juego como cualquier otra persona, siempre que tengamos los recursos necesarios.

accesibilidad en videojuegos: problemas

Retos que representan la programación de videojuegos

El videojuego es el top de la programación porque es lo que te hace buscar el equilibrio, y te limita muchas cosas: tienes un límite de almacenamiento, de velocidad de procesamiento, de sincronización de audio y vídeo, etc. Todo esto es necesario para que la experiencia de juego y la jugabilidad sea buena para las personas usuarias.

Hay herramientas para llevar a cabo el desarrollo de accesibilidad como Unity, Unreal Engine, Alice, Game Maker, pero el principal problema es que TODAS las interfaces presentan problemas de accesibilidad.

Así que, teniendo en cuenta estos problemas, ha tenido que buscar otras plataformas de desarrollo nativas:

  • Xcode para iOS
  • Eclipse para Android
  • Visual Studio para Windows
  • NDK

Pero aún queda mucho por hacer, y hay muchas cosas que solucionar y aprender.

A continuación, en el video, describe diferentes problemas de accesibilidad para las personas con diversidad funcional visual.

Los diferentes problemas de accesibilidad en los videojuegos son:

  • Uno de los problemas es no hacerlo accesible desde el principio, (que es algo que llevo comentando mucho tiempo, y nunca me cansaré de decirlo).
  • Poder personalizar los colores para personas con dificultades visuales, como el daltonismo, y añadir iconos para diferenciar las cosas.
  • Los programas que se usan para desarrollar videojuegos cuentan con la interfaz inaccesible, así que es recomendable usar plataformas nativas, como ya dije antes.
  • Describir a los personajes correctamente.
  • Limitar el número de respuestas en las descripciones de los personajes, para no marear con tanto contenido a las personas usuarias. Es importante saber que las diversidades funcionales son de muchos tipos, y es muy difícil abarcar las soluciones para todo el mundo, porque hay diversidades funcionales más complejas de entender, como por ejemplo, el autismo y las diversidades funcionales cognitivas. Y ya no es sólo que pueda jugar, sino que pueda seguir el flujo de juego y la jugabilidad.

¿Se podrían hacer todos los juegos accesibles?

Por ejemplo, para las personas ciegas los juegos en primera persona, en la que se requieren muchos enemigos, si tienen muchos personajes y los tienes que describir todos, llega un momento en que se satura y alguna información se pierde.

Habla de que hay opciones alternativas como los guantes hápticos, que emiten vibraciones cuando ocurre algo o tiene que mandar alguna información para avisar a la persona que esté jugando.

guante háptico Gloveone

También está el proyecto Tesla Suit, que consiste en un traje háptico por todo el cuerpo.

Accesibilidad en videojuegos:Tesla_Suit_3

 

En la actualidad, a la hora de jugar los estímulos se hacen mediante la recepción y percepción de la información, es decir, sólo se percibe a través de audio y vídeo como respuesta. Pero con la tecnología Kinect, que dirige el control con la mirada y comandos de voz, es una tecnología muy usada con las personas con parálisis cerebral.

Hace falta tecnología tanto para que las personas usuarias interactúen y para que reciban la información del juego.

En definitiva, el vídeo es muy interesante. Por aquí os dejo la charla de Jonathan Chacón.

 

 

 

Accesibilidad web: ARIA y su composición

¿Qué es ARIA?

Una forma en que podemos usar ARIA es agregándolo a nuestro HTML. Es posible que ya esté familiarizado con los elementos semánticos en HTML, como navegación, botón o encabezado.

Muchos elementos se pueden hacer dinámicos añadiendo JavaScript y teniendo en cuenta la CSS para darle apariencia a cada uno de los elementos.

Pero para las personas que usan lector de pantallas no es tan fácil, y por eso, se aplican los Roles ARIA, que es lo que permite a estas personas saber de qué información se trata. Aquí es donde el navegador expone a la API de accesibilidad la información que es y el lector de pantalla la anuncia a las personas usuarias.

ARIA y su composición

 

Por tanto, ARIA se puede definir como un conjunto de atributos que se añaden a las etiquetas HTML, para que los agentes de usuario (navegadores y productos de apoyo), comprendan el funcionamiento de las etiquetas y actúen de manera consecuente.

Roles ARIA

Los roles ARIA permiten indicar la función de un elemento de la interfaz. Se asigna con el atributo role. Hay 81 roles clasificados por categorías:

  • Abstract: widget, window, section, input, etc. Sirven para definir tipos de roles generales.
  • Widgets: Menu, menuitem, tree, treeitem, tablish, tab, tabpanel, button, grid, etc.
  • Document structure: Definen la estructura para organizar el contenido en una página. No suelen ser interactivos: heading, table, img, tooltip, toolbar, list, presentation, etc.
  • Landmarks: Permiten definir las grandes zonas de la página igual que las etiquetas semánticas en HTML5.
  • Live region: Definen las zonas «vivas» de la página, es decir, las que cambian automáticamente sin la intervención de las personas usuarias: alert, log, marquee, status y timer.

role="alert": contiene información relevante y se anuncia con “alerta”. Debería ser aria-live=»assertive»

role="log": donde la información se agrega en orden significativo y la antigua puede desaparecer, debería ser aria-live=»polite»

role="marquee": información no relevante que cambia con frecuencia, debería ser aria-live=»off»

role="status": advertencia no lo suficientemente importante para justificar una alerta, debería ser aria-live=»polite»

role="timer": contador numérico del tiempo transcurrido o restante

  • Window: Para definir los mensajes de las ventanas: dialog y alertdialog.

Atributos de ARIA: Estados y propiedades

¿Qué es un estado?

Un estado es una propiedad dinámica que puede cambiar según la intervención de las personas usuarias, pero no siempre. Y cambian con menor frecuencia que las propiedades.

¿Qué son las propiedades?

Atributos que son esenciales para determinar el cambio en la presentación de un objeto. Estas cambian con más frecuencia debido a la interacción de las personas usuarias.

Tanto los estados como las propiedades, en la práctica, no es necesario diferenciarlos, y todos empiezan por aria-.

Existen 48 estados y propiedades y se dividen en cuatro categorías:

  • Atributos de Widgets: aria-checked, aria-disabled, aria-required, aria-selected, aria-reandoly, aria-expended, aria-label, etc
  • Atributos de Live region: Permiten definir cuando se producen los cambios en los productos de apoyo; aria-live, aria-atomic, aria-revelant, aria-busy.

aria-live

Indica que un elemento se modifica y se actualizará dinámicamente.

Esta propiedad tiene tres valores: «off», «assertive» y «polite».

aria-live=»off» Indica que es un valor predeterminado, que los cambios se anunciarán a las personas usuarias sólo cuando el foco esté en esa región.

aria-live=»assertive» Indica la prioridad de los cambios, los cambios que se deben presentar inmediatamente a las personas usuarias, con independencia de lo que estén haciendo en ese momento. Como es algo que puede ocasionar desorientación, sólo debe utilizarse para mensajes y advertencias importantes.

aria-live=»polite» Indica los cambios deben anunciarse sin interrumpir a las personas usuarias, por ejemplo, cuando terminan de escribir o de leer.

aria-atomic

Indica si las tecnologías de asistencia presentarán toda o solo las partes que han cambiado.

Esta propiedad tiene dos valores: true/false

Si aria-atomic se establece en «false», sólo presentarán a las personas usuarias el nodo que ha cambiado. Si se establece en «true» presentarán el contenido completo.

aria-revelant

Con este atributo indicamos qué tipo de actualización de la live region deseamos que se anuncie al usuario:

Este atributo se compone de 4 valores: «additions», «all», «removals», «text»

aria-revelant=»additions», anuncia los elementos que se añaden al DOM.

Si el contenido que se añade es semánticamente relevante será importante anunciarlo. Sin embargo, si es meramente decorativo no tiene sentido que se anuncie.

aria-relevant=»all»: anunciará todo, es decir, los elementos añadidos, eliminados y las modificaciones de texto.

aria-relevant=»removals»: anuncia los elementos que se eliminan del DOM. Igual que en el caso anterior, es importante tener en cuenta si el elemento eliminado es relevante o solo decorativo. Por ejemplo, en un listado de amigos en línea, si un amigo se desconecta sería interesante anunciar que se ha eliminado de la lista.

aria-relevant=»text»: anuncia las modificaciones de texto.

aria-busy

Por defecto su valor es «false». Este atributo se utiliza cuando muchas partes de un mismo elemento van a ser modificadas, entonces puedes poner el valor a «true» para que temporalmente no anuncie las modificaciones y, una vez que se hayan llevado a cabo, volver a ponerlo a «false» para que las anuncie.

  • Atributos Drag and Drop: aria-dropeffect y aria-grabbed. Son elementos obsoletos que pueden eliminarse en futuras versiones, pero se recomienda a los agentes de usuario que continúen admitiéndolos por compatibilidad con versiones anteriores.
  • Atributos de relaciones: Expresan relaciones entre los elementos que no se pueden determinar fácilmente a partir de la estructura del documento; aria-controls, aria-labelledby, aria-posinset, aria-setsize, etc

aria-controls: Identifica el elemento cuyo contenido están controlados por el elemento actual. Por ejemplo, un grupo de casillas de verificación puede controlar qué precios de productos básicos se rastrean en vivo en una tabla o gráfico. O una pestaña que controla la visualización de su panel de pestañas asociado.

aria-labelledby: Identifica el contenido que etiqueta el elemento actual. Proporciona a las personas usuarias un nombre reconocible del objeto.

El atributo aria-labelledby es similar a aria-describedby, porque ambos hacen referencia a otros elementos para poner una alternativa de texto, pero una etiqueta debe ser concisa, una descripción está destinada a proporcionar información más detallada.

Se indica el ID del elemento que hace de título en esa zona.

<p id="report-title">Download 2012 Sales Report:
<a aria-labelledby="report-title pdf" href="pdf.pdf" id="pdf">PDF</a> |
<a aria-labelledby="report-title doc" href="word.doc" id="doc">Word</a> |
<a aria-labelledby="report-title ppt" href="ppt.ppt" id="ppt">Powerpoint</a></p>

Otro ejemplo donde se puede aplicar aria-labelledby es con los formularios de búsqueda, en la etiqueta del botón adyacente:

Formulario de búsqueda con una caja de texto y un botón Buscar

<input name="search" type="text" aria-labelledby="btn"></input>
<input name="search" id="btn" type="submit" value="Buscar">

aria-posinset: Define el número o la posición de un elemento en el conjunto actual de elementos de lista o de árbol. Esta propiedad está relacionada con aria-setsize.

El siguiente ejemplo muestra los elementos del 5 al 8 en un conjunto de 16.

<h2 id="label_fruit"> Available Fruit </h2>
<ul role="listbox" aria-labelledby="label_fruit">
  <li role="option" aria-setsize="16" aria-posinset="5"> apples </li>
  <li role="option" aria-setsize="16" aria-posinset="6"> bananas </li>
  <li role="option" aria-setsize="16" aria-posinset="7"> cantaloupes </li>
  <li role="option" aria-setsize="16" aria-posinset="8"> dates </li>
</ul>

Referencias:

  • Libro: Accesibilidad web WCAG 2.1 de forma sencilla, de Olga Carreras y Olga Revilla.
  • W3C WAI ARIA

Libro: «Accesibilidad web. WCAG 2.1 de forma sencilla»

Introducción

Hoy vamos a hablar del libro: «Accesibilidad web: WCAG 2.1 de forma sencilla» de Olga Carreras y Olga Revilla. 

El libro es muy útil y fácil de comprender para cualquier perfil profesional interesado en la accesibilidad web:

  • diseñadores
  • desarrolladores
  • arquitectos de información
  • responsables de contenido
  • consultores de experiencia de usuario
  • especialistas SEO
  • jefes de proyecto.

 

accesibilidad web:wcag 2.1 de forma sencilla. Portada.

Capítulo 1. Introducción a la Accesibilidad Web

En este capítulo se muestra una tabla, que es muy interesante porque te ayuda a tener una visión más amplia de que no hay una única solucion para según qué dificultad estamos tratando, sino que puede haber varias opciones alternativas.

Capítulo 2. Las pautas WCAG 2.1

En este capítulo se explican cada uno de los principios, las pautas, los criterios, técnicas y errores.

También se explican los conceptos de «compatible con la accesibilidad» y «dependencia tecnológica», que son fundamentales para comprender y aplicar las WCAG.

Capítulo 3. Requisitos de conformidad

Este capítulo está dedicado a los requisitos y niveles de conformidad, y a las declaraciones de conformidad, (la información obligatoria y opcional, las declaraciones de conformidad parcial…)

También se puede encontrar ejemplos de declaraciones de conformidad y una plantilla para elaborarla.

Capítulo 4. Evaluar la accesibilidad con WCAG-EM

Esta metodología se utiliza para una exhaustiva evaluación de la accesibilidad de todo tipo de sitios web de acuerdo con las WCAG 2.x.

Describe el procedimiento a seguir y las consideraciones necesarias para guiar a los evaluadores y promover buenas prácticas, evitar errores comunes y lograr resultados más comparables.

Capítulos dedicados a cada principio

  • Capítulo 5. Principio 1. Perceptible
  • Capítulo 6. Principio 2. Operable
  • Capítulo 7. Principio 3. Comprensible
  • Capítulo 8. Principio 4. Robusto

Los capítulos dedicados a los principios de las WCAG 2.1 recogen todos los criterios de cada principio agrupados en sus correspondientes pautas.

Cada una de las 13 pautas incluye una descripción e información que puede ser relevante, como consejos generales, o como por ejemplo, en el caso de la pauta «1.2 Medios tempodependientes», la tabla resumen de las alternativas necesarias para cada tipo de medio.

Por su parte, cada uno de los 78 criterios de conformidad de las WCAG 2.1 tiene su propia sección con la siguiente información:

  • el nivel y el enunciado literal del criterio en español, muy útil para los 17 nuevos criterios que todavía no tienen una traducción oficial
  • una explicación del criterio, especialmente si este es complejo o es uno de los nuevos criterios de las WCAG 2.1
  • listado de técnicas para cumplir con el criterio, técnicas para mejorar la usabilidad así como de errores a evitar
  • recursos de interés, en algunos criterios
  • ejemplos correctos e incorrectos, en algunos criterios

Todos los listados de técnicas y errores están también traducidos al español, lo cual puede ser muy útil para muchas personas, pues no existe una traducción actualizada y oficial de los documentos asociados a las WCAG.

Capítulo 9. Documentos PDF accesibles

En este capítulo podemos encontrar información detallada sobre cómo trabajar las técnicas PDF, así como herramientas y recursos para trabajar con Adobe Acrobat Profesional.

Capítulo 10. ARIA, el aliado (casi) desconocido

Hay muy poca información sobre WAI-ARIA, con lo cual este capítulo es muy interesante. Se da a conocer un poco cuáles son los problemas que suele haber al aplicar esta tecnología; los roles y los atributos, que son imprescindibles para comprender e interactuar mediante el lector de pantalla.

Capítulo 11. Recursos y herramientas

Este capítulo nos muestra diferentes herramientas que ayudan a registrar los datos de la evaluación manual, que evalúan automáticamente determinados criterios, que simulan diversidades funcionales o que ayudan a revisar de forma general el sitio web.

Capítulo 12. Resúmenes y esquemas

El capítulo incluye una serie de resúmenes y esquemas sobre:

  • Diagramas conceptuales de las WCAG 2.1
  • Principios, Pautas y Criterios de conformidad
  • Criterios de conformidad por niveles
  • Criterios para diseñadores
  • Criterios para creadores de contenido
  • Criterios para desarrolladores

 

 

 

Accesibilidad web: Diversidad funcional visual

Introducción

Como ya sabes hay muchas personas, que tienen diversidad funcional visual, y no pueden disfrutar de la tecnología y del acceso a Internet como las personas videntes.

Por eso, existen diversas formas de acceder a Internet para las personas que tienen algún tipo de dificultad para ver o directamente visión nula.

diversidad funcional visual

Ceguera: ¿Cómo acceden las personas ciegas a Internet?

En primer lugar, vamos a hablar de lo más importante que una persona ciega pueda acceder a los contenidos en Internet: el lector de pantalla.

Lectores de pantalla

Los lectores de pantalla permiten a las personas usuarias navegar a través del contenido web de muchas formas: Puede que lea toda la web, pasar de encabezado en encabezado, pasar por enlaces, etc. Algunos ejemplos de lectores de pantallas son: JAWS, NVDA y VoiceOver.

Los lectores de pantalla también puede ser utilizados por aquellas personas que son sordas e invidentes, pero en lugar de convertir texto en voz, los lectores de pantalla para los sordo-ciegos pueden convertir texto en caracteres Braille actualizables en dispositivos Braille.

Los dispositivos de este tipo poseen pines pequeños que se pueden subir o bajar para formar los caracteres Braille que las personas sordo-ciegas pueden sentir.

dispositivo braille

Problemas y limitaciones del lector de pantalla

Imágenes: Uno de los problemas más importantes que tienen es poder acceder al contenido de las imágenes porque los lectores de pantalla no pueden describir las imágenes. Para ello, tenemos que poner textos alternativos con el atributo alt.

Diseño visual: Las personas que ven se percatan de cómo está estructurado un sitio web. Mientras que, los lectores de pantalla no pueden estudiar la totalidad de una página web. No puede hacer eso porque se lee de forma lineal.

Tablas de datos: Del mismo modo, los lectores de pantalla deben leer de manera lineal tablas de datos lo que puede llegar a ser muy confuso. Imagínese tratando de escuchar una tabla de datos de gran tamaño. Os dejo un artículo que escribí sobre la elaboración de tablas accesibles.

Accesibilidad mediante teclado

El hecho de que los usuarios de lectores de pantalla usan el teclado como su medio principal de navegación en la Web es un punto que los desarrolladores deben tener en cuenta. Sin siquiera darse cuenta de las consecuencias, algunos desarrolladores web hacen que los sus sitios sean únicamente accesibles mediante el ratón. Os dejo un artículo que escribí sobre los problemas que existen y cómo mejorar la accesibilidad por teclado.

Diferentes problemas a los que se enfrentan las personas usuarias y posibles soluciones

  • Cuando no usan ratón, es imprescindible el uso alternativo del teclado.
  • En cuanto a imágenes, fotos gráficos, proporcionar descripciones de texto en el atributo alt y, si es necesario, añadir explicaciones detalladas, ya sea en la misma página o mediante un enlace a otra página.
  • Cuando leen las páginas mediante lector de pantallas, permitir saltarse menús y contenido que sea tedioso de escuchar.
  • Saltar enlaces con la tecla TAB, asegurarse de que los enlaces tengan sentido fuera de contexto.
  • Los marcos no se pueden «ver», por lo que no es recomendable usar marcos a no ser que sea estríctamente necesario. Si los usas, proporciona el título del marco que comunique su propósito. («contenido principal», «marco de navegación»).
  • Para las tablas y gráficos complejos, se recomienda proporcionar descripciones de texto o resúmenes.
  • No todos los lectores de pantalla soportan mapas de imágenes, así que se debe poner enlaces de texto redundantes en la propia página para los puntos calientes en los mapas de imágenes.
  • Los colores no se pueden usar, por lo que no debemos transmitir información sólo con el color. Uno de los problemas más significativos respecto al color, es el daltonismo.
  • Mientras navegan esperan que los enlaces les lleven a otro sitio, por lo que no se debe escribir guiones inferiores en los enlaces que no tienen destinos reales asociados (ejemplo: href="javascript: function(this)")
  • Es difícil poder leer el contenido de la celda una tabla, y tienen sentido cuando se leen fila por fila y de izquierda a derecha.

Tipos de baja visión

Como ya sabemos, hay muchos tipos de problemas de visión. La baja visión es más común entre los ancianos, pero puede ocurrir en personas de cualquier edad como consecuencia de enfermedades como la degeneración macular, glaucoma, retinopatía diabética o las cataratas.

Pero antes de empezar, es importante recordar el principio importante que hay que tener en cuenta: Perceptible.

Degeneración macular

La degeneración macular ocurre cuando los vasos sanguíneos anormales en la parte posterior del ojo empiezan a filtrar líquido o sangre, haciendo borrosa la visión central, siendo a menudo el resultado la pérdida rápida de la visión. El resultado es una pérdida gradual de la visión.

En cualquier caso, la zona central de la vista es la más afectada, por lo que es difícil ver los objetos que la persona está mirando directamente.

Las imagen a continuación son una simulación del efecto de la degeneración macular. El texto puede aparecer roto y poco claro.

dos fotografías iguales donde en una de ellas se ve el efecto de la degeneración macular, que es tener visión central nulaa

Glaucoma

El glaucoma es causado por un aumento de presión dentro del ojo, lo que provoca daños en el nervio óptico. El resultado es el efecto opuesto al de la degeneración macular.

Como se ve con glaucoma, efecto borroso en la visión central

Retinopatía diabética

Uno de los efectos a largo plazo de la diabetes puede ser la filtración de los vasos sanguíneos de la retina, causando manchas oscuras en el campo de visión en la que las fugas se producen. El texto puede aparecer borroso o distorsionado en estas regiones.

retinopatía diabética

Catarata

Las personas con cataratas tienen áreas de opacidad en el cristalino de sus ojos lo que se traduce en un efecto de difuminado o con neblina, especialmente a la luz brillante. El texto puede tender a desaparecer en el fondo. El alto contraste es especialmente importante para las personas con cataratas avanzadas.

cataratas

Magnificadores de pantallas, lupas

La tecnología más común que usan las personas con baja visión es la lupa de la pantalla. Este es un programa de software que acerca un área pequeña de la pantalla al usuario, permitiendo a las personas con baja visión que puedan ver con más claridad. Magnificadores de pantalla comunes incluyen ZoomText y MAGic.

Algunos tipos de contenido son difíciles de interpretar cuando se amplían. Por ejemplo, los gráficos que contienen texto pueden convertirse en bloques y pixelarse demasiado, por lo que el texto es difícil de entender.

Pero lo que es importante es que, para hacer más legible el texto cuando se amplía, la opción recomendada es el uso de texto real, en vez de gráficos o imágenes que contengan texto.

Alto Contraste

Los sitios con bajo contraste puede ser difíciles de leer para las personas con baja visión. Algunos sitios mal diseñados de la web tienen malas combinaciones de color, tales como enlaces de color azul sobre fondo negro, texto en color rojo sobre fondo verde, u otras combinaciones que no son fáciles a los ojos de cualquiera, pero especialmente difíciles para las personas con baja visión.

Por lo tanto, en la medida de lo posible, aumenta el contraste de tu página web, incluyendo gráficos, fuentes y fondos.

Fuentes predilectas y colores de fondo

Algunas personas con baja visión van a cambiar la configuración de su sistema operativo y/o el navegador no sólo para ampliar el texto, sino también para aumentar el contraste del texto en relación con el fondo. A algunas personas les gusta tener un fondo negro con texto blanco o amarillo. Por el contrario, otros prefieren tener un fondo blanco o amarillo con el texto en negro. Estos son los ajustes más comunes, pero hay otras personas que prefieren otras opciones de alto contraste. Y hablando de contrastes, os dejo aquí el artículo que hice sobre la sensibilidad reducida al contraste, que es un problema de baja visión.

color de alto contraste y texto grande

Para permitir que las diferentes personas realicen sus ajustes de contraste, ya que como hemos visto hay multitud de formas, lo mejor es poner el texto en plano, evitando que éste aparezca en fotografías.

Desplazamiento horizontal

Este punto no es tanto una cuestión de accesibilidad, sino más bien de usabilidad. Probablemente ha llegado a sitios web que requieren el uso de su barra de desplazamiento horizontal para ver el contenido de la derecha de la pantalla, a pesar de que tenía la ventana del navegador maximizada.

Esto puede ser un poco molesto para las personas con visión perfecta, pero es aún más para las personas que usan magnificadores de pantalla y se ven obligados a desplazarse aún más hacia el interior izquierdo y derecho del pequeño espacio ampliado que están viendo.

La regla general en el diseño de la baja visión es hacerlo todo configurable. Si el texto es un texto plano, las personas usuarias pueden ampliar, cambiar su color y cambiar el color de fondo. Si el diseño es en porcentajes, la pantalla puede ser ampliada o reducida para satisfacer las necesidades de las personas usuarias. La configuración es la clave.

Problemas y soluciones para la baja visión

  • El texto en gráficos o fotos no se agranda sin software especializado y se ve pixelado cuando se amplía, con lo cual, se recomienda limitar o eliminar el texto en gráficos o fotos.
  • Las personas usuarias pueden establecer su propia fuente y los colores de fondo, por lo que hay que permitir que lo hagan usando texto en plano, y no en texto escrito en una foto o gráfico.
  • Los magnificadores de pantalla reducen el tamaño de la ventana útil, por lo que, hay que utilizar unidades relativas en lugar de absolutas (por ejemplo, porcentajes de utilización de ancho de tabla en lugar de píxeles), para reducir la cantidad de desplazamiento horizontal.

Herramientas que se pueden usar para este tipo de dificultades visuales

  • NoCoffee Vision Simulator

Existen unas extensiones, tanto para Google Chrome como para Mozilla Firefox, que es bastante interesante, para hacernos una idea de cómo ven los sitios web las personas que tienen algún tipo de problema de visión.

Es muy sencilla de usar, simplemente tenemos que ver las diferentes opciones y comprobar el efecto visual que se produce en los sitios web cuando señalamos las opciones que queramos.

Herramienta de NoCoffee para diversidad funcional visual

Accesibilidad móvil: Cómo hacer apps accesibles

Introducción

El CEAPAT ha elaborado un documento de 94 páginas en el cual nos indican cómo hacer apps accesibles. Habla sobre los requisitos que deben tener en cuenta los desarrolladores a la hora de hacer una aplicación accesible.

Cómo hacer apps accesibles

Os resumo los puntos más importantes sobre el documento desarrollado por el Ceapat. «Cómo hacer apps accesibles»

Recomendaciones generales

Se incluyen las características de accesibilidad y usabilidad generales de la interfaz de usuario.

Identificación de objetos de la interfaz de usuario

  1. Nombre de los elementos de la interfaz: Debe garantizarse que todos los elementos de la interfaz, como casillas de verificación, botones o texto estático, están perfectamente identificados y son únicos en su contexto, con información de su nombre, estado y rol.
  2. Nombres consistentes y significativos: Los nombres de los elementos de la interfaz deben tener un nombre único y significativo a lo largo de toda la interfaz de usuario, usando un lenguaje natural que pueda entender el usuario.
  3. Nombres cortos y concisos: Deben utilizarse nombres que sean cortos y que no incluyan su función, de forma que el texto se diferencie del rol, el estado y el valor del elemento, información no visible pero que los lectores de pantalla verbalizarán a petición del usuario.
  4. Nombres visibles: Los elementos de la interfaz de usuario deben tener un etiquetado visible que informe al usuario
  5. Etiquetas de iconos: Todos los iconos deben poder tener asociada una etiqueta de texto y debe existir la posibilidad de visualizar sólo esa etiqueta.

Ajustes de preferencias de usuario

  1. Interfaz flexible y personalizable: Cada usuario debe poder cambiar y mantener las preferencias de la aplicación mediante la interfaz del sistema de una forma sencilla.
  2. Personalizar elementos comunes de la interfaz: Las aplicaciones desarrolladas deben admitir una configuración estándar para el tamaño, color y fuente de texto, utilizando las funciones del sistema.
  3. Personalizar la apariencia de los elementos. El usuario debe poder ajustar, de forma individual o en grupos, la posición u ocultación de aquellos iconos y objetos gráficos que puedan ser activados.
  4. Apariencia del cursor. Deben existir opciones para modificar la apariencia del cursor de texto y del puntero del ratón.
  5. Ajuste de tiempo de respuesta. Si se requiere una respuesta del usuario en un intervalo de tiempo determinado, se debe poder ajustar dicho intervalo, incluyendo la posibilidad de desactivar todos los límites de tiempo.
  6. Compatibilidad con atributos de visualización. La interfaz de usuario debe adaptarse a la configuración de contraste, color, tamaño y demás atributos de visualización que haya definido el usuario en el sistema operativo.

Pautas generales sobre control y uso

    1. Elección del método de entrada: Se debe permitir al usuario elegir el dispositivo de entrada preferido, ya sea el teclado, trackpad, pantalla táctil o la conexión de productos de apoyo que los sustituya.
    2. Elección del método de salida: Se debe proporcionar al usuario la posibilidad de elegir sistemas redundantes y combinados de salida para el sonido, imágenes, texto y gráficos.
    3. Pasos para realizar una acción: El software debe estar diseñado para minimizar el número de pasos que debe realizar el usuario para activar cualquier opción. Lo deseable es que el usuario alcance su objetivo en no más de dos o tres pasos. Regla de los tres clics
    4. Recuperación de errores: Se debe proporcionar una función que permita a los usuarios deshacer los efectos de acciones no intencionadas o que se quieran rectificar.
    5. Persistencia de avisos relevantes: La información sobre errores, o los avisos relevantes para la tarea actual, deben persistir hasta que el usuario confirme su lectura.
    6. Consistencia de las notificaciones: Los mensajes del mismo tipo, como mensajes o avisos, deben ser claramente identificables: deben tener el mismo formato y deben estar etiquetados de forma unívoca y estándar.
    7. Mensajes comprensibles: Los mensajes emitidos deben ser cortos, sencillos y redactados en un lenguaje claro para el usuario no técnico.
    8.  Mensajes de error: Cuando se produce un error, el sistema debería proporcionar sugerencias de soluciones posibles que ayuden a resolver el problema por parte del usuario.
    9. Información dinámica: El usuario debe poder pausar o detener la presentación de información que se mueve en carrusel o se actualiza periódicamente en un área de la pantalla.
    10. Controles temporales: Evitar los controles de interfaz de usuario que se extinguen o desaparecen después de un tiempo determinado.
    11. Salir de la aplicación: Las aplicaciones deberían ofrecer la opción de finalizar. Cerrar la aplicación en los sistemas operativos para dispositivos móviles no siempre parece evidente.

Opciones alternativas de entrada

Se incluyen las recomendaciones que tienen relación con los sistemas de entrada al dispositivo, tanto software como hardware.

  1. Método de entrada totalmente funcional: La aplicación se debe poder manejar de forma efectiva utilizando sólo uno de los posibles métodos de entrada, es decir, sólo con el teclado, sólo con el touchpad o con la pantalla táctil.

Foco del teclado

  1. Ubicación del foco: El foco de entrada debe quedar reflejado en pantalla de forma inequívoca.
  2. Contenidos de texto: Los contenidos relevantes en formato textual deben permitir su recorrido mediante un cursor cuando dispongan del foco.
  3. Función volver: Si el usuario cambia de tarea o de aplicación, al regresar, la interfaz debe recordar cuál era el control que tenía el foco, de forma que pueda seguir en el mismo punto en el que lo dejó.
  4. Navegación circular: La navegación entre elementos de la interfaz debe ser circular, de forma que el foco vuelva desde el último elemento al primero.

Entrada de teclado

  1. Acceso sólo por teclado. En la aplicación se deben poder navegar yactivar todas las funciones sólo mediante teclado,
  2. Atajos. Se deben proporcionar combinaciones de teclas para acceder rápidamente a las funciones principales y estas combinaciones deben estar documentadas.
  3. Métodos abreviados de teclado. Las etiquetas de los controles de la interfaz de usuario deben tener mnemónicos para un acceso rápido por teclado.
  4. Teclas de activación específicas. Los comandos de navegación por teclado no deben activar los objetos de interfaz.
  5. Compatibilidad con las funciones del teclado: Las aplicaciones deben respetar las convenciones de funcionamiento del teclado en el sistema operativo, de forma que no cambien la asignación funcional original de las teclas. Esto es una característica de consistencia que facilita su utilización por personas con diversidad funcional visual o intelectual.
  6. Navegación por listas y menús: Permitir a los usuarios elegir el elemento del menú utilizando las teclas del cursor, teclas principio y fin, mediante numeración, letras clave, etc.
  7. Agrupación de elementos relacionados: Los controles que estén relacionados deben estar próximos y alineados con un espacio de separación entre los grupos.
  8. Navegación lógica: El desplazamiento mediante teclado de un elemento a otro en los cuadros de diálogo debe seguir una secuencia consistente con la distribución de éstos en la pantalla.

Dispositivos apuntadores

La pantalla táctil cabe considerarla como un sistema de entrada que emula las funciones de un dispositivo apuntador.

  1. Alternativa al dispositivo apuntador. Las aplicaciones deben ofrecer laposibilidad de utilizar métodos alternativos para lograr entradas que serealizan normalmente mediante el dispositivo apuntador.
  2. Área táctil: El área sensible al tacto en una pantalla táctil, que activa o selecciona un elemento de la interfaz gráfica de usuario, debe tener una dimensión óptima de 9 x 9 mm, no debiendo ser inferior a 8 mm de ancho por 7 mm de alto.
  3. Asignación de botones: Se debe permitir cambiar la asignación de funciones de todos los botones del dispositivo apuntador.
  4. Evitar doble clic: Se debe poder emular el clic múltiple mediante la pulsación única de una tecla.
  5. Pulsación mantenida: Se debe poder emular la pulsación mantenida de un botón del dispositivo apuntador mediante la pulsación única de un botón.
  6. Velocidad del puntero: Se debe permitir configurar la velocidad y aceleración del movimiento del puntero del dispositivo apuntador.
  7. Ajustar la dirección del movimiento del puntero: La aplicación debería permitir cambiar la dirección predeterminada del puntero. Esta utilidad está asociada a un software de controladores de dispositivos, especialmente para joystick, lo que permite que el dispositivo pueda colocarse en cualquier posición.
  8. Pulsación simultánea: Se deben ofrecer alternativas para pulsaciones simultáneas de teclas y botones del dispositivo apuntador.

Recomendaciones generales sobre salidas

  1. Parpadeo. Se debe evitar presentar elementos que parpadeen o destellen con una frecuencia entre 2 y 50 Hz. El parpadeo dificulta la legibilidad y puede causar ataques epilépticos a algunas personas.
  2. Redundancia en la información auditiva y visual. La información relevante ofrecida en formato de audio o vídeo por las aplicaciones, debe también ser suministrada en otros formatos alternativos.

Pantalla

  1. Tamaño de imágenes: El usuario debe poder ajustar el tamaño de iconos y otras imágenes para facilitar su visión y selección.
  2. Magnificación: Debe existir al menos un modo de presentación de la información visual que sea legible para usuarios con agudeza visual entre 6/18 y 6/60 sin depender del sonido.
  3. No usar el texto para construir gráficos: No utilizar los caracteres para la creación de gráficos. Los lectores de pantalla interpretarán estos gráficos como texto y harán una lectura errática.

Texto

  1. Propiedades del texto: No se debe transmitir información sobre el estado sólo a través de los atributos del texto
  2. Tamaño y color: Las aplicaciones deben proporcionar opciones para que el usuario elija el tipo de letra, su tamaño y el color de todos los controles de la interfaz.
  3. Escalado de la interfaz: El diseño de la interfaz gráfica de usuario debe permitir que los elementos que la componen, principalmente el texto y los controles, sigan siendo visibles y navegables cuando se modifican su tamaño.

Color

  1. Color: La utilización del color es importante para realzar o resaltar la información, pero no debe usarse nunca como la única forma de transmitirla.
  2. Combinación de colores: Deben proporcionarse combinaciones de colores predefinidas que hayan sido diseñadas teniendo en cuenta las necesidades de las personas con diversidad funcional visual.
  3. Personalización de los colores de la interfaz: El usuario debería poder personalizar los colores de los elementos de la interfaz.

Ventanas

  1. Cambiar de una ventana a otra: El usuario debe poder cambiar de una ventana de trabajo o aplicación a otra utilizando el teclado, por combinación de teclas o mediante accesos directos.
  2. Gestión de las ventanas: Debe poder ajustarse el tamaño y posición de las ventanas. Así mismo, deben proporcionarse opciones para minimizar, maximizar, restaurar y cerrar las ventanas.
  3. Título de ventana único: El nombre de la ventana debe ser único y significativo en toda la interfaz del sistema.

Sonido

  1. Ajuste de volumen: El usuario debe poder ajustar el volumen del sonido de la aplicación. Este requisito tiene relación con la funcionalidad del propio sistema operativo y del dispositivo.
  2. Audio no vocal: Las señales acústicas auditivas no vocales están destinadas a proporcionar información al usuario del estado del dispositivo, de las aplicaciones o de las comunicaciones, como las señales de llamada, alertas o avisos de error.
  3. Alternativas a los avisos sonoros: Los usuarios con dificultad auditiva o que trabajan en entorno ruidosos o cuando deba utilizarse el dispositivo en silencio, deben poder activar una alternativa visual o por vibración.
  4. Lector de texto: Deben ofrecerse funciones que permitan enviar cualquier información textual a una salida mediante síntesis de voz.
  5. Lector de pantalla: La salida en síntesis de voz debe aparecer inmediatamente después de ocurrir el evento que la originó. Este requisito tiene relación con la utilización de un lector de pantalla.

Subtitulado y multimedia

  1. Proporcionar subtitulado: Si la aplicación proporciona reproducción de vídeo, debería ser compatible con el subtitulado adaptado y los subtítulos de idiomas para usuarios con problemas de audición.
  2. Visibilidad del subtitulado: El texto del subtitulado aparece en el borde inferior del vídeo, sobreimpuesto a la imagen.
  3. Control de reproducción multimedia: La aplicación debe proporcionar controles de reproducción para reproducir, pausar, saltar y avanzar o retroceder.

Servicios de accesibilidad de los sistemas operativos

Se describen a continuación los más relevantes:

  • Magnificador. Permite ampliar la imagen en pantalla de forma que los textos puedan leerse más cómodamente y percibirse mejor las imágenes.
  • Alto contraste y combinación de colores. Herramienta normalmente asociada al magnificador que permite invertir o modificar la combinación de colores para mejorar la visión de la pantalla por parte del usuario.
  • Lector de pantalla. Verbaliza la información que aparece en la pantalla, de forma que el usuario puede prescindir de verla para interactuar con el dispositivo.
  • Lectura de textos. Sistema de conversión texto a voz que ayuda a la lectura de documentos y otros contenidos, como páginas web o correos electrónicos. En alguno de los sistemas operativos es necesario adaptar el “Lector de pantalla” para esta función.
  • Reconocimiento de habla. Permite controlar el dispositivo por comandos de voz y escribir texto mediante dictado.
  • Avisos sonoros, visuales y hápticos. Señalización redundante de avisos o notificaciones del sistema operativo o de los programas para facilitar su percepción por parte de usuarios con dificultades visuales o auditivas.
  • Barrido. Método de acceso que permite al usuario controlar el dispositivo mediante un pulsador o una acción simple. No lo incorpora ningún sistema operativo.

 

Accesibilidad web: Programas para subtitulado

Formatos de subtítulos

En la actualidad existen infinidad de formatos y programas de subtitulado, los más comunes son:

  1. SubRip,
  2. Substation Alpha
  3. Timed Text Markup Language.
  4. SMIL

 

Programa para subtitulado y formatos de subtítulos

Formato SubRip

Este formato de subtitulado, con extensión .srt, es uno de los formatos más básicos de entre todos los formatos de subtítulos, y está compuesto por cuatro partes:

  • Número indicando el orden en la secuencia de subtítulos.
  • El momento en el tiempo en el que el subtítulo debe aparecer enpantalla, y cuando debe desaparecer.
  • El texto del subtítulo.
  • Una línea en blanco indicando que comienza un nuevo fragmento del subtítulo.

El principal inconveniente de este formato es que no admite colores, sinembargo es uno de los formatos más extendidos para publicar subtítulos en internet.

Formato Substation Alpha

El formato Substation Alpha, con extensión .ssa, es más avanzado que SubRip y tiene un formato avanzado que se denomina Advanced SubStation Alpha, con extensión .ass. Permite colores, efectos y otros elementos.

Permite la utilización de fuentes por lo que el usuario necesitará tenerinstalada la fuente que se indica en el fichero del subtítulo. Por lo demás,este formato es un fichero de texto en el que se indican los parámetros necesarios para la visualización del subtítulo.

Formato Timed Text Markup Language

El formato Timed Text Markup Language, DFXP, es una recomendación del W3C, para subtitular contenido en páginas web. Este formato, basado en XML, permite presentar un subtítulo sincronizado con contenidos multimedia, puede incorporar estilos y colores.

Formato SMIL (Synchronized Multimedia Integration Language)

Este formato es un estándar del W3C, permite sincronizar audio, vídeo u otros contenidos multimedia y texto. SMIL es el acrónimo de Lenguaje de Integración Multimedia Sincronizada. Este formato está basado en XML, y describe las fuentes del contenido, la sincronización, la temporización, la posición de las fuentes, enlaces y animaciones.

Edición de subtítulos

Siempre que sea posible, los subtítulos deben ser literales. No obstante, para ayudar a mantener el sincronismo, cuando la velocidad de la persona oradora es muy alta, existen ciertas estrategias para economizar el vocabulario.

Algunas estrategias para economizar el vocabulario son:

  • Utilizar todas las siglas que permite la Real Academia Española, y los acrónimos más conocidos (OTAN, ONU…).
  • Evitar las muletillas, repeticiones o saludos innecesarios.
  • Utilizar las formas cortas o más coloquiales de entidades u organismos. (Ejemplo: sustituir «La Cámara de los diputados» por «El Congreso»).
  • Utilizar en la medida de lo posible pronombres.
  • Utilizar las formas cortas de los nombres de personalidades o de sus cargos. (Ejemplo: sustituir «Sus Majestades los Reyes de España Don Felipe y Doña Letizia» por «Los Reyes de España».)

Herramientas para edición de subtítulos

Existe un gran número de herramientas en Internet que permiten subtitular vídeos.

Amara

Amara es una herramienta web colaborativa de código abierto que permite subtitular cualquier vídeo que esté publicado en plataformas como Youtube o Vimeo. A su vez permite que los usuarios incluyan traducciones de los subtítulos, insertar los vídeos subtitulados en páginas web, y descargar los subtítulos en formato srt.

Esta herramienta depende de la Participatory Culture Foundation, organización sin ánimo de lucro.

Jubler
Jubler permite editar subtítulos en formato de texto. Con él podemos crear nuevos subtítulos o convertir, editar y transformar subtítulos ya existentes. A su vez permite visualizarlos en tiempo real, comprobar la ortografía, traducirlos y editar los formatos entre otras funcionalidades.

Aegisub
Aegisub permite editar subtítulos en diferentes formatos y la creación de macros para facilitar su edición. Permite gran cantidad de opciones para la personalización de los subtítulos: color, tipografía, formato de subtítulo, etc.

Subtitle Workshop
Subtitle Workshop permite crear, editar y transformar subtítulos en prácticamente todos los formatos existentes. Puede guardar más de 60 formatos de subtítulos a través de la biblioteca de API de subtítulos, así como guardar subtítulos en un formato de archivo personalizado definido por el usuario. Así mismo, viene equipada con algunas opciones interesantes como la comprobación de la ortografía y la previsualización de vídeos.

Dotsub
Esta aplicación web permite crear, traducir e incluir subtítulos en múltiples lenguas en vídeos disponibles en diferentes plataformas.

HandBrake

Es un conversor de vídeo multiformato que podemos disfrutar en Windows, Mac y Linux libre y gratuitamente.

Herramientas para conversión de formatos de subtítulos

Caption Format Converter

Convierte los subtítulos en diferentes tipos de formatos. Es una herramienta bastante interesante.

Accesibilidad web: Técnicas PDF para las WCAG 2.1

Introducción

En esta entrada voy a hablar de las técnicas PDF para las WCAG 2.1 y os doy una serie de consejos prácticos para cada una.

El título de cada una de las técnicas os llevará a su descripción en la documentación de las WCAG 2.1

Técnicas pdf para las WCAG 2.1

Técnicas PDF de las WCAG 2.1

PDF1: Aplicar las alternativas de textos a imágenes con ALT

Esta técnica nos sirve para proporcionar alternativas de texto para las imágenes a través de un atributo Alt. Aquí os dejo una entrada donde hablé sobre cómo aplicar texto alternativo a las imágenes y cómo diferenciar unas de otras.

PDF2: Crear marcadores

El objetivo de esta técnica es permitir que las personas usuarias localicen contenido utilizando marcadores. Esto resulta beneficioso para las personas con diversidad funcional intelectual, por la facilidad que presenta el esquema jerárquico del documento. Esta técnica está asociada al criterio 2.4.5: Múltiples vías.

PDF3: Asegurar el tabulado correcto y el orden de lectura en documentos

Esta técnica sirve para que las personas usuarias puedan navegar a través del contenido en un orden lógico que sea consistente con el significado del contenido. Es imprescindible revisar el orden de lectura del documento mediante un lector de pantalla. Técnicas asociadas a los criterios 1.3.2: Secuencia significativa, 2.1.1: Teclado , 2.4.3: Orden del foco.

PDF4: Ocultar imágenes decorativas con la etiqueta “Artifact”

Esta técnica está relacionada con la técnica PDF1, en referencia a las imágenes decorativas. Esta asociada al criterio 1.1.1: Contenido sin texto

PDF5: Indicar los controles de formulario requeridos

Con esta técnica lo que pretendemos es notificar al usuario cuando un campo que debe completarse no se haya completado en un formulario PDF.

Para ello, hay que tener en cuenta la accesibilidad de los formularios en los sitios web.

Criterios: 3.3.1: Identificación de error, 3.3.2: Etiquetas o instrucciones,
3.3.3: Sugerencia de error

PDF6: Usar elementos de tabla para el marcado

Esta técnica nos da los pasos para marcar el etiquetado de las tablas. También es importante tener en cuenta la accesibilidad en las tablas. El criterio asociado es el 1.3.1: Información y relaciones.

PDF7: Aplicar Optical Character Recognition (OCR) en un documento PDF escaneado para proporcionar texto.

Un documento que tiene imágenes escaneadas de texto es intrínsecamente inaccesible. En este caso, las imágenes escaneadas de texto se pueden convertir a PDF mediante el reconocimiento óptico de caracteres (OCR). Criterios: 1.4.5: Imágenes de texto y 1.4.9: Imágenes de texto (sin excepción)

PDF8: Proporcionar definiciones de abreviaturas a través de una entrada para un elemento de estructura

El objetivo de esta técnica es proporcionar una expansión o definición de una abreviatura para la primera aparición de la abreviatura. Criterio 3.1.4: Abreviaturas.

PDF 9: Proveer encabezados al marcar el contenido con etiquetas de encabezado

Los encabezados se marcan utilizando los elementos de encabezado y tiene ser lógico y coherente. Es importante validar el documento siempre con un lector de pantalla. Criterios asociados: 1.3.1: Informaciones y relaciones y 2.4.1: Bloques de desvío

PDF10: Suministrar etiquetas para controles de formulario interactivos

Los campos de formulario tienen que tener un nombre significativo que esté relacionado con él, incluida la ayuda contextual. Criterios asociados: 1.3.1: Información y relaciones, 3.3.2: Etiquetas o instrucciones y 4.1.2: Nombre, Rol, Valor

PDF11: Proporcionar enlaces y vincular el texto mediante la anotación “Link”

La forma más sencilla de proporcionar enlaces que cumplan con los criterios de éxito de WCAG es crearlos al crear el documento, antes de la conversión a PDF. Es importante que el texto del enlace y el contexto en el que se incluye sea significativo, y en caso contrario añadir un texto alternativo. Criterios asociados: 1.3.1: Información y relaciones, 2.1.1: Teclado, 2.4.4: Propósito de los enlaces (en contexto) y 2.4.9: Propósito de los enlaces (sólo enlaces)

PDF12: Facilitar información de nombre, función y valor para los formularios

Como ya he dicho, todo campo de formulario debe tener un nombre y también tenemos que poner su valor y estado por defecto. Los criterios relacionados son: 1.3.1 y 4.1.2.

PDF13: Proveer texto de reemplazo usando la entrada “Alt” para enlaces

Volvemos a la técnica PDF11, donde se habla de los propósitos de los enlaces. Los criterios relacionados con esta técnica son: 2.4.4: Propósito de los enlaces (en contexto) y 2.4.9: Propósito de los enlaces (sólo enlaces).

PDF14: Proporcionar encabezados y pies de página en ejecución

Los encabezados y pies de página deben ser consistentes y deben incluir información relevante, así, como tener en cuenta la ubicación, ya que esto ayuda a las personas con diversidad funcional intelectual a orientarse
a lo largo de todo el documento. Los criterios relacionados son: 2.4.8: Ubicación y 3.2.3: Navegación consistente.

PDF15: Suministrar botones de envío con la acción de presentación en formularios

Al igual que ocurre en los sitios webs, también deberemos hacer lo mismo con los PDF. Criterio asociado a esta técnica, 3.2.2: En la entrada

PDF16: Configurar el idioma predeterminado mediante la entrada “Lang”

Con esta técnica, lo que conseguimos es especificar el idioma predeterminado de un documento. De esta manera, las personas con diversidad funcional pueden entender mejor el contenido. Es importante recordar que, también hay que marcar los cambios de idioma. Criterio asociado 3.1.1: Idioma de la página

PDF17: Describir la numeración de página coherente para documentos

Si vamos a añadir la paginación, por ejemplo en el pie, esta debe ser coherente con la paginación del propio documento. Criterios relacionados: 1.3.1 Información y relaciones, 2.4.8: Ubicación y  3.2.3: Navegación consistente.

PDF18: Especificar el título del documento mediante la entrada “Título”

Una de las cosas más importantes que siempre se recomienda es, como indica esta técnica: poner un título descriptivo al documento. Tiene mucho que ver con el criterio 2.4.2: Título de la página.

PDF19: Detallar el idioma para una frase con la entrada “Lang”

Volvemos a la técnica 16, donde ya se explicó. Si el texto en otro idioma está insertado dentro de un párrafo, será necesario convertirlo en una etiqueta independiente: <span></span>. Los criterios relacionados son: 3.1.1: Idioma de la página y 3.1.2: Idioma de las partes

PDF20: Utilizar el Editor de tablas de Adobe Acrobat Pro para tablas erróneas

En la técnica 6 explico todo lo que se refiere a las tablas. Criterio 1.3.1.

PDF21: Usar etiquetas de lista para documentos PDF

Esta técnica sirve para crear listas de elementos relacionados utilizando elementos de lista apropiados según su propósito, y que estén correctamente etiquetadas. Esto permite al lector de pantallas avisar de que hay listas. Criterio: 1.3.1: Información y relaciones

PDF22: Indicar la entrada de usuario que se encuentra fuera del formato requerido

Al igual que en un formulario web, en un formulario PDF se debe indicar los campos que son obligatorios y los formatos requeridos. Ya lo comenté en la técnica 5. Los criterios relacionados son: 3.3.1: Identificación de error y 3.3.3: Sugerencia de error

PDF23: Proporcionar controles de formularios interactivos en documentos PDF

Los formularios PDF deben ser accesibles también por teclado. Criterios relacionados: 2.1.1: Teclado.

WCAG-EM: Evaluación de Conformidad con la Accesibilidad Web

Introducción

WCAG-EM pretende proporcionar una metodología armonizada internacionalmente para la evaluación de todo tipo de sitios web (estáticos, dinámicos, responsive design, versiones móviles, etc.) de acuerdo con las WCAG 2.0. También es compatible con WCAG 2.1.

En el documento se especifican los pasos concretos, y ofrece orientación para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio.

wcag em_ Evaluación de conformidad con la accesibilidad web

La metodología se aplica siempre a un sitio web completo. También se permite aplicar a ámbitos claramente separables de un único sitio web, como podría ser la parte pública y la parte privada del mismo, o diferentes versiones del sitio (versión móvil, versión en determinado idioma, etc.)

Se especifica también el conocimiento que debería tener el evaluador y que se puede resumir en un profundo conocimiento de las WCAG 2.0, del diseño web accesible, de los distintos productos de apoyo y de cómo las personas con diferentes diversidades funcionales usan la Web. Esto implica comprender las tecnologías web, las barreras de accesibilidad o las técnicas, herramientas y métodos de evaluación para identificar dichas barreras.

Los pasos del procedimiento de evaluación son 5:

  1. Definir el alcance de la evaluación
  2. Explorar el sitio web
  3. Seleccionar una muestra representativa
  4. Auditar la muestra seleccionada
  5. Registrar los resultados de la evaluación.

 

Paso 1. Definir el alcance de la evaluación

  • 1a: definir el alcance del sitio, las páginas (y los estados de las mismas) a las que se va a aplicar la evaluación, sin contradecir las limitaciones que se han indicado en el ámbito de aplicación de la metodología.

Es necesario documentar aspectos particulares como servicios desarrollados externamente, diferentes versiones de la misma (móvil, versiones por idioma), partes del portal que forman parte del mismo aunque no estén integradas en él (por ejemplo la zona de ecommerce), etc. Esto puede requerir conocer las propiedades o el proceso de desarrollo de algunas partes del sitio, y tener que llevarse a cabo a la vez que el paso 2 (navegar por el sitio web).

El resultado debe ser una definición no ambigua que determine para cada página si está o no dentro del alcance de la evaluación.

Se recomienda utilizar formalizaciones como expresiones regulares o listados de URIs para definir las páginas que están en el alcance.

  • 1b: definir cuál el nivel de adecuación (A, AA, AAA) que se va a evaluar. Habitualmente será el nivel AA, pero a menudo es útil ampliar el alcance para tener una imagen más completa de la accesibilidad del sitio.
  • Paso 1c: definir el soporte de la accesibilidad, es decir, un listado de los navegadores web, los productos de apoyo u otros agentes de usuario con los que las características de accesibilidad deben ser compatibles. Salvo en el caso de las Intranets, lo ideal es que sea lo más amplia posible. Ponen un ejemplo: la posibilidad de enseñar subtítulos en un reproductor de vídeo no estará soportado por todas las combinaciones posibles de navegadores y productos de apoyo, y en este sentido las WCAG 2.0 no definen para qué combinación concreta debe ser soportada, pues depende del contexto particular del sitio.
  • Paso 1d (opcional): definir los requisitos de evaluación adicionales acordados entre el evaluador y quien ha encargado la evaluación (páginas adicionales solicitadas, casos de uso especiales, si desean un informe muy detallado indicando la solución para cada problema detectado, la participación de personas con diversidad funcional, etc.)

Paso 2. Explorar el sitio web

Este paso sirve para entender mejor el uso, propósito y funcionalidad del sitio; y además ayuda a identificar las páginas relevantes o con problemas que son candidatas a incluirse en la muestra a analizar.

Suele ser más eficaz si se hace participes a los desarrolladores y/o a los propietarios del sitio. La exploración inicial suele ser refinada en los pasos posteriores.

Se divide en los siguiente subpasos:

  • 2a: identificar las páginas (o estados de las páginas) relevantes Incluye la página de inicio, la página de login y otras páginas de entrada, el mapa del sitio, la página de contacto, de ayuda, de información legal y otras similares que normalmente están enlazadas desde todas las páginas (por lo general en la cabecera, el pie o el menú de navegación)
  • 2b: identificar las funcionalidades clave del sitio, el propósito de este paso no es identificar de forma exhaustiva todas las funcionalidades de un sitio web, sino determinar aquellas que son esenciales para el propósito y el objetivo del sitio. El resultado de este paso es una lista de funcionalidades que los usuarios pueden realizar en el sitio como «selección y compra de un producto», «registrar una cuenta en el sitio», «rellenar y enviar un formulario», etc.
  • 2c: identificar los diferentes tipos de páginas y estados de página con diferentes estilos, layout, estructuras y funciones, que a menudo son generadas por diferentes plantillas y escritas por diferentes personas. También pueden ser páginas con diferentes estados, páginas que se ven o comportan diferente dependiendo del usuario y el contexto.

El contenido que se debe buscar para identificar diferentes tipos de páginas o diferentes estados de una página son:

  • Contenido web con diferentes estilos, layout, estructura, navegación, interacción y diseño visual;
  • Diferentes tipos de contenido, como formularios, tablas, listas, encabezados, multimedia y scripts;
  • Contenido con diferentes componentes funcionales, tales como selector de fechas, lightbox, slider, y otros;
  • Contenido que utilizan diversas tecnologías, tales como HTML, CSS, JavaScript, WAI-ARIA, PDF, etc.;
  • Contenido de diferentes áreas del sitio (home, departamentos, ecommerce, etc.);
  • Contenido que ha sido creado usando diferentes plantillas;
  • Contenido cuya autoría es de diferentes personas, departamentos o entidades;
  • Contenido en el que cambia la apariencia y comportamiento en función del usuario, el dispositivo, el navegador, el contexto o la configuración;
  • Contenido dinámico: mensajes de error, cuadros de diálogo, pop-ups u otro tipo de interacción

 

  • 2d: identificar las tecnologías de las que se depende, que pueden ser HTML, CSS, JavaScript, WAI-ARIA, SMIL, SVG, PDF, etc. Si es posible, a menudo es útil identificar también las bibliotecas y los componentes utilizados como Dojo o jQuery.
  • 2e: identificar otras páginas (o estados de páginas) relevantes para las personas con discapacidad o para la accesibilidad del sitio: páginas que explican características de accesibilidad; con información y ayuda sobre el uso del sitio; páginas donde se explica la configuración, preferencias, opciones o accesos directos o páginas con información de contacto, direcciones o instrucciones de soporte.

Paso 3. Seleccionar una muestra representativa

Lo ideal es que se evalúe el sitio completo, pero esto no suele ser posible, y se debe seleccionar una muestra de páginas que represente a todo el sitio, de manera que asegure que los resultados de la evaluación reflejan la accesibilidad de todo el sitio con suficiente fiabilidad.

El tamaño de la muestra dependerá del tamaño, complejidad o consistencia del sitio y de otros factores que se enumeran.

Los subpasos de los que se compone (a no ser que pueda hacerse la evaluación del sitio completo) son:

  • 3a: incluir una muestra estructurada, en concreto las páginas (y estados de páginas) que se identificaron en el paso 2. Las identificadas como relevantes (2a, 2e), las que además tienen funcionalidades esenciales (2b), diferentes tipos de páginas (2c) o que dependan de diferentes tecnologías (2d). La cuidadosa selección de las páginas puede reducir significativamete el tamaño de la muestra requerida manteniendo una representación adecuada de todo el sitio web.
  • 3b: incluir una muestra al azar, de páginas y estados de páginas que no forman ya parte de la muestra y que actúa como indicador de verificación de los resultados y aumenta la confianza en los mismos. Debe ser un 10%, debe seleccionarse dentro de todo el ámbito del sitio y sin seguir un patrón predecible. Han de documentarse cuáles son porque en el paso 4c se compararán con el resto de la muestra.
  • 3c: incluir en la muestra procesos completos. Es decir, todas las páginas de un proceso, no se puede seleccionar solo una página del proceso. Se describe con detalle cómo identificarlas y seleccionarlas.

Paso 4. Auditar la muestra seleccionada

Se debe verificar por cada página de la muestra (comparando la muestra estructurada y la muestra seleccionada al azar) si cumple con los cinco requisitos de conformidad de las WCAG 2.0, y si cumple con los criterios de conformidad del nivel de adecuación que se evalúa.

  • 4a: revisa todas las páginas iniciales. Comprueba que todas las páginas (o estados de página) de la muestra que no estén dentro o al final de un proceso se ajustan a los cinco requisitos de conformidad de las WCAG 2.0 de acuerdo al nivel de conformidad definido. Esto incluye todos los componentes sin activar ninguna función, introduciendo datos o de cualquier otra manera en la que se pueda interactuar con el contenido. Los componentes comunes como la cabecera o el pie no necesitan ser re-evaluados en cada página.Ten en cuenta las técnicas y errores comunes documentados en las WCAG 2.0 pero recuerda que no son normativos y puede haber más.Si no hay contenido relacionado con los criterios de éxito (por ejemplo, no hay vídeo), entonces los criterios son satisfechos. Opcionalmente se puede indicar específicamente los criterios de conformidad para los que no hay contenido relevante, por ejemplo, indicando «no presente».El contenido de las páginas o estados de páginas pueden tener versiones alternativas, en ese caso se evalúan juntas (la página y la versión alternativa) como una unidad.Comprueba que todas las características son soportadas por los navegadores y productos de apoyo definidos en el paso 1c.
  • 4b: evalúa todos los procesos completos seleccionados en el paso 3c, comprobando la funcionalidad, introducción de datos, notificaciones y otro tipo de interacciones. No es necesario evaluar todo el contenido, solo el que cambia a lo largo del proceso.En particular incluye:
    • la interacción con formularios, cuadros de diálogo y otros componentes de la página.
    • la confirmación de entrada de datos, los mensajes de error y otros feedback resultantes de la interacción con el usuario.
    • comportamiento con diferentes ajustes, preferencias, dispositivos y parámetros de interacción.
  • 4c: compara las páginas de la muestra que seleccionaste de forma estructurada con las páginas de la muestra que seleccionaste aleatoriamente. Comprueba que en la muestra al azar no hay contenidos o resultados no representados en la muestra estructurada, en caso contrario es que la muestra estructurada no era suficientemente representativa y debes volver a los pasos anteriores.

Paso 5. Registrar los resultados de la evaluación

Los resultados se presentan al final del proceso, pero se registran durante la evaluación. No todos los datos registrados se tienen o pueden incluir obligatoriamente después en el informe, por ejemplo por motivos de confidencialidad.

Los subpasos propuestos son:

  • 5a: proporcionar documentación para cada paso. Documentar los resultados de los pasos 1, 2, 3 y 4 para justificar los resultados y garantizar su transparencia y su replicabilidad. Esta documentación no es necesario que sea pública, dependerá del nivel de confidencialidad acordado.Se debe documentar al menos:
    • Acerca de la evaluación: nombre del evaluador, nombre de la persona/empresa/organización que ha solicitado la evaluación y la fecha en la que se ha llevado a cabo la misma (fecha concreta o periodo de tiempo)
    • Alcance de la evaluación: alcance definido en el paso 1a, el nivel de adecuación a evaluar definido en el paso 1b, el soporte de accesibilidad definida en el paso 1c y los requisitos adicionales definidos en el paso 1d.
    • Exploración del sitio: tecnologías de las que se depende definidas en el paso 2d. Opcionalmente las páginas y funcionalidades identificadas en los pasos 2a, 2b, 2c, 2e.
    • Muestra representativa: las páginas seleccionadas de acuerdo a los distintos subpasos del paso 3.
    • Auditoría de la muestra: evaluación de los resultados según los subpasos del paso 4.

    Los resultados del paso 4 se pueden dar por cada página o por toda la muestra en su totalidad, indicando si se cumple o no en toda la muestra y poniendo al menos un ejemplo por cada requisito de conformidad que no se cumple. Pero en los requisitos adicionales se pudo acordar un informe más detallado con todos los fallos de cada página y recomendaciones para solucionarlos.

  • 5b (opcional): registrar los detalles específicos de la evaluación, guardar las páginas y estados auditados, una captura de pantalla y las rutas; describir los ajustes, datos introducidos o acciones para llegar a las páginas o a un estado de las mismas; credenciales de acceso para poder replicar los datos y flujo de trabajo; registrar las herramientas, navegadores, tecnologías de apoyo u otro software (nombre y versión); métodos, procedimientos y técnicas utilizados para la auditoría. Suele ser un registro interno pero es una buena práctica por ejemplo en caso de conflicto.
  • 5c (opcional): proporcionar una declaración que describa el nivel de conformidad de los resultados. Como se ha indicado, en la mayoría de las situaciones esta metodología no permite una declaración de conformidad de acuerdo a las WCAG 2.0 de todo el sitio completo. Se puede hacer una declaración pública de los resultados si se cumple la metodología y el propietario del sitio web se compromete a velar por la exactitud y validez de la declaración de conformidad de la evaluación.

    La declaración de conformidad según esta metodología debe incluir: la fecha de la declaración; el título, versión y URI de las pautas utilizadas; el nivel de conformidad satisfecho; una descripción de las páginas para las que se efectúa la declaración (según paso 1a); una lista de tecnologías web de las que se depende (identificadas en el paso 2d); y el soporte de la accesibilidad como se define en el paso 1c.

    La declaración puede ser parcial, en cuyo caso deben indicarse las áreas que no son conformes y la razón (contenido de terceros o falta de soporte para la accesibilidad)

  • 5d (opcional): proporcionar una puntuación, que puede ser útil para controlar el progreso a través del tiempo. Señala que actualmente no hay un indicador ampliamente reconocido, fiable, preciso y práctico. De hecho pueden ser engañosos porque no proporcionan suficiente contexto e información para comprender el estado de la accesibilidad real sitio.El documento del W3C Research Report on Web Accessibility Metrics proporciona diferentes enfoques y sus limitaciones. En cualquier caso, si se incluye una puntuación, el método de puntuación debe indicarse siempre claramente junto a la puntuación y debería documentarse para facilitar la transparencia y fiabilidad.
  • 5e (opcional): proporcionar un informe legible por máquinas (como EARL)

Herramienta de apoyo para la generación del informe

WCAG-EM Report Tool

El W3C tiene una herramienta, online y gratuita, WCAG-EM Report Tool que:

  • ayuda a aplicar la metodología del W3C/WAI WCAG-EM (Website Accessibility Conformance Evaluation Methodology) de evaluación de accesibilidad de un sitio web de acuerdo a las WCAG 2.0;
  • genera el informe de la evaluación de accesibilidad a partir de los datos introducidos.

Herramienta de informe wcag-em

Accesibilidad en videojuegos: Buenas prácticas

Introducción

Como curiosidad y con la charla que dieron en el Openzink, he empezado a investigar más sobre la accesibilidad en videojuegos.

El CEAPAT ha publicado el documento «Buenas prácticas de accesibilidad en videojuegos«, un extensa recopilación de 250 páginas de experiencias y estudios realizados en España sobre la accesibilidad en videojuegos en los últimos años.

Accesibilidad en videojuegos: Buenas prácticas

El objetivo del documento, es identificar, reunir y difundir buenas prácticas que permitan aprender de los otros, promover soluciones innovadoras, exitosas y sostenibles a problemas compartidos, establecer relaciones entre las soluciones efectivas, la investigación y las políticas y proporcionar orientaciones para el desarrollo de iniciativas nuevas.

Voy a hacer un resumen del documento, enumerando las cosas más importantes.

Principales barreras de accesibilidad en videojuegos

Los jugadores reciben estímulos del juego y deben procesarlos y responder a ellos proporcio
nando input al juego, con el fin de superar diversas tareas y cumplir determinadas misiones para alcanzar su objetivo, al mismo tiempo que disfrutan jugando. Yuan et al. (2010) identifican tres problemas principales de accesibilidad en videojuegos debidos a su interactividad:
  1. La persona que juega no puede recibir estímulos, ya sean visuales, auditivos o táctiles.
  2.  No puede determinar cuál es la respuesta adecuada para realizar una acción concreta necesaria para avanzar en el juego.
  3. El jugador no puede proporcionar input al juego debido a que no puede manipular el dispositivo de interfaz entre el jugador y el videojuego, ya sea el ratón, el teclado, etc.

Dichas barreras de accesibilidad afectan a distintos usuarios de forma diferente.
Por ejemplo, los jugadores sordos no reciben los estímulos auditivos y los ciegos no reciben los visuales. Los jugadores con diversidad funcional cognitiva pueden experimentar dificultades para determinar la respuesta de juego si la velocidad del juego es demasiado rápida o si la dificultad del juego es elevada.

Estrategias para mejorar la accesibilidad en videojuegos

  • Fomentar el diseño para todos en la fase conceptual del desarrollo de los videojuegos, de modo que las opciones de accesibilidad se tengan en cuenta desde el principio y no impliquen costosas modificaciones posteriores.
  • Promover el desarrollo y el uso de los dispositivos de tecnología adaptativa, así como la compatibilidad de las distintas plataformas con ellos. Otro avance consistiría en el diseño de un mando con controles simplificados que fuera compatible con todas las plataformas de juego y todos los juegos. El precio de dichos dispositivos debería estar al alcance de todos para asegurar que nadie no pueda acceder a este tipo de tecnología por falta de medios económicos.
  • Implementar un sistema de información y etiquetaje, similar al de la clasificación por edades de PEGI, que indique las opciones y el grado de accesibilidad de cada videojuego, por ejemplo, si está subtitulado o no, si incluye modo de práctica, si hay diversos niveles de dificultad, etc.
  • Concienciar a diferentes colectivos sobre la necesidad de mejorar el panorama de accesibilidad a los videojuegos mediante campañas de información dirigidas a la industria y el público, organización de eventos, conferencias, notas de prensa, etc.
  • Elaborar normas oficiales (UNE, ISO) que propongan pautas para mejorar la accesibilidad en videojuegos y se conviertan en un referente para la industria.
  • Fomentar la investigación interdisciplinar en el campo de la accesibilidad a los videojuegos

Recomendaciones generales de accesibilidad en videojuegos

  • Debe respetarse la zona de escritura segura para texto
  • La fuente empleada no debe distorsionarse y se debe utilizar un tamaño suficiente para asegurar la correcta legibilidad del texto.
  • Número de fuentes que se utilizan y su correcto visionado
  • Lenguaje claro y sencillo
  • Color y Contraste
  • Armonía de colores que no perjudique la lectura

Además la metodología desarrolla aspectos como:

  • Configuración de interfaz
  • Navegación
  • Menús de navegación
  • Imágenes e iconos

Accesibilidad y Jugabilidad

La accesibilidad y la jugabilidad van de la mano en pos de conseguir una mejor experiencia de usuario. Es importante destacar que si un videojuego es accesible pero tiene problemas de jugabilidad, no causará suficiente diversión y entretenimiento a los jugadores, será un juego que fracasará como tal, al no cumplir su principal objetivo.

Por otro lado, si un videojuego es jugable pero no es accesible, un conjunto de jugadores pueden verse limitados provocando frustración.

Soluciones existentes de acceso alternativo a los videojuegos

  1. Adaptaciones mecánicas de mandos de videojuegos basados en el movimiento natural. Como la Wii, Kinect. Sin embargo, su uso para personas con una grave diversidad funcional, queda limitado a un uso terapéutico, no competitivo.
  2. El acceso al ordenador como forma de acceso al videojuego. Una forma de acceder a los videojuegos es a través de un ordenador y podemos encontrar dispositivos de acceso como joysticks, ratones de bola, sistemas de seguimiento de la cabeza o incluso de la mirada.
  3. Mandos específicos para personas con diversidad funcional.

Recomendaciones para el subtitulado en videojuegos

  • Subtitular todos los elementos con audio en el texto: diálogos, tutorials con audio, sonidos ambientales, canciones, etc.
  • Utilizar fuentes fáciles de leer: Permitir al usuario ajustar el tamaño de la fuente. 
  • Asegurarse de que los subtítulos pueden leerse bien
  • Usar un máximo de 45 caracteres por línea
  • Limitar el número de líneas de los subtítulos a dos. Permitir la activación y desactivación de los subtítulos.
  • Hay que asegurarse de que haya un buen contraste entre los subtítulos y el fondo.
  • Utilizar etiquetas con el nombre de los personajes para facilitar su identificación.
  • Sincronizar los subtítulos con la imagen y el audio.

Y muchísimas cosas más, no lo puedo poner entero porque el documento es muy amplio, pero no tiene desperdicio. Se hace muy ameno y es fácil de entender.

Guía de accesibilidad para videojuegos.

Y para no perder la costumbre, y seguir el ejemplo de buenas prácticas para la accesibilidad de videojuegos, os dejo aquí una guía de vídeojuegos, Game Accesibility Guidelines, que está dividida en tres niveles: Básico, intermedio y avanzado. El documento está en inglés, pero es muy interesante