Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles

 

 

 

  • Accessibility for Designers, with Stéphanie Walter
  • Behavioral Design Workshop, with Susan and Guthrie Weinschenk

  • Índice
    1. Determinar si solo CSS es una solución adecuada
    2. Información sobre herramientas
      1. Alternativas a la información sobre herramientas
    3. modales
      1. Modal Focus Decision Tree
    4. Pestañas
      1. Sobre itinerantetabindex
    5. Patrones de pestañas de ejemplo
    6. Carruseles
      1. Recursos para construir carruseles accesibles
    7. Menús desplegables
      1. Recursos adicionales sobre la creación de componentes accesibles

    Alerta de spoiler: información sobre herramientas, modales, pestañas, carruseles y menús desplegables son algunos de los componentes de la interfaz de usuario que requieren más que CSS. Para garantizar la accesibilidad de su interfaz, JavaScript es una adición necesaria para lograr la gestión del foco, responder a eventos del teclado y alternar atributos ARIA.

     

    Como autor de ModernCSS.dev , soy un gran defensor de las soluciones CSS. ¡Y me encanta ver las formas inteligentes en que la gente usa CSS para lograr interactividad y diseños realmente innovadores! Sin embargo, he notado una tendencia hacia la promoción de componentes "solo CSS" utilizando métodos como el " truco de casilla de verificación ". Desafortunadamente, trucos como estos dejan a una cantidad significativa de usuarios sin poder utilizar su interfaz.

    Este artículo cubre varios componentes comunes y por qué CSS no es suficiente para cubrir la accesibilidad al detallar los requisitos de JavaScript. Estos requisitos se basan en las Pautas de accesibilidad al contenido web (WCAG) e investigaciones adicionales realizadas por expertos en accesibilidad. No prescribiré soluciones de JavaScript ni demostraciones de CSS, sino que examinaré lo que se debe tener en cuenta al crear cada componente. Ciertamente se puede utilizar un marco de JavaScript, pero no es necesario para agregar los eventos y características discutidos.

    Los requisitos enumerados en general no son opcionales; son necesarios para ayudar a garantizar la accesibilidad de sus componentes.

    Si está utilizando un marco o una biblioteca de componentes, puede utilizar este artículo para ayudar a evaluar si los componentes proporcionados cumplen con los requisitos de accesibilidad . Es importante saber que muchos de los elementos señalados no estarán completamente cubiertos por herramientas de prueba de accesibilidad automatizadas como aXe y, por lo tanto, necesitarán algunas pruebas manuales. O puede utilizar un marco de prueba como Cypress para crear pruebas para la funcionalidad requerida.

    Tenga en cuenta que este artículo se centra en informarle sobre las consideraciones de JavaScript para cada componente de la interfaz. Este no es un recurso completo para todos los detalles de implementación para crear componentes totalmente accesibles, como el aria necesaria o incluso el marcado. Se incluyen recursos para cada tipo para ayudarle a aprender más sobre las consideraciones más amplias para cada componente.

    Determinar si solo CSS es una solución adecuada

    Aquí hay algunas preguntas que debe hacerse antes de continuar con una solución solo CSS. Cubriremos algunos de los términos presentados aquí en más contexto junto con sus componentes relacionados.

    • ¿Es esto para tu propio disfrute?
      Entonces, ¡apueste por completo en CSS, supere los límites y aprenda lo que el lenguaje puede hacer!
    • ¿La función incluye mostrar y ocultar contenido?
      Luego necesita JS para alternar como mínimo aria y habilitar el cierre Esc. Para ciertos tipos de componentes que también cambian de estado, es posible que también necesite comunicar los cambios activando actualizaciones dentro de una región activa de ARIA.
    • ¿El orden de enfoque natural es el más ideal?
      Si el orden natural pierde la relación entre un disparador y el elemento que activó, o un usuario del teclado ni siquiera puede acceder al contenido a través del orden de tabulación natural, entonces necesita JS para ayudar en la gestión del enfoque.
    • ¿El control estilizado ofrece la información correcta sobre la funcionalidad?
      Los usuarios de tecnología de asistencia, como lectores de pantalla, reciben información basada en semántica y ARIA que les ayuda a determinar qué hace un control. Y los usuarios de reconocimiento de voz deben poder identificar la etiqueta o el tipo del componente para determinar la frase que utilizarán para operar los controles. Por ejemplo, si su componente tiene el estilo de pestañas pero usa botones de opción para "funcionar" como pestañas, un lector de pantalla puede escuchar "botón de opción" y un usuario de voz puede intentar usar la palabra "pestaña" para operarlos. En estos casos, necesitará JS para permitir el uso de los controles y la semántica adecuados para lograr la funcionalidad deseada.
    • ¿El efecto depende del desplazamiento y/o del enfoque?
      Entonces es posible que necesite que JS le ayude con una solución alternativa para proporcionar acceso equitativo o acceso persistente al contenido, especialmente para usuarios de pantalla táctil y aquellos que utilizan un zoom de escritorio de más del 200% o software de ampliación.

    Consejo rápido : Otra referencia al crear cualquier tipo de control personalizado es la Lista de verificación de desarrollo accesible de control personalizado de la guía W3 “Uso de ARIA”. Esto menciona varios puntos anteriores, con algunas consideraciones semánticas y de diseño adicionales.

     

    Información sobre herramientas

    Restringir la definición de información sobre herramientas es un poco complicado, pero en esta sección estamos hablando de pequeñas etiquetas de texto que aparecen al pasar el mouse cerca de un elemento activador. Se superponen a otro contenido, no requieren interacción y desaparecen cuando un usuario quita el cursor o el foco.

    Información sobre herramientas de ejemplo de GitHub, Whimsical y Notion. ( Vista previa grande )

    La solución CSS aquí puede parecer completamente buena y se puede lograr con algo como:

    buttonI have a tooltip/buttonspanTooltip/span.tooltip {display: none;}.tooltip-trigger:hover + .tooltip,.tooltip-trigger:focus + .tooltip {display: block;}

    Sin embargo, esto ignora una gran lista de problemas de accesibilidad y excluye a muchos usuarios del acceso al contenido de información sobre herramientas.

    Un gran grupo de usuarios excluidos son aquellos que usan pantallas táctiles donde :hoverposiblemente no se activen, ya que en las pantallas táctiles, un :hoverevento se activa en sincronización con otro :focusevento. Esto significa que cualquier acción relacionada conectada al elemento desencadenante, como un botón o enlace, se activará junto con la información sobre herramientas que se revela. Esto significa que el usuario puede perderse la información sobre herramientas o no tener tiempo para leer su contenido.

     

    En el caso de que la información sobre herramientas esté adjunta a un elemento interactivo sin eventos, la información sobre herramientas puede mostrarse pero no descartarse hasta que otro elemento obtenga el foco y, mientras tanto, puede bloquear el contenido e impedir que un usuario realice una tarea.

    Además, los usuarios que necesitan utilizar software de zoom o ampliación para navegar también experimentan una gran barrera para utilizar la información sobre herramientas. Dado que la información sobre herramientas se revela al pasar el mouse, si estos usuarios necesitan cambiar su campo de visión al desplazarse por la pantalla para leer la información sobre herramientas, es posible que desaparezca. La información sobre herramientas también elimina el control del usuario, ya que a menudo no hay nada que le indique que aparecerá información sobre herramientas con anticipación. La superposición de contenido puede impedirles realizar una tarea. En algunas circunstancias, como una información sobre herramientas vinculada a un campo de formulario, un móvil u otros teclados en pantalla pueden oscurecer el contenido de la información sobre herramientas. Y, si no están conectados adecuadamente al elemento desencadenante, es posible que algunos usuarios de tecnología de asistencia ni siquiera sepan que ha aparecido una información sobre herramientas.

    La orientación para el comportamiento de la información sobre herramientas proviene del Criterio de éxito 1.4.13 de las WCAG: Contenido al pasar el cursor o enfocarse . Este criterio tiene como objetivo ayudar a los usuarios con baja visión y a aquellos que utilizan software de zoom y ampliación. Los principios rectores de la información sobre herramientas (y otro contenido que aparece al pasar el cursor y enfocar) incluyen:

    • Descartable
      La información sobre herramientas se puede descartar sin mover el cursor o el foco.
    • Hoverable
      El contenido de la información sobre herramientas revelada se puede desplazar sin que desaparezca.
    • Persistente
      El contenido adicional no desaparece según un tiempo de espera, sino que espera a que un usuario elimine el cursor o el foco o lo descarte de otro modo.

    Para cumplir plenamente con estas pautas se requiere cierta ayuda de JavaScript, particularmente para permitir descartar el contenido.

    • Los usuarios de tecnología de asistencia asumirán que el comportamiento de descarte está vinculado a la Escclave, lo que requiere un detector de JavaScript.
    • Según la investigación de Sarah Higley que se describe en la siguiente sección, agregar un botón de "cerrar" visible dentro de la información sobre herramientas también requeriría JavaScript para manejar su evento de cierre.
    • Es posible que JavaScript necesite aumentar su solución de estilo para garantizar que un usuario pueda pasar el cursor sobre el contenido de la información sobre herramientas sin que se descarte mientras el usuario mueve el mouse.

    Alternativas a la información sobre herramientas

    La información sobre herramientas debería ser el último recurso. Sarah Higley, una experta en accesibilidad que tiene una pasión particular por disuadir el uso de información sobre herramientas, ofrece esta sencilla prueba:

     

    “¿Por qué agrego este texto a la interfaz de usuario? ¿A dónde más podría ir?

    — Sarah Higley de la presentación “ Información sobre herramientas: investigación en cuatro partes ”

    Según la investigación en la que Sarah participó por su puesto en Microsoft, una solución alternativa es una "sugerencia de alternancia" dedicada. Básicamente, esto significa proporcionar un elemento adicional que permita al usuario activar intencionalmente la visualización y ocultación de contenido adicional . A diferencia de la información sobre herramientas, las sugerencias de alternancia pueden conservar la semántica de los elementos dentro del contenido revelado. También le devuelven al usuario el control para alternarlos y mantienen la capacidad de descubrimiento y operatividad por parte de más usuarios y, en particular, de los usuarios de pantalla táctil.

    Si recuerda que el titleatributo existe, sepa que sufre los mismos problemas que notamos en nuestra solución solo CSS. En otras palabras, no lo utilice titlebajo el supuesto de que es una solución de información sobre herramientas aceptable.

    Para obtener más información, consulte la presentación de Sarah en YouTube , así como su extenso artículo sobre información sobre herramientas . Para obtener más información sobre información sobre herramientas versus sugerencias de alternancia y un poco más de información sobre por qué no usar title, revise el artículo de Heydon Pickering de Componentes inclusivos: información sobre herramientas y sugerencias de alternancia .

    modales

    Los modales, también conocidos como cajas de luz o cuadros de diálogo, son ventanas en la página que aparecen después de una acción desencadenante. Se superponen a otro contenido de la página, pueden contener información estructurada que incluye acciones adicionales y, a menudo, tienen un fondo semitransparente para ayudar a distinguir la ventana modal del resto de la página. Recetas de cocteles

    Modales de ejemplo de GitHub y Material Design. ( Vista previa grande )

    He visto algunas variaciones de un modal solo CSS (y soy culpable de crear una para una versión anterior de mi cartera). Pueden usar el "truco de casilla de verificación", hacer uso del comportamiento de :target, o intentar crearlo :focus(lo que probablemente sea en realidad una información sobre herramientas demasiado grande disfrazada).

    En cuanto al dialogelemento HTML, tenga en cuenta que no se considera accesible de forma completa. Entonces, si bien recomiendo absolutamente a la gente que use HTML nativo antes que soluciones personalizadas, desafortunadamente esta rompe esa idea. Puede obtener más información sobre por qué no se puede acceder al HTMLdialog .

    Unlike tooltips, modals are intended to allow structured content. This means potentially a heading, some paragraph content, and interactive elements like links, buttons or even forms. In order for the most users to access that content, they must be able to use keyboard events, particularly tabbing. For longer modal content, arrow keys should also retain the ability to scroll. And like tooltips, they should be dismissible with the Esc key — and there’s no way to enable that with CSS-only.

     

    JavaScript is required for focus management within modals. Modals should trap focus, which means once focus is within the modal, a user should not be able to tab out of it into the page content behind it. But first, focus has to get inside of the modal, which also requires JavaScript for a fully accessible modal solution.

    Here’s the sequence of modal related events that must be managed with JavaScript:

    1. Event listener on a button opens the modal
    2. Focus is placed within the modal; which element varies based on modal content (see decision tree)
    3. Focus is trapped within the modal until it is dismissed
    4. Preferably, a user is able to close a modal with the Esc key in addition to a dedicated close button or a destructive button action such as “Cancel” if acknowledgement of modal content is required
      1. If Esc is allowed, clicks on the modal backdrop should also dismiss the modal
    5. Upon dismissal, if no navigation occurred, focus is placed back on the triggering button element

    Based on the WAI-ARIA Authoring Practices Modal Dialog Example, here is a simplified decision tree for where to place focus once a modal is opened. Context will always dictate the choice here, and ideally focus is managed further than simply “the first focusable element”. In fact, sometimes non-focusable elements need to be selected.

    • Primary subject of the modal is a form.
      Focus first form field.
    • Modal content is significant in length and pushes modal actions out of view.
      Focus a heading if present, or first paragraph.
    • Purpose of the modal is procedural (example: confirmation of action) with multiple available actions.
      Focus on the “least destructive” action based on the context (example: “OK”).
    • Purpose of the modal is procedural with one action.
      Focus on the first focusable element

    Quick tip: In the case of needing to focus a non-focusable element, such as a heading or paragraph, add tabindex="-1" which allows the element to become programmatically focusable with JS but does not add it to the DOM tab order.

    Consulte la demostración modal WAI-ARIA para obtener más información sobre otros requisitos para configurar ARIA y detalles adicionales sobre cómo seleccionar a qué elemento agregar el foco. La demostración también incluye JavaScript para ejemplificar cómo realizar la gestión del enfoque.

    Para una solución lista para usar, Kitty Giraudel ha creado un diálogo a11y que incluye los requisitos de funciones que analizamos. Adrian Roselli también investigó la gestión del enfoque de los diálogos modales , creó una demostración y recopiló información sobre cómo las diferentes combinaciones de navegador y lector de pantalla comunicarán el elemento enfocado.

    Pestañas

    Las interfaces con pestañas implican una serie de activadores que muestran los paneles de contenido correspondientes uno a la vez. Los "trucos" de CSS que puede encontrar para estos implican el uso de botones de opción estilizados o :target, que solo permiten revelar un panel a la vez.

     

    Pestañas de ejemplo de Shopify Polaris e IBM Carbon. ( Vista previa grande )

    Estas son las funciones de las pestañas que requieren JavaScript:

    1. Alternar el aria-selectedatributo a verdadero para la pestaña actual y falso para pestañas no seleccionadas
    2. Crear un índice de tabulación móvil para distinguir la selección de pestañas del foco
    3. Mueva el foco entre pestañas respondiendo a los eventos de las teclas de flecha (y opcionalmente Homey End)

    Opcionalmente, puede hacer que la selección de pestañas siga el enfoque, es decir, cuando una pestaña está enfocada, también se selecciona y muestra su panel de pestañas asociado. Las Prácticas de Autoría WAI-ARIA ofrecen esta guía para elegir si la selección debe seguir el enfoque .

    Ya sea que elija que la selección siga el foco o no, también usará JavaScript para escuchar los eventos de las teclas de flecha para mover el foco entre los elementos de la pestaña. Este es un patrón alternativo para permitir la navegación por las opciones de pestañas , ya que el uso de un índice de pestañas móvil (descrito a continuación) altera el orden natural de enfoque de las pestañas del teclado.

    Sobre itinerantetabindex

    El concepto de un índice de tabulación itinerante es que el valor del tabindexvalor se controla mediante programación para gestionar el orden de enfoque de los elementos. En lo que respecta a las pestañas, esto significa que solo la pestaña seleccionada es parte del orden de enfoque mediante configuración tabindex="0", y las pestañas no seleccionadas se configuran para tabindex="-1"eliminarlas del orden de enfoque natural del teclado.

    La razón de esto es que cuando se selecciona una pestaña, la siguiente pestaña llamará la atención del usuario dentro del panel de pestañas asociado. Puede optar por hacer que el elemento que es el panel de pestañas sea enfocable asignándolo tabindex="0", o puede que no sea necesario si hay una garantía de un elemento enfocable dentro del panel de pestañas . Si el contenido de su panel de pestañas será más variable o complejo, puede considerar administrar el enfoque de acuerdo con el árbol de decisión que revisamos para los modales.

    Patrones de pestañas de ejemplo

    Aquí hay algunos patrones de referencia para crear pestañas:

    • Demostración de Tabpanel de la Universidad Deque
    • Pruebas de widgets de pestañas de Scott O'Hara (prueba varios patrones funcionales)
    • Interfaces con pestañas de Inclusive Components de Heydon Pickering , que demuestra cómo las pestañas pueden ser una mejora progresiva de una tabla de contenido.

    Carruseles

    También llamados presentaciones de diapositivas o controles deslizantes, los carruseles implican una serie de paneles de contenido giratorios (también conocidos como "diapositivas") que incluyen mecanismos de control. Los encontrará en muchas configuraciones con una amplia gama de contenido. Se los considera notoriamente un mal patrón de diseño .

     

    Un ejemplo de demostración de carrusel creado con bxSlider. ( Vista previa grande )

    La parte complicada de los carruseles exclusivos de CSS es que es posible que no ofrezcan controles o que utilicen controles inesperados para manipular el movimiento del carrusel. Por ejemplo, puede volver a utilizar el "truco de casilla de verificación" para provocar la transición del carrusel, pero las casillas de verificación brindan el tipo incorrecto de información sobre la interacción a los usuarios de tecnología de asistencia. Además, si diseña las etiquetas de las casillas de verificación para que aparezcan visualmente como flechas hacia adelante y hacia atrás, es probable que dé a los usuarios del software de reconocimiento de voz una impresión equivocada de lo que deberían decir para controlar el carrusel.

    Más recientemente, ha llegado el soporte CSS nativo para el ajuste de desplazamiento . Al principio, esta parece la solución perfecta solo para CSS. Pero incluso la verificación automática de accesibilidad los marcará como no navegables para los usuarios del teclado en caso de que no haya forma de navegar a través de elementos interactivos. Existen otras preocupaciones de accesibilidad y experiencia del usuario con el comportamiento predeterminado de esta función, algunas de las cuales he incluido en mi demostración de desplazamiento rápido en SmolCSS .

    A pesar de la amplia variedad de apariencia de los carruseles, existen algunos rasgos comunes. Una opción es crear un carrusel usando etiquetas de pestañas, ya que efectivamente es la misma interfaz subyacente con una presentación visual alterada. En comparación con las pestañas, los carruseles pueden ofrecer controles adicionales para el anterior y el siguiente, y también pausar si el carrusel se reproduce automáticamente.

    Las siguientes son consideraciones de JavaScript según las características de su carrusel:

    • Uso de controles paginados
      Al seleccionar un elemento numerado, enfoque mediante programación la diapositiva del carrusel asociada. Esto implicará configurar contenedores de diapositivas usando tabindex móvil para que pueda enfocar la diapositiva actual, pero evitar el acceso a diapositivas fuera de la pantalla.
    • Uso de la reproducción automática
      Incluya un control de pausa y también habilite la pausa cuando se pasa el cursor sobre la diapositiva o cuando se enfoca un elemento interactivo dentro de ella. Además, puede verificar prefers-reduced-motionen JavaScript que se cargue la presentación de diapositivas en un estado de pausa para respetar las preferencias del usuario.
    • Uso de controles anteriores/siguientes
      Incluya un elemento visualmente oculto marcado como aria-live="polite"y al activarse estos controles, complete la región en vivo con una indicación de la posición actual, como "Diapositiva 2 de 4".

    Recursos para construir carruseles accesibles

    • Consideraciones y detalles de implementación completos, así como un ejemplo de código completo del tutorial de accesibilidad web del W3C sobre carruseles.
    • El ejemplo de la Universidad Deque de cómo mejorar una interfaz de pestañas en un carrusel
    • El ejemplo de WAI-ARIA Authoring Practices de un carrusel de imágenes con rotación automática
    • Una selección de recursos de carrusel en el resumen de componentes accesibles de Smashing

    Esto se refiere a un componente donde un botón abre una lista de enlaces, generalmente utilizado para menús de navegación. Implementaciones de CSS que se limitan a mostrar el menú :hovero :focussolo omiten algunos detalles importantes.

     

    Menús desplegables de ejemplo de Dribbble, búsqueda de Google y GitHub. ( Vista previa grande )

    Lo admito, incluso pensé que al usar la :focus-withinpropiedad más nueva podríamos implementar de manera segura una solución solo CSS. Verá que mi artículo sobre los menús desplegables de CSS se modificó para incluir notas y recursos sobre el JavaScript necesario (conservé el título para que otros que busquen esa solución, con suerte, también completen la implementación de JS). Específicamente, confiar únicamente en CSS significa violar el Criterio de éxito 1.4.13 de las WCAG: Contenido al pasar el cursor o enfocarse , del cual aprendimos con información sobre herramientas.

    Necesitamos agregar JavaScript para algunas técnicas que deberían resultar familiares en este punto:

    • Alternar aria-expandeden el botón de menú entre truey falseescuchando clickeventos
    • Cerrar un menú abierto al usar la Esctecla y devolver el foco al botón de alternancia del menú
    • Preferiblemente, cerrar los menús abiertos cuando el foco se mueve fuera del menú.
    • Opcional : implementar teclas de flecha, así como teclas Homey Endpara la navegación con el teclado entre los botones de alternancia del menú y enlaces dentro de los menús desplegables.

    Consejo rápido : garantice la implementación correcta del menú desplegable asociando la visualización del menú al selector de .dropdown-toggle[aria-expanded="true"] + .dropdownen lugar de basar la visualización del menú en la presencia de una clase adicional agregada por JS como active. ¡Esto también elimina cierta complejidad de su solución JS!

    Esto también se conoce como “patrón de divulgación” y puede encontrar más detalles en el Menú de navegación de divulgación de ejemplo de WAI-ARIA Authoring Practices .

    Recursos adicionales sobre la creación de componentes accesibles

    • Guía completa de Smashing sobre componentes frontales accesibles
    • Artículo de Carie Fisher Bueno, mejor, mejor: desenredando el complejo mundo de los patrones accesibles
    • Demos and information on common design patterns and widgets available from the WAI-ARIA Authoring Practices 1.2
    • Deque University’s Code Library
    • Scott O’Hara’s Accessible Components
    • Heydon Pickering’s Inclusive Components

    (vf, il)Explore more on

    • CSS
    • JavaScript
    • Frameworks
    • Accessibility





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles

    Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles

    Determinar si solo CSS es una solución adecuadaInformación sobre herramientasmodalesPestañasPatrones de pestañas de ejemploCarruselesMenús desplegablesAcc

    programar

    es

    https://pseint.es/static/images/programar-cuando-css-no-es-suficiente-requisitos-de-javascript-para-componentes-accesibles-1105-0.jpg

    2024-05-22

     

    Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles
    Cuando CSS no es suficiente: requisitos de JavaScript para componentes accesibles

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Update cookies preferences