Mi nombre es Dima, trabajo en la oficina de Yandex en San Petersburgo y hago servicios internos en el equipo de desarrollo de interfaz de Toloka. Este año preparé una conferencia para la
Escuela de Desarrollo de Interfaces . A continuación se muestra su decodificación.
¿Qué es la disponibilidad de la interfaz? ¿Para quién es importante y por qué debería esforzarse por lograrlo? ¿Cuáles son las técnicas básicas que hacen que una interfaz sea accesible? Además de estas preguntas, la conferencia aclara los principios que subyacen a las tecnologías de asistencia. Traté de analizar la teoría y una gran cantidad de ejemplos prácticos, así como mostrar el proceso del lector de pantalla.
- ¿Qué se esconde bajo el término de accesibilidad ahora de moda? Que opciones tienes Para ciegos, lectura de pantalla, discapacidades, coordinación de movimientos ... Eso es correcto. Accesibilidad: la capacidad de utilizar la interfaz para todos, independientemente de las limitaciones físicas o técnicas.
Una interfaz accesible es una interfaz que es más conveniente de usar para una amplia gama de usuarios. Quizás alguien tenía una pregunta, ¿por qué hacer accesibles las interfaces? ¿Qué motivación tiene esto? La primera y, para mí, la motivación más importante es la moral. Las personas con discapacidad no son peores que el resto, también quieren y tienen la oportunidad de utilizar la funcionalidad completa de los recursos que desarrollas.
El aspecto financiero. Las personas con discapacidades son clientes que compran sus productos, usan sus servicios, por lo que garantizar la accesibilidad también ayuda a expandir su mercado actual e ingresar a nuevos mercados.
El aspecto legal. El derecho inalienable de acceso a la información está consagrado en las leyes de muchos países. Por ejemplo, en los EE. UU. Y la UE, todas las interfaces web deberían ser accesibles para las personas con discapacidad. En nuestro país, esto se aplica principalmente a los sitios web estatales, a todos los demás esto se aplica solo como una recomendación.
¿Quiénes son estas personas, a quienes les importa la accesibilidad? En primer lugar: usuarios con discapacidad visual, personas completamente ciegas, personas con discapacidad visual, personas con percepción de color deteriorada. A estos usuarios les resulta difícil ver su sitio. Es posible que no vean su sitio en absoluto. La segunda categoría son los usuarios con una violación del sistema musculoesquelético. Es difícil para esas personas usar dispositivos de entrada, tienen un problema con la motilidad, la contracción muscular espontánea.
Me gustaría llamar la atención especial sobre el hecho de que cualquiera de nosotros en algún momento puede enfrentar limitaciones de tiempo, y luego no podrá usar la interfaz en la forma habitual. Por ejemplo, un diestro que se rompe la mano derecha comienza a experimentar problemas motores. Y la interfaz, desarrollada sin tener en cuenta estas características, puede ser simplemente inaccesible para ella.
Ahora en Rusia, alrededor del 10% de la población son personas con una u otra discapacidad. Y lejos del último lugar aquí está ocupado por personas con problemas de visión o sistema musculoesquelético. Y todas estas personas son visitantes potenciales de su sitio. La accesibilidad es especialmente importante para ellos.
Las tecnologías que ayudan a las personas a usar las interfaces se pueden dividir en dos tipos: hardware y software. Las personas con discapacidad reciben ayuda para usar interfaces mediante teclados especiales, mouse, joysticks y otros dispositivos de entrada.
Quiero dar esto como un ejemplo. Este tipo de dispositivo se llama Switch. La accesibilidad no solo se trata de computadoras y computadoras portátiles, sino también de dispositivos móviles. Una persona con discapacidad puede acceder a su sitio desde su teléfono o tableta. Este dispositivo se conecta a un dispositivo iOS o Android, y puede asignar algunas acciones de usuario a sus botones. Por ejemplo, este interruptor: con dos botones grandes, es conveniente asignarle el control de enfoque en la página.
Para los usuarios que no ven su interfaz, la síntesis de voz no siempre es conveniente. Por lo tanto, hay una pantalla braille. Este es un dispositivo de salida especial que muestra información en forma de puntos tangibles de Braille. Genial, pero tiene dos problemas. Es muy costoso, no todas las personas necesitadas pueden pagarlo.
Además, las personas que han perdido la visión en una edad más madura a menudo no conocen el alfabeto Braille y no quieren dominarlo.
La tecnología del software también es suficiente. Estas son herramientas para aumentar la imagen en la página, por ejemplo, lupas de pantalla integradas en Windows, macOS, estos son modificadores de la gama de colores del software y más. Por ejemplo, hay un software que le permite controlar la interfaz utilizando los movimientos de los ojos y la cabeza. En macOS, dicho programa está incorporado, se llama Dwell Control. Pero entre las tecnologías de software, los lectores de pantalla ocupan un lugar especial. Esta es una aplicación especial que lee los contenidos del sitio y el sistema operativo para el usuario, le proporciona una conveniente funcionalidad de navegación.
Los lectores de pantalla son la forma más accesible y generalizada de percibir información para personas con discapacidad visual. Hablaremos de ellos con más detalle durante la conferencia.
Algunas palabras sobre las recomendaciones en el campo de la disponibilidad de la interfaz. Tenemos GOST, y en Occidente: WCAG y la Sección 508. Los métodos descritos en estas recomendaciones no afectan la apariencia del sitio, pero proporcionan a los usuarios con discapacidades algunas cosas adicionales para la navegación y el uso.
Prácticas que ayudan a que su interfaz sea accesible hoy. Una descripción alternativa debe transmitir información breve al texto, complementarlo o indicarlo.
Lo mismo ocurre con los gráficos e íconos en la página. Recuerde: también necesitan soporte adicional. Si algún elemento adicional en su página se presenta como una imagen, debe ocultarse del lector de pantalla utilizando el atributo aria-hidden = "true".
Hablaremos de atributos con el prefijo aria a continuación.
Es necesario describir los campos de entrada utilizando la etiqueta de etiqueta, para lo cual especificamos el atributo for con el valor de id del campo de entrada. Esto no solo le permitirá cambiar rápidamente a la edición del control haciendo clic en la etiqueta, sino que también conectará semánticamente el control con su descripción, es decir, el lector de pantalla nos leerá una descripción de este elemento. Indica los tipos de datos de los campos de entrada.
Además de las reglas de validación que se agregarán automáticamente a estas entradas, en muchos casos se presentará un método conveniente para ingresar información a través del navegador. Por ejemplo, como aquí, el calendario es en el caso del tipo Fecha o Color, si es un color. Si el navegador no admite ninguno de los tipos, se sustituirá la entrada con el texto de tipo, no se romperá nada.
Marque los campos obligatorios con los atributos obligatorios o aria-required = "true". Agrupe los campos relacionados utilizando la etiqueta del conjunto de campos, utilizando el elemento de leyenda, se indica el encabezado del grupo, donde puede especificar no solo el propósito del grupo, sino también las características generales de los campos (por ejemplo, todos los campos de este grupo son obligatorios).
Envolvemos tres botones de radio en la etiqueta del conjunto de campos, establecemos el título en la etiqueta de la leyenda. Ahora, independientemente de qué botón esté seleccionado, el lector de pantalla leerá el contenido de la etiqueta de la leyenda. Y la persona que visita el sitio comprenderá lo que está sucediendo en este formulario.
Mostrar mensajes de error y éxito.
Sobre el título y, por lo tanto, está claro, el texto en esta etiqueta debe describir el propósito o el título de la página. Si tiene una aplicación de una sola página, no olvide cambiar el contenido de la etiqueta del título cuando navegue por la página.
Especifica el idioma de la página. Para hacer esto, configure el atributo lang en la etiqueta HTML. Esto es bueno para el SEO, ayuda a los complementos del traductor y los lectores de pantalla pueden determinar con precisión el idioma de dicha página. Si su documento contiene varios idiomas, puede especificar el atributo lang para etiquetas individuales. Observe la validez del diseño. Esto es importante porque los lectores de pantalla pueden leer mal las páginas no válidas. Lo mismo ocurre con la semántica. Todos los elementos en la página deben ser semánticamente correctos, debe usar etiquetas HTML para su propósito semántico. Y cuando cree sus elementos personalizados, cuide la semántica correcta.
Hablemos de ejemplos en el campo de la semántica. Primero sobre los titulares. Son uno de los elementos semánticamente más importantes de la página. Cuando una persona visita el sitio usando un lector de pantalla, llega a una página desconocida, lo primero que hace en esta página es seguir los encabezados. Y en los lectores de pantalla hay incluso un modo especial que le permite hacer esto convenientemente. Si su página contiene encabezados y muestra una jerarquía clara, será conveniente que una persona navegue por el sitio, podrá ir rápidamente a la sección deseada. Es muy conveniente, úsalo.
Otro ejemplo de la importancia de la semántica es el diseño del menú. Si crea el menú como a la izquierda, desde el punto de vista de la semántica, será solo un grupo. div es una etiqueta de agrupación, y dentro de ella habrá una cantidad de elementos no relacionados, en este caso solo hay tres enlaces.
Si realiza la navegación envolviendo una etiqueta semántica especial, dentro de la cual habrá una lista de elementos, cada uno de los cuales es un enlace, entonces, desde el punto de vista de la semántica, el lector de pantalla y el navegador, esta será una navegación honesta, dentro de la cual hay una lista de tres elementos, según lo cual será conveniente moverse
Espero que el siguiente consejo sea obvio para usted: el uso correcto de etiquetas semánticas del quinto estándar HTML garantiza que su diseño sea interpretado lógicamente correctamente por los navegadores y las tecnologías de asistencia.
Sobre diseño adaptable y versión móvil.
Ya tuvo una conferencia sobre diseño adaptativo, espero que comprenda la importancia de esto.
Siempre debe dar preferencia a los elementos HTML incrustados, y solo si es necesario, cree los suyos propios. La razón de esto es simple: los elementos integrados que ya están en la caja tienen la semántica correcta y una serie de características funcionales. Cuando la gente habla de ello, a menudo dan botones como ejemplo. Por lo tanto, tendré dos botones.
Solo difieren en la inscripción, pero en realidad solo el botón izquierdo es un botón. Se basa en la etiqueta del botón. El correcto es solo un div estilizado. Por lo tanto, podemos enfocarnos en el botón izquierdo: el botón es el elemento enfocable predeterminado. El botón tiene un estado deshabilitado en el que no se puede presionar. Y se hace clic en el botón presionando Intro y Espacio, si estamos en el foco del botón. Y solo este botón tiene la función semántica correcta, desde el punto de vista del navegador, el lector de pantalla es el botón, y cuando el lector de pantalla llegue allí, dirá que es un botón. El botón basado en div no tiene todo esto. Tendrá que implementar los siguientes puntos usted mismo. ¿Pero por qué, si hay una buena API de navegador incorporada que se puede usar?
Es importante pensar en la accesibilidad antes de las etapas de desarrollo y diseño. ¿Quién ha estado involucrado en el diseño o diseño de dibujos en el trabajo o en sus proyectos paralelos? Definitivamente hay más de la mitad de la audiencia. Un par de consejos en esta dirección. No permita que la apariencia de sus interfaces sea demasiado pequeña o se fusione con los elementos de fondo.
Además, no use fuentes decorativas o caligráficas para el texto principal. Recuerde a los usuarios con problemas de baja visión y percepción del color. Acerca de las personas que usan monitores con poca reproducción del color. Es posible que todos ellos simplemente no vean los elementos de su interfaz. Esto es especialmente crítico para los controles, para los controles.
Hablamos de formas, pero más en términos de semántica. Aquí, preste atención al diseño competente de la interacción del usuario con los formularios y tenga en cuenta las características de algunos usuarios. Por ejemplo, hay personas con problemas con las habilidades motoras, puede ser difícil para ellos entrar en elementos pequeños. Por lo tanto, haga que el área de clic de estos elementos sea más grande que el control o el botón. Lo mismo ocurre con los elementos ubicados cerca uno del otro. Una persona que tiene un problema con las habilidades motoras puede fallar y presionar en el lado equivocado. Separe más los elementos importantes y asegúrese de solicitar la confirmación de algunas operaciones irreversibles, como la eliminación de datos.
Un punto común sobre la uniformidad de diseño, consistencia, previsibilidad y consistencia. Todo su diseño debe ser de un solo estilo. Todos los bloques en su sitio deben ubicarse en un solo lugar. No debe ser tal que el bloque salte de un lugar a otro al moverse por las páginas. Esto es especialmente crítico para la navegación. Una persona que no ve su sitio crea su imagen en su cabeza, imagina cómo se ve. Si de página en página su navegación salta de un lugar a otro, entonces simplemente se confundirá en esto, será imposible usar el sitio.
Además de todas las tecnologías que hemos aprendido, existe un estándar diseñado para proporcionar a los usuarios con discapacidades una forma conveniente de interactuar con los sitios en Internet.
Antes de comprender las complejidades, veamos cómo funciona bajo el capó desde el punto de vista del navegador. Después de cargar su página, el navegador comienza a analizar el marcado HTML y crea un árbol DOM basado en él. Espero que conozca esta estructura, es la base para mostrar datos en el navegador, se puede cambiar usando JS, etc. Cuando se construye el árbol DOM, el navegador construye otra estructura de datos basada en él: el árbol de accesibilidad. Este árbol contiene información útil en términos de accesibilidad. Las tecnologías de asistencia, como los lectores de pantalla, toman esta información. Y brinde al usuario una forma conveniente de interactuar con el sitio. Durante esta interacción, el DOM puede cambiar, por lo que el navegador monitorea los cambios en el DOM y actualiza el árbol de accesibilidad según sea necesario. Las tecnologías de asistencia eliminan estos cambios y de alguna manera modifican la funcionalidad que proporcionan a sus usuarios.
Esta es una estructura de datos aislada. No se puede acceder desde el DOM, no se puede ver o editar usando JS. La implementación y gestión de esta estructura es tratada en su totalidad por los navegadores. La información sobre la semántica de los elementos se almacena en este árbol, con la ayuda de las cuales las tecnologías de asistencia entienden cómo interpretar los elementos de la página.
El acceso a esta información ahora solo se puede obtener con la ayuda de herramientas especiales. Uno de esos elementos es el Inspector de accesibilidad de DevTools. El Inspector de disponibilidad de Chrome ahora se encuentra en la sección de tecnología experimental, que puede habilitar visitando la página de Banderas de Chrome. Activa estas tecnologías, luego ve a DevTools y activa el panel de accesibilidad. Entonces ella se ve en los negocios.
Aquí se muestra información útil sobre accesibilidad. Y de inmediato surge la pregunta, ¿de dónde viene esta información y cómo se puede cambiar?
Pequeños ejemplos.
Solo una casilla de verificación nativa envuelta en una etiqueta. Por lo tanto, se presentará en el árbol de accesibilidad. Vemos que este es un objeto, tiene campos, un tipo de casilla de verificación, un nombre tomado de una etiqueta y un estado que se puede marcar y desmarcar.
Ahora hacemos una casilla de verificación personalizada usando un div, su estado se denota por estilo. Pero desde el punto de vista del navegador, las tecnologías de asistencia, será solo texto con algún significado. Estos dos ejemplos confirman claramente lo que dije antes: siempre que sea posible, siempre deben usarse elementos nativos. Pero a menudo esto no es posible. Entonces el estándar ARIA viene al rescate.
La especificación ARIA agrega atributos especiales que determinan cómo se representará el elemento en el árbol de accesibilidad, qué propiedades tendrá. Lo principal que nos da esta especificación son los roles para describir el tipo de elementos, las propiedades para describir su estado.
Veremos brevemente qué roles y propiedades son, luego lo arreglaremos con ejemplos. Comencemos con el concepto de rol. Un rol nos permite clasificar elementos en una página. Está instalado. Agregamos al elemento HTML del atributo de rol con el valor deseado.
Hay muchos roles diferentes en el estándar, y se dividen en diferentes grupos. Por ejemplo, el papel de los widgets. Se asignan a elementos que son partes independientes de la interfaz de usuario. Estos son los botones habituales, botones de radio, pestañas, información sobre herramientas. Luego están los roles compuestos que agregan elementos de otros roles. Obviamente, un radiogrupo consiste en elementos de radio o una lista de pestañas consiste en pestañas. Los siguientes son roles estructurales y puntos de referencia, puntos de referencia. Estos roles se asignan a grandes bloques semánticos en una página.
Además de los roles, el estándar ARIA también proporciona estados. Pueden describir qué estado tiene un elemento actualmente. Por ejemplo, el estado de los widgets, indican que el elemento está oculto, marcado, bloqueado, etc.
También hay estados que indican la conexión de elementos. Por ejemplo, un elemento describe otro elemento, controla otro elemento. Los estados también pueden declarar áreas específicas en las que se espera que ocurran cambios de contenido. Estas áreas se llaman regiones vivas.
Hay muchos roles y condiciones. Todos ellos se pueden leer en el sitio web de especificaciones.
Veamos ejemplos de los roles más utilizados.
Terminemos nuestra casilla de verificación personalizada. Tomamos el mismo div, pero ahora le agregamos la función de casilla de verificación, así como un atributo que muestra el estado, verificado por aria, verdadero o falso. Ahora necesita agregar el JS apropiado y, desde el punto de vista del navegador, la semántica será una casilla honesta. Se pueden hacer otros elementos de la misma manera. Por ejemplo, un botón que actuará como un interruptor cambiará entre estados. Ella tiene su propio papel como interruptor y un atributo que indica su estado actual.
Un ejemplo de un papel compuesto. Hay una lista con un elemento tablist, dentro de ella hay elementos con roles tab. Por lo tanto, le decimos al navegador, lo que implica que estos elementos son pestañas.
Un ejemplo más complejo es un menú de varios niveles. Además de varios roles, entre los cuales hay un rol estructural: navegación, hay roles compuestos anidados entre sí. Hay un par de estados interesantes, por ejemplo, aria-haspopup con un valor verdadero significa que este elemento es desplegable. , , aria-hidden true, , , .
, , , . , , JS, , , . aria-haspopup . aria-hidden , .
, . , . « », . aria-controls id , . , , , aria-describedby. , .
, , . . , , ? aria live . alert, aria-live. , , , . role=”alert” aria-live assertive, . , , live-region.
, , live region aria-live polite. , , .
. live , . , , , , , , , , . 100%, , .
. , , : Shift + Tab Tab. . , .
HTML-. , . - CSS-, , , float order , , .
. , , , . . . tab, , . , - , .
, focus ring, . , , , . .
, , , . , . . , , outline, box-shadow, border, , .
. , , -. , . , . , . , .
, ? , , focus ring . .
, focus ring. , , , : , , , . , . , , . , , , .
, , , . , , ? tabindex. 0, . . , tab.
div . tab, . tabindex=0, , .
tabindex=-1, , . JS.
tabindex > 0 . , , .
tabindex > 0 — , . , , . . . , . , -, Bootstrap.
, — ESC , — , . , . , . , .
, material design, . , , . , . , , . , , , . , tab - .
, - . . . , . — inert.
, . inert , . , , , . , .
, JS. . — Focus Manager. . apture - . release , , . , , , . , .
— , . — .
(, React Modal) .
. ?
VoiceOver, Apple, macOS, iOS, WatchOS, . , , , , , . , macOS.
Windows, NVDA. . , , VoiceOver, , , , .
Windows — JAWS. , , , VoiceOver, .
. , , , . VoiceOver, .
macOS Accessability « », VoiceOver. “ VoiceOver” Cmd + F5. , , , , . , .
macOS. , . , , . , tab, .
. . , focus ring , . , ?
-, , . . , . complimentary, . 2 , - , . tab .
. — . , aria-haspopup. , , , Enter . :
, .
popup. , , . . , , , . Apenas dicho que hecho. , .
, .
. , tablist, , . . , , .
.
. . , , , . . .
, . , , , . , . , .
, , , .
, , , , . , , .
, , tab, .
, tab shift+tab . . VoiceOver , Ctrl+Cmd+U.
, . . landmarks, .
. , , , , , , .
. . , , , . — .
, VoiceOver, , .
, , — .
, , . , . , . , . , , , . , , . . . Tab Shift +Tab. , — .
, . . , - , , , .
Accessibility Inspector. , , .
Audits DevTools. -, 60- Chrome. , , , .
, Audits, — Axe. , . . , . , , , , .
Axe - Selenium. , — , . . Axe CLI — , , , . Phantom JS.
. , .
—
Mozilla;
—
, ;
—
A11ycast — YouTube Google, , ;
—
Inclusive components , . , , .
, , — , . .
— 52872-2012
— WCAG 2.0
— inert
— :focus-visible
— Focus manager
— React Focus Lock
— Axe Core