WAI-ARIA 1.2. Novedades de la nueva versión del estándar Accessible Rich Internet Applications (WAI-ARIA), de 6 de junio de 2023

En este artículo enumero y explico detalladamente todas las novedades de la nueva versión del estándar WAI-ARIA: Accessible Rich Internet Applications (WAI-ARIA) 1.2, recomendación desde el 6 de junio de 2023.

Me parece que fue ayer cuando escribía el artículo explicando las novedades de la versión 1.1, pero ya han pasado más de cinco años: Novedades WAI-ARIA 1.1, Usable y accesible, 22/12/2017.

Este artículo parte de la base de que conoces el estándar WAI-ARIA, imprescindible hoy en día para hacer accesible un portal web para los productos de apoyo, como un lector de pantalla, y para realizar una auditoría de accesibilidad web.

Si no estás familiarizado con el estándar, puedes consultar los artículos introductorios sobre WAI-ARIA.

Nuevo rol "caption"

Se añade el rol caption para definir el nombre visible de los siguientes roles:

figure
table
grid
treegrid

El rol caption puede nombrar, o nombrar y describir.

En cualquiera de estos roles, caption debe ser un hijo directo y ser el primer hijo de forma obligatoria, salvo en el rol figure, donde puede ser el primero hijo o el último.

Estos roles, además, deberían tener un atributo aria-labelledby que haga referencia al caption.

Si el caption incluye una descripción, entonces el atributo aria-labelledby solo hará referencia a la parte que tiene el nombre, y se añadirá un atributo aria-describedby para hacer referencia al texto que funciona como descripción.

En el propio rol caption está prohibido usar aria-label o aria-labelledby.

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">Contest Entrants</div>
     <div id="desc">
       This table shows the total number of entrants (500) the
       contest accepted over the past four weeks.
     </div>
   </div>
   <!-- ... -->

Ejemplo de código del estándar WAI-ARIA 1.2

Consulta el rol "caption" en ARIA 1.2.

Nuevo rol "code"

El nuevo rol code permite definir un fragmento de código, es decir, es el equivalente a la etiqueta HTML <code>.

La especificación indica que los productos de apoyo deberían asegurar la lectura completa de la puntuación dentro de un contenido marcado con code. De este modo se garantiza su comprensión.

Consulta el rol "code" en ARIA 1.2.

Nuevo rol "time"

El nuevo rol time permite definir un punto específico en el tiempo.

Todavía no tiene una propiedad equivalente al atributo datetime de la etiqueta HTML equivalente, <time>, pero se prevé incluirla en la versión ARIA 1.3. Por ahora marcaría una cadena válida con la fecha o la hora.

Consulta el rol "time" en ARIA 1.2.

Nuevos roles "subscript" y "superscript"

Con el nuevo rol subscript podemos marcar un subíndice, es decir, es el equivalente a la etiqueta HTML .

Con el nuevo rol superscript podemos marcar un superíndice, es decir, el equivalente a la etiqueta HTML .

No deben usarse para aspectos de presentación, sino cuando se usan para marcar convenciones tipográficas que tienen significados específicos.

Por ejemplo, en 10³, el significado cambia si el "3" está o no marcado como superíndice.

Consulta el rol "subscript" en ARIA 1.2.

Consulta el rol "superscript" en ARIA 1.2.

Nuevos roles "insertion" y "deletion"

Con el nuevo rol insertion definimos un contenido agregado, o que se sugiere agregar, es decir, es el equivalente a la etiqueta HTML <ins>.

Por el contrario, con deletion definimos un contenido eliminado, o que se sugiere eliminar, es decir, es el equivalente a la etiqueta HTML <del>.

Es habitual utilizarlos para marcar las diferencias entre dos versiones de un contenido, o para marcar sugerencias en la revisión de un documento.

Consulta el rol "insertion" en ARIA 1.2.

Consulta el rol "deletion" en ARIA 1.2.

Nuevos roles "strong" y "emphasis"

Con el nuevo rol strong definimos un contenido importante, serio o urgente, es decir, es el equivalente a la etiqueta HTML . Igual que la etiqueta HTML, este rol no debe usarse para cambios en la presentación del contenido, sino solo si su ausencia cambiaría el significado.

Por su parte, el nuevo rol emphasis permite transmitir énfasis y es el equivalente a la etiqueta HTML. Tampoco debe usarse para comunicar cambios en la presentación que no impacten en el significado.

Recuerda que no es lo mismo transmitir importancia que énfasis: "Voy a nadar todos los días."

Consulta el rol "strong" en ARIA 1.2.

Consulta el rol "emphasis" en ARIA 1.2.

Nuevo role "blockquote"

Con el nuevo rol blockquote definimos una sección de contenido que es una cita, es decir, es el equivalente a la etiqueta HTML <blockquote>.

Consulta el rol "blockquote" en ARIA 1.2.

Nuevo role "paragraph"

Con el nuevo rol paragraph definimos un párrafo, es decir, es el equivalente a la etiqueta HTML .

Consulta el rol "paragraph" en ARIA 1.2.

Nuevo rol "meter"

El nuevo rol meter permite definir un elemento que representa una medida escalar dentro de un rango conocido o fraccionado, es decir, es el equivalente a la etiqueta HTML <meter>.

No se debe utilizar para indicar progreso, porque para ello ya está el rol progressbar.

Consulta el rol "meter" en ARIA 1.2.

Nuevo rol "generic"

Este nuevo rol permite definir un elemento contenedor que no tiene significado semántico, como son en HTML las etiquetas <div> o .

Debe ser un contenedor sin nombre, está prohibido que tenga nombre.

No lo uses en el contenido: no está pensado para ser usado en el contenido, sino por los agentes de usuario. Los autores deben usar role="presentation" o role="none" para eliminar la semántica implícita en un elemento.

Consulta el nuevo rol "generic" en ARIA 1.2.

Roles eliminados

Se eliminan los roles:

directory, definía una lista de referencias a miembros de un grupo, como una tabla de contenido estática. Se recomienda que en su lugar se use el rol list.

Nueva implementación de un "combobox"

La guía para implementar un combobox ha cambiado significativamente en ARIA 1.2 debido a los problemas con la implementación de los patrones anteriores.

En ARIA 1.1 el combobox tenía tres partes primarias: un input, que estaba dentro de un contenedor combobox, y una lista con el rol listbox:


<div aria-label="Tag" role="combobox" aria-expanded="true" 
     aria-owns="owned_listbox" aria-haspopup="listbox">
     
    <input type="text" aria-autocomplete="list" 
    aria-controls="owned_listbox"
    aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox">
    <li role="option">Zebra</li>
    <li role="option" id="selected_option">Zoom</li>
</ul>

Implementación en WAI-ARIA 1.1

Esta implementación tenía diferentes debilidades. Por ejemplo, hay tres elementos que se pueden nombrar, cuando en pantalla solo hay un elemento que necesita un nombre accesible. La especificación dice que se dé nombre solo al contenedor, pero entonces se incumplen las WCAG porque hay un input sin nombre. Por ello, los autores nombran las tres partes, creando problemas de verbosidad en la escucha con el lector.

Este es solo un ejemplo de los problemas de esta implementación. Se listan todos en Resolving ARIA 1.1 Combobox Issues, W3C.

En ARIA 1.2 la implementación que se propone es:


<label for="tag_combo">Tag</label>

<input type="text" id="tag_combo"
      role="combobox" aria-autocomplete="list"
      aria-haspopup="listbox" aria-expanded="true"
      aria-controls="popup_listbox"
      aria-activedescendant="selected_option">

<ul role="listbox" id="popup_listbox">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

Implementación en WAI-ARIA 1.2

Ahora el combobox tiene solo una parte, el input, y luego el listado asociado. Es una implementación análoga a la habitual para un botón de menú.

Se puede consultar el ejemplo operativo de la implementación de combobox en ARIA 1.2 en Combobox With List Autocomplete Example.

Consulta el rol "combobox" en ARIA 1.2.

Grupos en los roles "listbox" y "list"

Con el rol listbox marcamos un componente que permite seleccionar al usuario uno o más elementos de una lista de opciones. Los elementos de la lista son estáticos y, a diferencia de una select de HTML, la lista de opciones puede tener imágenes.

En ARIA 1.2, un listbox puede contener roles de tipo option, como hasta ahora, pero, como novedad, también puede incluir ya roles de tipo group.

Además, en el rol listbox ya no se admite el atributo aria-haspopup.

Por el contrario, en el rol list se quita la opción de que haya grupos y ahora solo admite el hijo listitem, ya no admite el hijo group.

Consulta el rol "listbox" en ARIA 1.2.

Consulta el rol "list" en ARIA 1.2.

Cambios en el estado "aria-expanded"

En ARIA 1.2 el rol menuitem ya soporta el atributo aria-expanded, y por herencia, puede ser soportado en los roles menuitemcheckbox y menuitemradio.

También se admite en el rol checkbox.

Sin embargo, se elimina el soporte del atributo aria-expanded en los siguientes roles:

alert, alertdialog, article, banner, blockquote, caption, cell, complementary, contentinfo, definition, deletion, dialog, directory, feed, figure, form, grid, group, heading, img, insertion, landmark, list, listitem, log, main, marquee, math, menu, menubar, navigation, note, paragraph, radiogroup, region, search, select, status, subscript, superscript, table, tabpanel, term, time, timer, toolbar, tooltip, tree, treegrid.

Consulta el estado "aria-expanded" en ARIA 1.2.

Cambios en el rol "spinbutton"

Con el rol spinbutton definimos un botón giratorio que normalmente permite cambiar el valor que se muestra mediante unos botones. Algunas implementaciones tienen el valor en un campo de texto que se puede editar.

spinbutton. botones giratorios para seleccionar una fecha

Ejemplo spinbutton de ARIA Authoring Practices Guide

En la versión ARIA 1.1, se incluían los atributos aria-valuemax, aria-valuemin y aria-valuenow como obligatorios, y aria-valuetext como heredado. En la versión 1.2 los cuatro están en el apartado de estados y propiedades soportados.

Consulta el rol "spinbutton" en ARIA 1.2.

Cambios en el atributo "aria-level" de los roles "tablist" y "grid"

El rol tablist nos permite definir, en una implementación mediante pestañas, la zona que contiene las pestañas.

En ARIA 1.1 el rol tablist admitía la propiedad aria-level en el caso de que hubiera tablist anidadas. En la nueva versión ARIA 1.2 tablist ya no se admite este atributo.

También se elimina la propiedad aria-level del rol grid, rol que permite definir una tabla cuyas celdas pueden coger el foco.

Es una manera de decir que no anides pestañas ni tablas.

Consulta el rol "tablist" en ARIA 1.2.

Consulta el rol "grid" en ARIA 1.2.

Cambios en el rol "rowgroup"

El rol rowgroup permite definir una agrupación de elementos row.

Los estados y propiedades aria-disabled, aria-errormessage, aria-haspopup y aria-invalid están obsoletos en el rol rowgroup de ARIA 1.2.

Hay que tener en cuenta que estas cuatro propiedades ya no se admiten como globales, sino que en ARIA 1.2 se especifica en concreto qué roles las admiten.

Consulta el rol "rowgroup" en ARIA 1.2.

Cambios en los roles "menuitemcheckbox" y "menuitemradio"

En la definición de estos roles en ARIA 1.2 están obsoletos los estados y propiedades: aria-errormessage y aria-invalid.

Por otra parte, se elimina que el valor implícito por defecto de su atributo aria-checked sea "false".

Consulta el rol "menuitemcheckbox" en ARIA 1.2.

Consulta el rol "menuitemradio" en ARIA 1.2.

Cambios en el rol "checkbox"

En el rol checkbox se admite el atributo aria-expanded, pero se elimina que el valor implícito por defecto de su estado aria-checked sea "false".

Consulta el rol "checkbox" en ARIA 1.2.

Cambios en el rol "progressbar"

El rol progressbar permite definir una barra de progreso. En ARIA 1.2 se establece que los valores por defecto para aria-valuemin y aria-valuemax son 0 y 100, respectivamente.

Además, se indica que en este rol están obsoletos los estados y propiedades: aria-disabled, aria-errormessage, aria-haspopup y aria-invalid.

Consulta el rol "progressbar" en ARIA 1.2.

Otros cambios

Otros cambios del WAI-ARIA 1.2 respecto a WAI-ARIA 1.1 son:

Se quita la obligación de que los roles log y timer tengan un nombre accesible.
Se hace hincapié entre la diferencia de los roles alert y alertdialog.
En el rol form se obliga a que tenga un nombre accesible.
En el rol gridcell se elimina la obligatoriedad de que tenga un nombre accesible.
Los atributos aria-valuemin y aria-valuemax pasan a ser soportados, en vez de obligatorios, en los roles separator, slider, y scrollbar.
El atributo aria-orientation pasa a ser soportado, en vez de obligatorio, en el role scrollbar.
En el rol switch se elimina que el valor implícito por defecto de su estado aria-checked sea "false".
Se especifica que un elemento con el atributo aria-errormessage (que relaciona un campo de formulario con su mensaje de error) no puede tener el atributo aria-invalid="false".