La navegación por voz en webs ha dejado de ser una curiosidad de showcase para volverse una capa útil de accesibilidad y UX en 2026. No solo ayuda a personas con discapacidad: sirve a cualquiera en contextos donde no puede usar las manos (cocinando, conduciendo, entrenando). En esta guía práctica verás qué tecnologías hay, qué patrones de UX funcionan, un ejemplo de código para arrancar, cómo encaja con la accesibilidad y la European Accessibility Act, y los errores que conviene evitar.
Por qué la voz importa más en 2026
Convergen tres motores: los modelos de reconocimiento de voz han alcanzado una calidad casi humana, los asistentes (Siri, Alexa, Gemini) han entrenado al usuario a hablarle a los dispositivos, y la presión legal por accesibilidad va en aumento. Resultado: implementar navegación por voz es más fácil que nunca y el usuario la entiende sin necesidad de onboarding.
Dos tipos de navegación por voz (y la que sí te exige la ley)
Cuando se habla de navegación por voz en una web se mezclan dos cosas muy distintas. Conviene separarlas, porque solo una depende de lo que tú diseñas.
| Control por voz del sistema | Voz dentro de tu web | |
|---|---|---|
| Qué es | El usuario maneja todo el dispositivo hablando: «pulsa Buscar», «desplázate abajo», «muestra números» | Un botón de micrófono que tú programas, por ejemplo para buscar |
| Herramientas | Voice Control (iPhone y Mac), Voice Access (Android y Windows 11), Dragon | Web Speech API u otro servicio de reconocimiento |
| Quién lo usa | Personas con movilidad reducida, lesiones temporales o las manos ocupadas | Cualquiera que prefiera dictar a escribir |
| ¿Obligatorio? | Que tu web funcione con él, en la práctica sí (WCAG 2.1 AA) | No, es un extra |
La regla clave: la etiqueta visible tiene que estar en el nombre
Quien usa Voice Control o Voice Access dice en voz alta el texto que ve en pantalla. El sistema busca un elemento con ese nombre accesible. Si tu botón pone «Buscar» pero su aria-label dice «Enviar consulta», la orden puede no responder.
Eso es el criterio 2.5.3 Etiqueta en el nombre de WCAG, de nivel A. Entra en WCAG 2.1 AA y, por tanto, en lo que exige la European Accessibility Act.
<!-- Puede fallar: se ve «Buscar», pero se llama «Enviar consulta» -->
<button aria-label="Enviar consulta">Buscar</button>
<!-- Bien: sin aria-label, el nombre es el texto visible -->
<button>Buscar</button>
<!-- Bien: el nombre accesible empieza por el texto visible -->
<button aria-label="Buscar en la tienda">Buscar</button>
<!-- Botón solo con icono: dale un nombre corto y obvio -->
<button aria-label="Menú"><svg aria-hidden="true">…</svg></button>Checklist de diseño para el control por voz
- Botones y enlaces con texto visible siempre que puedas. Un icono suelto obliga al usuario a pedir números en pantalla.
- Si usas
aria-label, que empiece por el texto visible: «Buscar en la tienda» para un botón que pone «Buscar». - Nada de diez enlaces «Ver más» iguales. Cambia el texto («Ver más plantillas») para que cada orden apunte a uno solo.
- Todo lo que se abre al pasar el ratón tiene que abrirse también al pulsar. El control por voz hace clic, no pasa el ratón.
- Usa elementos nativos (
button,a,label). Undivcon evento de clic no tiene nombre ni rol. - Pruébalo tú: activa Voice Control en el iPhone o en el Mac (Ajustes, Accesibilidad) y recorre tu web sin tocarla.
Tecnologías disponibles
| Tecnología | Tipo | Cuándo usarla |
|---|---|---|
| Web Speech API | Nativa del navegador, gratis | Para empezar y casos básicos |
| OpenAI Whisper | Más precisa, requiere backend | Producción seria, multi-idioma |
| AssemblyAI / Deepgram | Servicios cloud | Cuando quieres precisión sin montar infraestructura |
| Soniox | Cloud, buen español y baja latencia | Proyectos en español que priorizan rapidez |
La regla práctica: empieza con la Web Speech API (gratis y sin backend) y, si el proyecto lo pide, pasa a Whisper o a un servicio cloud para más precisión e idiomas.
Código para añadir búsqueda y navegación por voz
Este ejemplo añade un botón «Buscar por voz» junto al buscador. Si dices «ir a contacto», «servicios» o «inicio», te lleva a esa página. Cualquier otra cosa la busca en la web. Funciona con el buscador estándar de WordPress.
El HTML
<form role="search" action="/" method="get">
<label for="voz-q">Buscar</label>
<input id="voz-q" type="search" name="s">
<button type="submit">Buscar</button>
<button type="button" id="voz-btn" aria-pressed="false" hidden>Buscar por voz</button>
<p id="voz-estado" aria-live="polite"></p>
</form>El JavaScript
const SR = window.SpeechRecognition || window.webkitSpeechRecognition;
const btn = document.getElementById('voz-btn');
const input = document.getElementById('voz-q');
const estado = document.getElementById('voz-estado');
// Lo que dice el usuario → página a la que va
const comandos = {
'inicio': '/',
'contacto': '/contacto/',
'servicios': '/servicios/'
};
if (SR) {
const rec = new SR();
rec.lang = document.documentElement.lang || 'es-ES';
rec.interimResults = false;
rec.maxAlternatives = 1;
btn.hidden = false;
btn.addEventListener('click', () => {
rec.start(); // el permiso del micrófono se pide aquí, no al cargar la página
btn.setAttribute('aria-pressed', 'true');
estado.textContent = 'Escuchando…';
});
rec.addEventListener('result', (e) => {
const texto = e.results[0][0].transcript.toLowerCase().replace(/[.,¿?¡!]/g, '').trim();
const pagina = Object.keys(comandos).find((c) => texto === c || texto === 'ir a ' + c);
if (pagina) {
window.location.href = comandos[pagina];
} else {
input.value = texto;
input.form.requestSubmit();
}
});
rec.addEventListener('error', (e) => {
estado.textContent = e.error === 'not-allowed'
? 'No tengo permiso para usar el micrófono. Escribe tu búsqueda.'
: 'No te he entendido. Prueba otra vez o escribe tu búsqueda.';
});
rec.addEventListener('end', () => {
btn.setAttribute('aria-pressed', 'false');
if (estado.textContent === 'Escuchando…') estado.textContent = '';
});
}Qué hace cada parte
- El botón empieza oculto y solo aparece si el navegador tiene la API. En Firefox no la verás, y el buscador normal sigue ahí.
- El permiso del micrófono se pide al pulsar el botón, nunca al cargar la página.
aria-pressedy la zonaaria-livele dicen a un lector de pantalla si la web está escuchando o si algo ha fallado.- Los errores tienen mensaje propio. Si el usuario deniega el micrófono, le invitas a escribir en vez de dejarle sin respuesta.
- El botón se llama «Buscar por voz» y eso es lo que pone. Cumple el 2.5.3 por diseño.
Un aviso de privacidad que casi nadie menciona: según la documentación de MDN, en navegadores como Chrome el audio se envía a un servicio externo para reconocerlo. Por eso no funciona sin conexión. Si usas este código, menciónalo en tu política de privacidad.
¿Te sirven los snippets? Mi pack gratis de 42 estilos CSS incluye un foco visible accesible, texto oculto para lectores de pantalla y la utilidad de «reducir movimiento». Todo listo para copiar. Descarga el pack CSS gratis.
Accesibilidad y European Accessibility Act
Aquí conviene ser preciso para no vender humo. La navegación por voz es una mejora complementaria, no un requisito de la ley ni un criterio WCAG que se «cumpla» sin más. Añade un mecanismo de entrada extra, lo que va en la línea del criterio 2.5.6 Concurrent Input Mechanisms (nivel AAA) y ayuda en situaciones de discapacidad temporal o situacional. Pero no sustituye al cumplimiento base.
Ojo con una confusión muy común. Añadir un botón de micrófono a tu web no es obligatorio. Lo que sí lo es, en la práctica, es que tu web se pueda manejar con el control por voz del sistema.
La EAA se apoya en la norma EN 301 549, que incorpora WCAG 2.1 AA. Ahí entran el 2.5.3 «Etiqueta en el nombre» y el 2.1.1 «Teclado», los dos de nivel A. El 2.5.6, que pide admitir varios métodos de entrada a la vez, es AAA y no es exigible.
El riesgo ya no es teórico. El 4 de junio de 2026, el tribunal judicial de Caen ordenó a Carrefour France hacer accesibles su web y su app. Le dio seis meses, bajo multa coercitiva. Carrefour alegaba un 71 % de conformidad y no le bastó. Lo cuenta Handicap.fr.
Traducción para ti: prioriza cumplir WCAG 2.1 AA (eso es lo que exige la ley) y ofrece la voz como valor añadido encima. Tienes el detalle en la guía de la European Accessibility Act para diseñadores.
¿Tienes una tienda online y no sabes si cumple? Revisar etiquetas, teclado y contraste forma parte de cualquier rediseño serio. Si prefieres que lo hagamos por ti, mira nuestros servicios de diseño web.
Dónde aporta más valor
No hay datos públicos fiables que demuestren que la búsqueda por voz convierta más. Si la añades a una tienda, mide cuánta gente la usa antes de prometer cifras a un cliente. Basta con un evento de GA4 al pulsar el botón.
Errores frecuentes y cómo evitarlos
- Pedir permisos demasiado pronto (al cargar la web). Pídelos solo cuando el usuario activa la función.
- No ofrecer alternativa para quien no tiene micrófono o no quiere activarlo. La voz siempre es un extra, no la única vía.
- Ignorar las variantes del idioma (español de España vs LATAM, acentos, jerga). Prueba con usuarios reales de perfiles distintos.
- Dar por hecho el soporte: en algunos navegadores no funciona (ver FAQ). Diseña con degradación elegante.
Preguntas frecuentes
¿La navegación por voz es solo para personas con discapacidad?
No. Beneficia también a quien tiene una limitación temporal (manos ocupadas, una lesión), a quien está en una situación concreta (móvil, conducción) y a quien simplemente prefiere hablar. Es accesibilidad universal en el sentido pleno.
¿Funciona en todos los navegadores?
No. El reconocimiento de la Web Speech API funciona en Chrome, Edge y Safari (con el prefijo webkitSpeechRecognition en macOS 14.1+ e iOS 14.5+). En Firefox está deshabilitado por defecto, así que en la práctica no cuentes con él. Por eso es imprescindible la degradación elegante: si no hay soporte, oculta el botón sin mostrar error.
¿Es un requisito de la European Accessibility Act?
Añadir búsqueda por voz, no. Que tu web funcione con Voice Control o Voice Access, en la práctica sí. Depende de criterios de nivel A, como el 2.5.3 y el 2.1.1, que forman parte de lo que exige la norma EN 301 549.
¿Cómo afecta al SEO?
De forma directa, en nada: Google no premia que tengas un botón de micrófono. De forma indirecta, lo que haces para el control por voz ayuda a todo lo demás. Botones con texto, etiquetas claras y HTML semántico son también lo que hace tu página más fácil de entender.
¿Qué idioma configuro en la API?
El de tu audiencia principal (por ejemplo es-ES o es-419 para LATAM). Si tu público es mixto, considera dar a elegir o detectar el idioma del navegador, y prueba con acentos distintos.
¿Estás poniendo al día la accesibilidad de una web? Sigue con la guía de la European Accessibility Act para diseñadores. Después, aprende a escribir texto alternativo con ayuda de la IA y echa un vistazo a estos plugins de accesibilidad para WordPress.
Conclusión
La navegación por voz no es una moda: es una capa de UX y accesibilidad que en 2026 empieza a separar webs profesionales de webs amateur. Implementarla es más fácil de lo que parece (un botón, una API y un fallback a texto) y aporta valor a varios perfiles de usuario. Eso sí, tenlo claro: cumple primero WCAG 2.1 AA, que es lo que pide la ley, y ofrece la voz como valor añadido, no como sustituto.
Como freelance, proponerla te diferencia frente a la mayoría de la competencia que aún no la contempla. Si quieres seguir, mira la guía de la European Accessibility Act. Si te ha servido, compártelo. Disfrútalo.
