Medidas de accesibilidad en muchas formas

La accesibilidad es una variedad de cosas, por favor considere lo siguiente:

• Algo debería ser comprensible: Eso quiere decir textualmente, visualmente, lógicamente y en complejidad.
• Algunos usuarios necesitan un lector de pantalla para interactuar, también, sino más comunes son: una lupa, alto contraste, software texto a voz (text-to-speech), ajustes CSS personalizados o un teclado/dispositivo de entrada especial.
• Debe ser accesible; capacidad de respuesta, asequibilidad, ubicación, lenguaje, hardware, etc.

En resumen, la accesibilidad no es sólo accesibilidad de teclado o sólo accesibilidad de lector de pantalla. A menudo nos enfocamos en esos dos porque, tradicionalmente, son más fáciles de pasar por alto. Pero estos asuntos también son solucionables y a menudo proporcionan las bases para cualquier otra clase de mejoras posibles.

Algunos problemas de accesibilidad tienden a ser problemas con el diseño del producto, elecciones estratégicas, audiencia objetivo, etc. Como éstas áreas son mas difífiles de capturar en reglas escritas que puedan ser aplicadas universalmente a todo el ecosistema de MediaWiki, las mismas se encuentras fuera del alcance de éste documento.

Navegación de teclado

Llamamos a esto navegación de teclado, pero lo que realmente quiere decir es: No dependa de un dispositivo apuntador (touch, mouse).

• La navegación de teclado es manipular el enfoque del sitio y ejecutar acciones utilizando su teclado.
• Elementos en los que se puede utilizar el Tabulador, pueden recibil el foco del cursor, pero no en todos los elementos que pueden recibir el foco del cursor, se puede utilizar el tabulador.
• Todo lo que sea capaz de hacerse con un mouse debería ser posible con un teclado.
• La información de la navegación de teclado puede ser usada por los lectores de pantalla para mejorar su experiencia.

Lector de pantalla

• Un lector de pantalla utiliza un 'cursor' diferente, que generalmente recorre la estructura lógica del DOM.
• El foco tiende a seguir el cursor de lector de la pantalla y viceversa, pero no son iguales.
  • Puedes realizar un seguimiento del elemento enfocado al establecer una expresión en vivo en Chrome
• Un lector de pantalla utiliza el 'accesibilidad' APIs, el cual te podría considerar para ser una producción/de entrada 'vista' arriba del normal DOM.
• ARIA son anotaciones DOM que mejoran o manipulan la forma en que la lógica DOM se transforma en las API de accesibilidad. No es una alternativa escribir apropiadamente en HTML y Javascript. ¡La navegación de teclado es sencillamente conseguida por orden lógico el DOMǃ Para obtener más información sobre ARIA, consulte w3.org explicación y MDN explicación.
• Un lector de pantalla no está limitado a navegar por la estructura lógica DOM, solo es por efecto.
  • Un lector de pantalla puede leer lo que está bajo el puntero del ratón por caso.
  • VoiceOver para iOS usa un cursor de pantalla que es manipulado por posicionamiento de pulgar y gestos en la pantalla táctil.
  • La mayoría de software de lectura de pantalla tiene modos de navegación adicionales, donde puedes listar y navegar por áreas de referencia, una tabla de contenidos auto-generada, o incluso marcadores definidos por el usuario dentro de una página.
• A partir del punto anterior de los múltiples métodos de navegación, se sigue: Hay un principio y un final, pero también izquierda, derecha, arriba y abajo. No deberías confiar demasiado en ellos en tu comunicación, pero tampoco necesitas negar completamente su existencia. No confundan las capacidades visuales del usuario con la conciencia espacial que el lector de pantalla podría transmitir al usuario. Ejemplo:
  1. una frase larga [imagen] la imagen anterior muestra... Still acceptable
  2. una frase larga [imagen] la imagen izquierda muestra, la imagen derecha muestra... Still acceptable
  3. una frase larga [imagen] la imagen derecha muestra, la imagen izquierda muestra... Not acceptable
  4. una frase larga [imagen] la imagen anterior muestra... Not acceptable
  5. una frase larga [imagen][imagen][image] la imagen izquierda muestra, la imagen derecha muestra... Not acceptable
  6. una frase larga [imagen] algo totalmente diferente. La imagen izquierda muestra, la imagen derecha muestra... Definitely not acceptable

Hacer uso o proporcionar siempre

Elementos HTML semánticos adecuados

Utilice los elementos HTML para su propósito previsto. Por ejemplo:

• Usa ‎<button> y no ‎<div> o ‎<span> o ‎<a> con un manipulador de clics
• Si siente la necesidad de atrever algo, considere si no es más apropiado usar un encabezado o un elemento de strong

Estructura lógica de la partida

Todas las páginas deben tener siempre una estructura lógica y coherente de encabezado. Los encabezados son una de las herramientas de navegación primarias utilizadas por los usuarios de lectores de pantalla.

1. No debe haber brechas en la configuración de los niveles de las direcciones. (Así que no hay H2->H4.)
2. Las titulares deben ser descriptivos
3. Las posiciones deben ser únicas en su propio nivel. (No debe haber dos H3s con el mismo contenido bajo la misma sección H2)
4. Debe haber una separación entre la navegación y el contenido

alt atributo para imágenes con valores significativos

Si una imagen es decorativa, use un valor vacío explícito para el atributo alt; aún mejor, conviértelo en una imagen de fondo CSS.

El alt de imagen suele tener prioridad sobre el atributo de título de las imágenes e incluso sobre el atributo de título de los enlaces que envuelven una imagen.

title atributo para enlaces

Estos se muestran generalmente como las puntas de herramienta

Solo utilice títulos si difieren del texto del enlace.

La mayoría de los títulos de enlace no son hablados por lectores de pantalla, a menos que el lector haya sido configurado explícitamente de esta manera.

lang, dir y hreflang atributos

Usando lang y hreflang permite seleccionar una voz adecuada en los lectores de pantalla, elige la corrección ortográfica correcta en los navegadores, etc.

Contraste suficiente

Siempre compruebe sus colores para el contraste suficiente. Para el texto, se necesita un contraste más alto para el texto más pequeño (debido al antialiasing).

Enfoque para la navegación en teclado

No no eliminar contorno de los elementos enfocables a menos que defina su propio contorno para el estado :focus.

• No uses outline: 0 de lo contrario.
• Si defines una clase pseudo, como :hover o :active, por favor también defínese un estilo de :focus.

Navegación en teclado

Los elementos interactivos de una página deben ser navegables mediante teclado. Por favor, asegúrese de que la navegación con la tecla de pestaña esté habilitada en su navegador y le permita controlar cada elemento interactivo sin usar un dispositivo de señalización.

1. Utilice tabIndex: 0 para hacer accesibles los elementos de teclado, que no son accesibles implícitamente (cualquier cosa excepto ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
   1. En este caso también añadir un manejador de eventos keydown que responda a Enter (keyCode 13) y espacio (keyCodes 32).
2. Utilice tabindex: -1 para eliminar elementos de la accesibilidad. (utilice esto en enlaces que son etiquetas para la acción dentro de un ‎<li>...‎</li> por ejemplo)
3. Los elementos que son implícitamente accesibles en teclado se reenviarán a la tecla de entrada/espacio hacia abajo al manejador de clics

Diálogos, etc.

Cuando no se cuida bien la accesibilidad, los diálogos son algunos de los elementos más inaccesibles para los usuarios de lectores de pantalla y teclados. Pasen un tiempo en esto.

• El elemento que abre el diálogo debe tener aria-haspopup
• El diálogo en sí mismo debe tener role=[dialog | alertdialog | tooltip]
• El diálogo debe insertarse en orden DOM, ^[1] o aria posee/controla necesita especificar esta relación entre el elemento de apertura y el diálogo
• Al abrir el diálogo, recuerde el último elemento enfocado y cambia el enfoque al primer elemento de control enfocable dentro del diálogo
• Cuando el diálogo es modal, impida interactuar con el resto de la página
  • Captura los clics fuera del diálogo e ignoralos o deja que desechen el diálogo
  • Asegúrese de que no puede pestañear enlaces o elementos de entrada fuera del diálogo
  • Hacer que los elementos fuera del diálogo sean inaccesibles para el lector de pantalla, utilizando aria-hidden
• Asegúrese de que haya un modo de cierre (clave Esc y un botón de cierre enfocable con un título descriptivo)
• Cierre debe devolver el enfoque (teclado) al punto de enfoque original que guardó cuando abrió el diálogo. Para que los lectores de pantalla vuelvan al mismo punto, asegúrese de especificar el derecho [propietario de http://www.w3.org/WAI/PF/aria/states_and_properties#aria-owns] del diálogo, si no ha insertado el diálogo en orden DOM.
• Lea más: Aria módiles, Aria diálogo módiles ARIA diálogo no módiles, ARIA herramientas de tips.

WCAG 2.1 directrices

Sigue donde sea posible

Y sus documentos de acompañamiento:

• Una guía para comprender e implementar las Directrices 2.0 de accesibilidad de contenido web
  • Suplemento WCAG 2.1
• Técnicas y fallos de las Directrices de accesibilidad de los contenidos web 2.0
  • Suplemento WCAG 2.1

No

• Hay un consejo común de usar left: -1000px para empujar algo (a menudo las etiquetas de los botones de icono) fuera del puerto de visualización para los usuarios visuales y mantenerlo en el DOM de accesibilidad. text-indent: -9999px es una variante de esto. Es un mal consejo.
  • Esto rompe nuestra representación RTL en varios navegadores. Específicamente en el modo rtl crea un gran lienzo a la izquierda del puerto de vista y las barras de desplazamiento, casi como +1000px crearía en el modo ltr. (Si es necesario, se prefiere top: -1000px sobre left: -1000px para evitar esto.).
  • VoiceOver en móvil no puede utilizar este texto como retroceso, ya que es un lector de pantalla "posicional". No puede mover el dedo sobre este texto y, por lo tanto, tampoco se leerá el texto. (la etiqueta de aire es a menudo la mejor opción).
  • Por último, esto amplía la superficie de renderización necesaria para calcular la página web final y esto puede afectar el rendimiento de en dispositivos móviles.
  • Un resumen de los trucos de 'ocultar texto fuera de pantalla' es dado por Jonathan Snook.
• Las cosas no deben repetirse a menudo. Si tienes 100 enlaces en una página que puede abrir un diálogo, entonces no añadas 100 etiquetas a esos 100 enlazos diciendo al usuario que se puede usar para abrir un diálogo. Decirle al usuario cómo usar/qué hacer con la interfaz es bueno, hacerlo de forma consistente es simplemente molesto. Encuentra una manera diferente de explicarlo una vez (¿en este caso podría ser una idea un aria-live=polite?).
• <a href="#">Hide</a> con un manejador de clic. VO lee tal JS como "Escondir el enlace interno". Utilice un botón adecuado, o <a role="button" tabindex="0">Hide</a>, con los controladores de teclas 'Space' y 'Enter' en el clic en. Pero no hay atributo href.
• No anidar la funcionalidad interactiva dentro de otro elemento interactivo (enlaces o botones dentro de enlaces). Esto confunde a los lectores de pantalla.

Evite

Símbolos de Unicode

La mayoría de las tecnologías de asistencia no son buenas con los símbolos. Por lo tanto, trate de evitar caracteres como ↑, → o caracteres más complejos, porque muchos lectores de pantalla no los entenderán. Si son necesarios, trate de envolver con un elemento de espacio con el atributo título, para que el atribudo título pueda comunicar el significado implícito dentro del contexto al lector.

Fuentes pequeñas

Se prefiere la legibilidad. Si haces algo tan pequeño que es difícil de leer, ¿lo necesitas para empezar? También evite las fuentes pequeñas con valores de contraste bajos o mediocres (incluso si se encuentran dentro de las pautas de WCAG, los tamaños pequeños requieren contraste más explícito que los tamaños grandes, especialmente con antialiasing habilitado).

Fuentes inusualmente grandes

Si haces el texto mucho más grande de lo normal, puede ser igual de difícil de leer (a menos que sea muy corto). Esto se aplica principalmente al texto corporal, o cualquier cosa que ocupa más de un par de líneas. Pero cuanto más grande sea el texto, más líneas tendrá.

tabIndex > 0

La orden DOM es preferida siempre que sea posible. La orden de la DOM proporciona el contexto de las acciones.

Con solución alternativa

Tradicionalmente, lograr una accesibilidad "completa" ha requerido muchas soluciones para el propio html, los navegadores e incluso un software específico de lectura de pantalla. Sin embargo, estas soluciones a menudo vienen con efectos secundarios, hacen uso de errores o comportamientos no especificados y inevitablemente crean deuda técnica.

MediaWiki, debido a los usuarios que busca servir, la cantidad de código, su (falta) de fondos, etc. tiende a preferir el código de prueba futuro al código que se rompe fácilmente. Como tal, en general evita soluciones a problemas, aunque eso pueda limitar a veces la accesibilidad que podemos ofrecer. Las decisiones sobre esto a menudo están influenciadas por la audiencia relativa de la función en MediaWiki. Si algo es omnipresente para todos los usuarios, una solución de trabajo es más garantizada que si la función afectada solo es utilizada por una pequeña parte de la audiencia (por ejemplo, leer una página vs modificar la configuración de la instalación).

Considera

• Roles de la ARIA
  • Si un div o span se comporta como un botón real, use role="button". También role="dialog" y role="alert"
  • Ten cuidado cuando compartas tablas. Por ejemplo, no agregue role="button" a un elemento de ‎<th>, ya que el elemento de ‎<th> tiene un role="columnheader", que será superwritto. En su lugar, usa elementos anidados. Del mismo modo para ‎<li> que tiene un implicito role="listitem"
  • Si un botón crea un diálogo emergente, utilice aria-haspopup.
  • Utilice aria-labelled-by para contextos donde esto no es totalmente lógico por sí mismo (así que en todas partes excepto para las etiquetas en los formularios y los encabezados en las tablas).
• Evite las tablas para diseño y prueba en anchos de pantalla más pequeños.
• cosas ocultas: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
• saltar/salto a los enlaces