Caso práctico, ejercicios y lista de comprobación

Es hora de juntar todo lo aprendido. Primero resolverás con nosotros un caso realista paso a paso; después pondrás a prueba tu criterio con seis ejercicios y terminarás con una lista de comprobación que podrás usar en cualquier formulario que desarrolles o revises.

Caso práctico: la solicitud de ayuda para material escolar

Un ayuntamiento ficticio publica en su sede electrónica la «Solicitud de ayuda para material escolar». Es un proceso de tres pasos: datos del solicitante, documentación y revisión y envío. Las quejas recibidas a través del mecanismo de comunicación que exige el RD 1112/2018 (PDF, se abre en una ventana nueva) hablan de «no puedo terminar la solicitud» y «me echa a mitad». El equipo de desarrollo te pide revisarlo y proponer correcciones. Este es el proceso que sigues.

Paso 1. Recorrer el proceso con teclado y lector de pantalla

Antes de abrir el código, completas el trámite solo con teclado y después con NVDA, anotando cada barrera. Encuentras: campos de nombre, apellidos y DNI etiquetados solo con placeholder; la pregunta «¿Actúas en representación de otra persona?» con dos botones de opción sin fieldset; un desplegable de «Centro educativo» hecho con <div> que no se abre con teclado; una zona para arrastrar el empadronamiento sin botón; un CAPTCHA de texto distorsionado antes de enviar, y una sesión que caduca a los 10 minutos sin aviso.

Paso 2. Etiquetas, grupos y nombres

Sustituyes los placeholder por <label for> visibles, agrupas la pregunta de representación con <fieldset> y <legend> y asocias la ayuda del DNI («8 cifras y una letra») con aria-describedby. En el panel Accessibility descubres además que el botón visible «Enviar solicitud» tiene aria-label="Submit": lo eliminas para cumplir 2.5.3 Etiqueta en el nombre.

Paso 3. Errores y conservación de datos

Al enviar con errores, la página se recargaba, marcaba los campos solo en rojo y vaciaba el archivo adjunto. Ahora el servidor devuelve el formulario con los valores conservados (3.3.7), un resumen de errores enlazado que recibe el foco, mensajes en texto junto a cada campo vinculados con aria-describedby, aria-invalid="true" en los campos afectados y el número de errores en el <title>.

<title>2 errores – Paso 1 de 3: Datos del solicitante – Ayuda escolar</title>

Paso 4. autocomplete y entrada redundante

Añades autocomplete a nombre (given-name), apellidos (family-name), correo (email), teléfono (tel) y dirección (street-address, postal-code, address-level2). El DNI no tiene valor en la lista, así que solo lleva inputmode adecuado y su ayuda. En el paso 3 se volvía a pedir el correo «para enviar el justificante»: lo sustituyes por el correo ya introducido, mostrado y editable.

Paso 5. Controles especiales y visuales

El desplegable de centros pasa a ser un <select> nativo agrupado por localidad con <optgroup>. La zona de arrastre conserva el arrastre, pero ahora contiene un <input type="file"> con su etiqueta, la ayuda «PDF, JPG o PNG. Máximo 10 MB» y una lista de adjuntos con botones «Eliminar» que nombran el archivo. Los bordes de los campos pasan de #DDDDDD a #767676 y se recupera el outline de foco que eliminaba la hoja de estilos.

Paso 6. CAPTCHA, tiempo y verificación

El CAPTCHA no forma parte de la autenticación (la persona ya entró con Cl@ve), así que 3.3.8 no se aplica, pero sigue siendo una barrera bajo 1.1.1. Como el acceso ya está autenticado, el equipo lo retira y refuerza la protección en el servidor con límites de frecuencia. Para la sesión, se añade un aviso con role="alertdialog" dos minutos antes de caducar, con un botón para ampliarla, y el guardado automático de borradores. Por último, repites el recorrido completo con teclado, NVDA, zoom al 400 % y colores forzados, y documentas cada corrección con capturas de antes y después.

Ejercicios de autoevaluación

1. Un campo tiene <label for="tel">Teléfono</label> y, además, aria-label="Móvil de contacto". ¿Qué nombre anuncia el lector y qué criterio se incumple?

2. Escribe el marcado de «Fecha de nacimiento» con tres campos (día, mes y año).

<fieldset>
  <legend>Fecha de nacimiento</legend>
  <label for="nac-d">Día</label>
  <input id="nac-d" inputmode="numeric" autocomplete="bday-day">
  <label for="nac-m">Mes</label>
  <input id="nac-m" inputmode="numeric" autocomplete="bday-month">
  <label for="nac-a">Año</label>
  <input id="nac-a" inputmode="numeric" autocomplete="bday-year">
</fieldset>

3. Reescribe este mensaje de error de un adjunto: «Archivo no válido».

4. La sesión de una sede caduca a los 15 minutos de inactividad y se pierden los datos. Propón una solución que cumpla 2.2.1 Tiempo ajustable.

5. Un desplegable «Provincia» lleva onchange="this.form.submit()". ¿Qué problema hay y cómo lo corriges?

6. Las casillas personalizadas de un formulario muestran el estado marcado solo con un fondo azul. En el modo de contraste de Windows, marcadas y vacías se ven iguales. ¿Por qué y cómo se arregla?

Lista de comprobación final

• Cada campo tiene un <label> visible asociado; ninguno depende del placeholder.
• Los grupos de opciones usan <fieldset> y <legend>.
• Formatos, límites y ayudas se ven antes del campo y están en aria-describedby.
• El nombre accesible contiene el texto visible (2.5.3); no hay aria-label innecesarios.
• Los errores están en texto, junto al campo, con aria-invalid y resumen enlazado.
• Tras un error se conservan todos los datos, incluidos los adjuntos.
• Los datos personales llevan un autocomplete válido (1.3.5).
• Ningún dato se pide dos veces en el proceso (3.3.7).
• El inicio de sesión permite pegar y usar gestores de contraseñas (3.3.8).
• No hay CAPTCHA de texto ni controles personalizados sin patrón APG (se abre en una ventana nueva).
• Bordes y estados tienen contraste de 3:1 y el foco siempre se ve.
• El formulario funciona a 400 % de zoom y en colores forzados.
• Cada paso indica dónde estás en el encabezado y en el <title>.
• Los límites de tiempo se avisan y se pueden ampliar (2.2.1).
• Cambiar un valor nunca envía ni navega sin aviso (3.2.2); hay revisión antes de enviar (3.3.4).

Para seguir aprendiendo

• Tutorial de formularios de la WAI (W3C): etiquetas, agrupación, instrucciones, validación y formularios en varias páginas.
• Lista de propósitos de entrada de WCAG 2.2: los valores que cuentan para 1.3.5.
• Documento de comprensión de 3.3.8 Autenticación accesible (mínimo).
• Documento de comprensión de 2.2.1 Tiempo ajustable.
• Patrones de la ARIA Authoring Practices Guide: combobox, switch, slider y date picker.