Nuevas técnicas ARIA en las WCAG 2.0. Novedades de la actualización del documento "Techniques for WCAG 2.0" del 11 de marzo de 2014

Sobre las "Techniques for WCAG 2.0"

El documento Web Content Accessibility Guidelines (WCAG 2.0) es el documento normativo y estable de las WCAG 2.0, es decir, es un documento que no se modifica porque está concebido para ser un estándar web perdurable en el tiempo. Por ello está redactado de forma neutral, sin hacer referencia a una tecnología concreta.

Para explicar cómo cumplir los criterios de conformidad definidos en las WCAG 2.0, estas tienen una serie de documentos complementarios, no normativos, que se van modificando con el tiempo y que sirven de guía de implementación para diferentes tecnologías y situaciones.

Uno de estos documentos es "Techniques for WCAG 2.0", en el cual se recogen las técnicas que se pueden emplear para cumplir con los criterios de conformidad de las WCAG 2.0.

Digo "que se pueden emplear" porque se admite que puedan usarse otras técnicas diferentes. Por ello, cada cierto tiempo, a medida que evolucionan los productos de apoyo, las diferentes tecnologías y se documentan nuevas técnicas que permiten mejorar la accesibilidad o cumplir con determinados criterios de conformidad, este documento se actualiza incorporándolas. Por ejemplo, en la actualidad se está trabajando en las técnicas relativas a HTML5.

En los documentos "Understanding WCAG 2.0" y "How to Meet WCAG 2.0" se puede consultar qué técnicas (o combinación de técnicas) son suficientes para cumplir con cada criterio de conformidad en función de la tecnología usada (HTML, PDF, Silverlight, etc.) o la situación.

Se enumeran también técnicas recomendables para mejorar la accesibilidad de la página, aunque por sí mismas no permiten cumplir con todos los requisitos del criterio de conformidad (o solo son apropiadas en determinadas circunstancias)

Por último se incluyen fallos comunes, es decir, prácticas de uso común que impiden que se cumpla con uno o varios criterios de conformidad.

Novedades de la actualización del 11 de marzo de 2014

Esta semana (11 de marzo de 2014) se actualizaron los documentos "Techniques for WCAG 2.0" y "Understanding WCAG 2.0".

Comparando las técnicas enumeradas en la nueva versión del documento, con las de la versión anterior ("Techniques for WCAG 2.0" del 5 de septiembre de 2013) las novedades son las siguientes:

Se ha eliminado la técnica "ARIA3: Identifying valid range information with the aria-valuemin and aria-valuemax properties" que era una técnica recomendable del criterio de conformidad "3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)". Ahora se hace referencia al uso de estos atributos en la nueva técnica ARIA5.
Se ha incluido un nuevo fallo común, siendo ya 92 los documentados: "F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content which conveys semantic information"
Se han incluido 15 nueve técnicas ARIA, de la ARIA4 a la ARIA19

Las nuevas técnicas por tanto son todas referidas a WAI-ARIA, y puesto que incluyen ejemplos, son una buena oportunidad para repasar la aplicación de WAI-ARIA y una serie de buenas prácticas.

Las nuevas técnicas están relacionadas con los criterios 1.1.1, 1.3.1, 2.4.4 y 4.1.2 en mayor medida, y algunas también con los criterios 2.4.9, 3.3.1, 3.3.2, 3.3.3, como iré concretando a continuación.

La mayoría son relativas a los atributos aria-label y aria-labelledby, pero también al uso de landmark roles y al uso de otro tipo de roles (role="presentation", role="heading", role="group", role="radiogroup", role="alertdialog", role="alert") y atributos (aria-describedby, aria-valuemin, aria-valuemax, aria-valuenow, aria-pressed).

Descripción de las técnicas y fallos comunes incluidos

"F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content which conveys semantic information"

Está asociado al criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)"

El role="presentation" oculta los roles nativos de los elementos y sus descendientes a los productos de apoyo, y por tanto se usa solo para marcar elementos puramente decorativos.

Este fallo común hace referencia a la aplicación de role="presentation" a elementos cuya finalidad es transmitir información o relaciones en el contenido.

ARIA4: Using a WAI-ARIA role to expose the role of a user interface component

Es un técnica suficiente asocida a la G10 para cumplir con el criterio de conformidad "4.1.2 Name, Role, Value" (level A) en la situación "Situation D: If creating your own user interface component in a programming language"

Hace referencia al uso del atributo role según la especificación WAI-ARIA. Ejemplifica el uso de roles en una toolbar y en un tree widget.

ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component

Al igual que en el caso anterior, es un técnica suficiente asocida a la G10 para cumplir con el criterio de conformidad "4.1.2 Name, Role, Value ... (level A)" en la situación "Situation D: If creating your own user interface component in a programming language"

Trata del uso de WAI-ARIA para indicar el estado, propiedad o valor de un elemento de forma que sus cambios puedan ser notificados a los productos de apoyo. Lo ejemplifican con el atributo aria-pressed de un botón y con los atributos relacionados con el valor de un slider: aria-valuemin, aria-valuemax, and aria-valuenow.

Como he comentado, ha desaparecido la técnica recomendable "ARIA3: Identifying valid range information with the aria-valuemin and aria-valuemax properties", que precisamente hacía referencia a estos atributos porque ya son tratados en la nueva técnica ARIA5.

ARIA6: Using aria-label to provide labels for objects

Es un técnica suficiente en diversas situaciones para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)"

Trata del uso del atributo aria-label para etiquetar los objetos.

Advierte que:

puede ser desatendida por los productos de apoyo si se usa junto a aria-labelledby
anulará otras formas nativas de etiquetado, como el alt de las imágenes o el elemento <label> para etiquetar un campo de formulario

Ejemplifican su uso para identificar landmarks o para distinguir varios del mismo tipo (como os comenté en "Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)") o para etiquetar una función matemática.

ARIA7: Using aria-labelledby for link purpose

Es un técnica suficiente para cumplir con el criterio de conformidad "2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A) "

Trata de la aplicación del atributo aria-labelledby, que permite aprovechar un elemento de texto de la página (o varios) para etiquetar a otro elemento, en este caso un enlace para aclarar su propósito.

De esta manera, el lector de pantalla, en vez de leer el texto del enlace, leerá los textos que se han identificado en el atributo aria-labelledby mediante su ID (o IDs, de forma concatenada, separados por espacios). Es decir sustituye al texto del enlace.

Se proporcionan varios ejemplos típicos, como es su uso para reemplazar el texto del enlace "Leer más", o para concatenar etiquetas a los enlaces de un recurso en diversos formatos "Memoria del 2002 en PDF" (sin tener que incluir en el texto del enlace más que "PDF").

ARIA8: Using aria-label for link purpose

Es una técnica suficiente para cumplir con el criterio de conformidad "2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)" pero también para cumplir con la versión más restrictiva de este criterio (de nivel AAA) "2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)

Trata del uso del atributo aria-label para identificar el propósito de un enlace, como se hacía en la técnica anterior mediante aria-labelledby, pero en este caso cuando no hay elementos visibles que se puedan usar para etiquetarlo. Si los hubiera se debe usar aria-labelledby.

Indican que en algunos productos de apoyo el valor del atributo aria-label (el texto indicado directamente en el atributo) se mostrará en la lista de enlaces en vez del texto utilizado en el enlace.

Los ejemplos que se incluyen son de su aplicación para los típicos enlaces "Leer más".

ARIA9: Using aria-labelledby to concatenate a label from several text nodes

Es una técnica suficiente en combinación con la G82 para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)" en la situación C "Situation C: If non-text content is a control or accepts user input"

También es una técnica suficiente, en combinación con la G131, para cumplir con el criterio de conformidad "3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)"

Trata del uso del atributo aria-labelledby pero en este caso para etiquetar text inputs en situaciones en las que la etiqueta descriptiva debe construirse a partir de más de un elemento, por ejemplo "[Ampliar tiempo de espera a] [20] [minutos]":


<form>
<p><span id="timeout-label" tabindex="-1">
          <label for="timeout-duration">Extend time-out to</label>
   </span>
   <input type="text" size="3" id="timeout-duration" value="20" 
        aria-labelledby="timeout-label timeout-duration timeout-unit">
   <span id="timeout-unit" tabindex="-1"> minutes</span>
</p>
</form>

Otro ejemplo de uso que incluyen es cuando no nos cabe el label de un campo de texto. Ponen un ejemplo de campos de texto incluidos en una tabla y etiquetados con varios de los encabezados de la misma de forma concatenada.

ARIA10: Using aria-labelledby to provide a text alternative for non-text content

Trata del uso del atributo aria-labelledby pero en este caso para incluir una descripción corta al contenido no textual. Ponen un ejemplo para etiquetar las típicas estrellas que simulan una puntuación. Permite englobarlas todas en un DIV con role="image" y etiquetarlas en su conjunto ("4 de 5").

ARIA11: Using ARIA landmarks to identify regions of a page

Es un técnica suficiente para cumplir con el criterio de conformidad "1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)" en la situación A "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable"

También es un técnica suficiente para cumplir con el criterio de conformidad "2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)"

Trata el uso del landmarks roles para identificar partes de una página como os contaba en "Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)"

ARIA12: Using role=heading to identify headings

Habla del uso de role="heading" para identificar encabezados y aria-level para indicar su nivel. Advierten que siempre es preferible usar H1, H2, etc. pero incluyen algún ejemplo en el que puede ser útil, como por ejemplo en encabezados con un nivel H7 o superior (la especificación HTML incluye hasta H6)

ARIA13: Using aria-labelledby to name regions and landmarks

Aborda el uso del atributo aria-labelledby para proporcionar nombre a los landmark roles.

ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used

Es una técnica suficiente del criterio de conformidad "4.1.2 Name, Role, Value ...(level A)" en la situación A "Situation A: If using a standard user interface component in a markup language (e.g., HTML)"

Aborda el uso de aria-label para proporcionar un nombre accesible a elementos que no tienen una etiqueta visible, por ejemplo por el enfoque de diseño elegido (incluyen el ejemplo de etiquetar la "X" que sirve para cerrar una capa), o porque el elemento no admite el etiquetado nativo (un div de tipo contentEditable)

ARIA15: Using aria-describedby to provide descriptions of images

Es una técnica suficiente para cumplir con el criterio de conformidad "1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)", en combinación con otras, para incluir contenido textual alternativo largo en la situación B "Situation B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)".

Trata del uso del atributo aria-describedby para dar descripciones largas a las imágenes cuando un breve texto alternativo no resulta suficiente. Su función es similar al longdesc, pero lo que incluimos no es una url, sino el ID (o IDs) de los elementos de la página que proporcionan la descripción de la imagen.

Señalan que en la fecha de redacción (octubre 2013) algunos productos de apoyo leen la descripción definida por el atributo aria-describedby después de leer el alt de la imagen, sin mediar activación de los usuarios, mientras que la mayoría de las implementaciones de longdesc requieren que el usuario solicite la acción explícita de leer la descripción adicional.

Trato en detalle esta propiedad ARIA en el artículo LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA: "aria-describedby" y "aria-describedat", HTML5: "figure" y "picture"

En el artículo "Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)" os hablaba de otro uso muy útil de este atributo, para asociar semánticamente la ayuda contextual de los campos con los mismos.

ARIA16: Using aria-labelledby to provide a name for user interface controls

También es una técnica suficiente del criterio de conformidad "4.1.2 Name, Role, Value ...(level A)" en la situación A "Situation A: If using a standard user interface component in a markup language (e.g., HTML)"

Trata del uso del atributo aria-labelledby pero en este caso para etiquetar campos de formulario.

Se detallan las diferencias entre aria-labelledby y el elemento <label>

aria-labelledby can reference more than one text element; label can only reference one.

aria-labelledby can be used for a variety of elements while the label element can only be used on form elements.

clicking on a label focuses the associated form field. This does not occur with aria-labelledby. If this behaviour is required then use label or implement this functionality using scripting.

Note that as of December 2013, label has better support than aria-labelledby, especially in older browsers and assistive technologies.

ARIA17: Using grouping roles to identify related form controls

También es una técnica suficiente junto a la G131 para cumplir con el criterio de conformidad "3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)"

Trata del uso de roles de agrupación (role=group, role="radiogroup") para identificar controles del formulario relacionados.

ARIA18: Using aria-alertdialog to Identify Errors

Es un técnica suficiente para cumplir con el criterio de conformidad "3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)" en la situación B "Situation B: If information provided by the user is required to be in a specific data format or of certain values."

También es un técnica suficiente para cumplir con el criterio de conformidad "3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)" en varias situaciones.

Trata del uso role="alertdialog" para identificar una notificación modal, que debe cumplir con ciertos requisitos:

aria-label or aria-labelledby attribute gives the alertdialog an accessible name.

aria-describedby provides a reference to the text of the alert.

The alertdialog contains at least one focusable control, and the focus should move to that control when the alertdialog opens.

The tab order is constrained within the alertdialog whilst it is open.

When the dialog is dismissed, the focus moves back to the position it had before the dialog opened, if possible.

ARIA19: Using ARIA role=alert or Live Regions to Identify Errors

Trata del uso del role="alert" para notificar errores, por ejemplo, los errores de validación al rellenar un campo.

El uso de role="alert" es equivalente a usar aria-live="assertive". Os hablé del atributo aria-live y las live regions en Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente

ARIA 1 y ARIA 2

Por tener recopiladas en un mismo artículo todas las técnicas ARIA, incluyo a continuación la descripción de las técnicas que se mantienen respecto a la versión anterior.

ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls

Es un técnica recomendable del criterio de conformidad 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A).

Trata del uso general de la propiedad aria-describedby para propocionar una descripción a un elemento. Uno de ellos es la asociación de la ayuda contextual de un campo con dicho campo, un tema que traté en "Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)"

Explico en detalle esta propiedad ARIA y su actual soporte en el artículo LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA: "aria-describedby" y "aria-describedat", HTML5: "figure" y "picture"

ARIA2: Identifying a required field with the aria-required property

También es una técnica suficiente junto a la G131 para cumplir con el criterio de conformidad 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A), aunque esta asociación no se indique en la ficha de la técnica, sí se indica en la del criterio 3.3.2

Trata el uso del atributo aria-required para indicar que un campo de formulario es obligatorio. Es beneficioso incluso aunque se indique con un asterisco o un texto "obligatorio" en el label del campo.

Hablé de esta propiedad en el artículo HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa