Cómo describir diseños complejos para usuarios con discapacidades

Eres un desarrollador que acaba de recibir una especificación de diseño compleja. Usted sabe que los diseños admiten accesibilidad porque su equipo de UX leyó una publicación de Medium sobre diseño accesible hace unos meses. Ahora depende de usted crear una experiencia accesible, pero ¿dónde debería comenzar?

Existe el WCAG 2.0, que es ampliamente respetado como "la verdad" ya que se relaciona con los estándares internacionales de accesibilidad. También existe la especificación WAI-ARIA, que es una parte importante de cualquier kit de herramientas para desarrolladores centrado en la accesibilidad. Retrocediendo en el tiempo, existe el estándar del Gobierno Federal de los EE. UU., La Sección 508 de la Ley de Rehabilitación.

Aunque no es conocido por su relevancia duradera, los estándares de accesibilidad técnica en la Sección 508 contienen una sugerencia muy sabia. Se afirma que,

"... la información suficiente sobre un elemento de la interfaz de usuario, incluida la identidad, el funcionamiento y el estado del elemento, estará disponible para la tecnología de asistencia".

Originalmente escrito para software, estas palabras son aún más relevantes hoy en día dada la prevalencia de las aplicaciones basadas en la web. Describen el tipo de información que los usuarios con discapacidades necesitan para completar con éxito una tarea. Esto podría ser un usuario ciego con un lector de pantalla, un usuario de entrada de voz con una discapacidad física o cualquier otro tipo de usuarios con una variedad de tecnologías de asistencia.

Los fundamentos básicos para hacer que cualquier interacción sea accesible tanto con el teclado como para los usuarios de lectores de pantalla se reduce a proporcionar tres elementos básicos de información: identidad, operación y estado.

Los usuarios que interactúan con un elemento tan básico como una casilla de verificación, o tan complejo como la experiencia de arrastrar y soltar, deben considerar estas tres preguntas:

  1. Identidad: ¿con qué estoy interactuando?
  2. Operación: ¿Cómo uso esta cosa?
  3. Estado: ¿Cuál es el estado actual de esta cosa?

Una mirada más cercana a las casillas de verificación

Un usuario vidente recibe muchas señales visuales relacionadas con la identidad, el funcionamiento y el estado. Veamos una simple casilla de verificación como ejemplo.

Casilla de verificación con etiqueta,

Cuando veo un cuadrado al lado de las palabras, "Acepto estos términos y condiciones", he identificado una casilla de verificación.

Misma casilla de verificación con un mouse listo para hacer clic.

Sé cómo operar la casilla de verificación, haciendo clic en el cuadrado. Hacerlo lo cambiará de marcado a no marcado.

Una casilla de verificación marcada con la etiqueta

Si veo una marca de verificación dentro de ese cuadrado, sé que su estado está "marcado".

¿Cómo obtendría un usuario ciego esta información?

“Estoy de acuerdo con estos términos y condiciones. Casilla de verificación, sin marcar. Presione la barra espaciadora para verificar.

Si un lector de pantalla lee esto a un usuario ciego, se le dan tres datos importantes.

  1. La identidad del objeto: una casilla de verificación para declarar si estoy de acuerdo o no
  2. El estado: sin marcar
  3. La operación: presionar la barra espaciadora alternará el estado

Con esto en mente, consideremos tres métodos, desde el más preferible hasta el menos preferible, para proporcionar identidad, operación y estado a la tecnología de asistencia: usar controles nativos, usar ARIA y, como último recurso, ser inteligente con texto oculto y regiones en vivo.

Controles nativos

Los controles nativos, como los controles de formulario y los botones, siempre serán la mejor opción. En el ejemplo anterior, una casilla de verificación real es ideal, ya que hace todo el trabajo por usted. No tiene que crear la operación usando JavaScript, la casilla de verificación ya se identifica a sí misma y su estado, y además, las personas saben cómo usarlas.

Para interacciones más complejas, como arrastrar y soltar, considere si un elemento nativo se puede utilizar detrás de escena. Considere cambiar el tamaño del ancho de las columnas en una tabla:

Arrastre y suelte para cambiar el tamaño del ancho de columna

Un control deslizante o entrada de rango es el equivalente nativo perfecto para este comportamiento y proporciona su propia identidad, operación y estado.

Control deslizante de rango

Esto puede ocultarse visualmente usando CSS, mientras que aún está disponible para los usuarios de lectores de pantalla. Sincronice su valor con el ancho de la columna y un usuario ciego puede interactuar con un control de formulario familiar. Un usuario avistado aún arrastrará y soltará como se esperaba.

WAI-ARIA

En lugares donde no es posible utilizar un control nativo, siga las mejores prácticas de ARIA (Aplicaciones de Internet enriquecidas accesibles) para patrones de diseño comunes como menús, cuadros de diálogo y autocompletar.

Estas pautas están escritas de modo que los patrones de IU que no están disponibles de forma nativa en HTML se identifiquen adecuadamente a los usuarios de tecnología de asistencia.

Tomemos, por ejemplo, un elemento de selección estándar:

Elemento de selección básico.

Este es un elemento accesible de forma nativa. Es perfecto para usar en formularios, para elegir una opción de una lista. Incluso pueden funcionar como menús. Desafortunadamente, son "feos" a los ojos de muchos equipos de diseño y son muy difíciles de diseñar y mantener consistentes en todos los navegadores. Debido a esto, su uso es ampliamente rechazado en las aplicaciones web modernas. En cambio, las personas crean sus propios menús desplegables.

Menú construido con ARIA

Si crea su propia interfaz de usuario interactiva desde cero, es muy importante utilizar el marcado apropiado, proporcionar los comportamientos de teclado apropiados e incluir y actualizar los atributos ARIA. Esta es la única forma de proporcionar identidad, operación y estado adecuados a los usuarios de tecnología de asistencia.

Regiones en vivo y texto oculto

Si no hay un elemento nativo equivalente a lo que está construyendo y no existe una directriz ARIA, debe proporcionar deliberadamente información utilizando una combinación de técnicas.

  • Un que se oculta visualmente mediante CSS, pero que los usuarios de lectores de pantalla todavía pueden leer
  • Una región "aria-live"
  • Un método de JavaScript para actualizar el contenido de texto de esta región

Cuando el texto se agrega a una región en vivo, se coloca directamente en la cola de un lector de pantalla y se habla a sus usuarios. Al ocultar esta región visualmente, estamos creando un método para comunicarse directamente con los usuarios de lectores de pantalla.

Si está creando una IU compleja, como una lista ordenable que usa arrastrar y soltar, estos métodos son imprescindibles.

Arrastre y suelte para reordenar una lista.

Para identificar la función de arrastrar y soltar, utilice aria-describeby para asociar texto oculto a cada elemento de la lista que dice: "Presione la barra espaciadora para agarrar este elemento". Esto proporcionará identidad. Cuando los usuarios agarren el elemento, proporcione la operación y el estado colocando texto en la región activa:

"{Nombre del elemento} agarró, use las teclas de flecha para reordenar, barra espaciadora para soltar. Escapar para cancelar. Posición actual en la lista, 1 de 7 ".

También puede proporcionar el estado final después de que se suelta un elemento:

"{Nombre del elemento} descartado. Posición final en la lista, 4 de 7 ".

Para reiterar, este método solo debe usarse después de descartar elementos nativos y de que los componentes especificados por ARIA no existen o no funcionan. A medida que proporciona identidad, operación y estado por su cuenta, será necesario realizar pruebas de usuario para determinar la mejor manera de comunicar esta información a sus usuarios.

Ahora tome esos diseños accesibles y cree una experiencia que pueda disfrutar para todos los usuarios, incluidos aquellos con discapacidades. A través de estos métodos, podrá proporcionar información de identidad, operación y estado a todos sus usuarios, independientemente de cuán simple o compleja sea la interacción.

Jesse es el Especialista Principal de Accesibilidad en Salesforce. Envíale un tweet a @jessehausler, su teléfono está solo.

Síguenos en @SalesforceUX.
¿Quieres trabajar con nosotros? Póngase en contacto con uxcareers@salesforce.com
Consulte el sistema de diseño de Salesforce Lightning