DocoMatic

Traducción automática, pendiente de revisión profesional. Leer el original en inglés.

Documentos accesibles

Los formularios rellenables, sus documentos más difíciles

Un formulario es una interfaz, no una página: cada campo necesita una etiqueta real, un orden de tabulación sensato e instrucciones en el lugar correcto. Por qué los formularios van a nuestro nivel más alto de remediación, y cómo probar uno.

Rakesh PatelDirector ejecutivo y fundador

4 min de lectura

Three overlapping forms with a dotted path weaving through fields, one field highlighted in orange mid-route

La mayoría de los documentos de un sitio web público se leen. Los formularios se usan, y esa diferencia es todo el problema. Un residente que no puede terminar una solicitud de permiso no ha sufrido una molestia; ha quedado fuera de un servicio del gobierno. Los formularios son la razón por la que existe nuestro nivel más alto de remediación, y esta publicación explica qué los convierte en los documentos más difíciles que usted publica.

¿Por qué los formularios son los documentos más difíciles que usted publica?

Porque un formulario es una interfaz, no una página. Un informe necesita un orden de lectura correcto; un formulario necesita etiquetas, foco, estado, agrupación, instrucciones y recuperación de errores: el conjunto completo de requisitos interactivos que WCAG 2.1 aplica a cualquier cosa que una persona opera en lugar de leer. La mayoría de los formularios PDF se dibujaron primero como diseños visuales, así que nada de esa estructura existe, y toda tiene que añadirse deliberadamente.

Lo que está en juego también es mayor. Bajo la regla de Title II del Departamento de Justicia, un formulario en uso activo es contenido plenamente cubierto: las excepciones para documentos viejos dejan de aplicar explícitamente en el momento en que un documento se usa actualmente para solicitar un servicio o acceder a él (hoja informativa de ADA.gov). Sus formularios más viejos suelen ser sus documentos más cubiertos.

¿Qué necesita cada campo de formulario accesible?

Cuatro cosas, y ninguna de ellas parecerá faltar en un vistazo al diseño. Primero, una etiqueta programática y una descripción emergente que lleven la pregunta real: un usuario de lector de pantalla que tabula hasta un campo escucha su descripción emergente, así que un campo etiquetado "Text1" en lugar de "Fecha de nacimiento (MM/DD/AAAA)" es un callejón sin salida. Segundo, un orden de tabulación que siga el flujo visual: un formulario de dos columnas que tabula hacia abajo en orden de creación hace que los usuarios de teclado reboten de una sección a otra. Tercero, agrupación programática: cinco botones de opción solo son "Sí/No para la pregunta 7" si están agrupados; si no, cada uno se anuncia como huérfano. Cuarto, instrucciones en el lugar correcto: requisitos e indicaciones de formato etiquetados para encontrarse antes de los campos que rigen, no descubrirse después de un envío fallido.

Un ejemplo concreto: las casillas de "tipo de obra" de una solicitud de permiso de construcción. Visualmente, el encabezado que está encima lo explica todo. Programáticamente, a menos que esa relación se construya, un lector de pantalla anuncia "casilla, sin marcar" siete veces seguidas sin ninguna pista de qué significa cada una.

Otro, del formulario más común de cualquier sitio público: la solicitud de registros. Suele tener un cuadro de descripción de texto libre con sus instrucciones ("describa los registros, incluidos los rangos de fechas") impresas encima como texto ordinario del diseño. Si esas instrucciones no están vinculadas al campo, un usuario de lector de pantalla cae en un cuadro de texto sin etiqueta del tamaño de un párrafo y tiene que adivinar qué va ahí, justo en el formulario diseñado para garantizar el acceso público.

¿Por qué los formularios van al Nivel 3?

Porque "casi bien" sigue dejando gente fuera. En una página de texto, una etiqueta imperfecta degrada la experiencia; en un formulario, un campo sin etiqueta o una secuencia de tabulación rota puede hacer imposible completar todo el documento. La automatización hace la preparación estructural —construir el árbol de etiquetas, detectar los campos— y luego un revisor humano etiqueta, ordena y recorre cada formulario antes de que se verifique. Eso es lo que paga el nivel L3 de 30 créditos, y por eso el umbral L3 incluye una revisión puntual humana obligatoria en lugar de solo puntuaciones de máquina.

A form skeleton with checkboxes, radio buttons and text fields connected by a dotted tab-order path ending at an orange submit button
Tab order must connect every labeled field before the form is usable

¿Debería remediar el PDF o reconstruirlo como formulario web?

Depende del uso. Si un formulario se completa más de unas pocas veces al mes, un formulario HTML bien construido suele ser la mejor respuesta: más fácil de mantener accesible, apto para móviles y valida la entrada en el origen. Remedie el PDF cuando el formulario se use poco, tenga un formato fijado por ley o deba seguir siendo imprimible y firmable tal cual. Un híbrido —formulario web al frente, PDF accesible como registro— a menudo satisface tanto a los residentes como a la oficina de registros.

¿Cómo se prueba un formulario remediado?

Complételo. Solo con teclado, desde la primera instrucción hasta el envío; luego otra vez con un lector de pantalla, escuchando qué anuncia cada campo. Los verificadores automatizados comprueban que las etiquetas existen; solo un recorrido humano comprueba que las etiquetas tienen sentido, que el orden permite llegar al final y que un mensaje de error no deja al usuario varado al pie de la página. Si tiene cientos de formularios, pruebe una muestra de esta manera y pronto sabrá de qué generación de plantillas desconfiar.

Los formularios son donde la accesibilidad de documentos deja de ser una abstracción. Hágalos bien primero: son los documentos que los residentes no pueden rodear.

Temasformspdfwcagremediation

Sobre el autor

Rakesh PatelDirector ejecutivo y fundador

Rakesh Patel es el fundador y director ejecutivo de DocoMatic y el fundador de Space-O Technologies (2010), la empresa de ingeniería que la respalda. Aporta 32 años de experiencia de liderazgo en estrategia de negocios, operaciones y TI, y ha supervisado la entrega de más de 3,000 proyectos de software. DocoMatic aplica esa experiencia de entrega a un problema concreto: hacer accesibles los documentos públicos, de forma verificable.

Todos los artículos de Rakesh Patel

Las guías mantenidas sobre este tema

Esta publicación es una opinión fechada y se queda tal como se escribió. La guía se revisa cuando cambian los hechos.

Publicaciones relacionadas