Crear interfaces de usuario con marcas semánticas

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Explicar por qué las marcas semánticas son necesarias para hacer accesible el contenido.
• Definir los tres tipos de atributos en ARIA.

Introducción

Muchos factores influyen en la creación de interfaces de usuario accesibles, y en general, cuanto más compleja es la interfaz, más factores necesita tener en cuenta. Por ejemplo, una simple publicación de blog o artículo de noticias tiene menos consideraciones para la accesibilidad que un artículo de noticias con funciones de redes sociales, comentarios u otras funciones interactivas. Una aplicación web compleja, como un generador de tableros o reportes, un editor de formato de página o incluso una vista de lista con estilo Kanban tiene aún mayores necesidades en términos de accesibilidad.

Cuanto más compleja es la página web o aplicación, más tiene que hacer para asegurarse de que es accesible para usuarios con discapacidad. Dicho eso, para que cualquier página web o aplicación sea accesible, debe iniciar con los fundamentos. 

Platiquemos de marcas semánticas

Las marcas semánticas son la base de toda la accesibilidad. El contenido que aparece en una página web debe presentarse utilizando marcas que representan el tipo de contenido que se está presentando. Por ejemplo, los datos tabulares deben presentarse utilizando marcas basadas en <table>, las listas deben presentarse utilizando marcas basadas en <ul>, los encabezados gráficos deben utilizar etiquetas de encabezado, etc.

Las marcas semánticas hacen que el contenido sea legible y comprensible por máquinas y software (específicamente tecnologías de asistencia), lo que es necesario para que el contenido sea accesible. Un usuario invidente puede utilizar un lector de pantalla para navegar por un generador de reportes creado con elementos de HTML <table> con formato correcto. Sin embargo, este mismo usuario no puede navegar correctamente o comprender lo mismo marcado utilizando elementos <div>, aunque puedan parecer iguales para usuarios videntes.

La estructura HTML de páginas web y aplicaciones proporciona el significado de su contenido para tecnologías de asistencia, y los usuarios que se apoyan en tecnologías de asistencia. Le recomendamos utilizar elementos HTML5 semánticos siempre que sea posible, y validar sus marcas utilizando un comprobador como Comprobador de Nu HTML.

Primeros pasos con ARIA

ARIA, que es acrónimo de Aplicaciones de Internet enriquecidas accesibles, es una extensión de HTML que reconoce que las páginas web se utilizan para mucho más que fines de marcado o visualización. ARIA comprende que la web es una plataforma para la creación de aplicaciones complejas, y proporciona opciones para comunicarse con interacciones mucho más avanzadas con usuarios con discapacidad, a través de tecnologías de asistencia.

ARIA funciona aplicando atributos especiales a nodos DOM HTML. Existen tres tipos de atributos disponibles en ARIA: funciones, estados y propiedades.

Funciones

Las funciones son una forma de proporcionan significado semántico a elementos HTML que normalmente no tienen ningún significado semántico, como <div> o <span>. Por ejemplo, puede utilizar funciones de ARIA para identificar un conjunto de elementos no semánticos como un botón o un vínculo, o incluso componentes más complejos como menús, cuadro combinados, modales o cuadrículas interactivas. 

Las funciones son una promesa a los usuarios. Si agrega una función de ARIA a un elemento, como agregar role="button" a un <div>, está indicando al <div> para identificarse como un botón. Este <div> ahora se muestra en el árbol de accesibilidad del navegador como un <button>. El árbol de accesibilidad del navegador es una instantánea de la información presentada en el lector de pantalla. Esto significa que también debe proporcionar todas las funciones que un botón tiene de forma nativa a este <div>. Esto incluye estados seleccionados, interactividad de teclado, interactividad de ratón, etc. Llamar un <div> un botón pero no convertirlo en una función como un botón está rompiendo esa promesa a sus usuarios.

Estados

Los estados son atributos que describen el estado de un componente ARIA en el árbol de accesibilidad de un navegador. Un estado describe si un menú desplegable es o no expanded, si su tipo de entrada es disabled o readonly, si una casilla de verificación es checked, si un elemento en un cuadro de lista es selected, etc. Al crear componentes complejos utilizando ARIA, es vital actualizar de forma precisa sus varios estados a través de la operación de un control. Todo esto es parte de mantener esa promesa a usuarios que dio al utilizar un atributo de función. 

Propiedades

W3C define propiedades de ARIA como, “Los atributos que son esenciales para la naturaleza de un objeto concreto, o que representan un valor de datos asociado con el objeto.” Estos son atributos que describen la naturaleza de un objeto. Considere la diferencia entre un elemento <select> con el atributo multiple y un elemento <select> sin el atributo multiple. El primero es un cuadro combinado donde uno puede realizar varias selecciones, mientras que el último es uno donde un usuario debe hacer clic en el estado contraído con el fin de abrir el cuadro y seleccionar un único elemento. En este caso, multiple es un propiedad de su elemento <select> nativo. 

Del mismo modo, ARIA tiene varios atributos de propiedad que se utilizan para describir objetos, pero no necesariamente cambian con regularidad para actualizar el estado de un objeto.

Conocer el cuál, el cuándo y el cómo de atributos de ARIA puede ser muy engañoso. En general, recomendamos encarecidamente seguir nuestros planes de componente en Salesforce Lightning Design System (SLDS). SLDS contiene más de 900 planos de HTML, con directrices de accesibilidad detalladas para interacciones de teclado, atributos y marcado. Estos planos incluyen todas las funciones, las propiedades y los estados de ARIA correctas, en los lugares correctos. Además, nuestros planos incluyen información de accesibilidad, detallando cómo asociar y gestionar de forma apropiada estados y propiedades de los componentes que está creando. 

Se probaron los planos del componente ARIA en SLDS con tecnología de asistencia y se basan en la Guía de prácticas de redacción de ARIA. Este documento se actualiza con regularidad, y es la fuente actual de la verdad para ARIA y varios patrones de diseño comunes. 

Es posible que no encuentre cada patrón de interacción que necesite en los planos de componente SLDS. Para cualquier cosa que no vea en nuestro sistema de diseño, consulte la Guía de prácticas de redacción de ARIA y la especificación de ARIA en sí. No confíe en nada más en internet: existen muchas ideas, exploraciones y componentes inaccesibles y malos de hace muchos años ocultándose como soluciones modernas y accesibles.

Ahora que conoce los fundamentos de la creación de interfaces de usuario accesibles, exploremos la navegación con facilidad de acceso. 

Recursos

• Documentación: Guía de prácticas de redacción de ARIA
• Documentación: Aplicaciones de Internet enriquecidas accesibles (WAI-ARIA) 
• Herramienta: Comprobador de Nu HTML
• Ayuda de Salesforce: Salesforce Lightning Design System