WCAG 2.1 e EN 301-549
Desenvolveuse e aprobado unha nova versión da EN 301-549, a EN 301-549 v2.1.2 (2018-08)
Esta nova versión da EN 301-549 está aliñada coa versión do WCAG 2.1 e por tanto introduce todos os novos criterios.
Ademais, a nova versión da EN 301-549 foi declarada o 21 de decembro de 2018 pola Comisión Europea como estándar harmonizado para a aplicación da Directiva de Accesibilidade Web e por tanto é o estándar que aplica nas Administracións Públicas españolas.
Guía rápida de aplicación WCAG 2.1
O WCAG 2.1 introduce 17 novos criterios de conformidade, 12 dos cales teñen un nivel de conformidade A ou AA. Estes son:
- Pauta 1.3 Adaptable:
- 1.3.4 Orientación (AA)
- 1.3.5 Identificar o Propósito da Entrada (AA)
- 1.3.6 Identificar o Propósito (AAA)
- Pauta 1.4 Distinguible:
- 1.4.10 Reflujo (AA)
- 1.4.11 Contraste sen texto (AA)
- 1.4.12 Espaciado de texto (AA)
- 1.4.13 Contido no cursor ou foco (AA)
- Pauta 2.1 Teclado Accesible:
- 2.1.4 Atallos de teclas de caracteres (A)
- Pauta 2.2 Tempo Suficiente:
- 2.2.6 Tempos de espera (AAA)
- Pauta 2.3 Convulsións e reaccións físicas:
- 2.3.3 Animación das Interaccións (AAA)
- Pauta 2.5 Modalidades de entrada:
- 2.5.1 Xestos do punteiro (A)
- 2.5.2 Cancelación do punteiro (A)
- 2.5.3 Etiqueta en Nome (A)
- 2.5.4 Accionamiento de movemento (A)
- 2.5.5 Tamaño obxectivo (AAA)
- 2.5.6 Mecanismos de entrada simultáneos (AAA)
- Pauta 4.1 Compatible:
- 4.1.3 Mensaxes de estado (AA)
Os novos criterios de conformidade inclúense entre as Pautas xa existentes excepto para a pauta 2.5 “Modalidades de entrada”, a cal é unha nova pauta introducida no WCAG 2.1. Está dedicada especificamente a facilitar a interacción a través de diferentes dispositivos de entrada máis aló da interacción mediante teclado, especialmente desde dispositivos móbiles.
As Pautas de Accesibilidade para a Contido Web (WCAG) 2.1 ( Web Content Accessibility Guidelines 2.1 ) é a última versión das pautas de accesibilidade do contido na Web do World Wide Web Consortium (W3C). O 5 de xuño de 2018 publicouse a recomendación definitiva despois dun proceso de elaboración de case 10 anos desde a publicación de Web Content Accessibility Guidelines 2.0 o 11 de decembro de 2008.
Entre as novidades que encerra esta nova versión con respecto ao seu antecesor están:
- Engadíronse 17 novos criterios de conformidade (5 novos criterios de conformidade de nivel A, 7 de nivel AA e 5 de nivel AAA)
- Engadíronse novos termos ao glosario
- Engádese unha nova pauta (2.5 "Modalidades de entrada") ao segundo principio (Operabilidad), pasando de ter 12 pautas a 13
- Engádese no enunciado do criterio 1.3.3 especificamente a cor e quítase en consecuencia a nota do criterio 1.4.1
- Engádese unha nota adicional no requisito 5.2.2 "Páxinas completas"
- Engádese un punto adicional en "Compoñentes opcionais da declaración de conformidade" da sección de conformidade
Cabe mencionar que esta nova versión non se modificaron os criterios de conformidade do WCAG 2.0, nin sequera a súa numeración.
O WCAG 2.1 xorden co obxectivo de mellorar a accesibilidade principalmente de tres grupos de usuarios:
- Persoas con discapacidade cognitiva ou da aprendizaxe
- Persoas con baixa visión
- Persoas con discapacidade que acceden desde dispositivos móbiles
Considerábase que o WCAG 2.0 non cubrían como era de esperar as necesidades de determinados tipos de discapacidades como as cognitivas ou as necesidades de persoas con baixa visión. Así mesmo, nos últimos anos as tecnoloxías e as formas de acceder á contido web variaron de forma significativa dando lugar a situacións non contempladas orixinalmente no WCAG 2.0.
O WCAG 2.1 pretenden cubrir un maior conxunto de recomendacións para facer a web máis accesible. Estas Pautas aspiran a mellorar a accesibilidade da contido web tanto en contornas de escritorio e portátiles como en tablets e dispositivos móbiles.
Si, o WCAG 2.1 teñen compatibilidade cara atrás co WCAG 2.0.
O WCAG 2.1 pódense considerar como un superconjunto que contén ao WCAG 2.0. Aqueles criterios de conformidade do WCAG 2.0 que se consideraban mellorables foron complementados con outros novos criterios máis específicos, pero sen cambiar a redacción orixinal dos requisitos orixinais os cales seguen sendo válidos. Por tanto, como o WCAG 2.1 estenden o WCAG 2.0, non existen requisitos que sexan incompatibles entre unha versión e a outra.
Esta estratexia de ampliación axuda a deixar claro que se unha páxina web é conforme ao WCAG 2.1 tamén será conforme ao WCAG 2.0. E en sentido contrario, se unha páxina web é conforme ao WCAG 2.0 poderase actualizar ao WCAG 2.1 sen incompatibilidades.
Así, por exemplo, mentres no WCAG 2.0 pedíase unicamente un contraste suficiente entre a cor do texto e a cor de fondo (SC 1.4.3) no WCAG 2.1 o requisito de contraste esténdese tamén ao contido non textual mediante a incorporación dun novo criterio de conformidade (SC 1.4.11).
Non, como se comentou na pregunta anterior, os criterios de conformidade do WCAG 2.0 mantivéronse sen modificar dentro do WCAG 2.1. Podemos dicir que o WCAG 2.0 están incluídas tal cal dentro do WCAG 2.1.
As novidades inclúense en forma de novos criterios de conformidade, novas definicións para a súa explicación e un par de novas consideracións a ter en conta nos requisitos xerais de conformidade.
Non, a numeración dos criterios de conformidade do WCAG 2.0, así como o seu nivel de conformidade, mantense sen modificar no WCAG 2.1. De igual forma, tamén se mantén a numeración das técnicas suficientes, técnicas complementarias e fallos asociados aos criterios de conformidade. Desta forma non é necesario cambiar ningunha das referencias existentes á documentación das Pautas realizadas desde informes, guías, ferramentas, etc.
Para preservar a numeración do WCAG 2.0 os novos criterios de conformidade engádense a seguir dos xa existentes nas Pautas correspondentes. Con todo, esta estratexia de actualización na que non se modifica a numeración ten como consecuencia que no WCAG 2.1 pérdese a orde dos criterios con base no seu nivel de conformidade dentro de cada pauta, onde estaban ordenados desde o nivel A ata o AA.
Así, por exemplo, a Pauta 1.4 contiña 9 criterios de conformidade, desde o 1.4.1 de nivel A ata o 1.4.9 de nivel AAA. No WCAG 2.1 engádense a esta pauta catro novos criterios continuando coa numeración existente (1.4.10 ata 1.4.13) sendo todos de nivel AA.
Si, introdúcese unha novidade importante a ter en conta á hora de considerar se unha páxina web é conforme co WCAG 2.1 (apartado 5.2).
Engádese unha nota adicional na que se indica que para que unha páxina sexa conforme hao de ser tamén en cada variación da páxina que se presenta de forma automática para diferentes tamaños de pantalla (p. ex. as variacións dunha páxina web “responsive” ou adaptable). Por tanto, un sitio web que teña un deseño web adaptable (Responsive web design) con diferentes maquetaciones para móbil, tablet e escritorio deberá cumprir todos os criterios de conformidade en cada unha das súas posibles visualizacións.
Un dos principais obxectivos do WCAG 2.1 é mellorar a accesibilidade das páxinas web para as persoas con discapacidade que acceden desde dispositivos móbiles.
Para conseguir este obxectivo incluíronse unha serie de novos requisitos que apuntan nesa dirección. Con todo, e en relación directa coa visualización en dispositivos móbiles, o criterio de conformidade 1.4.10 Reflow esixe que o contido se presente sen perda de información ou funcionalidade e sen necesidade de realizar scroll en dúas dimensións en áreas de visualización reducidas (320x256 píxeles CSS). Aínda que este criterio está pensado inicialmente para mellorar a experiencia das persoas con baixa visión asegurando que se poida facer zoom ata polo menos un 400% do tamaño orixinal sen que se produza un dobre scroll (partindo dunha resolución de 1280x1024), na práctica e implicitamente tamén supón que a páxina se debe “adaptar” correctamente a diferentes tamaños de xanela.
No propio criterio de conformidade indícase que permitir o reaxuste do contido coñécese tamén como Deseño Web Adaptable (Responsive Web Design) e considérase como a forma máis efectiva para conseguir cumprir este criterio. Así, entre as técnicas indicadas está o uso de media queries para establecer puntos de ruptura e reformatear o contido para diferentes largos de visualización. Estes puntos de ruptura dispáranse de igual forma tanto se se reduce o tamaño da xanela coma se faise zoom sobre o contido.
Precisamente, determinouse un valor de 320 píxeles CSS como obxectivo porque se considera o tamaño mínimo razoable para o que é factible maquetar un sitio web. Tamén se escolleu este valor porque coincide co largo de pantalla máis pequeno dos dispositivos móbiles máis comúns e porque se corresponde cun zoom de 400% nun navegador de escritorio cun largo de xanela de 1280px.
No entanto, é importante ter en conta que este requisito contempla como excepcións aquelas partes do contido que requiren dunha presentación e maquetación en dúas dimensións para poder transmitir su significado o para poder emplearse de forma correcta.
Dentro desta excepción pódense incluír as imaxes e contidos multimedia xa que por natureza teñen dúas dimensións, aínda que é posible a súa redimensión ata adaptalos ao tamaño da xanela. Unha excepción máis clara é o caso das táboas de datos, nas que as relacións entre as celas establécense nun contexto bidimensional. Por tanto, as táboas de datos, en especial as táboas de datos complexas, están fóra do alcance deste requisito.
Outro contido que se pode considerar como unha excepción son aquelas interfaces de usuario complexas como as que proporcionan barras de ferramentas para editar contidos que se deben mostrar simultaneamente xunto coa barra de ferramentas (editores de texto, editores gráficos, etc.). Por outra banda, aínda que non se mencione de forma explícita no WCAG 2.1, pódense considerar tamén como excepción os formularios ou trámites de notoria complexidade, tanto a nivel de interacción como de visualización, de forma que non son razoablemente operables desde dispositivos móbiles.
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í, o criterio de conformidade 1.3.4 Orientación indícanos que o contido non pode restrinxir a súa visualización e funcionalidade a unha única orientación da pantalla (horizontal ou vertical) a non ser que dita orientación específica sexa esencial. Algúns usuarios teñen os dispositivos ancorados nunha posición fixa (p. ex. sobre unha cadeira de rodas) e non poden modificar a súa orientación. Por exemplo, un usuario cunha tablet ancorada en posición vertical non podería acceder a un sitio web que só se mostrase en posición horizontal.
O criterio de conformidade 2.5.1 Xestos do Punteiro indica que toda a funcionalidade que empregue xestos multipunto ou dependentes do trazo realizado tamén se debe poder realizar empregando un único punto de contacto e sen trazos, mediante unha pulsación sinxela cun dedo ou cun punteiro. Por exemplo, se é posible facer un xesto de pinza con dous dedos para facer zoom sobre un mapa ou un movemento lineal para desprazarse sobre o mesmo entón tamén debe haber un par de botóns que permitan facer zoom e outros botóns (p. ex. roda de catro puntos) que permitan o desprazamento. O obxectivo deste criterio é asegurar que o contido se pode operar desde un gran número de dispositivos de entrada sinxelos de forma que as persoas con problemas de mobilidade póidanos realizar.
O criterio de conformidade 2.5.4 Activación Mediante o Movemento indica que calquera funcionalidade que se poida operar mediante o movemento do dispositivo tamén se debe poder realizar a través da interface de usuario e tamén se debe poder desactivar dita operación mediante o movemento para evitar accións non desexadas. Isto beneficia ás persoas que teñen os seus dispositivos ancorados en posicións fixas (p. ex. unha cadeira de rodas) e non poden interactuar mediante o movemento. Tamén se evita que persoas con problemas de mobilidade executen certas accións accidentalmente ao realizar movementos non controlados.
Por outra banda, aínda que o contido véxase correctamente nun dispositivo móbil non se debe bloquear a posibilidade de facer zoom sobre o mesmo. Considérase un erro empregar, por exemplo, elementos meta con “maximum-scale” ou “minimum-scale” ou ben con “user-scalable=non” ou “user-scalable=0”.
Finalmente, e cun carácter máis xeral, no requisito de conformidade Páxinas Completas indícase que para que unha páxina web póidase considerar conforme tamén debe selo en cada unha das súas diferentes formas de visualización. É dicir, tamén se han de cumprir todos os criterios de conformidade en cada unha das versións da páxina web (móbil, tablet, escritorio, etc.).
En relación aos formularios o WCAG 2.1 inclúen algunhas novidades importantes a ter en conta.
O criterio de conformidade 1.3.5 Identificar o Propósito da Entrada indica que se debe poder determinar automaticamente a finalidade daqueles campos de introdución de datos que solicitan información acerca das persoas. O obxectivo é que as aplicacións de usuario poidan extraer esta información e ofrecerlla ás persoas en diferentes modalidades ou ben autocompletar dita información para facilitar a interacción cos formularios.
Nalgúns casos pode parecer suficiente cos novos tipos de elementos de HTML5 tipo “tel”, “e-mail”, “contrasinal”, etc. Con todo, aínda que estes campos achegan certa información sobre a natureza do tipo de dato a introducir, as categorías que se poden empregar son demasiado xenéricas. Por exemplo, serven para indicar que un campo se trata dun e-mail ou un teléfono, pero non aclaran cal é o dato concreto ao que se refiren (teléfono ou e-mail do usuario ou doutra persoa?).
Por tanto é preciso empregar técnicas alternativas como o atributo “autocomplete” de HTML 5.2 e un valor que indique o tipo de información solicitada (p. ex. "name", "honorific-prefix", "given-name", "additional-name", "family-name", ...).
Por outra banda, o criterio de conformidade 2.5.3 Etiqueta no Nome pide que para os compoñentes da interface de usuario que dispoñan dunha etiqueta textual (ou imaxe de texto) entón o seu nome programático ou nome accesible (etiqueta
Aínda que no WCAG 2.0 só se esixía un contraste mínimo para o contido textual, incluíndo o texto mostrado en imaxes, no WCAG 2.1 este requisito esténdese tamén para aquel contido non textual cuxa información visual é necesaria para a súa comprensión ou identificación. Así, é necesario asegurar un mínimo de contraste en todos os elementos visuais necesarios para recoñecer e identificar os diferentes compoñentes que forman parte da interface de usuario e os seus posibles estados (excepto no caso dos compoñentes inactivos). Por exemplo, as ligazóns, botóns, campos de formulario, iconas que actúan como ligazóns (non acompañados de texto), o indicador do foco do teclado, etc.
Este requisito tamén é aplicable, de forma xeral, a todas aquelas partes dos contidos gráficos que sexan necesarias para a súa comprensión. É o caso, por exemplo, de calquera imaxe que transmita información como as iconas achega do formato de documentos ou aqueles que indican estados, identifican avisos, accións, redes sociais, etc. Isto tamén inclúe os diferentes elementos gráficos que formen parte de diagramas, infografías ou gráficas como poden ser as liñas, os fondos, límites dos obxectos, formas, etc., ademais do propio texto que puidese formar parte das mesmas.
Este criterio de conformidade esixe que se o usuario axusta a presentación do contido a certos parámetros, non se perda contido ou funcionalidade. Os parámetros a justar son os seguintes:
- Alto de liña: polo menos 1.5veces o tamaño da fonte.
- Espazo entre parágrafos: polo menos 2 veces o tamaño da fonte.
- Espazo entre letras (tracking): polo menos 0.12 veces o tamaño da fonte.
- Espazo entre palabras: polo menos 0.16 veces o tamaño da fonte.
Para validar este criterio pódese utilizar o Bookmarklet de Steve Faulkner, dispoñible en https://www.html5accessibility.com/tests/tsbookmarklet.html https://www.html5accessibility.com/tests/tsbookmarklet.html
Este criterio de conformidade fai referencia ao contido adicional que se mostra cando un elemento recibe ou perde o punteiro (hover) ou o foco do teclado (focus), por exemplo o menú desplegable que se mostra cando se pon o punteiro por encima dun elemento. Debe existir un mecanismo adicional que permita descartar o contido adicional sen necesidade de mover o punteiro ou cambiar o foco do teclado.
Que mecanismo pódese utilizar para descartar o contido adicional sen necesidade de mover o punteiro ou cambiar o foco do teclado?
As opcións que se propoñen son o uso da tecla ESC ou un botón específico para pechar (o típico botón “X” ou “Pechar”), aínda que o botón debe ter xa o foco no momento de mostrarse o contido adicional para que non faga falta desprazar o foco ata o mesmo.
Sempre debe existir un mecanismo que permita descartar o contido adicional sen necesidade de mover o punteiro ou cambiar o foco do teclado?
Non, se o contido adicional que se mostra informa acerca dun erro na entrada de datos ou se non tapa ou substitúe outro contido, non é necesario ofrecer este mecanismo, xa que non entorpece a visualización de ningún contido.
O contido adicional que se mostra ou oculta cuxa presentación visual está controlada pola aplicación de usuario e non polos desenvolvedores como, por exemplo, o tooltip que mostra o contido do atributo title (título), tampouco está afectado por este criterio.
O criterio se aplica, por exemplo a menús desplegables, pop-ups non modais, tooltips personalizados…
Nos compoñentes da interface de usuario (como os campos de formulario, botóns, ligazóns, controis que se poidan xerar mediante scripts como sliders, tabs, treeviews…) é necesario que o texto visible (que actúa como a súa etiqueta e que serve para recoñecelos visualmente) tamén forme parte do seu nome accesible (usado polos axentes ou ferramentas de usuario para mostrar o contido a persoas con discapacidade).
Para cumprir este criterio débese cumprir que o Nome accesible sexa o contido da etiqueta accesible e opcionalmente pódese pór algo máis, pero o comezo do nome accesible debe ser idéntico ao contido da etiqueta accesible, para que o que se mostra en pantalla (etiqueta) e o que as ferramentas utilizan (nome accesible) comece exactamente igual.
Nome accesible = Etiqueta accesible + [xxxx]
Cada compoñente de interface de usuario ten un nome accesible por defecto ou ben o nome accesible pode determinarse usando a ARIA. Se se usa a ARIA, prevalece sobre o nome por defecto.
Cada compoñente de interface de usuario ten un nome accesible por defecto (contido do elemento, valor dun atributo ou elemento asociado). A seguir móstrase o nome accesible por defecto para cada compoñente de EU:
| Compoñente da EU | Nome accesible por defecto |
|---|---|
| Contido do elemento asociado |
|
| Valor do atributo value=”XXXX” | |
| Valor do atributo alt=”XXXX” | |
|
|
Contido do elemento |
| Contido do elemento XXXX |
Hai que ver o que se mostra por pantalla e ver se coincide co nome accesible.
A seguir móstranse exemplos para clarificar o criterio.
Nos seguintes casos o texto que aparece por pantalla e o nome accesible COINCIDEN:
Buscar
Nos seguintes casos o texto que aparece por pantalla NON COINCIDEN co nome accesible:
Por pantalla aparece “Go” e o nome accesible é “Find in this site”
Por pantalla aparece “Download specification” e o nome accessible é “Download gizmo specification”
Download gizmo specification
Por pantalla aparece “Search” e o nome accessible é “find in this site”
Material relacionado
Material relacionado