Artículo Lo que debe saber sobre los próximos cambios de las WCAG
Publicado: 2022-10-07En septiembre de 2022, el W3C anunció que la próxima versión de las WCAG había alcanzado el estado de recomendación de candidato. A menos que se produzcan cambios de última hora, la versión 2.2 de la norma debería ratificarse pronto. Los cambios son relativamente menores, pero cualquier persona responsable de la construcción o el mantenimiento de un sitio web debe saber lo que se avecina.
Si ya está familiarizado con las WCAG, puede omitir la descripción general y pasar directamente a los detalles nerd; de lo contrario, siga leyendo.
¿Qué son las WCAG y por qué son importantes?
Las Pautas de Accesibilidad al Contenido Web (WCAG) comprenden un conjunto de criterios diseñados para ayudar a los desarrolladores web, diseñadores y administradores de contenido a garantizar que sus sitios web sean accesibles para personas con una amplia gama de discapacidades. El equipo de la Iniciativa de Accesibilidad Web del W3C es responsable del estándar. El W3C y WAI comprenden un consorcio de líderes de la industria y expertos en la materia enfocados en hacer que la web sea más accesible.
Las WCAG están organizadas bajo cuatro principios de accesibilidad. Esos principios establecen que un sitio web debe ser perceptible, operable, comprensible y robusto. Dentro de cada uno de estos principios hay pautas que describen los objetivos básicos. Dentro de cada directriz hay criterios de éxito que describen un objetivo específico y medible que los desarrolladores de sitios web deben cumplir para cumplir con las WCAG.
Cada uno de los criterios de éxito tiene un indicador de nivel de conformidad de A, AA o AAA. Los criterios del nivel A se cumplen más fácilmente, mientras que AAA es el más estricto.
¿Me demandarán si mi sitio web no cumple con WCAG 2.2 AA?
La respuesta definitiva es "tal vez".
En los EE. UU., las leyes son ambiguas y la ADA no aborda explícitamente los sitios web. Si bien existen leyes muy específicas sobre las adaptaciones que se deben realizar en un espacio físico, lo único que dice la ADA que se puede aplicar directamente a los sitios web es que las "instalaciones de una empresa deben ser accesibles". Incluso entonces, no todos los tribunales están de acuerdo sobre si un sitio web cuenta como una instalación de una empresa y en ninguna parte existe una definición clara de "accesible". Tenga en cuenta que estamos hablando de sitios web de empresas privadas y leyes federales. Para los sitios web del gobierno federal y de algunos estados, existen leyes que se aplican.
Debido a que no existe una definición clara de "accesible", recurrimos a las WCAG para que nos digan qué hacer al crear o mantener un sitio web. Ninguna ley de EE. UU. recomienda específicamente ninguna versión de las WCAG (o cualquier otro estándar) para sitios web públicos. Sin embargo, esforzarse por cumplir con cualquier versión de los criterios de éxito de las WCAG es una buena meta. Debe conducir a un sitio que sea razonablemente accesible para todos.
¿Cómo se desarrollan los estándares?
Contrariamente a la creencia popular, el desarrollo de estándares no se lleva a cabo en una torre de marfil por un grupo selecto de participantes. Si bien gran parte del trabajo lo realizan los empleados de las organizaciones miembros, gran parte del trabajo proviene de expertos invitados y otras personas apasionadas por el tema y dispuestas a dedicar su tiempo. Además, muchos equipos de estándares tienen foros públicos abiertos donde se alienta a los miembros de la comunidad en general a participar haciendo preguntas o planteando nuevos problemas.
Para las WCAG, el público puede leer y comentar sobre los estándares abriendo una nueva edición, una solicitud de incorporación de cambios o simplemente participando en las discusiones existentes en el repositorio de las WCAG en Github. Cuando llega al grupo con una idea, siempre es aconsejable buscar todos los problemas existentes y las solicitudes de extracción para asegurarse de que su idea aún no se haya presentado. Si está pensando en contribuir a las WCAG con una solicitud de extracción, siempre tómese el tiempo para abrir un problema y discutir su idea primero. Existe una gran posibilidad de que pueda ahorrarse un trabajo innecesario.
Contribuir a los estándares puede ser frustrante y difícil, pero también es muy gratificante. En su mayor parte, los participantes son muy acogedores y pacientes. Si se toma el tiempo de investigar sus ideas, hace su debida diligencia y es cortés y respetuoso con los demás, entonces sus contribuciones serán bienvenidas. El peor resultado posible es que te familiarices con el tema más de lo que jamás habías creído posible.
¿Qué está cambiando?
Un criterio de éxito existente ha cambiado en WCAG 2.2 y se han agregado nueve criterios de éxito completamente nuevos. Aquí nos limitaremos solo a los niveles A y AA, ya que rara vez apuntamos a AAA. Para ver todos los nuevos criterios, consulte el artículo completo del W3C,
2.4.7 Foco Visible (A)
Este criterio ha cambiado del Nivel AA al A, que es el nivel más bajo para el cumplimiento de las WCAG. Parte de la razón por la que existe es que, en un pasado no muy lejano, era una práctica común para las personas que creaban sitios web eliminar los anillos de enfoque. Después de todo, no formaban parte del diseño. Esto significaba que los usuarios que navegaban por una página web con su teclado no podían ver dónde estaban en una página. Tiene sentido que este criterio se mueva a single-A porque una gran cantidad de usuarios dependen de la navegación del teclado, incluso aquellos sin ningún tipo de impedimento.
Todos los principales navegadores web mostrarán anillos de enfoque de forma predeterminada. El requisito clave aquí es no romper la funcionalidad integrada.
W3C - Comprender el enfoque visible
2.4.11 Aspecto de enfoque (AA)
Este nuevo criterio define algunas reglas aclaratorias sobre la visibilidad de los anillos de enfoque. Deben tener una relación de contraste de 3:1 con los píxeles circundantes y los píxeles que reemplazan. También deben encerrar el elemento o subcomponente que está enfocado o ser tan grandes como una línea gruesa de 4 píxeles a lo largo del borde más corto del elemento.
Nuevamente, los anillos de enfoque predeterminados del navegador generalmente cumplirán este criterio. Dado que los usuarios están acostumbrados a los valores predeterminados, solo debe anularlos si es necesario. Un ejemplo podría ser si no hay suficiente contraste de color entre el anillo de enfoque predeterminado y el color primario de su marca. Los navegadores suelen tener anillos de enfoque azules predeterminados, por lo que si tiene azul en la paleta de su marca, puede haber un conflicto.
W3C – Comprender la apariencia del foco
2.4.12 Foco no oscurecido (mínimo) (AA)
Este criterio establece que el enfoque no debe quedar completamente oscurecido por el contenido generado por el usuario. Esto está destinado a evitar que el contenido en capas, como la navegación fija (una barra de menú que permanece en la parte superior de la ventana mientras el usuario se desplaza), oculte los indicadores de enfoque.
La solución más fácil aquí es simplemente no tener ningún elemento pegajoso. Sin embargo, los sitios web modernos hacen un uso liberal de la navegación fija y los CTA flotantes, por lo que es probable que no sea una opción. Existe cierta expectativa de que las propiedades CSS de relleno de desplazamiento y margen de desplazamiento algún día nos permitan definir un desplazamiento que se adapte a la navegación fija. Por ahora, esas propiedades se usan exclusivamente en elementos que aprovechan el ajuste de desplazamiento.
Eso nos deja con JavaScript. En general, nuestro objetivo es usar JavaScript en el navegador solo cuando sea necesario. Esta función StickyFix monitoreará los elementos enfocables dentro del elemento principal, y si están oscurecidos por la navegación fija cuando se enfocan, se desplazarán a la vista.
Para usar esta función, simplemente inclúyala en los archivos JavaScript de su sitio.
/** * A minimal function that will detect if a focusable element is obscured by sticky navigation * This only works for sticky elements at the top of the page, but could be extended * @author Donovan Buck <dbuck@brandextract.com> * @param {string} selector - A valid CSS selector string for the sticky element * @param {number} offset - An additional offset for the focused element * * @see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors * @tutorial https://www.brandextract.com/Insights/Articles/Changes-to-the-Web-Content-Accessibility-Guidelines/ * @license MIT */ function stickyFix(selector, offset = 0) { // Find the height of our sticky element const sticky = document.querySelector(selector); let stickyRect = sticky.getBoundingClientRect(); let stickyHeight = stickyRect.bottom - stickyRect.top; // Select all the focusable elements within the main element const focusables = document.querySelectorAll('main button:not([disabled]), main [href], main input:not([disabled]), main select:not([disabled]), main textarea:not([disabled]), main [tabindex]:not([tabindex="-1"]):not([disabled]), main details:not([disabled]), main summary:not(:disabled)'
); // Add a listener to each focusable element focusables.forEach(focusable => { focusable.addEventListener('focus', (event) => { const targetRect = event.target.getBoundingClientRect(); if(targetRect.top < stickyHeight + offset) { window.scrollTo({ top: targetRect.top + window.scrollY - stickyHeight - offset }); } }); }); };A continuación, puede llamar a la función:
// Wait for the document to load document.addEventListener("DOMContentLoaded", function() { stickyFix('.sticky', 24); });Comprender el enfoque no oscurecido (mínimo)
2.5.7 Movimientos de Arrastre (AA)
Este criterio establece que si los movimientos de arrastre son parte de la interfaz de usuario, entonces se debe proporcionar un método alternativo que permita acciones simples de apuntar y hacer clic. Un ejemplo de esto podría ser un formulario que permita a los usuarios arrastrar y soltar archivos desde su computadora al navegador para cargarlos. Debe asegurarse de que un usuario también pueda usar su cuadro de diálogo de carga de archivos para elegir qué archivos se deben cargar. Los movimientos de arrastre generalmente no son necesarios en la mayoría de las interfaces de usuario de sitios web, con esta excepción.
Comprender los movimientos de arrastre
2.5.8 Tamaño del objetivo (mínimo) (AA)
Cualquier objetivo de puntero debe tener un mínimo de 24 x 24 píxeles, a menos que ese objetivo esté al menos a 24 píxeles de distancia de todos los objetivos adyacentes o el objetivo esté en una oración o bloque de texto. Al verificar un diseño para este criterio, tenga mucho cuidado de verificar los enlaces para compartir en redes sociales que usan solo íconos y todas sus listas de navegación.
Comprender el tamaño objetivo (mínimo)
3.2.6 Ayuda consistente (A)
Suponga que su sitio web contiene detalles de contacto, una opción de autoayuda o cualquier mecanismo de contacto que aparece en varias páginas. En ese caso, esos elementos deberían aparecer en el mismo orden en relación con el resto del contenido de la página en todo su sitio. Esto es en gran parte una función de un diseño bueno y consistente, y este criterio no debería ser difícil de cumplir.
Comprensión de la ayuda consistente
3.3.7 Autenticación Accesible (AA)
Obligar a un usuario a recordar un nombre de usuario y una contraseña puede crear una carga indebida para las personas con discapacidades cognitivas. Debido a esto, los desarrolladores web nunca deben crear un proceso de inicio de sesión que no permita el uso de administradores de contraseñas o copiar y pegar. Este criterio permite métodos de autenticación alternativos, siempre que no dependan de una prueba de función cognitiva como recordar una contraseña o resolver un rompecabezas.
Descripción de la autenticación accesible
3.3.9 Entrada redundante (A)
Este criterio establece que cualquier información ingresada previamente por el usuario durante el mismo proceso se completará automáticamente o estará disponible para que el usuario la seleccione en lugar de tener que volver a ingresar la información manualmente. Obviamente, esto debería ser una conveniencia esperada para cualquiera.
Comprender la entrada redundante
Referencias
- Novedades en el borrador de WCAG 2.2
- El repositorio WCAG del W3C en Github