ACCESIBILIDAD PARA DESARROLLADORES Y PROBADORES DE QA
Resumen
Estos documentos cubren todos los fundamentos clave de diseño y también deben revisarse al inicio de un proyecto por el equipo. Cubren las mejores prácticas clave de accesibilidad web que no están relacionadas con el diseño de un componente específico. Como ocurre con muchos de los documentos de componentes, contienen pruebas que el Director de Proyecto puede usar como criterios de aceptación para QA y técnicas que los Desarrolladores pueden utilizar para cumplir esos criterios.
Estas guías están diseñadas para dar soporte a cualquier sistema de diseño, incluido Material Designde Google, y también pueden utilizarse para apoyar el diseño accesible en plataformas de terceros como Wordpress, SAP y Salesforce, por lo que pueden usarse en cada sprint de cualquier proyecto.
Más formación y consejos sobre accesibilidad pueden encontrarse en los siguientes canales de Youtube:
1. Creación de componentes accesibles
Al desarrollar nuevos diseños de componentes pueden surgir problemas de accesibilidad que no están cubiertos por las directrices de accesibilidad porque son específicos de un diseño de interacción particular.
En estos casos es necesaria una investigación adicional para identificar mejores prácticas disponibles en la web, por lo que la página siguiente le proporcionará una lista de componentes que necesitan investigación adicional y las técnicas y metodologías que puede utilizar para asegurar que su componente cumpla las expectativas del usuario.
Cuando procede, los documentos de orientación contienen implementaciones de referencia que demuestran los comportamientos de código requeridos y proporcionan pruebas de QA recomendadas.
Pruebas
Para permitir que los equipos integren criterios de prueba en su plan de trabajo, el siguiente guion de pruebas de accesibilidad ayudará tanto a Directores de Proyecto como a Desarrolladores a cumplir los criterios de éxito de accesibilidad. Las pruebas automatizadas también están disponibles a través de UTS Test Magic, Cypress, Sa11y para Salesforce y deben usarse en combinación con el siguiente guion de pruebas manuales: Guion de pruebas para desarrolladores de Colt.
Para probar la accesibilidad con lectores de pantalla, use Windows Narrator para comprobar la accesibilidad de su componente o aplicación. La guía Usando Windows Narrator para probar la accesibilidad web describe los controles, el enfoque y los números esperados.
Las páginas web pueden probarse parcialmente usando complementos del navegador. Hay varios comerciales y no comerciales que funcionan en Microsoft Edge y Google Chrome. Uno que es fiable, gratuito y que genera hojas de cálculo que pueden usarse para rastrear errores es IBM Equal Access Tracker:
Diferentes herramientas de pruebas automatizadas pueden dar resultados distintos; algunas son comerciales o semicomerciales y no todas generan informes. Por favor asegúrese de que todos en un equipo de producto estén usando la misma herramienta.
Usado en combinación con las pruebas manuales en las directrices y las pruebas con Windows Narrator, la mayoría de los problemas de accesibilidad de uso serán fáciles de detectar y arreglar.
Esta visión general por Sparkbox cubre todas las características clave de la herramienta de prueba de IBM.
Guías de componentes
Las siguientes guías de mejores prácticas se toman de varios sistemas de diseño de terceros, blogs o recursos de documentación de confianza y, aunque los diseños pueden no ser exactamente los mismos que los implementados por Colt, las metodologías y técnicas siguen siendo una forma válida de comprender posibles problemas y sus soluciones.
Navegación
Contenido interactivo
Campos meta
Entrada de datos
2. Accesibilidad de la plataforma
Si está creando páginas web, aplicaciones o componentes en una plataforma o marco de terceros como Salesforce, SAP o Wordpress, cada una de estas plataformas proporciona orientación específica. Estas deben usarse además de las Guías de Accesibilidad de Colt.
Wordpress
Salesforce
SAP
3. Percepción del color
Cada color se percibe de forma ligeramente y a veces significativamente diferente por distintas personas, y muchas personas no pueden diferenciar entre ciertos matices. Asegurar que los diseños de las páginas web de Colt no dependan de una percepción precisa del color significa que nadie quedará excluido porque algunas características dependan del color en el diseño.
Sin embargo, el uso considerado de los colores de la marca Colt puede aumentar la accesibilidad para algunos usuarios y mejorar la usabilidad para muchos. Así que, en lugar de evitar el significado basado en el color en una página web, asegúrese de que cuando el color se utilice como indicio visual, también se proporcionen indicios visuales alternativos no basados en el color. A esto se le denomina a menudo en diseño e ingeniería como 'redundancia.'
La deficiencia de visión rojo-verde es la forma más habitual de los llamados trastornos del daltonismo. Afecta a aproximadamente 1 de cada 12 hombres y 1 de cada 200 mujeres. La deficiencia de percepción azul-amarillo es mucho menos común, y el daltonismo monocromático es aún más raro. También existen otras condiciones como Sinestesia, Glaucoma, Síndrome de Irlens y algunas personas con TEA que pueden presentar problemas para procesar colores.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
Pruebas que deben realizarse manualmente
A continuación hay un par de ejemplos de preguntas clave que debe formular:
Considerando cada uno de los enlaces de la página, ¿son todos visualmente identificables sin usar color? [Y/N]
Al interactuar con cada una de las funciones de la página (como validación o indicadores de progreso), ¿es posible saber en qué estado se encuentra cada una, incluso con el color desactivado? [Y/N]
Con respecto a gráficos y diagramas, ¿las categorías o conjuntos de datos mostrados en el gráfico están identificados mediante un tratamiento visual distinto al color? [Y/N]
Métodos y estrategias de prueba adicionales
Si usted mismo no es daltónico, puede probar una página web con un simulador de daltonismo. La aplicación Sim Daltonism se puede instalar en su teléfono móvil y abrirá un visor que aplicará un filtro de daltonismo a todo lo que esté delante de la cámara.
4. Interacciones de formularios
Los formularios pueden ser un desafío para usuarios con discapacidades visuales y/o cognitivas. Garantizar que los formularios están bien diseñados y son accesibles es asegurar que los usuarios comprendan y utilicen esos formularios según lo previsto.
Cuando los formularios web aplican convenciones y buenas prácticas de usabilidad, los usuarios pueden completar los formularios más rápidamente y con menos errores en el primer intento. Los formularios pueden ser puertas de acceso al contenido y servicios de Colt mediante inicio de sesión, oportunidades de empleo, el paso final para convertirse en cliente o incluso la única forma de presentar un problema o una queja. Si los formularios están mal diseñados o mal implementados, excluyen por completo a los usuarios con discapacidad.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
Pruebas que podrían automatizarse
A continuación hay un ejemplo de una prueba que no requiere escaneo manual:
¿Cada elemento de entrada tiene asociado un elemento label HTML semánticamente válido? [Y/N]
Pruebas que deben realizarse manualmente
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Se puede completar todo el formulario, incluida la corrección de posibles errores, y enviarlo usando solo el teclado? [Y/N]
¿El orden de tabulación a través del formulario (como lo muestra un indicador de foco visible) es lógico y predecible para un usuario con teclado con buena visión? [Y/N]
¿Los campos de entrada obligatorios están marcados visualmente como tales y utilizan el atributo HTML input required en el elemento de entrada? [Y/N]
¿Los mensajes de error están redactados y mostrados de forma que quede claro qué campos han rechazado la entrada, por qué no se aceptó la entrada y qué hacer para corregirlo? [Y/N]
Restablecimientos, tiempos y validación
Botones de restablecer
Evite usar un botón de restablecer en los formularios. Rara vez se usan y puede ser frustrante que un formulario completado se borre con un solo clic accidental. Tenga en cuenta que sin un botón de restablecer, los grupos de botones de opción pueden ser problemáticos en ciertos casos. Una de sus particularidades es que no se puede "deseleccionar" el grupo una vez que se ha seleccionado alguna opción; solo puede moverse la selección a otro botón de opción del mismo grupo. Por ello, se recomienda incluir una opción del tipo "ninguno de los anteriores" cuando proceda.
Temporización
Los formularios que caducan demasiado pronto pueden ser frustrantes, especialmente si el proceso ha sido largo, como introducir una especificación para un presupuesto o solicitar un empleo. Si no existe una necesidad específica de tener un tiempo de espera en un formulario, asegúrese de que los datos se conservan al menos durante 20 horas. Si debe haber uno, asegúrese de que sea al menos 5 veces más largo que el tiempo necesario para un usuario medio con buena visión y que los tiempos se transmitan en las instrucciones.
Validación
Al validar un formulario, asegúrese de que el valor original introducido por el usuario que provocó el error no se borre. Manteniendo el valor original, el usuario puede identificar más fácilmente su error y corregirlo editándolo. El uso de atributos WAI-ARIA puede ayudar a que los errores de validación sean más fáciles de seguir para los usuarios de tecnologías de asistencia. Use el atributo aria-invalid para marcar cada campo de entrada inválido como que tiene un error, y el atributo aria-describedby para asociar el mensaje de error específico a ese campo de entrada.
Mensajes de error
Cuando los mensajes de error no se muestran en absoluto, debe considerarse un defecto grave. Cuando el envío de un formulario es rechazado y no hay retroalimentación que explique qué debe corregirse para continuar, el formulario se vuelve inutilizable.
Los mensajes de error deben ser concisos y específicos al explicar por qué se rechazó el envío del formulario, y deben evitar el uso de largas cadenas de jerga técnica. Cualquier código de error debe explicarse en términos no técnicos.
Compruebe que todos los mensajes de error que pueden mostrarse cumplen los siguientes requisitos:
Específico: Decir simplemente "hubo un error" o "el formulario no es válido" no es útil. El mensaje debe indicar claramente qué campo o campos de entrada fueron inválidos y por qué fueron rechazados. El nombre del campo en el error debe coincidir exactamente con la etiqueta del campo donde se produjo el error.
Amable: Aunque el usuario haya cometido un error, la experiencia debe ser de ayuda. Evite frases que suenen agresivas, como "error del usuario: entrada ilegal", aunque sean técnicamente correctas, ya que no generan una buena experiencia de usuario.
Accionable: Comunicar que hay un problema y cuál es solo es parte de la respuesta. El usuario también debe saber qué pasos puede tomar para solucionar el problema. Compruebe que hay información sobre lo que necesita hacer a continuación para avanzar y, si es necesario, proporcione un enlace a las preguntas frecuentes y a un servicio de asistencia.
Texto de marcador de posición
Estas son palabras que aparecen dentro de un campo de formulario y están pensadas como una pista agradable. No son sustitutos de etiquetas adecuadas y no deben duplicar una etiqueta, sino proporcionar instrucciones o sugerencias adicionales.
Los marcadores de posición que sustituyen a las etiquetas son difíciles de usar para los usuarios de teclado porque en cuanto el usuario entra con tab en el campo de texto las instrucciones desaparecen. El contraste del texto del marcador de posición es deliberadamente bajo, lo que es otra razón por la que no sustituyen a las etiquetas, y el texto del marcador de posición no puede ajustarse en varias líneas, por lo que en pantallas estrechas el usuario podría no ver su totalidad.
5. Acceso por teclado
Aunque existen muchos tipos diferentes de teclados (o dispositivos de conmutador) que la gente puede usar para navegar por páginas web, desde el punto de vista de implementación necesitamos considerar los siguientes grupos:
Todos los demás usuarios de teclado, es decir, usuarios que pueden al menos ver parcialmente la pantalla, que pueden o no usar un lector de pantalla para complementar su experiencia, pero que dependen de indicios visuales mostrados en la pantalla para navegar.
Usuarios que no tienen acceso a un dispositivo apuntador como un panel táctil o un ratón, o que tienen condiciones físicas como LESIONES POR ESFUERZO REPETITIVO (RSI), parálisis cerebral o diferencias en las extremidades y para quienes el teclado es un método mejor.
La Directrices de Accesibilidad para el Contenido Web (WCAG) requiere que los proveedores de páginas web "garanticen que, cuando sea posible, el contenido pueda operarse mediante teclado o interfaz de teclado." Sin soporte de teclado, estos usuarios quedarán excluidos de acceder a su página web. Una encuesta WebAIM a usuarios de lectores de pantalla encontró que una porción considerable de usuarios indicó que "la falta de accesibilidad por teclado" era un problema para ellos. El acceso puede incluir el uso de formularios, menús de navegación, widgets interactivos, ventanas emergentes, alertas y cualquier otro tipo de componente en una página.
Elementos de control enfocables
Enlace: La tecla Enter debe activar/seguir el enlace
Botón: La tecla Enter o Espacio debe activar/pressionar el botón
Casillas de verificación/Botones de opción: Las teclas de flecha deben mover el elemento resaltado; la tecla Espacio debe marcar o desmarcar el elemento resaltado
Select (desplegable): Las teclas de flecha deben mover el elemento resaltado; la tecla Enter debe seleccionar el elemento resaltado
Diálogo: La tecla Esc debe cerrar el diálogo
Mantener el foco visible
Los navegadores web ya son accesibles en cuanto a indicar qué elemento en una página web tiene el foco mediante un contorno visible. Usando CSS para estilizar ese foco, el indicador puede personalizarse o incluso desactivarse. La ausencia de un indicador de foco o uno difícil de ver debe considerarse un defecto.
Nota n.º 1: Usar solo el cambio de color para indicar el foco sería inaccesible para los usuarios que no pueden percibir el color.
Nota n.º 2: No desactive funciones necesarias para la navegación por teclado, p. ej. :focus {outline:none;}
Visible al recibir el foco
El contenido que está visualmente oculto en la pantalla, pero que puede recibir el foco mediante la navegación por teclado, debe autorizarse de forma que el contenido se vuelva visible una vez que tenga el foco. Un ejemplo sería un enlace "Saltar al contenido principal", destinado a permitir a los usuarios saltarse rápidamente todo el contenido de navegación en la parte superior de cada página y continuar al contenido principal.
Validación
Al validar un formulario, asegúrese de que el valor original introducido por el usuario que provocó el error no se borre. Manteniendo el valor original, el usuario puede identificar más fácilmente su error y corregirlo editándolo. El uso de atributos WAI-ARIA puede ayudar a que los errores de validación sean más fáciles de seguir para los usuarios de tecnologías de asistencia. Use el atributo aria-invalid para marcar cada campo de entrada inválido como que tiene un error, y el atributo aria-describedby para asociar el mensaje de error específico a ese campo de entrada.
Atajos de teclado
Si bien existen muchos atajos de teclado conocidos definidos en aplicaciones de escritorio, no ocurre lo mismo con la miríada de páginas web diferentes que existen. Aunque es posible usar el atributo accesskey para definir teclas de acceso rápidas personalizadas, esto no aumentará la accesibilidad si los usuarios no pueden predecirlas o conocerlas de forma evidente. Definir tales atajos podría incluso empeorar las cosas si entran en conflicto con atajos estándar integrados en el navegador o en la tecnología asistiva. Consulte los atajos comunes en la Megapedia de BBC GEL.
Evitar trampas de teclado
Existe una "trampa de teclado" siempre que una función en una página web impida al usuario moverse fuera de un elemento con foco. Esto no debería ocurrir, por supuesto, pero un JavaScript mal implementado a veces puede alterar la forma en que el foco de teclado funciona normalmente y romperlo de esta manera si el autor de la página no tiene cuidado.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
Pruebas que deben realizarse (al menos en parte) manualmente
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Es posible usar la tecla Tab para avanzar, y la combinación de teclas Shift+Tab para mover el foco de modo que cada enlace y control pueda accederse y utilizarse sin ratón ni pantalla táctil? [Y/N]
Al mover el foco, debe ser claramente visible qué elemento de la página web tiene actualmente el foco, por ejemplo mediante un contorno consistente y con contraste visible. [Y/N]
Al mover el foco, ¿sigue cada elemento que recibe el foco un orden lógico y predecible, moviéndose de arriba abajo y de izquierda a derecha (para páginas publicadas en inglés y otros idiomas de izquierda a derecha)? [Y/N]
Para componentes interactivos, incluidos elementos de formulario, ¿es posible navegar y operar cada elemento, incluyendo configurar cualquier opción posible, usando las teclas de flecha, la tecla Enter, la tecla Espacio, etc.? [Y/N]
Para componentes complejos que mueven el foco automáticamente cuando se abre o aparece contenido nuevo, ¿vuelve el foco al elemento original una vez que ese contenido se cierra? [Y/N]
Para contenido que está visualmente oculto cuando se carga la página web, ¿ese contenido se vuelve visible cuando el foco del teclado se mueve al elemento? [Y/N]
6. Etiquetas para elementos interactivos
Los controles de formulario y otros elementos interactivos deben estar etiquetados correctamente. No hacerlo dificultará que los usuarios de tecnologías de asistencia comprendan el propósito del control. La falta o el etiquetado incorrecto de elementos interactivos puede causar problemas o confusión a sus usuarios.
La Directrices de Accesibilidad para el Contenido Web indican que todos los elementos interactivos deben tener tanto una etiqueta como un nombre accesible. La etiqueta se presenta visualmente y el nombre accesible es utilizado por las tecnologías de asistencia, como los lectores de pantalla. A menudo ambos son iguales; por ejemplo, si un enlace envuelve el texto "Inicio", como Inicio el texto "Inicio" es la etiqueta y el nombre accesible.
De forma similar, un botón que contiene el texto "Enviar" tiene tanto una etiqueta visual como un nombre accesible de "Enviar".
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
Pruebas que deben realizarse manualmente
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Existe una etiqueta de texto visible que identifique qué tipo de información se espera introducir? [Y/N]
¿La etiqueta está cerca del control que describe, de manera que sea obvio a qué control se refiere? [Y/N]
¿La etiqueta sigue siendo visible cuando el control tiene el foco? [Y/N]
Si el control es un grupo de opciones seleccionables, como un menú desplegable o una lista de botones de opción o casillas de verificación, ¿hay una etiqueta de texto visible que describa la colección de opciones? [Y/N]
Cuando un lector de pantalla encuentra los controles, ¿la etiqueta se lee en voz alta como se espera? [Y/N]
Ejemplos e información adicional
Los tres aspectos de etiquetas y nombres accesibles que deben implementarse correctamente se basan en el usuario y en cómo interactúa con la página web. Tener una etiqueta visual es claramente necesario para permitir que los usuarios videntes que navegan usando un cursor o ratón sepan qué están diseñados para hacer los elementos interactivos: hacer clic en el botón "cerrar pestaña" o navegar por tabulación hasta el enlace "página de soporte" son ejemplos.
Al proporcionar esas etiquetas de formas accesibles también atenderá a los usuarios de dispositivos lectores de pantalla, que usarán ese texto para anunciar el nombre accesible al usuario. En algunos casos, sin embargo, es posible aplicar una etiqueta visible diferente del nombre accesible. Esto crea problemas potenciales para usuarios que usan control por voz y reconocimiento de voz para navegar, por ejemplo diciendo "hacer clic en Enviar". Estos usuarios verán la etiqueta y la usarán para dirigir su tecnología asistiva, que a su vez se basará en el nombre accesible. Por esta razón, se recomienda mantener la etiqueta visible igual que el nombre accesible.
No confíe en el texto de marcador de posición
Texto de marcador de posición a veces lo usan los autores de páginas como si fuera una alternativa a una etiqueta. Esto a veces es un intento de ahorrar espacio en un formulario ya que el texto de marcador aparece dentro del campo en lugar de junto a él. Pero esto es exactamente por lo que no es adecuado como etiqueta. Además de tener por defecto bajo contraste, por diseño desaparece en cuanto el usuario empieza a escribir en el campo. En ese momento ya no hay ninguna etiqueta visible. Los usuarios con deterioro de la memoria a corto plazo o incluso los que se distraen y se distraen mirando hacia otro lado pueden dejar de saber para qué sirve ese campo.
No añada un atributo title
A veces se añade un atributo title a los elementos de entrada de formularios. Si bien es cierto que la mayoría de los lectores de pantalla leerán el atributo title, esto no aporta beneficio: usar el más elemento label semántico también funcionaría y tiene la ventaja de que la etiqueta puede hacerse clic para enfocar la entrada. Tener tanto una etiqueta como un atributo title significa, por supuesto, que ambas cadenas de texto se leerán, lo que genera duplicación.
Ocultar partes de las etiquetas a los lectores de pantalla
En algunos casos, partes específicas del texto usado en una etiqueta tienen un significado convencional, pero solo cuando se ven. Por ejemplo, el asterisco se usa a menudo para indicar visualmente que un elemento del formulario es obligatorio. Aunque algunos lectores de pantalla pueden leer el asterisco, muchos no lo harán. Es aceptable ocultar el asterisco a los lectores de pantalla si la información se deja clara de otra manera.
Ocultar partes de las etiquetas a los no lectores de pantalla
Una etiqueta a menudo es texto plano pero puede ser un elemento con texto alternativo, como una imagen, siempre que la imagen sea un icono bien entendido. Cuando una etiqueta es visible solo como un icono, se debe proporcionar texto alternativo para los usuarios que no pueden ver el icono. Idealmente el control mostraría ese texto para todos junto con el icono, pero las limitaciones de diseño pueden no permitirlo. En ese caso, proporcionar texto como etiqueta que sea accesible solo para un lector de pantalla es aceptable, siempre que el icono sea bien conocido y entendido por los videntes sin el texto (por ejemplo, un icono de "lupa" como etiqueta para un formulario de búsqueda).
El ejemplo siguiente utiliza una de las técnicas de la sección Texto alternativo para imágenes Estas alternativas de texto naturalmente estarán ocultas a los usuarios que miran la imagen.
7. Landmarks (puntos de referencia)
Al agregar landmarks HTML a sus páginas web, permite que las tecnologías de asistencia identifiquen las regiones a las que un usuario podría querer saltar rápidamente, por ejemplo usando las etiquetas mínimas header, nav, main, section y footer. Guía W3C sobre landmarks WAI-ARIA.
Una encuesta de WebAIM a usuarios de lectores de pantalla reveló que más de la mitad de los encuestados al menos a veces usan landmarks HTML para navegar dentro de una página web. Si bien otras características, como Encabezados y Enlaces, pueden usarse con más frecuencia según la encuesta, agregar landmarks HTML al conjunto de señales virtuales solo puede ser de ayuda, particularmente para usuarios que no pueden escanear visualmente un documento para decidir dónde comenzar.
Navegar por landmarks HTML es una técnica que pueden usar tanto usuarios videntes como usuarios ciegos, incluso sin la ayuda de un lector de pantalla.
Para usuarios que no tienen acceso a funciones de navegación por landmarks integradas en su navegador o tecnología asistiva, puede proporcionar lo que se conoce como "enlaces de salto" como una característica de la propia página web. Los enlaces de salto deben ser el primer contenido en el body de la página web y deben enlazar al contenido identificado usando el landmark main.
Esto es útil para usuarios que, de lo contrario, tendrían que examinar muchas enlaces de navegación y contenido de encabezado con el teclado, por ejemplo, antes de llegar al contenido que quieren acceder. Es aceptable ocultar estos enlaces de salto para evitar saturar la página web a los usuarios que navegan con puntero (ratón o toque, por ejemplo) aplicando CSS que hace que el enlace esté visualmente oculto hasta que reciba el foco del teclado. Pruebas que podrían automatizarse:
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Todo el contenido de la página web está contenido dentro de una región landmark? [Y/N]
Pruebas que deben realizarse (al menos en parte) manualmente:
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿El contenido del encabezado de la página web está identificado usando el landmark header? [Y/N]
¿El contenido del pie de página de la página web está identificado usando el landmark footer? [Y/N]
Teniendo en cuenta otros landmarks, si se usan, ¿cada uno comunica correctamente el contenido que contiene: section, article, aside? [Y/N]
Si existe un enlace de salto, ¿ese enlace está en o cerca de la parte superior de la página web y puede usarse al navegar con el teclado para saltar al contenido principal? [Y/N]
8. Enlaces
Al escribir el texto de un enlace, use texto conciso pero completo que describa el recurso enlazado. Esto es particularmente importante para las personas que usan un lector de pantalla para escanear la página completa y leer una lista solo de enlaces, donde cada enlace no tendrá contexto y debe entenderse por sí mismo.
Por ejemplo, una serie de resúmenes de artículos, cada uno con el enlace con el texto "Leer más" se presentará como una lista de muchos fragmentos "Leer más" al usuario del lector de pantalla, sin indicación de sobre qué permitirá leer más cada enlace.
Usuario de lector de pantalla:
"¿Leer más" qué? Agregar contexto al texto del enlace eliminará barreras para los usuarios de lectores de pantalla y probablemente ayudará a los usuarios videntes a llevar un seguimiento de a dónde navegan. En casos excepcionales, donde sería redundante o una distracción para los usuarios videntes leer todos los detalles en el contenido del enlace, esto puede gestionarse agregando el contexto como texto visualmente oculto disponible solo para usuarios de lectores de pantalla.
Aunque el texto del enlace aparece visualmente como solo "Leer más" en el contexto del artículo titulado "Nuestros valores", aparecerá como "Leer más sobre nuestros valores..." cuando un usuario de lector de pantalla abra la lista de todos los enlaces de la página web. Cuando sea posible, debe mantener el contenido destinado a usuarios de lectores de pantalla visualmente igual al contenido destinado a otros usuarios. No todos los usuarios de lectores de pantalla son ciegos, y los usuarios de lectores de pantalla que pueden ver el texto pueden confundirse al oír y ver contenido diferente.
Iconos en enlaces
Si bien tener texto visible y descriptivo es la forma más accesible de etiquetar un enlace, existen casos de uso donde un icono bien entendido sería más natural. En estos casos, se debe proporcionar texto alternativo para los usuarios de lectores de pantalla que no pueden ver el icono.
Un simple
elemento img HTML mostrará el icono. Los lectores de pantalla anunciarán que hay una "imagen" presente y leerán cualquier texto en el atributo alt Consulte la guía de.
Alternativas de texto para imágenes funcionales Enlaces externos.
Al enlazar a sitios web externos, es buena idea, desde una perspectiva de seguridad y responsabilidad, informar al usuario de que está a punto de visitar contenido del que usted no es responsable. Esto puede ser un problema si el usuario ha iniciado sesión en su sitio o tiene alguna otra sesión que se interrumpiría o perdería al salir de su sitio.
Nuevas pestañas
Abrir enlaces en pestañas o ventanas nuevas puede hacer que la experiencia de algunos usuarios sea más confusa y menos accesible, por lo que debe usarse con poca frecuencia. Una excepción puede ser los enlaces a sitios web externos. Si el enlace abre un
modal o una página en una pestaña o ventana nueva, asegúrese de que esto se explique en el texto del enlace. Pruebas que deben realizarse manualmente:
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿Cada enlace contiene texto visible o un icono convencional bien entendido? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
Para enlaces que contienen solo un icono, ¿se ha asignado texto equivalente al gráfico? [Y/N]
¿Todos los enlaces son consistentemente y visualmente distintos del texto circundante para que el usuario pueda identificarlos de una manera que no dependa únicamente del color? [Y/N]
Al navegar por la página web usando el teclado, ¿es visualmente aparente cuando un enlace tiene el foco del teclado? [Y/N]
Cuando los enlaces se presentan como una lista, separada de su contexto circundante, ¿todos tienen texto único o texto alternativo que sea conciso pero describa distintamente el recurso al que enlazan? [Y/N]
¿El texto de todos o de cualquiera de los enlaces de la página es totalmente comprensible cuando se lee aisladamente? Por ejemplo, no usar "haga clic aquí" o "más información" [Y/N]
9. Metadatos
Los metadatos son literalmente "datos sobre datos" y son vitales para que una página web sea accesible. El estándar HTML define múltiples formas para que los autores de páginas web proporcionen estos metadatos, incluyendo una serie de apropiadas "meta tags" y varias otras etiquetas y atributos que declaran cosas como el idioma, el conjunto de caracteres, el título y la escala de ventana preferida, todo lo cual se relaciona con el documento de la página web.
Aunque los metadatos de la página web pueden proporcionarse usando una variedad de etiquetas y atributos, lo que tienen en común es que siguen estándares bien establecidos de la industria y, por tanto, son legibles por máquina.
Accesibilidad y SEO
Los beneficios de metadatos precisos y bien redactados se aplican a dos tipos de legibilidad por máquina: los rastreadores de motores de búsqueda y las tecnologías de asistencia. Por ejemplo, tener un
tag title HTML significativo y bien redactado para una página web permitirá a Google mostrar ese título como el titular que se puede hacer clic en su página de resultados de búsqueda, que el título se incluya al compartir la página en redes sociales y que el título se use como nombre del marcador en el navegador del usuario. Además, ese mismo título será usado por los dispositivos lectores de pantalla para anunciar el nombre de la página web cuando se cargue, de modo que los usuarios que no puedan ver la pantalla puedan escuchar una descripción precisa y concisa del tema de la página.
Validar el HTML
Validación
siempre es un buen comienzo para comprobar los metadatos subyacentes. La extensión Web Developer para navegadores hace esto simple; use el elemento del menú: Tools → Validate HTML Evaluar las meta tags también se simplifica con esta herramienta. Active la opción del menú:Information → View Meta Tag Información para la página web bajo prueba. Eventualmente, debido a la naturaleza de los metadatos optimizados para máquinas, puede que necesite usar la opción ver fuente de las herramientas de desarrollador de su navegador para acceder directamente al HTML de la página bajo prueba. Busque cualquier metadato establecido en la etiqueta html o definido en la sección head del documento.
Declarar el idioma de una página web
El atributo
La lang puede añadirse a muchos elementos HTML para indicar en qué idioma está escrito el texto de ese elemento. Como mínimo, la etiqueta HTML exterior debe tener un idioma declarado. Si partes de la página están escritas en un idioma diferente (por ejemplo cuando se cita intencionadamente una frase extranjera), ese elemento debe tener un valor de atributo lang correcto dependiendo del idioma usado. Si el idioma no sigue el orden predeterminado de izquierda a derecha para la lectura de texto, asegúrese de que también se incluya el atributo dir para especificar "rtl", por ejemplo, al citar un patrón de visualización de derecha a izquierda.
No establecer el idioma probablemente perjudicará la clasificación de su página web en motores de búsqueda, dificultará que las herramientas generen traducciones automáticas de su contenido y evitará que los dispositivos lectores de pantalla utilicen con precisión el motor de pronunciación más apropiado al leer su contenido de texto.
Haga los títulos lo suficientemente específicos como para ser distintos
El título de una página web debe ser lo bastante específico como para poder usarse para distinguir esa página de cualquier otra página en todo el sitio web. Siguiendo esta regla, cada página web debería tener un título único; de lo contrario, la implicación es que el título elegido no fue lo bastante específico en su descripción o bien tiene varias páginas web con el mismo contenido.
No desactive el gesto de 'pellizcar y expandir' para hacer zoom
Los dispositivos con pantalla táctil a menudo soportan gestos conocidos como pellizcar y expandir para permitir al usuario acercar y alejar áreas visibles específicas de una página web. Es técnicamente posible definir metadatos que desactiven esto (por ejemplo estableciendo maximum-scale=1). Si se detecta que esto ocurre, debe considerarse un defecto.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿La página web no produce errores de validación HTML cuando se comprueba con una herramienta de validación HTML W3C? [Y/N]
¿La página web tiene al menos un atributo de idioma general establecido que siga los códigos de idioma estándar para HTML? [Y/N]
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿La página web tiene una etiqueta title que describa con precisión y concisión el tema de la página completa? [Y/N]
Si la página web se visualiza en una pantalla táctil que admite pellizcar y expandir para hacer zoom, ¿es posible usar estos gestos para acercar y alejar la página? [Y/N]
10. Mejora y diseño responsive
La mejora progresiva garantiza que los usuarios puedan usar la más amplia gama posible de dispositivos y software, mientras que el propósito central de la página sigue siendo usable y comprensible. Se pueden añadir características adicionales "agradables de tener" sobre esa experiencia básica para beneficio de dispositivos y navegadores más capaces.
Accesibilidad robusta
Aplicar prácticas de mejora progresiva hará que su página web sea más resiliente además de inclusiva; no todos los usuarios dispondrán de la conectividad más rápida, el ordenador más potente o el software más reciente instalado. y a veces una función puede estar desactivada por decisión del usuario. Debe asumir que tienen una buena razón para ello, pero no todos los usuarios tienen elección.
1. Asegúrese de que el texto sea redimensionable
El texto se considera usable y legible cuando no se recorta y no se superpone a otro texto o elementos cercanos. Debe envolver según sea necesario y mantener sus cualidades tipográficas, permitiendo suficiente interlineado y espaciado entre letras y líneas, por ejemplo. Asegúrese de que se utilicen unidades relativas (ems o rems) para especificar los tamaños de los elementos de la página como texto y diseño. Esto permitirá que la página se escale y se adapte en relación con el tamaño de la pantalla del dispositivo o su orientación (vertical u horizontal).
2. Asegúrese de que la página web sea ampliable (zoom)
El zoom de página aumenta el tamaño aparente de toda la página, mientras que redimensionar el texto solo aumenta el tamaño del texto. Asegúrese de que todo el contenido sea visible y usable cuando la página esté ampliada al menos al 200% de su nivel predeterminado.
3. Ajuste los objetivos táctiles para que sean más grandes en pantallas pequeñas
En dispositivos móviles con pantalla táctil, el usuario debe enfrentarse tanto a una pantalla física más pequeña como a usar el dedo para intentar pulsar objetivos como enlaces o botones. Teniendo esto en cuenta, el tamaño físico mínimo del objetivo táctil debe ser al menos de 7 x 7 mm, o más grande si es posible. Esto sin duda requerirá aumentar el tamaño de los elementos interactivos en pantallas pequeñas.
4. No confíe en una alternativa noscript
Algunas páginas web usan la etiqueta noscript HTML para definir contenido alternativo para navegadores donde JavaScript está desactivado. Investigaciones realizadas por Gov.uk mostraron que una porción significativa de usuarios que no pudieron ejecutar JavaScript no lo tenían desactivado. En otras palabras, JavaScript estaba activado pero no se ejecutó por alguna otra razón. Esto importa porque un navegador mostrará contenido noscript solo en el caso específico de que JavaScript esté desactivado. Cuando JavaScript no se ejecuta por otra razón, el usuario no verá el contenido que requiere JavaScript ni verá ningún contenido alternativo noscript.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Todos los tamaños especificados en el diseño (CSS) de la página están declarados usando únicamente unidades relativas (ems o rems), evitando el uso de unidades fijas en píxeles como px? [Y/N]
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
Cuando el tamaño del texto se modifica al 200% de su tamaño predeterminado en la configuración del navegador, ¿todo el texto de la página sigue siendo visible y legible? [Y/N]
Cuando el zoom de la página se aumenta al 200% en el navegador, ¿todo el texto de la página aumenta proporcionalmente? [Y/N]
En DevTools, con el simulador de CPU y Network Throttle del navegador ajustado a sus configuraciones más degradadas, ¿se sigue cumpliendo el propósito principal de la página? [Y/N]
En DevTools, cuando el simulador de Modo dispositivo del navegador está configurado en la pantalla de dispositivo más pequeña disponible, ¿se sigue cumpliendo el propósito principal de la página? [Y/N]
Prácticas de prueba adicionales
Puede usar herramientas como el navegador Chrome DevToolsy aplicar los Modo dispositivo ajustes para aproximar la página web en prueba en una gama de dispositivos: desde móviles, a tabletas y escritorio. Incluso puede simular entradas de dispositivo para tacto, geolocalización y orientación del dispositivo.
Tenga en cuenta que la pestaña Network le permite simular la limitación de CPU y red.
11. Estructura semántica
Dentro de cualquier página web, los encabezados se utilizan para comunicar la organización y estructura general del contenido. Los encabezados deben actuar como un esquema de alto nivel del contenido de la página, con una clasificación lógica de cada tema y subtema en orden jerárquico.
Una encuesta de WebAIM a usuarios de lectores de pantalla reveló que el 67,5% de los encuestados probablemente intentan los encabezados primero para encontrar información en una página larga. Y el 85,7% dijo que tener niveles de encabezado adecuados fue útil al navegar por una página web mediante encabezados.
No proporcionar encabezados utilizables y bien organizados impide que los usuarios de lectores de pantalla comprendan la estructura de su contenido y puedan navegar por su página de forma eficiente. Aunque los encabezados son útiles para todos, los usuarios de tecnologías de asistencia quedan más excluidos que otros cuando faltan encabezados o están mal implementados.
Encabezados
El encabezado h1 debe describir el tema de la página web en su conjunto y por tanto será similar o idéntico en contenido al elemento title de la página web.
Es típico que el primer encabezado sea h1, pero no es un defecto que aparezca primero un h2, por ejemplo. El orden y la clasificación lógica de los encabezados es más importante que cuál aparece primero; por ejemplo, asegurarse de que ningún h2 sea seguido inmediatamente por un h4 (saltándose el h3 esperado). Para ilustrar, si la parte de navegación de la página apareciera antes del título mostrado de la página, podría dar al encabezado de navegación una clasificación h2 pero luego más abajo usar un h1 para indicar el tema principal de toda la página.
Los lectores de pantalla no pueden reconocer elementos que solo están estilizados visualmente como encabezados como encabezados reales. Use una herramienta que pueda comprobar el código fuente HTML para encontrar los encabezados reales (que es exactamente cómo lo hacen los lectores de pantalla) y use un div solo para lo que fue diseñado; nunca lo use como reemplazo de otras etiquetas más apropiadas. Para una experiencia más auténtica de navegación por encabezados, use el lector de pantalla Narrator integrado en su máquina Windows para probar la página.
Esto hará que la importancia del H1 sea inaccesible para los usuarios de lectores de pantalla.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Aparecen etiquetas de encabezado HTML como h1 y h2 en el HTML de la página? [S/N]
¿Están los encabezados en un orden jerárquico sin saltos de nivel de encabezado (por ejemplo, de h2 a h4)? [S/N]
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Se muestran los encabezados con un estilo coherente y reconocible que los hace fáciles de identificar frente a otro contenido que no es encabezado? [S/N]
¿El texto de cada encabezado describe correctamente y de forma concisa el tema que encabeza? [S/N]
¿El h1 principal de la página describe correctamente y de forma concisa el tema de la página en su totalidad? [S/N]
¿Todas las ocasiones de texto que visualmente se parecen a encabezados están implementadas con una etiqueta de encabezado HTML? [S/N]
12. Alternativas de texto
Cuando el usuario no tiene imágenes disponibles en su navegador web o no puede ver las imágenes debido a una discapacidad, DEBEN proporcionarse alternativas de texto que actúen como una fuente comparable de información y utilidad para que el usuario aún pueda acceder, comprender y usar la página web para su propósito principal previsto.
Este documento cubre las técnicas y pruebas necesarias para garantizar que las imágenes funcionales, como iconos, botones, controles, logotipos y activos de marca, sean accesibles para los usuarios de lectores de pantalla.
También cubre técnicas para identificar imágenes de contenido; sin embargo, las pruebas no probarán de forma concluyente que las imágenes de contenido sean accesibles. Nunca confíe en una herramienta automatizada de generación de texto alternativo basada en IA. Las imágenes funcionales requieren una alternativa de texto que describa lo que hacen o representan en lugar de cómo se ven. Una descripción visual de un botón o icono es de poco o ningún uso para un usuario.
Imágenes puramente decorativas
Estas imágenes no aportan significado al contenido de la página web y, por lo tanto, deben ser ignoradas silenciosamente por los lectores de pantalla. Por definición, las imágenes decorativas podrían eliminarse sin afectar la comprensibilidad y la usabilidad de la página.
De manera similar, las imágenes de fondo (definidas en CSS) son automáticamente ignoradas por los lectores de pantalla, por lo que solo deben usarse con fines puramente decorativos.
Existe un caso límite que se abusa con frecuencia en el que el elemento que muestra la imagen de fondo se diseña para contener texto destinado a ser una alternativa a la imagen, en lugar de definirse en un atributo alt de HTML.
Observe que el texto alternativo está en el cuerpo de la página web pero se oculta mediante estilos (a través de una clase visualmente oculta definida por el desarrollador) para que solo sea accesible para los usuarios de un lector de pantalla. Aunque esto es técnicamente accesible para los usuarios de lectores de pantalla, es un enfoque peor que usar un elemento img con un atributo alt porque el texto visualmente oculto nunca se revelará cuando las imágenes estén deshabilitadas o, por cualquier motivo, no se carguen, mientras que el texto del atributo alt sí lo hará.
Imágenes de contenido
Estas imágenes son intrínsecas al contenido o a la utilidad de la página. Use el atributo alt de HTML para proporcionar una alternativa textual para la imagen.
Tenga cuidado de no proporcionar contenido redundante; sin embargo, si el texto utilizado como alternativa para la imagen ya está cerca en el texto del cuerpo, entonces el texto alternativo debe considerarse redundante y la imagen debe tratarse como puramente decorativa. De lo contrario, la experiencia con el lector de pantalla será escuchar el mismo texto leído en voz alta dos veces.
Al evaluar la calidad del texto alternativo, considere el significado editorial y el propósito de la imagen en el contexto de la página circundante. El texto alternativo debe transmitir de forma concisa lo que la imagen significa, no solo lo que muestra.
No asuma que otras características HTML destinadas a proporcionar texto alternativo, como los atributos longdesc, title o figcaption, funcionarán para los lectores de pantalla. No es predecible si un lector de pantalla en particular (dependiendo de cómo esté configurado) ignorará esos atributos o si leerá alguno o incluso todos ellos.
Si la cantidad de información textual requerida es grande o compleja, es aceptable usar un atributo ARIA para marcar otro elemento HTML adyacente como el texto alternativo.
Imágenes en controles
Cuando las imágenes actúan como la etiqueta de un control —piense en una imagen del logotipo de una red social que es el único contenido en un enlace al feed de la empresa— el control debe ser accesible para los usuarios que no pueden ver la imagen. Use texto alternativo que explique la acción del control. Un enlace debe describir el destino, por ejemplo "Página principal", "Sobre nosotros", etc. Una imagen en un botón debe usar texto alternativo que describa el propósito del botón, como "Buscar", "Iniciar sesión" o "Enviar", por ejemplo.
Gráficos en formato SVG
En algunos casos, la imagen mostrada puede no definirse usando una etiqueta img tradicional, pero todavía debe ser posible que los lectores de pantalla accedan a algunas alternativas textuales. El ejemplo a continuación muestra una técnica documentada por Léonie Watson que utiliza una combinación de los atributos role y aria-labelledby que hacen referencia a un title y desc para ayudar a los usuarios de tecnología asistiva a acceder al texto que describe el gráfico.
Cómo probar esto
Para cada página web, realice las siguientes comprobaciones. Anote una respuesta, "sí" o "no" a cada pregunta. El resultado de aprobación se indica en mayúsculas después de cada pregunta, p. ej. [Y/N], donde Y es necesario para aprobar. Para cada resultado no aprobado, documentelo como una de las siguientes opciones:
Como un defecto
Un defecto, pero con una explicación de por qué debería permitirse como excepción
Un defecto, pero con una explicación de por qué no es aplicable
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un ejemplo de una pregunta clave que debe hacerse:
¿Cada imagen tiene texto alternativo asociado (incluso si ese texto es un valor vacío)? [S/N]
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
¿Es el texto alternativo conciso, gramaticalmente correcto y libre de errores ortográficos? [S/N]
Si el propósito de la imagen es puramente decorativo, ¿el texto alternativo es un valor vacío, como alt="" ? [S/N]
¿Describe el texto alternativo la imagen de una manera que comunique un significado comparable a los usuarios que no pueden ver la imagen? [S/N]
Si la imagen aparece como la única etiqueta de un control, por ejemplo un enlace o botón, ¿es posible entender qué hace el control únicamente a partir del texto alternativo? [S/N]
¿Es el texto alternativo original/útil y no simplemente una repetición del texto adyacente del cuerpo? [S/N]
¿Coincide el idioma utilizado para el texto alternativo con el idioma declarado para el resto del documento? [S/N]
Si la imagen es el logotipo de una marca y no es funcional, ¿simplemente indica el nombre de la marca? [S/N]
Si la imagen es, por ejemplo, un icono de Diageo, ¿utiliza el texto asociado a ese icono según lo descrito en el sistema de diseño? [S/N]
¿La página web tiene exactamente una región identificada con el landmark main? [Y/N]
A continuación hay un ejemplo de una pregunta clave que debe hacerse:
¿El comprobador de contraste automatizado indica que no hay errores de contraste? [S/N]
¿Las áreas de la página web que están destinadas principalmente a mostrar enlaces de navegación están identificadas usando el landmark nav? [Y/N]
A continuación hay un par de ejemplos de preguntas clave que debe formular:
Con la emulación de visión borrosa habilitada, ¿es posible leer fácilmente el texto que se superpone a imágenes o degradados? [S/N] Nota: busque la opinión de al menos 2 personas más relacionadas con este proyecto
Emulación de visión borrosa
El contraste suficiente es particularmente importante cuando los usuarios pueden estar experimentando su web con visión borrosa, con un deslumbramiento intenso o cuando están distraídos. Habilitar la emulación de visión borrosa es una forma fantástica de comprobar que el texto es lo suficientemente legible.
En el navegador Chrome, esta emulación está disponible siguiendo los pasos a continuación:
Escriba las teclas: command + shift + p y luego escriba (enter) el texto "render" para ver todas las opciones de representación disponibles
Desplácese hasta el menú desplegable "Emulate vision deficiencies"
Luego seleccione la opción "Blurred vision"
Para comprobar el contraste y la legibilidad para usuarios que puedan tener deficiencias en la percepción del color, elija la opción "Achromatopsia" (eliminación de todo color).
Información adicional
Deshabilitar las imágenes (también una opción a través de la extensión Web Developer del navegador) es una forma efectiva de garantizar que el texto diseñado para aparecer sobre una imagen siga siendo legible si esa imagen no llegara a mostrarse. Establecer un color de fondo de reserva en dichos elementos con imágenes de fondo es importante para manejar esos casos.
14. Uso de Windows Narrator
Narrator es un lector de pantalla que está integrado en todos los sistemas operativos Windows. Esta guía está diseñada para ayudar a desarrolladores y evaluadores que son nuevos en Narrator a aprender los controles básicos para probar sus páginas web.
Actualmente Narrator funciona mejor con el navegador MS Edge, pero también tiene soporte para Chrome y Firefox.
Comenzando
Para iniciar o detener Narrator, presione la tecla Windows + Ctrl + Enter. Esto abrirá una ventana con opciones para obtener más información sobre Narrator y configurar sus ajustes. Si es nuevo en Narrator, vea este video para un breve tutorial introductorio.
Cosas útiles para recordar:
Presione la tecla Windows + Ctrl + N para acceder a la configuración. Aquí puede modificar la voz, el volumen relativo y la velocidad.
Tanto la tecla Bloq Mayús como la tecla Insert pueden usarse como la tecla "modificadora" de Narrator utilizada en muchos comandos—la llamaremos la tecla Narrator.
Ctrl + Inicio: lo llevará al principio de la página
Ctrl + R: actualizará la página (útil si está perdido o si Narrator no se comporta como se espera)
Para una lista completa de atajos de Narrator https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
Escuchar contenido web
Hay múltiples formas de usar Narrator para acceder al contenido web. Estas son las teclas más útiles:
Ctrl + ↑/↓: Leer línea anterior/siguiente
↑/↓: Leer párrafo o elemento anterior/Siguiente
Narrator + Tab: Volver a leer el elemento actual
Narrator + +/-: Aumentar/disminuir la velocidad de voz
Ctrl: Detener la lectura
Quizá desee practicar leyendo algunas páginas diferentes antes de comenzar las pruebas.
Probar la navegación de la página
La mayoría de los usuarios con vista examinarán y tomarán una instantánea visual de una página web para hacerse una idea de dónde está todo, pero si no puede hacer eso, entonces el contenido de la página en términos de encabezados, imágenes, elementos de formulario, mensajes, etc., es desconocido. Si una página web está bien estructurada y ha seguido las Guías de Accesibilidad de Colt, un usuario debería poder navegar por la página usando los Encabezados, Puntos de referencia, Enlaces o Listas, etc.
Hay varios atajos de una sola tecla para navegar rápidamente por elementos comunes de la página. Compruebe que estos funcionen y pueda acceder con éxito a cada tipo de elemento.
Estos incluyen:
H: Encabezados
1 - 6: Encabezado 1, encabezado 2, etc.
D: Puntos de referencia
Tab: Enlaces y controles de formulario
F: Controles de formulario
B: Botones
K: Enlaces
L: Listas
I: Elementos de una lista
T: Tablas
Shift + Cualquier tecla de navegación invierte la acción.
Abra el cuadro de diálogo Buscar y pruebe a buscar diferentes elementos
Narrator + Ctrl + F : Abrir el cuadro de diálogo Buscar
Narrator + F3: Moverse por los resultados de Buscar de Narrator (agregue Shift para ir hacia atrás)
Guía de accesibilidad de navegación
Probar formularios
Cuando un control de formulario recibe el foco del teclado, Narrator lee la etiqueta (si la hay) y luego anuncia el tipo de control de formulario. Si un grupo de controles de formulario —típicamente grupos de casillas de verificación o botones de opción— está contenido en un fieldset con una leyenda, Narrator presenta los elementos del fieldset como un grupo y lee la leyenda cuando primero navega a cualquier cosa dentro del grupo.
Use los siguientes controles de teclado del navegador para interactuar con los controles de formulario y probar si se puede navegar hacia ellos, y si sus etiquetas son tanto únicas como descriptivas.
Tab y Shift + Tab: Navegar por los controles de formulario
Espacio para seleccionar y deseleccionar casillas de verificación
↑/↓: Seleccionar de un grupo de botones de opción
Espacio, luego ↑/↓ o la primera letra de una opción: Expandir y luego seleccionar una opción en un cuadro combinado
Enter: Enviar un formulario
Guía de accesibilidad de formularios
Probar imágenes
Las imágenes pueden ser funcionales, de contenido o decorativas. Los Gráficos de Stream son mayormente estéticos y, por lo tanto, se clasificarían como decorativos. Esto significaría que deberían ser silenciosos para los lectores de pantalla. Si no se define un texto alternativo, Narrator normalmente dirá "imagen" o "gráfico sin etiqueta" (la mayoría de los otros lectores de pantalla ignoran esto). El texto alternativo de una imagen funcional o de contenido será leído por Narrator y debe describir el propósito del uso de la imagen.
Ejemplos:
Logotipos de Colt deberían simplemente decir el nombre de la marca, "Colt Technology Services"
Logotipos co-marcados deberían decir ambos nombres de marca, "Colt Technology Services en asociación con Cisco"
Iconos de Colt o Visuales ESG, deberían simplemente indicar el propósito de lo que representa la imagen.
Las imágenes que son enlaces, si el logotipo de Colt también es un enlace a la página principal, deberían incluir tanto el nombre de la marca como el destino, "Página principal de Colt".
Guía de accesibilidad de imágenes
Probar tablas de datos
Para navegar a la siguiente tabla en una página, presione la tecla T. Para navegar dentro de una tabla de datos, mantenga presionadas Ctrl + Alt y use ↑/↓/←/→ para moverse de celda en celda. Si una tabla tiene encabezados de fila y columna adecuados, se leerán automáticamente mientras navega.
Asegúrese de que las filas y columnas tengan etiquetas significativas.
Para una lista completa de atajos de Narrator: https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. Descargas
Para facilitar a los desarrolladores las pruebas de posibles problemas de accesibilidad, hemos creado una Lista de verificación manual de accesibilidad para estructurar sus pruebas.
Última actualización
¿Te fue útil?