Barreras que se crean cuando se usa mal ARIA para mejorar la accesibilidad

En Best intention barriers (ARIA edition) se indican varias barreras que se crean cuando se usa mal ARIA para mejorar la accesibilidad:

• Adding aria-label as some form of accessible description
• Adding an ARIA Role is enough, or: Adding ARIA implements functionality
• Roles that are not what you think they are

ARIA puede ayudar a la accesibilidad web, pero también la puede dañar

En ARIA can hurt or help web accessibility: How to review your website’s ARIA se advierte de los peligros que tiene el mal uso de ARIA:

Not all HTML elements have accessibility built into them. So, we use ARIA to add accessibility when a native HTML element cannot do the job.

When used correctly, ARIA can help people with disabilities access and use your website – when used correctly. Unfortunately, it’s misused all over the web.

Using ARIA incorrectly can actually make your website more inaccessible. It can unintentionally hide content from assistive technology, announce the wrong label, and cause functionality confusion for assistive tech users.

To actually make a more accessible web experience for all users, ARIA needs to be used correctly. A great place to start is looking at the ARIA your own website already uses.

Going through your own website’s ARIA can make it more accessible while also giving you a chance to learn more about ARIA (nothing like a hands-on learning experience).

WAI-ARIA 1.2 ya es una recomendación

El 6 de junio de 2023 se publicó la versión definitiva de Accessible Rich Internet Applications (WAI-ARIA) 1.2.

Las diferencias respecto a WAI-ARIA 1.1 están recogidas en B. Substantive changes since the WAI-ARIA 1.1 Recommendation.

Análisis de aria-describedby (ARIA)

En Accessible Description Exposure, un análisis excepcional sobre el uso del atributo aria-describedby de ARIA. En el análisis, se han probado diferentes elementos de HTML, diferentes lectores de pantalla y diferentes navegadores web.

¿Qué pasa si una imagen tiene aria-lable, aria-labelledby, alt y title?

 Para que una página web sea accesible, es necesario garantizar que cada elemento de la página tenga un "nombre". El nombre se puede definir de varias formas, pero ¿qué pasa cuándo se emplean varios mecanismos para definir el nombre?

En HTML Accessibility API Mappings 1.0 se explica cómo se calculan las propiedades de accesibilidad de cada elemento HTML.

Por ejemplo, en el caso de la imagen, podemos leer en 5.10 img Element:

5.10.1 img Element Accessible Name Computation

1. If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use alt attribute.
3. Otherwise use title attribute.
4. If none of the above yield a usable text string there is no accessible name.

5.10.2 img Element Accessible Description Computation

1. If the element has an aria-describedby attribute the accessible description is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the title attribute if it wasn't used as the accessible name.
3. If none of the above yield a usable text string there is no accessible description.

Las cinco reglas de ARIA

En Using ARIA:

1. First Rule of ARIA: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
2. Second Rule of ARIA Use: Do not change native semantics, unless you really have to.
3. Third Rule of ARIA Use: All interactive ARIA controls must be usable with the keyboard.
4. Fourth Rule of ARIA Use: Do not use role="presentation" or aria-hidden="true" on a focusable element.
5. Fifth Rule of ARIA Use: All interactive elements must have an accessible name.

Y en español:

1. Primera regla de ARIA: si puede usar un elemento o atributo HTML nativo con la semántica y el comportamiento que ya necesita, en lugar de reutilizar un elemento y agregar un rol, estado o propiedad de ARIA para hacerlo accesible, entonces hágalo.
2. Segunda regla de ARIA: no cambie la semántica nativa, a menos que realmente tenga que hacerlo.
3. Tercera regla de ARIA: todos los controles interactivos de ARIA deben poder utilizarse con el teclado.
4. Cuarta regla de ARIA: no use role="presentation" o aria-hidden="true" en un elemento enfocable.
5. Quinta regla de ARIA: todos los elementos interactivos deben tener un nombre accesible.

Landmarks

Landmarks es una fantástica extensión para varios navegadores web que permite navegar por las áreas de una página web.

La primera regla de ARIA

Conviene recordar la primera regla de WAI-ARIA (2.1 First Rule of ARIA Use):

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. 

Under what circumstances may this not be possible?

• If the feature is available in HTML [HTML51] but it is not implemented or it is implemented, but accessibility support is not.

• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.

• If the feature is not currently available in HTML.

Las cinco reglas de ARIA

En Using ARIA:

1. First Rule of ARIA: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
2. Second Rule of ARIA Use: Do not change native semantics, unless you really have to.
3. Third Rule of ARIA Use: All interactive ARIA controls must be usable with the keyboard.
4. Fourth Rule of ARIA Use: Do not use role="presentation" or aria-hidden="true" on a focusable element.
5. Fifth Rule of ARIA Use: All interactive elements must have an accessible name.

Y en español:

1. Primera regla de ARIA: si puede usar un elemento o atributo HTML nativo con la semántica y el comportamiento que ya necesita, en lugar de reutilizar un elemento y agregar un rol, estado o propiedad de ARIA para hacerlo accesible, entonces hágalo.
2. Segunda regla de ARIA: no cambie la semántica nativa, a menos que realmente tenga que hacerlo.
3. Tercera regla de ARIA: todos los controles interactivos de ARIA deben poder utilizarse con el teclado.
4. Cuarta regla de ARIA: no use role="presentation" o aria-hidden="true" en un elemento enfocable.
5. Quinta regla de ARIA: todos los elementos interactivos deben tener un nombre accesible.

La primera regla de ARIA

La primera regla de ARIA es bien sencilla: no uses ARIA.

Lo podemos leer en 2.1 First rule of ARIA use:

If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Cómo usar ARIA de forma efectiva con HTML5

El artículo How to Use ARIA Effectively with HTML5 explica cómo se debe usar ARIA con HTML5.

En este artículo se repasa el uso de los roles, de los atributos y unas reglas básicas:

• Utiliza la semántica de HTML siempre que sea posible.
• Un elemento sólo puede tener un role.
• No cambies la semántica nativa de los elementos.

Uso del atributo aria-owns

En el artículo Using the aria-owns attribute se explica el uso del atributo aria-owns. Este atributo es útil para indicar una relación de dependencia padre/hijo que puede ser clara en la presentación visual, pero que puede no existir realmente en la estructura de la página, es decir, que no existe en el DOM.

Por ejemplo, puede ser útil para definir relaciones de dependencias en listas anidadas.

Duplicación de los roles con ARIA

Todos los elementos de HTML poseen un rol nativo que es expuesto a los productos de apoyo como los lectores de pantalla.

ARIA permite modificar el rol nativo de cualquier elemento. Por ejemplo, con ARIA se puede convertir un simple

en un botón... ¡pero no se tiene que hacer, aunque se pueda!

Una duda que a veces surge es si se debe añadir el rol a aquellos elementos que ya lo tienen. Por ejemplo, ¿conviene escribir button role="button" o input role="checkbox" type="checkbox"?

No, no conviene hacerlo porque no aporta ninguna ventaja, pero sí que puede ocasionar algunos problemas.

Como identificar que un enlace o botón abren una ventana nueva

En WCAG 2.0 no existe un requisito de accesibilidad que indique que se tenga que hacer, pero es una buena práctica.

La típica forma es añadir un icono con forma de ventana y una flecha que indica que se abre una ventana nueva. Pero existe una forma mejor.

En ARIA existe la propiedad aria-haspopup="true". En la especificación oficial podemos leer sobre aria-haspopup lo siguiente:

Indicates that the element has a popup context menu or sub-level menu.
This means that activation renders conditional content. Note that ordinary tooltips are not considered popups in this context.
A popup is generally presented visually as a group of items that appears to be on top of the main page content.

Si se añade aria-haspopup="true" a un enlace o a un botón, los lectores de pantalla modernos anunciarán que el enlace o el botón se abren en una ventana nueva al activarse.

Resumen de ARIA

Accessible Rich Internet Applications (WAI-ARIA) 1.0 es una recomendación del W3C que tiene como objetivo mejorar la accesibilidad de las interfaces web avanzadas.

En The ARIA Role Conformance Matrices se resumen los roles con sus atributos, obligatorios y opcionales, junto con una nota sobre la implementación.

Etiquetar una lista para que sea más significativa

Muy interesante la propuesta de usar aria-labelledby para darle contexto a una lista: Use aria-labelledby to provide context to unordered lists.

En el siguiente vídeo se muestra lo que se logra:

Uso de ARIA en HTML

Existen dos documentos sobre el uso de WAI-ARIA en HTML.

Por un lado tenemos Using WAI-ARIA in HTML, que tiene como resumen:

This document is a practical guide for developers on how to add accessibility information to HTML elements using the Accessible Rich Internet Applications specification [WAI-ARIA], which defines a way to make Web content and Web applications more accessible to people with disabilities. This document demonstrates how to use WAI-ARIA in [HTML5], which especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

Por otro lado tenemos el documento ARIA in HTML que es simplemente un working draft, y que tiene como resumen:

This specification defines the web developer rules (author conformance requirements) for the use of [wai-aria-1.1] attributes on [HTML51] elements. It also defines requirements for Conformance Checking tools.

Controles de usuario accesibles con HTML5, JavaScript y ARIA

Interesante el vídeo Fluent 2015: Custom interfaces with aria html and javascript - Léonie Watson, presentado en la reciente conferencia Fluent organizada por O'Reilly.

El vídeo tiene subtítulos en inglés, pero aparecen etiquetados como Afrikaans (WTF!).



La conferenciante es ciega, lo que se oye a veces de fondo es su lector de pantallas cuando pasa de diapositiva.

Navegación por landmarks en Mozilla Firefox

Los landmarks, regiones o puntos de referencia (Easy ARIA Tip #4: Landmarks) es una característica definida en WAI-ARIA que permite definir puntos especiales en una página web a los que luego se puede navegar directamente.

Los landmarks se añaden a cualquier elemento de HTML con el atributo role y un valor que representa la semántica del landmark: application, banner, complementary, contentinfo, main, navigation, search.

En HTML5 existen nuevas etiquetas que ya incorporan la semántica de los landmarks: header (banner), nav (navigation), main (main), aside (complementary) y footer (contentinfo).

Los navegadores más populares no proporcionan un mecanismo para visualizar y acceder a los landmarks. Sin embargo, los lectores de pantalla como JAWS y NVDA sí que son capaces de ello.

Como podemos leer en Bug 670928 - HTML5 element and WAI-ARIA landmark roles easily navigable in Firefox, el soporte de los landmarks en Mozilla Firefox es algo que se lleva discutiendo varios años.

Existen dos complementos, el de David Todd del 21/5/2013 y el de Matthew Atkinson (Enabling landmark-based keyboard navigation in Firefox) del 10/1/2014, que permiten utilizar los landmarks en Mozilla Firefox. Este último parece que está desarrollado a partir del primero. He probado los dos y no encuentro ninguna diferencia entre ellos. Por defecto, la tecla "n" permite navegar al siguiente landmark y la tecla "p" al anterior. Los cuadro de diálogos son prácticamente iguales:

Este complemento añade una opción al menú Herramientas que permite visualizar y navegar a los landmarks:

Referencia sobre ARIA de Microsoft

Accessible Rich Internet Applications (ARIA) es la referencia de Microsoft sobre ARIA.