8.4: Opiniones informales

Una revisión informal es un escaneo rápido de un sitio web para identificar problemas obvios de accesibilidad. Si bien estas revisiones no representan auditorías exhaustivas, son útiles para una variedad de propósitos.

Propósito de la revisión

A menudo se adjunta una revisión informal a una cotización para una auditoría formal de accesibilidad, proporcionando información introductoria a un cliente para darle una mejor idea de los tipos de problemas en su sitio web antes de comprometerse con la revisión formal. Una revisión informal puede ser útil para justificar una revisión formal.

Proceso de Revisión

Las revisiones informales a menudo ocurren como parte de una conversación, tal vez con un miembro de una organización que es responsable de administrar la imagen de una organización, o con un desarrollador que está planeando o revisando actividades de diseño. Estas revisiones a menudo implican un par de pruebas rápidas, como la prueba de navegación por teclas de tabulación, o pasar una página a través de un verificador de accesibilidad automatizado, o examinar rápidamente el código donde pueden estar presentes problemas sospechosos, o ejecutar una página a través de un lector de pantalla. Estas revisiones rápidas a menudo muestran una serie de barreras potenciales que ayudan a comenzar una discusión sobre los próximos pasos para hacer que el contenido web sea accesible.

Reportando los resultados de la revisión

El siguiente es un ejemplo de los tipos de temas que podrían documentarse en una revisión informal. Las características de una revisión informal podrían incluir (en este ejemplo):

1. Tipo de sitio: un sistema de registro con eCommerce integrado
2. Momento de revisión: previo a la puesta en marcha
3. Duración de la revisión: alrededor de 30 minutos
4. Público: el desarrollador de la Interfaz de Usuario (UI) creada a través de un sistema de comercio electrónico de terceros
5. Estilo de Reporte:
   1. Proporcionado por correo electrónico al desarrollador y al equipo directivo del desarrollador
   2. Breves y sucintos
   3. Escrito de una manera que el desarrollador entendería, ya estando familiarizado con la interfaz de usuario, y ya estando familiarizado con el lenguaje técnico que se está utilizando
   4. Algunos problemas relacionados con la falta de accesibilidad identificados como cortesía
   5. No demasiado detallado si la revisión pretende provocar una revisión formal

Ejemplo de revisión informal por correo electrónico

Hola John,

Aquí hay un breve resumen de los posibles problemas encontrados en su sitio de registro. Si lo desea, podemos concertar un tiempo para hablar sobre estos temas, y la posibilidad de realizar una revisión formal que aborde estos y otros temas potenciales con más detalle para garantizar que el mayor número de personas posible puedan acceder a su sitio y registrarse.

He identificado algunos problemas y he ofrecido sugerencias para posibles correcciones cuando corresponda:

• Asocie etiquetas con campos de formulario haciendo coincidir el atributo for en la etiqueta con el atributo id en el elemento de entrada.
• Agrega aria-required="true” a los campos de entrada requeridos.
• Utilice aria-describedby= "[id]” para asociar la descripción en los vanos ocultos con el campo de entrada respectivo.
• Las entradas Sí/No parecen casillas de verificación, pero funcionan como botones de radio. Quizá no sea un problema, sino inconsistente con lo que la mayoría de la gente podría esperar.
• Para los números de nota al pie junto a Price y Group, aria-describedby podría usarse para asociar la nota al pie con el número, o los números podrían vincularse a un ancla junto a la nota al pie de página asociada.
• Debido a que hay dos niveles de celdas de encabezado de tabla en la tabla de tickets, deben usar headers/id para asociar ambos niveles de encabezado, aunque en este caso este es un tema trivial dado el pequeño tamaño de la tabla.
• El botón de casilla de verificación al lado de la línea de tarjetas de crédito aceptadas es un poco confuso. Muestra un cursor de mano lo que sugiere que debe ser clicable, pero no lo es.
• Cuando se muestre un mensaje de error, incluya role="alert” en el div que contiene el mensaje.
• Cuando se produce un error, envíe el foco al primer campo que tenga un error.
• Fue posible enviar el formulario de pago sin que el correo electrónico del titular del boleto fuera válido.
• Al hacer clic en “volver al formulario” en la ventana emergente de la tarjeta de crédito se cuelga, aparentemente tratando de acceder a Google Analytics.
• En la ventana emergente de la tarjeta de crédito, el enfoque debe quedar atrapado en el diálogo en un bucle hasta que se presione Pagar ahora, Volver al formulario o la tecla Escape.
• En la ventana emergente de tarjeta de crédito, la casilla de verificación inicial y otros campos de formulario deben asociarse con las etiquetas respectivas usando el elemento Label (con coincidencia para/id).
• Para el mensaje de error que aparece en la ventana emergente de la tarjeta de crédito, agregue role="alert” al lapso que contiene el mensaje.
• La X de cierre debe tener el texto del título agregado, como title="close credit card details”.
• Después de enviar el formulario de la tarjeta de crédito, la pantalla se cuelga, nuevamente intentando acceder a Google Analytics.
• No se puede ver la salida después de hacer un envío de tarjeta de crédito, para determinar si hay algún problema en el paso final.
• Incapaz de ver cómo se emiten los boletos, quizás vía correo electrónico. No estoy seguro de si hay algún problema ahí.