Semántica del lector de pantalla: una lista en sí misma

• Rol: Grupo
  • Rol: Etiqueta
  • Rol: Control deslizante
    Nombre: ¿Cuál es su estado de ánimo hoy en una escala del 1 al 10?
    Descripción: Algunos consejos útiles para evaluar su estado de ánimo.
    Etiquetado por: estado de ánimo
    Descrito por: helperText
    ValueNow: 5
    ValueMin: 1
    ValueMax: 10

El párrafo se agrega como un objeto de párrafo simple ("Texto" o "Grupo" en algunas API):

• Rol: Grupo
  • Rol: Etiqueta
  • Rol: Control deslizante
    Nombre: ¿Cuál es su estado de ánimo hoy en una escala del 1 al 10?
    Descripción: Algunos consejos útiles para evaluar su estado de ánimo.
    EtiquetadoPor: estado de ánimo
    DescritoPor: helperText
    ValueNow: 5
    ValueMin: 1
    ValueMax: 10
  • Rol: párrafo

El último elemento es un ejemplo de agregar semántica de roles a través del atributo "ARIA role ". Este div se representa como un botón llamado "Log Mood" porque los botones pueden obtener sus nombres de sus hijos. Este botón también se muestra como "invocable" para lectores de pantalla y otros AT. Los tipos de botones especiales pueden proporcionar la funcionalidad expandir / contraer (botones con el atributo aria-extended ) o alternar (botones con el atributo aria-press ). Aquí está nuestro pedigrí:

• Rol: Grupo
  • Rol: Etiqueta
  • Rol: Control deslizante
    Nombre: ¿Cuál es su estado de ánimo hoy en una escala del 1 al 10?
    Descripción: Algunos consejos útiles para evaluar su estado de ánimo.
    EtiquetadoPor: estado de ánimo
    DescritoPor: helperText
    ValueNow: 5
    ValueMin: 1
    ValueMax: 10
  • Función: Párrafo
  • Función: Botón
    Nombre: Estado de ánimo de registro

Selecciona la semántica del lenguaje host # section7

En nuestro El marcado de ejemplo menciona que es preferible utilizar el elemento de botón nativo de HTML en lugar de un elemento div con una función de "botón , "Nuestro div abotonado se puede servir como un botón a través de las API de accesibilidad, ya que el atributo ARIA hace lo que debería: transmitir semántica. Sin embargo, al elegir artículos nativos, puede obtener mucho de forma gratuita. En el caso del botón que incluye el manejo del enfoque, el manejo de la entrada del usuario, el envío de formularios y el estilo básico.

Aaron Gustafson tiene lo que él llama un "ensayo detallado" sobre botones. [Enparticular pero en general, es genial cuando la plataforma web cancela la semántica y la interacción lo más rápido posible.

Los roles, el estado y las propiedades de ARIA siguen siendo una gran herramienta en su cinturón de herramientas. Algunos buenos casos de uso para estos son

• que proporcionan semántica y relaciones adicionales que no se expresan naturalmente en el idioma anfitrión;
• completando la semántica en los márgenes sobre los que quizás no tengamos control completo;
• parcheando posibles inconsistencias entre navegadores;
• y hacer que los elementos definidos por el usuario sean reconocibles y utilizables para las tecnologías asistidas por el usuario.

Sugerencias para incluir o excluir en la estructura de árbol # section8

Las normas definen algunas reglas que los programas de usuario deben usar para excluir elementos de la estructura de árbol. Los elementos excluidos pueden ser los ocultos por CSS, o los atributos aria-hidden o ocultos ; sus hijos también serían excluidos. Los niños con roles específicos (como la casilla de verificación ) también pueden excluirse del árbol, a menos que tengan excepciones especiales. Las reglas completas se pueden encontrar en "Árbol de accesibilidad" de la especificación ARIA . Sin embargo, todavía hay algunas diferencias entre los implementadores, algunos de los cuales contienen más div sy span s en el árbol que otros.

Cómo calcular el nombre y la descripción # section9

Calcular nombres y descripciones puede ser confuso. Algunos elementos tienen reglas especiales, y algunos roles ARIA permiten el cálculo de nombres a partir del contenido del elemento, mientras que otros no. El cálculo del nombre y la descripción probablemente podría ser un artículo separado, por lo que no entraremos en todos los detalles aquí (ver "Literatura y recursos relacionados" para algunos enlaces). Algunas referencias breves:

• aria-label aria-labelledby y aria -writby tienen prioridad sobre otros métodos de cálculo de nombre y descripción.
• ] Si espera que se use un atributo HTML específico para el nombre, revise las Reglas de cálculo de nombre de cálculo HTML . En su escenario, en su lugar, puede usarse para la descripción completa.
• El contenido generado ( :: before y :: after ) puede participar en el nombre accesible si este nombre se toma del contenido del elemento. Aparte de eso, los desarrolladores web no deben confiar en pseudoelementos para contenido no decorativo ya que este contenido puede perderse si no se puede cargar una hoja de estilo o se aplican formularios aplicados por el usuario a la página.

En caso de duda, ¡contacta a la comunidad! Etiquete las preguntas en las redes sociales con "#accessibility". "# A11y" es una abreviatura común. El "11" significa "11 letras intermedias en la palabra" accesibilidad ". Si encuentra una inconsistencia en un navegador en particular, ¡está informando un error! Para enlaces al seguimiento de errores, consulte" Información y recursos relacionados ".

No solo objetos accesibles # section10

Además de una estructura jerárquica de objetos, las API de accesibilidad también proporcionan interfaces a través de las cuales los AT pueden interactuar con el texto, los AT pueden recuperar áreas de texto de contenido, selecciones de texto y una variedad de atributos de texto sobre los que construir experiencia Por ejemplo, si alguien escribe un correo electrónico y solo resalta los comentarios agregados en color, la persona que lee el correo electrónico puede aumentar la verbosidad de su lector de pantalla para saber cuándo encuentra frases con ese estilo sin embargo, es mejor si el autor del correo electrónico inserta etiquetas de texto muy cortas en este escenario. [19659006] La gran ventaja para los desarrolladores web es que el nombre accesible de un elemento no siempre está en cada modo de navegación en cada lector de pantalla. Si su texto aria-label no se lee en un modo particular, el lector de pantalla puede utilizar principalmente interfaces de texto y solo admitirá parcialmente los objetos. Puede valer la pena pensar en usar contenido textual, incluso si está visualmente oculto en lugar de texto a través de un atributo ARIA. Más reflexiones sobre aria-label y aria-labelledby .

Eventos de API de accesibilidad # section11

Es responsabilidad del navegador realizar cambios en el contenido de la interfaz, la estructura y la entrada del usuario. Para hacer esto, los navegadores envían notificaciones API de accesibilidad a varios eventos que pueden suscribirse a lectores de pantalla. Nuevamente, por razones de rendimiento, los navegadores solo pueden enviar notificaciones cuando los AT están activos.

Digamos que un lector de pantalla quiere mostrar cambios en una región activa (un elemento con role = "alert" ). o aria-live ):

1. El lector de pantalla se suscribe a las notificaciones de eventos. Puede suscribirse a notificaciones de todos los tipos o solo de tipos específicos categorizados por la API de accesibilidad. En nuestro ejemplo, supongamos que el lector de pantalla al menos escucha los eventos de cambio de región en vivo.
2. En el contenido web, el desarrollador web cambia el contenido de texto de una región en vivo.
3. El navegador (proveedor) reconoce esto como
4. La API reenvía esta notificación al lector de pantalla.
5. El lector de pantalla puede usar metadatos de la notificación para buscar los objetos accesibles relevantes a través de la API de accesibilidad y ver los cambios para el usuario.

Los AT no tienen que hacer nada con la información recuperada. Esto puede dificultar que un desarrollador web descubra por qué un lector de pantalla no anuncia un cambio: puede ser que no se emitan notificaciones (por ejemplo, porque un navegador no envía notificaciones para una región en vivo pegada dinámicamente en el contenido web) o el AT no está suscrito o no responde a este tipo de evento.

Pruebas de lector de pantalla y herramientas de desarrollo # section12

Si bien los auditores de cumplimiento pueden ayudar a abordar algunos problemas básicos de accesibilidad, es ideal buscar manualmente el contenido en diferentes contextos, como:

• solo a través de un teclado,
• con varias configuraciones habilitadas para la accesibilidad del sistema operativo,
• y con diferentes niveles de zoom y tamaños de texto

Tenga en cuenta las Pautas de accesibilidad al contenido web (WCAG) 2.1) incluye las pautas generales para las expectativas de contenido web inclusivo. Si puede probar con los usuarios después de que se ejecute su propia prueba manual, ¡esto es aún mejor!

Probablemente, las pruebas de accesibilidad robustas pueden ser una serie separada de artículos. Este artículo proporciona algunos consejos para probar con lectores de pantalla y detectar errores de accesibilidad en la asignación general a la API de accesibilidad.

Prueba del lector de pantalla # section13

Los lectores de pantalla vienen en muchas formas: algunos están preinstalados en el sistema operativo, otros son aplicaciones separadas que en algunos casos se pueden descargar de forma gratuita. La WebAIM Screen Reader User Survey contiene una lista de combinaciones de lector de pantalla y navegador comúnmente utilizadas por los encuestados. La sección "Lecturas y recursos adicionales" al final de este artículo contiene documentos de usuario para lectores de pantalla completa. Deque University tiene una serie de Instrucciones de lectura de pantalla Cheat Sheets que puede consultar. Algunas acciones que puede tomar para probar su contenido:

• Lea el elemento siguiente / anterior.
• Lea la línea siguiente / anterior.
• Sigue leyendo en cierto punto.
• Salta a los titulares, puntos de referencia y enlaces.
• Pestaña solo para elementos enfocables.
• Resumen de todos los elementos de un tipo particular en la página.
• Busque en el sitio contenido específico.
• Utilice comandos específicos de la tabla para interactuar con sus tablas.
• Saltar a través del campo de formulario; ¿Las declaraciones de campo son reconocibles en este modo de navegación?
• Utilice los métodos abreviados de teclado para interactuar con todos los elementos interactivos. ¿Pueden sus interacciones controladas por JavaScript continuar siendo realizadas por lectores de pantalla (que pueden interceptar pulsaciones de teclas en ciertos modos)? WAI-ARIA Authoring Practices 1.1 proporciona orientación sobre las interacciones de teclado esperadas para varios widgets.
• Pruebe todo lo que conduzca a un cambio en el contenido oa otra navegación. ¿Sería evidente a partir de la salida del lector de pantalla que se ha producido un cambio?

Buscando la fuente del comportamiento inesperado # section14

Si un lector de pantalla no anuncia algo como se esperaba, aquí hay algunas comprobaciones diferentes que puede realizar:

• Esto funcionará con el mismo lector de pantalla en ¿Múltiples navegadores reproducidos bajo este sistema operativo? Möglicherweise liegt ein Problem mit dem Bildschirmleser vor, oder Ihre Erwartung entspricht möglicherweise nicht dem Benutzererlebnisdesign des Bildschirmlesers. Beispielsweise kann ein Bildschirmleser festlegen, dass der zugängliche Name eines statischen, nicht interaktiven Elements nicht angezeigt wird. Das Überprüfen der Benutzerdokumente oder das Einreichen eines Bildschirmleseproblems mit einem einfachen Testfall ist ein guter Anfang.
• Wird dies mit mehreren Bildschirmleseprogrammen in demselben Browser, jedoch nicht in anderen Browsern unter diesem Betriebssystem reproduziert? Der betreffende Browser weist möglicherweise ein Problem auf. Möglicherweise gibt es Kompatibilitätsunterschiede zwischen Browsern (z. B. ein Browser, der besonders hilfreiche, aber nicht standardmäßige Berechnungen ausführt), oder die Unterstützung eines Bildschirmleseprogramms für eine bestimmte API für Eingabehilfen kann variieren. Das Einreichen eines Browser-Problems mit einem einfachen Testfall ist ein guter Anfang. Wenn es sich nicht um einen Browserfehler handelt, kann der Entwickler ihn an die richtige Stelle weiterleiten oder einen Codevorschlag unterbreiten.
• Wird dieser Fehler mit mehreren Bildschirmlesegeräten in mehreren Browsern reproduziert? Möglicherweise können Sie Änderungen vornehmen Ihr Code oder Ihre Erwartungen können von den Standards und üblichen Vorgehensweisen abweichen.
• Wie werden die Eigenschaften und die Struktur dieses Elements in den Browser-Entwicklungstools angezeigt?

Überprüfen von Eingabehilfen und Eigenschaften in Entwicklungstools # section15

Die wichtigsten modernen Browser bieten Entwicklertools, mit denen Sie die Struktur des Eingabehilfenbaums sowie die Eingabehilfeneigenschaften eines bestimmten Elements beobachten können. Wenn Sie beobachten, welche barrierefreien Objekte für Ihre Elemente generiert werden und welche Eigenschaften für ein bestimmtes Element verfügbar gemacht werden, können Sie möglicherweise Probleme feststellen, die entweder im Front-End-Code auftreten oder in der Art und Weise, wie der Browser Ihre Inhalte in die Barrierefreiheits-API einbindet.

Nehmen wir an, wir testen diesen Code in Microsoft Edge mit einem Bildschirmlesegerät:

   Lieblingsfarbe 
  

Wir navigieren durch das Formularfeld und wenn wir in diesem Textfeld landen, den Bildschirm Der Leser sagt uns nur, dass es sich um ein "Bearbeiten" -Steuerelement handelt - es nennt keinen Namen für dieses Element. Überprüfen Sie die Werkzeuge auf den Namen des Elements, auf den zugegriffen werden kann.

1. Untersuchen Sie das Element, um die Entwicklungstools aufzurufen.

2. Rufen Sie die Eingabehilfenstruktur für diese Seite auf, indem Sie auf die Schaltfläche der Eingabehilfenstruktur klicken (ein Kreis mit zwei Pfeilen) oder Strg + Umschalt + A (Windows) drücken.

Das Überprüfen der Eingabehilfenstruktur ist ein zusätzlicher Schritt für diesen bestimmten Ablauf, kann jedoch hilfreich sein.

Wenn der Bereich "Eingabehilfenstruktur" angezeigt wird, stellen wir fest Es gibt einen Baumknoten, der nur "textbox :," mit nichts nach dem Doppelpunkt sagt. Dies deutet darauf hin, dass es für dieses Element keinen Namen gibt. (Beachten Sie auch, dass es das div um unsere Formulareingabe nicht in den Eingabehilfenbaum geschafft hat; es war semantisch nicht nützlich.)

3. Öffnen Sie den Bereich "Eingabehilfen-Eigenschaften", der dem Bereich "Stile" nachgeordnet ist. Wenn wir nach unten zur Eigenschaft Name scrollen - aha! Es ist leer. Die API für Eingabehilfen erhält keinen Namen. (Randnotiz: Einige andere Eingabehilfen werden standardmäßig aus dieser Liste herausgefiltert. Um die vollständige Liste zu erhalten, aktivieren Sie die Filtertaste, die wie ein Trichter aussieht.)

geöffnet. 4. Überprüfen Sie den Code. Wir stellen fest, dass wir das Label nicht mit dem Textfeld verknüpft haben. that is one strategy for providing an accessible name for a text input. We add for="myTextInput" to the label:

  Favorite color
  

And now the field has a name:

In another use case, we have a breadcrumb component, where the current page link is marked with aria-current="page":

When navigating onto the current page link, however, we don’t get any indication that this is the current page. We’re not exactly sure how this maps into accessibility properties, so we can reference a specification like Core Accessibility API Mappings 1.2 (Core-AAM). Under the “State and Property Mapping” table, we find mappings for “aria-current with non-false allowed value.” We can check for these listed properties in the Accessibility Properties pane. Microsoft Edge, at the time of writing, maps into UIA (UI Automation), so when we check AriaProperties, we find that yes, “current=page” is included within this property value.

Now we know that the value is presented correctly to the accessibility API, but the particular screen reader is not using the information.

As a side note, Microsoft Edge’s current dev tools expose these accessibility API properties quite literally. Other browsers’ dev tools may simplify property names and values to make them easier to read, particularly if they support more than one accessibility API. The important bit is to find if there’s a property with roughly the name you expect and whether its value is what you expect. You can also use this method of checking through the property names and values if mapping specs, like Core-AAM, are a bit intimidating!

Advanced accessibility tools#section16

While browser dev tools can tell us a lot about the accessibility semantics of our markup, they don’t generally include representations of text ranges or event notifications. On Windows, the Windows SDK includes advanced tools that can help debug these parts of MSAA or UIA mappings: Inspect and AccEvent (Accessible Event Watcher). Using these tools presumes knowledge of the Windows accessibility APIs, so if this is too granular for you and you’re stuck on an issue, please reach out to the relevant browser team!

There is also an Accessibility Inspector in Xcode on MacOS, with which you can inspect web content in Safari. This tool can be accessed by going to Xcode > Open Developer Tool > Accessibility Inspector.

Diversity of experience#section17

Equipped with an accessibility tree, detailed object information, event notifications, and methods for interacting with accessible objects, screen readers can craft a browsing experience tailored to their audiences. In this article, we’ve used the term “screen readers” as a proxy for a whole host of tools that may use accessibility APIs to provide the best user experience possible. Assistive technologies can use the APIs to augment presentation or support varying types of user input. Examples of other ATs include screen magnifiers, cognitive support tools, speech command programs, and some brilliant new app that hasn’t been dreamed up yet. Further, assistive technologies of the same “type” may differ in how they present information, and users who share the same tool may further adjust settings to their liking.

As web developers, we don’t necessarily need to make sure that each instance surfaces information identically, because each user’s preferences will not be exactly the same. Our aim is to ensure that no matter how a user chooses to explore our sites, content is perceivable, operable, understandable, and robust. By testing with a variety of assistive technologies—including but not limited to screen readers—we can help create a better web for all the many people who use it.

Further reading and resources#section18