Jump to content

Guía de accesibilidad para desarrolladores

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 66% complete.
Languages:

La accesibilidad es importante para nuestros usuarios y podemos mejorarla si tenemos en cuenta algunas ideas y reglas básicas. La accesibilidad es difícil en la medida en que no existen estándares técnicos fijos y universalmente aceptados que realmente funcionen de manera consistente y para todos los usuarios. Esta página no enumera ni discute problemas específicos de accesibilidad en MediaWiki. Intenta centrarse en las opciones tecnológicas y en lo que se debe y no se debe hacer para prevenir problemas de accesibilidad.

En términos de desarrollo, creo que este debería ser nuestro libro de reglas:

  • Intentar habilitar a nuestros usuarios (y eso significa a todos ellos)
  • Intentar evitar los problemas de accesibilidad si es posible, pero no a toda costa
  • We should use an approach of Progressive enhancement over that of Graceful degradation.
  • Implementar cosas que son tecnológicamente apropiadas.

Como funciona la accesibilidad

Algunos conceptos importantes que te tendría que mantener en mente.

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.

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 [1]
  • 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

Versiones de desarrollo

Existen varias normas sobre accesibilidad y, honestamente, casi todas ellas, aunque son sólidas en la identificación de problemas, todavía presentan problemas significativos en cuanto a soluciones técnicas (Tienen una alta proporción de "desagravamientos feos"). Esto ha sido causa de mucha controversia en las comunidades. Como tal, debemos identificar cosas no controvertidas que simplemente siempre (o nunca) debemos hacer y por qué. Es mucho más fácil alcanzar ciertos objetivos si separamos las cosas no controvertidas de las cosas controvertidas.

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. (There should not be two H3s with the same content under the same H2 section)
  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
Do not remove outline from focusable elements unless you define your own outline for the :focus state.
  • 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 controlador de despegue de llave que responde a Enter (keyCode 13) y espacio (keyCodes 32).
  2. Use tabindex: -1 to remove elements from accessibility. (use this on links that are labels for the action inside an ‎<li>...‎</li> for instance)
  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]
  • The dialog should be inserted in DOM order,[1] or aria owns/controls needs to specify this relation between opening element and dialog
  • 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:

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 [2] 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. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an aria-live=polite might be an idea in this case ?).
  • <a href="#">Hide</a> with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. But no href attribute.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). This confuses screen readers.

Evite

Unicode symbols
Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
Small fonts
Legibility is preferred. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
Unusually large fonts
If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
tabIndex > 0
DOM order is preferred wherever possible. DOM order provides context for the actions.
Workaround
Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

Considera

  • ARIA Roles
    • If a div or span behaves like an actual button use role="button". also role="dialog" and role="alert"
    • Be careful with roles. For instance, don't add role="button" to a ‎<th> element, since the ‎<th> element has an implicit role="columnheader", which will be overwritten. Instead use nested elements. Similarly for ‎<li> which has an implicit role="listitem"
    • If a button creates a popupdialog, use aria-haspopup.
    • Use aria-labelled-by for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
  • Avoid tables for layout purposes and test on smaller screen widths.
  • hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/jump to links

Véase también

Referencias

  1. ↑ See DOM order at w3.org and Style order Property at w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/es&oldid=6820990"