Accesibilidad básica para interfaces web

Una interfaz accesible no es una versión especial para algunas personas. Es una interfaz mejor construida para todas. Cuando una página se puede recorrer con teclado, cuando los formularios tienen etiquetas claras, cuando los mensajes de error se entienden y cuando el contraste permite leer sin esfuerzo, la experiencia mejora para más usuarios, más dispositivos y más situaciones reales.

En desarrollo web, la accesibilidad suele aparecer tarde, como una revisión final. Ese es uno de los errores más comunes. Si esperamos al final, corregir puede ser más costoso. Si la incorporamos desde el primer HTML, se vuelve parte natural del criterio de programación.

En el capítulo anterior hablamos del flujo: pasar del usuario a la tarea. Hoy vamos a revisar una base práctica para que ese flujo pueda ser usado por más personas. No veremos toda la norma WCAG en profundidad, pero sí aprenderemos decisiones concretas que puedes aplicar en tus primeras interfaces.

Qué aprenderás hoy

• Entender accesibilidad como una responsabilidad de diseño y desarrollo.
• Usar HTML semántico para dar estructura real a la interfaz.
• Probar una pantalla con teclado y foco visible.
• Escribir textos alternativos útiles para imágenes.
• Crear formularios con etiquetas, ayudas y errores comprensibles.

Por qué importa

La accesibilidad web busca que las personas puedan percibir, operar, comprender y usar una interfaz, incluso cuando sus condiciones, dispositivos o capacidades son distintas. Esto incluye personas con discapacidad visual, auditiva, motriz o cognitiva, pero también usuarios con pantallas pequeñas, mala conexión, cansancio, lesiones temporales o ambientes con poca luz.

W3C/WAI organiza sus guías WCAG alrededor de cuatro principios: perceptible, operable, comprensible y robusto. Para un estudiante de Desarrollo de Interfaces, esos principios pueden traducirse en preguntas simples: ¿se puede leer?, ¿se puede usar con teclado?, ¿se entiende lo que ocurre?, ¿el código está construido de forma que otras tecnologías puedan interpretarlo?

La accesibilidad también es una forma de calidad. Un enlace que parece botón pero no se comporta como enlace confunde. Un botón sin foco visible excluye a quien navega con teclado. Un formulario sin etiquetas complica la tarea incluso para quien ve perfectamente la pantalla. Lo accesible suele ser más claro, más mantenible y más profesional.

HTML semántico: la primera capa

Antes de pensar en ARIA, JavaScript o librerías, revisa si tu HTML describe correctamente la página. Las etiquetas semánticas no son decoración: comunican estructura. Un lector de pantalla, un navegador, un buscador y otro desarrollador pueden entender mejor una interfaz cuando usas elementos correctos.

<header>
  <h1>Cursos disponibles</h1>
</header>

<main>
  <section aria-labelledby="featured-title">
    <h2 id="featured-title">Curso destacado</h2>
    <article>
      <h3>JavaScript para interfaces</h3>
      <p>Aprende eventos, formularios y validaciones básicas.</p>
      <a href="/cursos/javascript-interfaces">Ver detalles del curso</a>
    </article>
  </section>
</main>

Este ejemplo tiene una jerarquía clara: encabezado, contenido principal, sección, artículo, títulos y enlace. No necesitamos llenar todo de div. Cuando el HTML ya comunica estructura, CSS y JavaScript trabajan sobre una base más sólida.

Ejemplo básico: una tarjeta poco accesible

Veamos una tarjeta común. Visualmente podría parecer aceptable, pero tiene problemas importantes.

<div class="card" onclick="openCourse()">
  <img src="curso.jpg">
  <div class="title">JavaScript</div>
  <div class="button">Entrar</div>
</div>

Hay varios detalles: el contenedor no es naturalmente interactivo, la imagen no tiene texto alternativo, el título no usa una etiqueta de encabezado y el falso botón no se puede activar correctamente con teclado. Además, si JavaScript falla, la interacción puede quedar rota.

Ejemplo mejorado: estructura y navegación real

Una versión más accesible usa elementos nativos. El navegador ya sabe cómo manejar enlaces y botones: foco, teclado, activación y semántica vienen incluidos.

<article class="course-card">
  <img
    src="curso-javascript.jpg"
    alt="Estudiante practicando JavaScript en una laptop">

  <h2>JavaScript para interfaces</h2>
  <p>Aprende a responder a eventos, validar formularios y mejorar la experiencia del usuario.</p>

  <a class="button-link" href="/cursos/javascript-interfaces">
    Ver detalles del curso
  </a>
</article>

La diferencia no es solo estética. El enlace se puede alcanzar con teclado. El texto alternativo explica la imagen cuando la imagen aporta contexto. El título permite comprender la tarjeta como una unidad de contenido.

Foco visible y teclado

Una prueba básica: desconecta el mouse mentalmente y usa la tecla Tab. ¿Puedes llegar a todos los controles? ¿El orden tiene sentido? ¿Se ve dónde estás? Si la respuesta es no, el flujo está fallando.

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  outline: 3px solid #ff4f4f;
  outline-offset: 3px;
}

No elimines el foco con outline: none sin ofrecer una alternativa clara. WCAG 2.2 presta atención al foco visible porque muchas personas dependen de él para navegar. Un buen foco no arruina el diseño; lo hace operable.

Contraste y lectura

El contraste no se trata solo de cumplir una cifra. Se trata de lectura real. Texto gris muy claro sobre fondo blanco, botones con letras pequeñas o enlaces que solo se distinguen por color pueden producir fricción. En interfaces educativas, esa fricción se acumula rápido.

:root {
  --color-text: #26394d;
  --color-muted: #5f6b7a;
  --color-accent: #ff4f4f;
  --color-background: #ffffff;
}

.course-card {
  color: var(--color-text);
  background: var(--color-background);
}

.course-card .description {
  color: var(--color-muted);
}

.button-link {
  color: #ffffff;
  background: var(--color-accent);
}

Una recomendación práctica: no evalúes el contraste solo mirando tu monitor. Usa herramientas de contraste y revisa también en móvil. Un diseño que parece cómodo en una pantalla grande puede perder claridad en un teléfono con brillo bajo.

Formularios accesibles

Los formularios son una de las zonas donde más se nota la accesibilidad. Cada campo necesita una etiqueta real. El placeholder no reemplaza al label, porque desaparece al escribir y muchas veces se interpreta como ejemplo, no como instrucción.

<form class="contact-form" novalidate>
  <div class="field">
    <label for="email">Correo electrónico</label>
    <p id="email-help">Usaremos este correo para responder tu consulta.</p>
    <input
      id="email"
      name="email"
      type="email"
      autocomplete="email"
      aria-describedby="email-help email-error"
      required>
    <p id="email-error" class="field-error" aria-live="polite"></p>
  </div>

  <button type="submit">Enviar consulta</button>
</form>

La ayuda está conectada con el campo mediante aria-describedby. El mensaje de error tiene un lugar estable. El botón dice qué hará. Todo esto reduce dudas y ayuda a tecnologías de asistencia.

const form = document.querySelector('.contact-form');
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');

form.addEventListener('submit', function (event) {
  event.preventDefault();
  error.textContent = '';

  if (!email.validity.valid) {
    error.textContent = 'Escribe un correo válido para poder responderte.';
    email.focus();
    return;
  }

  form.reset();
  error.textContent = 'Consulta enviada correctamente.';
});

Este ejemplo mantiene una lógica simple: si hay error, lo comunica y devuelve el foco al campo. Si todo está bien, confirma la acción. La accesibilidad no elimina la validación; la vuelve más comprensible.

Buenas prácticas para empezar

• Usa HTML semántico antes de agregar ARIA.
• No elimines el foco visible.
• Comprueba navegación con teclado.
• Escribe textos alternativos según la función de la imagen.
• No uses color como única forma de comunicar estado.
• Conecta etiquetas, ayudas y errores con sus campos.
• Prueba la interfaz en móvil y con zoom.

Reto práctico

Conclusión

La accesibilidad básica no es una lista interminable de requisitos imposibles. Es una forma de programar con más cuidado. Cuando usas etiquetas correctas, respetas el teclado, cuidas el contraste y escribes mensajes claros, tu interfaz se vuelve más humana y más robusta.

Para estudiantes de desarrollo, esta es una ventaja enorme: aprender accesibilidad temprano evita malos hábitos. En el siguiente capítulo seguiremos profundizando esta base con HTML semántico como estructura central de una buena interfaz.

Fuentes consultadas

• W3C WAI: How to Meet WCAG 2.2
• W3C WAI: Introduction to Web Accessibility
• MDN Web Docs: elemento img y atributo alt
• MDN Web Docs: Keyboard accessible
• MDN Web Docs: aria-describedby