Lista de accesibilidad para formularios de contacto

Asegura que tus formularios de contacto sean usables por todos, incluidas las personas que usan tecnología de asistencia.

Por qué importa la accesibilidad

Requisitos legales

Muchas jurisdicciones exigen que los sitios sean accesibles:

• ADA (Americans with Disabilities Act)
• Cumplimiento WCAG 2.1 Nivel AA
• Section 508 (agencias federales EE. UU.)
• Ley Europea de Accesibilidad

Imperativo moral

Alrededor del 15 % de la población mundial tiene alguna forma de discapacidad. Un formulario de contacto inaccesible implica:

• Oportunidades de negocio perdidas
• Clientes potenciales excluidos
• Menor alcance
• Mala experiencia para muchas personas

Beneficios para el negocio

Formularioularios accesibles mejoran la UX para todos:

• Etiquetas claras ayudan a todos los usuarios
• Mejores mensajes de error reducen la frustración
• Navegación por teclado ayuda a usuarios avanzados
• Diseño móvil beneficia a todos los dispositivos

Requisitos básicos de accesibilidad

1. Etiquetas y campos del formulario

Requisito: Cada campo debe tener una etiqueta visible y asociada.

Bien:

<label for="name">Tu nombre:</label>
<input type="text" id="name" name="name" required>

Mal:

<!-- Sin etiqueta -->
<input type="text" name="name" placeholder="Tu nombre">

<!-- Etiqueta no asociada -->
<label>Tu nombre:</label>
<input type="text" name="name">

Por qué importa:

• Los lectores de pantalla anuncian la etiqueta
• Los usuarios saben qué introducir
• Al hacer clic en la etiqueta se enfoca el campo
• Propósito claro de cada campo

Cómo lo hace SupportRetriever:

• Todos los campos tienen etiquetas correctas
• Las etiquetas son visibles (no ocultas)
• Atributos id/for enlazados correctamente
• No hay campos solo con placeholder

2. Indicadores de campos obligatorios

Requisito: Marcar claramente campos obligatorios frente a opcionales.

Bien:

<label for="email">
  Correo electrónico <span aria-label="obligatorio">*</span>
</label>
<input type="email" id="email" name="email" required aria-required="true">

<label for="phone">
  Teléfono <span>(opcional)</span>
</label>
<input type="tel" id="phone" name="phone">

Mal:

<!-- Sin indicación de obligatorio -->
<label for="email">Correo</label>
<input type="email" id="email" name="email" required>

Por qué importa:

• Los usuarios saben qué es obligatorio
• Reduce el abandono del formulario
• Los lectores de pantalla anuncian requisitos
• Evita errores al enviar

Cómo lo hace SupportRetriever:

• Campos obligatorios marcados con asterisco
• Atributo aria-required="true"
• Campos opcionales etiquetados explícitamente
• Estilo consistente para obligatorios

3. Mensajes de error

Requisito: Los errores deben ser claros, específicos y asociados programáticamente a los campos.

Bien:

<label for="email">Correo electrónico</label>
<input 
  type="email" 
  id="email" 
  name="email" 
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" role="alert">
  Introduce una dirección de correo válida (p. ej. nombre@ejemplo.com)
</span>

Mal:

<!-- Error genérico al inicio del formulario -->
<div>Corrige los errores</div>

<!-- El campo se pone rojo pero sin explicación -->
<input type="email" style="border-color: red;">

Por qué importa:

• Los usuarios saben exactamente qué falla
• Los lectores de pantalla anuncian errores específicos
• Menos frustración
• Recuperación más rápida

Cómo lo hace SupportRetriever:

• Errores junto a los campos
• Mensajes de error específicos
• aria-invalid y aria-describedby
• Indicación visual y programática del error

4. Resumen de errores

Requisito: Ofrecer un resumen de todos los errores al enviar el formulario.

Bien:

<div role="alert" class="error-summary" tabindex="-1">
  <h2>Corrige los siguientes errores:</h2>
  <ul>
    <li><a href="#name">El nombre es obligatorio</a></li>
    <li><a href="#email">La dirección de correo no es válida</a></li>
  </ul>
</div>

Por qué importa:

• Vista general de todos los problemas
• Los lectores de pantalla anuncian el resumen
• Los enlaces saltan a los campos con error
• Reduce la carga cognitiva

5. Gestión del foco

Requisito: Orden de foco lógico e indicadores de foco visibles.

Bien:

/* Indicador de foco visible */
input:focus,
textarea:focus,
button:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Mal:

/* Quitar indicadores de foco */
*:focus {
  outline: none; /* Nunca hagas esto */
}

Por qué importa:

• Los usuarios de teclado ven dónde están
• El orden de tabulación es lógico
• No hay trampas de foco
• Retroalimentación visual clara

Cómo lo hace SupportRetriever:

• Indicadores de foco claros en todos los elementos interactivos
• Orden de tabulación lógico
• El foco va al resumen de errores si falla el envío
• No hay elementos enfocados invisibles

6. Navegación por teclado

Requisito: Toda la funcionalidad del formulario accesible solo con teclado.

Lista de comprobación:

• Se puede llegar a todos los campos con Tab
• Se puede enviar con Enter
• Se pueden activar botones con Espacio/Enter
• Se puede salir de todos los campos con Tab/Shift+Tab
• El orden de Tab coincide con el orden visual
• No hay trampas de teclado

Cómo lo hace SupportRetriever:

• Todos los elementos interactivos accesibles por teclado
• Comportamiento estándar del teclado
• Sin controles de teclado personalizados que rompan expectativas
• El orden de Tab sigue el diseño visual

7. Contraste de color

Requisito: Contraste suficiente entre texto y fondo.

Requisitos WCAG 2.1 Nivel AA:

• Texto normal: relación de contraste 4,5:1
• Texto grande (18 pt+): 3:1
• Elementos de interfaz: 3:1

Bien:

/* Contraste suficiente */
label { color: #333333; background: #ffffff; } /* 12.6:1 */
button { color: #ffffff; background: #0066cc; } /* 7.5:1 */

Mal:

/* Contraste insuficiente */
label { color: #cccccc; background: #ffffff; } /* 1.6:1 - falla */
button { color: var(--color-border-secondary)ddd; background: #ffffff; } /* 1.2:1 - falla */

Cómo lo hace SupportRetriever:

• Todo el texto cumple AA
• Los campos tienen límites claros
• Los mensajes de error tienen contraste suficiente
• Los indicadores de foco son claramente visibles

8. Tipos de campo

Requisito: Usar tipos de campo apropiados para mejor accesibilidad.

Bien:

<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input type="url">
<input type="number">

Por qué importa:

• Los teclados móviles se adaptan al tipo
• Validación del navegador
• El autocompletado funciona mejor
• Los lectores de pantalla dan contexto

Cómo lo hace SupportRetriever:

• Tipos correctos para correo, teléfono, URL
• Atributos autocomplete cuando aplica
• No se usan inputs de texto genéricos para datos específicos

Anti-spam que no bloquee a humanos

Qué NO hacer

Enfoques malos:

• ✗ CAPTCHAs difíciles (selección de imágenes, operaciones)
• ✗ CAPTCHAs de audio (a menudo incomprensibles)
• ✗ Límites de tiempo (castigan a usuarios lentos)
• ✗ Seguimiento del movimiento del ratón (excluye usuarios de teclado)
• ✗ Campos obligatorios innecesarios

Técnicas anti-spam accesibles

Enfoques buenos:

1. Cloudflare Turnstile

• Suele ser invisible
• No requiere interacción del usuario
• Respeta la accesibilidad
• Compatible con WCAG

2. Campos honeypot

<!-- Campo oculto que los bots rellenan pero los humanos no ven -->
<input 
  type="text" 
  name="website" 
  tabindex="-1" 
  autocomplete="off"
  aria-hidden="true"
  style="position: absolute; left: -9999px;"
>

• Invisible para humanos
• Fuera del orden de tabulación
• Sin impacto en usuarios legítimos

3. Límite de tasa

• Limitación en el servidor
• Sin impacto visible para el usuario
• Evita avalanchas automatizadas

4. Validación de correo

• Comprobación de formato
• Verificación de dominio
• Mensajes de error útiles

Cómo lo hace SupportRetriever:

• Cloudflare Turnstile (accesible)
• Límite de tasa en el servidor
• Validación de correo con errores claros
• Sin CAPTCHAs hostiles para el usuario

Cómo probar rápido

Prueba solo teclado (5 minutos)

Desconecta el ratón y:

1. Recorre todo el formulario con Tab
2. Rellena todos los campos solo con teclado
3. Envía el formulario con Enter
4. Navega a los mensajes de error si los hay
5. Completa un envío correcto

Si puedes hacer todo esto, la accesibilidad por teclado es buena.

Conceptos básicos de lector de pantalla (10 minutos)

macOS (VoiceOver):

1. Pulsa Cmd+F5 para activar VoiceOver
2. Navega el formulario con Tab
3. Escucha lo que se anuncia
4. Prueba a enviar con errores
5. Escucha los mensajes de error

Windows (NVDA - gratuito):

1. Descarga NVDA en nvaccess.org
2. Inicia NVDA
3. Navega el formulario con Tab
4. Escucha las anunciaciones
5. Prueba el manejo de errores

Lo que deberías oír:

• Etiquetas de los campos
• Tipos de campo ("texto editable", "botón")
• Estado de obligatorio
• Mensajes de error
• Confirmaciones de éxito

Prueba de contraste (2 minutos)

Herramientas:

• WebAIM Contrast Checker
• Chrome DevTools (Lighthouse)
• Extensiones (WCAG Color Contrast Checker)

Comprobación rápida:

• Inspecciona elementos de texto
• Comprueba relaciones de contraste
• Mínimo 4,5:1 para texto
• Mínimo 3:1 para elementos de interfaz

Pruebas automatizadas (5 minutos)

DevTools del navegador:

1. Abre Chrome DevTools
2. Ve a la pestaña Lighthouse
3. Marca "Accessibility"
4. Ejecuta la auditoría
5. Revisa los problemas

Herramientas:

• WAVE Browser Extension
• axe DevTools
• Lighthouse (incluido en Chrome)

Nota: Las herramientas automatizadas detectan ~30–40 % de los problemas. Las pruebas manuales son esenciales.

Cómo ayuda SupportRetriever

Accesibilidad integrada

Los formularios de SupportRetriever incluyen:

✓ HTML semántico correcto

• Jerarquía de encabezados correcta
• Puntos de referencia del formulario
• Elementos de formulario semánticos

✓ Etiquetas ARIA

• Todos los campos etiquetados correctamente
• Campos obligatorios anunciados
• Estados de error comunicados

✓ Accesible por teclado

• Orden de tabulación lógico
• Indicadores de foco visibles
• Sin trampas de teclado

✓ Compatible con lectores de pantalla

• Etiquetas significativas
• Anunciación de errores
• Actualizaciones de estado

✓ Contraste de color

• Compatible con WCAG AA
• Límites visuales claros
• Estados de error claramente visibles

✓ Responsive y móvil

• Objetivos táctiles adecuados
• Soporte correcto de zoom
• Tipos de teclado móvil adecuados

✓ Anti-spam accesible

• Cloudflare Turnstile (compatible WCAG)
• Sin CAPTCHAs hostiles
• Sin límites de tiempo
• Sin patrones hostiles para el usuario

De qué no tienes que preocuparte

Al usar SupportRetriever:

• ✓ El marcado del formulario es correcto
• ✓ Los atributos ARIA son adecuados
• ✓ La gestión del foco funciona
• ✓ El manejo de errores es accesible
• ✓ La navegación por teclado funciona
• ✓ Los lectores de pantalla funcionan correctamente

Solo necesitas:

• Insertar el formulario
• Probar en tu contexto
• Asegurar que el contenido que lo rodea sea accesible

Lista rápida de accesibilidad

Antes del lanzamiento

• Todos los campos tienen etiquetas visibles
• Los campos obligatorios están marcados
• Los indicadores de foco son visibles
• El formulario es navegable por teclado
• El contraste cumple WCAG AA
• Los tipos de campo son apropiados
• Los mensajes de error son específicos y claros
• Aparece resumen de errores si falla el envío
• El mensaje de éxito se anuncia a lectores de pantalla
• Probado solo con teclado
• Probado con lector de pantalla
• Escaneo de accesibilidad automatizado pasado

Continuo

• Revisar feedback sobre accesibilidad
• Probar con usuarios reales de tecnología de asistencia
• Seguir las actualizaciones de WCAG
• Supervisar cambios en navegadores
• Probar en dispositivos móviles
• Verificar con lectores de pantalla recientes

Errores habituales a evitar

Etiquetas solo con placeholder

Mal:

<input type="text" placeholder="Introduce tu nombre">

Por qué: El placeholder desaparece al escribir y los lectores de pantalla no lo leen de forma consistente.

Bien:

<label for="name">Nombre:</label>
<input type="text" id="name" placeholder="p. ej. Juan García">

Etiquetas ocultas

Mal:

<label style="display:none;">Nombre</label>
<input type="text">

Por qué: Invisible para usuarios que ven, genera confusión.

Mensajes de error genéricos

Mal:

<div>El formulario tiene errores</div>

Bien:

<div role="alert">
  <h2>Corrige lo siguiente:</h2>
  <ul>
    <li><a href="#email">La dirección de correo es obligatoria</a></li>
  </ul>
</div>

Quitar indicadores de foco

Nunca hagas esto:

*:focus { outline: none; }

Alternativa:

*:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Recursos

Herramientas de prueba

• WAVE: Herramienta de evaluación de accesibilidad web
• axe DevTools: Pruebas de accesibilidad automatizadas
• Lighthouse: Incluido en Chrome
• NVDA: Lector de pantalla gratuito (Windows)
• VoiceOver: Incluido en macOS/iOS

Directrices

• WCAG 2.1: Web Content Accessibility Guidelines
• ARIA: Accessible Rich Internet Applications
• WebAIM: Web Accessibility In Mind

Aprendizaje

• Artículos WebAIM
• A11y Project
• Accesibilidad en MDN

Temas relacionados

• Entender la protección contra bots
• Reducir spam en formularios sin CAPTCHAs
• Experiencia móvil frente a escritorio
• Buenas prácticas de soporte al cliente