Programa ampliado · Actualización noviembre de 2026
Clase avanzada: fundamentos y aplicación real
Lee los conceptos, reproduce el ejemplo en un proyecto de prueba y después completa el laboratorio. Los fragmentos marcados como didácticos requieren adaptarse a las versiones y dependencias del proyecto.
Accesibilidad como propiedad funcional
Una interfaz accesible permite entender, navegar y operar el contenido mediante distintos medios, incluidos teclado, lector de pantalla, ampliación y alto contraste. Usa HTML semántico antes de agregar ARIA: <button> para acciones y <a href> para navegación. No conviertas un div en botón sin replicar soporte de teclado, foco y significado; es fácil introducir fallos que el navegador ya resuelve correctamente.
Contraste, jerarquía y tamaño táctil
WCAG 2.2 AA establece normalmente 4.5:1 para texto común y 3:1 para texto grande, con excepciones. Contraste suficiente no reemplaza una tipografía legible ni un interlineado adaptable. Evita depender exclusivamente del color para señalar errores. El zoom al 200 %, texto ampliado y el contenido estrecho permiten detectar pérdidas de información.
<label for="consulta">Buscar tutorial</label>
<input id="consulta" type="search" aria-describedby="ayuda">
<p id="ayuda">Puedes escribir un término como Kotlin o SEO.</p>
<button type="button">Buscar</button>
Recorrido práctico con teclado
Desconecta el mouse. Pulsa Tab desde el inicio de la página y verifica que el foco recorre enlaces, filtros y botones sin quedar atrapado. Abre el menú, cierra diálogos con Escape cuando corresponda y comprueba que el foco vuelve al elemento desencadenante. Un enlace «Saltar al contenido» evita pasar por el encabezado en cada navegación.
Formularios con errores comprensibles
Cada control necesita nombre visible, instrucciones y mensajes de error específicos. Explica cómo corregir un dato, no solo que «falló». Prueba un envío con formulario vacío y otro con contenido válido. Comprueba mensajes mediante lector de pantalla y evita anuncios repetitivos que interrumpan la tarea.
Laboratorio guiado con evidencia
Este laboratorio es un escenario propuesto, no una afirmación sobre el código o las métricas de las aplicaciones de AppInitDev. No utilices información personal ni credenciales reales durante la práctica.
Auditar una página usando solo teclado
- Recorre navegación, búsqueda y formularios sin tocar el ratón.
- Comprueba etiqueta visible para cada entrada y mensajes al enviar errores.
- Aumenta zoom y tamaño de texto; verifica lectura y controles visibles.
- Calcula contraste de combinaciones reales y registra excepciones aplicables.
Entrega esperada: Lista priorizada de barreras, capturas y criterios de corrección.
Comprueba lo que entendiste
¿Basta una puntuación automática alta?
No. También hacen falta pruebas manuales de interacción.
Autoevaluación: ¿Puedes explicar el objetivo, los datos de entrada y las condiciones de error sin copiar instrucciones? Si la respuesta es no, repite primero un caso mínimo. No confundas una herramienta que se ejecuta con una validación completa en producción.
Unidad ampliada · Subtemas y casos resueltos
Profundización temática: decisiones y criterios
Subtema 1. Auditoría de la lectura y el foco
Cuando una persona navega solo con teclado, un enlace que parece visible pero no recibe foco deja de ser operable. Recorre los componentes con Tab y Shift+Tab, anota el orden, comprueba que el foco nunca quede oculto por una barra fija y que cada control tenga nombre accesible. Ejecuta el mismo recorrido con 200 % de zoom: una tarjeta que solo funciona con ratón no está terminada. La inspección automática detecta errores, pero no determina si la secuencia de lectura tiene sentido. [1]
Subtema 2. Caso concreto explicado
Escenario de práctica: Un formulario de contacto con tres campos y un error de validación: al enviar vacío, el mensaje debe explicar cuál campo falla, sin depender solo del color.
El primer paso es describir el comportamiento esperado sin depender de una pantalla concreta. Después hay que preparar entradas controladas y registrar resultados observados. Si el resultado difiere, conviene distinguir un error de la explicación, una limitación del entorno y un defecto de implementación. El objetivo no es completar una casilla por intuición: es producir evidencia que otra persona pueda repetir. [2]
Subtema 3. Protocolo de comprobación y rúbrica
- Prepara un caso válido basado en el ejemplo y describe los prerrequisitos que necesita.
- Prueba una entrada vacía, ausente o inválida y escribe cómo debería responder el sistema.
- Repite en un segundo contexto relevante (otra pantalla, otro idioma, sin conexión o distinta versión), si corresponde a esta unidad.
- Conserva una tabla con entrada, resultado esperado, resultado observado y conclusión.
- Contrasta al menos una decisión con la documentación oficial y registra la fecha de consulta.
Subtema 4. Notas técnicas y errores que conviene evitar
Para profundizar: La primera fuente describe el mecanismo principal; la segunda amplía las condiciones o métodos de comprobación. No son certificaciones del ejemplo inventado: consulta las secciones relevantes de cada documento.
Referencias y citas de esta unidad
- W3C WAI. WCAG 2.2: referencia rápida. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.
- W3C WAI. Criterio de contraste mínimo. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.
Pregunta de reflexión: ¿qué evidencia demostraría que comprendiste este ejemplo?
Debes poder reproducir el caso, explicar el mecanismo, mostrar una prueba negativa y justificar una decisión con una fuente primaria. Si no es posible repetirlo, documenta qué información falta.
Registra tu progreso en este navegador
Esta sección almacena únicamente las casillas y tus notas mediante almacenamiento local del navegador. Puedes borrar los datos cuando quieras. No escribas contraseñas ni información confidencial.
Referencia primaria para ampliar
Consulta el alcance exacto de las APIs y políticas en su fuente oficial antes de aplicar un cambio en producción. Los ejemplos de esta página son educativos y no sustituyen una revisión de requisitos actuales.