Accesibilidad Web (WCAG)

Una reserva que cualquiera pueda completar

Trabajarás con un sitio ficticio de reservas para una biblioteca. La tarea es elegir una sala, indicar una fecha y recibir una confirmación. Parece un recorrido pequeño, pero concentra problemas frecuentes: imágenes que comunican información, botones, calendario, formulario, validación y mensajes de estado. El objetivo del curso es aprender a encontrar barreras en ese recorrido y corregirlas con pruebas que otra persona pueda repetir.

Empieza definiendo qué significa completar la reserva: localizar la sala, conocer su capacidad, seleccionar una fecha disponible, corregir un dato equivocado y reconocer el resultado del envío. Esta descripción evita confundir una auditoría con una colección de advertencias técnicas. Un botón puede tener buen contraste y, aun así, no responder al teclado. Un formulario puede usar etiquetas correctas y, aun así, perder los datos cuando aparece un error. Evaluarás la tarea completa, además de sus controles aislados.

En los fundamentos construirás un mapa de barreras y consecuencias. Usarás los cuatro principios de accesibilidad para ordenar observaciones, sin tratar sus nombres como sustitutos de una comprobación. Un texto alternativo se revisa preguntando qué información necesita la persona; un control se revisa preguntando si puede encontrarlo y accionarlo. También separarás las comprobaciones automáticas de las que requieren recorrer la interfaz: una herramienta ayuda a encontrar ciertos problemas, pero su resultado no certifica por sí solo la experiencia.

En HTML semántico y ARIA revisarás la elección de elementos, los nombres de controles y los estados dinámicos. Primero buscarás una solución con elementos nativos. Después estudiarás cuándo un componente personalizado necesita comunicar información adicional. Cada atributo debe corresponder a un comportamiento real: declarar un cuadro de diálogo no crea su gestión del foco, y anunciar un botón deshabilitado no impide automáticamente que su código ejecute una acción.

La parte de teclado, formularios y errores convierte esas decisiones en pruebas de uso. Registrarás el orden del foco, la visibilidad de la selección y el regreso a la tarea después de un error. Trabajarás con mensajes concretos: qué dato falló, cómo corregirlo y qué información sigue conservada. Las prácticas usan datos inventados y un entorno de prueba; no necesitas recopilar información personal de estudiantes ni publicar sus dificultades.

En medición y mejora prepararás un inventario pequeño y priorizado. Una incidencia tendrá pasos de reproducción, comportamiento observado, resultado esperado y evidencia después de la corrección. Distinguirás una mejora cerrada de una pendiente y evitarás prometer una conformidad completa a partir de unas pocas pantallas. Los planes de siete y treinta días sirven para asignar responsables y repetir pruebas, no para afirmar que todos los problemas desaparecen en ese plazo.

El trabajo final será una reserva accesible acompañada de un informe de cinco incidencias. Entregarás una versión inicial, una versión corregida y un registro que muestre qué cambió. Comprueba el recorrido sin ratón, con aumento de texto y con tecnología de asistencia disponible. Si una comprobación no pudo realizarse, márcala como pendiente. El resultado útil es una interfaz mejor y evidencia clara de sus límites.