WCAG 2.1 y EN 301-549

Se ha desarrollado y aprobado una nueva versión de la EN 301-549, la  EN 301-549 v2.1.2 (2018-08)

Esta nueva versión de la EN 301-549 está alineada con la versión de las WCAG 2.1 y por lo tanto introduce todos los nuevos criterios.

Además, la nueva versión de la EN 301-549 ha sido declarada el 21 de diciembre de 2018 por la Comisión Europea como estándar armonizado para la aplicación de la Directiva de Accesibilidad Web y por lo tanto es el estándar que aplica en las Administraciones Públicas españolas.

Guía rápida de aplicación WCAG 2.1

Las WCAG 2.1 introduce 17 nuevos criterios de conformidad, 12 de los cuales tienen un nivel de conformidad A o AA. Estos son:

• Pauta 1.3 Adaptable:
  • 1.3.4 Orientación (AA)
  • 1.3.5 Identificar el Propósito de la Entrada (AA)
  • 1.3.6 Identificar el Propósito (AAA)
• Pauta 1.4 Distinguible:
  • 1.4.10 Reflujo (AA)
  • 1.4.11 Contraste sin texto (AA)
  • 1.4.12 Espaciado de texto (AA)
  • 1.4.13 Contenido en el cursor o foco (AA)
• Pauta 2.1 Teclado Accesible:
  • 2.1.4 Atajos de teclas de caracteres (A)
• Pauta 2.2 Tiempo Suficiente:
  • 2.2.6 Tiempos de espera (AAA)
• Pauta 2.3 Convulsiones y reacciones físicas:
  • 2.3.3 Animación de las Interacciones (AAA)
• Pauta 2.5 Modalidades de entrada:
  • 2.5.1 Gestos del puntero (A)
  • 2.5.2 Cancelación del puntero (A)
  • 2.5.3 Etiqueta en Nombre (A)
  • 2.5.4 Accionamiento de movimiento (A)
  • 2.5.5 Tamaño objetivo (AAA)
  • 2.5.6 Mecanismos de entrada simultáneos (AAA)
• Pauta 4.1 Compatible:
  • 4.1.3 Mensajes de estado (AA)

Los nuevos criterios de conformidad se incluyen entre las Pautas ya existentes excepto para la pauta 2.5 “Modalidades de entrada”, la cual es una nueva pauta introducida en las WCAG 2.1. Está dedicada específicamente a facilitar la interacción a través de diferentes dispositivos de entrada más allá de la interacción mediante teclado, especialmente desde dispositivos móviles.

Las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1 ( Web Content Accessibility Guidelines 2.1 ) es la última versión de las pautas de accesibilidad del contenido en la Web del World Wide Web Consortium (W3C). El 5 de junio de 2018 se publicó la recomendación definitiva después de un proceso de elaboración de casi 10 años desde la publicación de Web Content Accessibility Guidelines 2.0 el 11 de diciembre de 2008.

Entre las novedades que encierra esta nueva versión con respecto a su antecesor están:

• Se han añadido 17 nuevos criterios de conformidad (5 nuevos criterios de conformidad de nivel A, 7 de nivel AA y 5 de nivel AAA)
• Se han añadido nuevos términos al glosario
• Se añade una nueva pauta (2.5 "Modalidades de entrada") al segundo principio (Operabilidad), pasando de tener 12 pautas a 13
• Se añade en el enunciado del criterio 1.3.3 específicamente el color y se quita en consecuencia la nota del criterio 1.4.1
• Se añade una nota adicional en el requisito 5.2.2 "Páginas completas"
• Se añade un punto adicional en "Componentes opcionales de la declaración de conformidad" de la sección de conformidad

Cabe mencionar que esta nueva versión no se han modificado los criterios de conformidad de las WCAG 2.0, ni siquiera su numeración.

Las WCAG 2.1 surgen con el objetivo de mejorar la accesibilidad principalmente de tres grupos de usuarios:

• Personas con discapacidad cognitiva o del aprendizaje
• Personas con baja visión
• Personas con discapacidad que acceden desde dispositivos móviles

Se consideraba que las WCAG 2.0 no cubrían como era de esperar las necesidades de determinados tipos de discapacidades como las cognitivas o las necesidades de personas con baja visión. Asimismo, en los últimos años las tecnologías y las formas de acceder al contenido web han variado de forma significativa dando lugar a situaciones no contempladas originalmente en las WCAG 2.0.

Las WCAG 2.1 pretenden cubrir un mayor conjunto de recomendaciones para hacer la web más accesible. Estas Pautas aspiran a mejorar la accesibilidad del contenido web tanto en entornos de escritorio y portátiles como en tablets y dispositivos móviles.

Sí, las WCAG 2.1 tienen compatibilidad hacia atrás con las WCAG 2.0.

Las WCAG 2.1 se pueden considerar como un superconjunto que contiene a las WCAG 2.0. Aquellos criterios de conformidad de las WCAG 2.0 que se consideraban mejorables han sido complementados con otros nuevos criterios más específicos, pero sin cambiar la redacción original de los requisitos originales los cuáles siguen siendo válidos. Por lo tanto, como las WCAG 2.1 extienden las WCAG 2.0, no existen requisitos que sean incompatibles entre una versión y la otra.

Esta estrategia de ampliación ayuda a dejar claro que si una página web es conforme a las WCAG 2.1 también será conforme a las WCAG 2.0. Y en sentido contrario, si una página web es conforme a las WCAG 2.0 se podrá actualizar a las WCAG 2.1 sin incompatibilidades.

Así, por ejemplo, mientras en las WCAG 2.0 se pedía únicamente un contraste suficiente entre el color del texto y el color de fondo (SC 1.4.3) en las WCAG 2.1 el requisito de contraste se extiende también al contenido no textual mediante la incorporación de un nuevo criterio de conformidad (SC 1.4.11).

No, como se ha comentado en la pregunta anterior, los criterios de conformidad de las WCAG 2.0 se han mantenido sin modificar dentro de las WCAG 2.1. Podemos decir que las WCAG 2.0 están incluidas tal cual dentro de las WCAG 2.1.

Las novedades se incluyen en forma de nuevos criterios de conformidad, nuevas definiciones para su explicación y un par de nuevas consideraciones a tener en cuenta en los requisitos generales de conformidad.

No, la numeración de los criterios de conformidad de las WCAG 2.0, así como su nivel de conformidad, se mantiene sin modificar en las WCAG 2.1. De igual forma, también se mantiene la numeración de las técnicas suficientes, técnicas complementarias y fallos asociados a los criterios de conformidad. De esta forma no es necesario cambiar ninguna de las referencias existentes a la documentación de las Pautas realizadas desde informes, guías, herramientas, etc.

Para preservar la numeración de las WCAG 2.0 los nuevos criterios de conformidad se añaden a continuación de los ya existentes en las Pautas correspondientes. Sin embargo, esta estrategia de actualización en la que no se modifica la numeración tiene como consecuencia que en las WCAG 2.1 se pierde el orden de los criterios en base a su nivel de conformidad dentro de cada pauta, donde estaban ordenados desde el nivel A hasta el AA.

Así, por ejemplo, la Pauta 1.4 contenía 9 criterios de conformidad, desde el 1.4.1 de nivel A hasta el 1.4.9 de nivel AAA. En las WCAG 2.1 se añaden a esta pauta cuatro nuevos criterios continuando con la numeración existente (1.4.10 hasta 1.4.13) siendo todos de nivel AA.

Sí, se introduce una novedad importante a tener en cuenta a la hora de considerar si una página web es conforme con las WCAG 2.1 (apartado 5.2).

Se añade una nota adicional en la que se indica que para que una página sea conforme lo ha de ser también en cada variación de la página que se presenta de forma automática para diferentes tamaños de pantalla (p. ej. las variaciones de una página web “responsive” o adaptable). Por tanto, un sitio web que tenga un diseño web adaptable (Responsive web design) con diferentes maquetaciones para móvil, tablet y escritorio deberá cumplir todos los criterios de conformidad en cada una de sus posibles visualizaciones.

Uno de los principales objetivos de las WCAG 2.1 es mejorar la accesibilidad de las páginas web para las personas con discapacidad que acceden desde dispositivos móviles.

Para conseguir este objetivo se han incluido una serie de nuevos requisitos que apuntan en esa dirección. Sin embargo, y en relación directa con la visualización en dispositivos móviles, el criterio de conformidad 1.4.10 Reflow exige que el contenido se presente sin pérdida de información o funcionalidad y sin necesidad de realizar scroll en dos dimensiones en áreas de visualización reducidas (320x256 píxeles CSS). Si bien este criterio está pensado inicialmente para mejorar la experiencia de las personas con baja visión asegurando que se pueda hacer zoom hasta al menos un 400% del tamaño original sin que se produzca un doble scroll (partiendo de una resolución de 1280x1024), en la práctica e implícitamente también supone que la página se debe “adaptar” correctamente a diferentes tamaños de ventana.

En el propio criterio de conformidad se indica que permitir el reajuste del contenido se conoce también como Diseño Web Adaptable (Responsive Web Design) y se considera como la forma más efectiva para conseguir cumplir este criterio. Así, entre las técnicas indicadas está el uso de media queries para establecer puntos de ruptura y reformatear el contenido para diferentes anchos de visualización. Estos puntos de ruptura se disparan de igual forma tanto si se reduce el tamaño de la ventana como si se hace zoom sobre el contenido.

Precisamente, se ha determinado un valor de 320 píxeles CSS como objetivo porque se considera el tamaño mínimo razonable para el que es factible maquetar un sitio web. También se ha escogido este valor porque coincide con el ancho de pantalla más pequeño de los dispositivos móviles más comunes y porque se corresponde con un zoom de 400% en un navegador de escritorio con un ancho de ventana de 1280px.

No obstante, es importante tener en cuenta que este requisito contempla como excepciones aquellas partes del contenido que requieren de una presentación y maquetación en dos dimensiones para poder transmitir su significado o para poder emplearse de forma correcta.

Dentro de esta excepción se pueden incluir las imágenes y contenidos multimedia ya que por naturaleza tienen dos dimensiones, aunque es posible su redimensión hasta adaptarlos al tamaño de la ventana. Una excepción más clara es el caso de las tablas de datos, en las que las relaciones entre las celdas se establecen en un contexto bidimensional. Por lo tanto, las tablas de datos, en especial las tablas de datos complejas, están fuera del alcance de este requisito.

Otro contenido que se puede considerar como una excepción son aquellas interfaces de usuario complejas como las que proporcionan barras de herramientas para editar contenidos que se deben mostrar simultáneamente junto con la barra de herramientas (editores de texto, editores gráficos, etc.). Por otra parte, aunque no se mencione de forma explícita en las WCAG 2.1, se pueden considerar también como excepción los formularios o trámites de notoria complejidad, tanto a nivel de interacción como de visualización, de forma que no son razonablemente operables desde dispositivos móviles.

No, los nuevos criterios de conformidad a tener en cuenta en dispositivos móviles van más allá de una correcta maquetación o visualización de los contenidos.

Así, el criterio de conformidad 1.3.4 Orientación nos indica que el contenido no puede restringir su visualización y funcionalidad a una única orientación de la pantalla (horizontal o vertical) a no ser que dicha orientación específica sea esencial. Algunos usuarios tienen los dispositivos anclados en una posición fija (p. ej. sobre una silla de ruedas) y no pueden modificar su orientación. Por ejemplo, un usuario con una tablet anclada en posición vertical no podría acceder a un sitio web que sólo se mostrase en posición horizontal.

El criterio de conformidad 2.5.1 Gestos del Puntero indica que toda la funcionalidad que emplee gestos multipunto o dependientes del trazo realizado también se debe poder realizar empleando un único punto de contacto y sin trazos, mediante una pulsación sencilla con un dedo o con un puntero. Por ejemplo, si es posible hacer un gesto de pinza con dos dedos para hacer zoom sobre un mapa o un movimiento lineal para desplazarse sobre el mismo entonces también debe haber un par de botones que permitan hacer zoom y otros botones (p. ej. rueda de cuatro puntos) que permitan el desplazamiento. El objetivo de este criterio es asegurar que el contenido se puede operar desde un gran número de dispositivos de entrada sencillos de forma que las personas con problemas de movilidad los puedan realizar.

El criterio de conformidad 2.5.4 Activación Mediante el Movimiento indica que cualquier funcionalidad que se pueda operar mediante el movimiento del dispositivo también se debe poder realizar a través del interfaz de usuario y también se debe poder desactivar dicha operación mediante el movimiento para evitar acciones no deseadas. Esto beneficia a las personas que tienen sus dispositivos anclados en posiciones fijas (p. ej. una silla de ruedas) y no pueden interactuar mediante el movimiento. También se evita que personas con problemas de movilidad ejecuten ciertas acciones accidentalmente al realizar movimientos no controlados.

Por otra parte, aunque el contenido se vea correctamente en un dispositivo móvil no se debe bloquear la posibilidad de hacer zoom sobre el mismo. Se considera un error emplear, por ejemplo, elementos meta con “maximum-scale” o “minimum-scale” o bien con “user-scalable=no” o “user-scalable=0”.

Finalmente, y con un carácter más general, en el requisito de conformidad Páginas Completas se indica que para que una página web se pueda considerar conforme también debe serlo en cada una de sus diferentes formas de visualización. Es decir, también se han de cumplir todos los criterios de conformidad en cada una de las versiones de la página web (móvil, tablet, escritorio, etc.).

En relación a los formularios las WCAG 2.1 incluyen algunas novedades importantes a tener en cuenta.

El criterio de conformidad 1.3.5 Identificar el Propósito de la Entrada indica que se debe poder determinar automáticamente la finalidad de aquellos campos de introducción de datos que solicitan información acerca de las personas. El objetivo es que las aplicaciones de usuario puedan extraer esta información y ofrecérsela a las personas en diferentes modalidades o bien autocompletar dicha información para facilitar la interacción con los formularios.

En algunos casos puede parecer suficiente con los nuevos tipos de elementos <input> de HTML5 tipo “tel”, “email”, “password”, etc. Sin embargo, aunque estos campos aportan cierta información sobre la naturaleza del tipo de dato a introducir, las categorías que se pueden emplear son demasiado genéricas. Por ejemplo, sirven para indicar que un campo se trata de un email o un teléfono, pero no aclaran cuál es el dato concreto al que se refieren (¿teléfono o email del usuario o de otra persona?).

Por lo tanto es preciso emplear técnicas alternativas como el atributo “autocomplete” de HTML 5.2 y un valor que indique el tipo de información solicitada (p. ej. "name", "honorific-prefix", "given-name", "additional-name", "family-name", ...).

Por otra parte, el criterio de conformidad 2.5.3 Etiqueta en el Nombre pide que para los componentes de la interfaz de usuario que dispongan de una etiqueta textual (o imagen de texto) entonces su nombre programático o nombre accesible (etiqueta <label> o atributos “title”, “aria-label”, “aria-labelledby”, etc.) debe contener también el texto que se muestra visualmente y preferiblemente al comienzo del mismo. El objetivo de este requisito es que las personas que dependan de estas etiquetas visuales también puedan emplear los nombres accesibles. Así, una persona con una discapacidad motriz que pueda ver la página web en un navegador gráfico pero para interactuar emplee entrada por voz podrá leer el texto visible de la etiqueta para accionar o seleccionar el componente. Si la etiqueta visible y el nombre accesible no coinciden la interacción resulta mucho más complicada para este tipo de personas y se abre la posibilidad además de accionar componentes accidentalmente.

Si bien en las WCAG 2.0 sólo se exigía un contraste mínimo para el contenido textual, incluyendo el texto mostrado en imágenes, en las WCAG 2.1 este requisito se extiende también para aquel contenido no textual cuya información visual es necesaria para su comprensión o identificación. Así, es necesario asegurar un mínimo de contraste en todos los elementos visuales necesarios para reconocer e identificar los diferentes componentes que forman parte de la interfaz de usuario y sus posibles estados (excepto en el caso de los componentes inactivos). Por ejemplo, los enlaces, botones, campos de formulario, iconos que actúan como enlaces (no acompañados de texto), el indicador del foco del teclado, etc.

Este requisito también es aplicable, de forma general, a todas aquellas partes de los contenidos gráficos que sean necesarias para su comprensión. Es el caso, por ejemplo, de cualquier imagen que transmita información como los iconos acerca del formato de documentos o aquellos que indican estados, identifican avisos, acciones, redes sociales, etc. Esto también incluye los diferentes elementos gráficos que formen parte de diagramas, infografías o gráficas como pueden ser las líneas, los fondos, límites de los objetos, formas, etc., además del propio texto que pudiera formar parte de las mismas.

Este criterio de conformidad exige que si el usuario ajusta la presentación del contenido a ciertos parámetros, no se pierda contenido o funcionalidad. Los parámetros a justar son los siguientes:

• Alto de línea: al menos 1.5veces el tamaño de la fuente.
• Espacio entre párrafos: al menos 2 veces el tamaño de la fuente.
• Espacio entre letras (tracking): al menos 0.12 veces el tamaño de la fuente.
• Espacio entre palabras: al menos 0.16 veces el tamaño de la fuente.

Para validar este criterio se puede utilizar el Bookmarklet de Steve Faulkner, disponible en https://www.html5accessibility.com/tests/tsbookmarklet.html

Este criterio de conformidad hace referencia al contenido adicional que se muestra cuando un elemento recibe o pierde el puntero (hover) o el foco del teclado (focus), por ejemplo el menú desplegable que se muestra cuando se pone el puntero por encima de un elemento. Debe existir un mecanismo adicional que permita descartar el contenido adicional sin necesidad de mover el puntero o cambiar el foco del teclado.

¿Qué mecanismo se puede utilizar para descartar el contenido adicional sin necesidad de mover el puntero o cambiar el foco del teclado?

Las opciones que se proponen son el uso de la tecla ESC o un botón específico para cerrar (el típico botón “X” o “Cerrar”), si bien el botón debe tener ya el foco en el momento de mostrarse el contenido adicional para que no haga falta desplazar el foco hasta el mismo.

¿Siempre debe existir un mecanismo que permita descartar el contenido adicional sin necesidad de mover el puntero o cambiar el foco del teclado?

No, si el contenido adicional que se muestra informa acerca de un error en la entrada de datos o si no tapa o reemplaza otro contenido, no es necesario ofrecer dicho mecanismo, ya que no entorpece la visualización de ningún contenido.

El contenido adicional que se muestra u oculta cuya presentación visual está controlada por la aplicación de usuario y no por los desarrolladores como, por ejemplo, el tooltip que muestra el contenido del atributo title (título), tampoco está afectado por este criterio.

El criterio si aplica, por ejemplo a menús desplegables, pop-ups no modales, tooltips personalizados…

En los componentes del interfaz de usuario (como los campos de formulario, botones, enlaces, controles que se puedan generar mediante scripts como sliders, tabs, treeviews…) es necesario que el texto visible (que actúa como su etiqueta y que sirve para reconocerlos visualmente) también forme parte de su nombre accesible (usado por los agentes o herramientas de usuario para mostrar el contenido a personas con discapacidad).

Para cumplir este criterio se debe cumplir que el Nombre accesible sea el contenido de la etiqueta accesible y opcionalmente se puede poner algo más, pero el comienzo del nombre accesible debe ser idéntico al contenido de la etiqueta accesible, para que lo que se muestra en pantalla (etiqueta) y lo que las herramientas utilizan (nombre accesible) comience exactamente igual.
 

Nombre accesible = Etiqueta accesible + [xxxx]

Cada componente de interfaz de usuario tiene un nombre accesible por defecto o bien el nombre accesible puede determinarse usando el ARIA. Si se usa el ARIA, prevalece sobre el nombre por defecto.

Cada componente de interfaz de usuario tiene un nombre accesible por defecto (contenido del elemento, valor de un atributo o elemento asociado). A continuación se muestra el nombre accesible por defecto para cada componente de IU:

Hay que ver lo que se muestra por pantalla y ver si coincide con el nombre accesible.

A continuación se muestran ejemplos para clarificar el criterio.

En los siguientes casos el texto que aparece por pantalla y el nombre accesible COINCIDEN:

<label for=”nombre”>Nombre: <input type="text" id="nombre" > </label>
<input type="submit" value="Buscar">
<button type="submit">Buscar</button>
<div role="button" aria-label="Buscar">Buscar</div>

En los siguientes casos el texto que aparece por pantalla NO COINCIDEN con el nombre accesible:
 

Por pantalla aparece “Go” y el nombre accesible es “Find in this site”

<button id="sitesearch" aria-label="Find in this site">Go</button>

Por pantalla aparece “Download specification” y el nombre accessible es “Download gizmo specification”

<a href="#">Download <span class="accessibly-hidden">gizmo</span>
specification</a>

Por pantalla aparece “Search” y el nombre accessible es “find in this site”

<div id="hidden-label">Find in this site</div>
<input type="submit" aria-labelledby="hidden-label" value="search">