Para saber si la navegación de un sitio de restaurante cumple con WCAG 2.2, hay que probar tres superficies por separado —menú principal, pie de página y buscador interno— sin usar el ratón en ningún momento. La prueba consiste en desconectar el ratón, recorrer todo el sitio solo con Tab, Shift+Tab, Enter y las flechas, y verificar si el foco siempre es visible, si el orden en que salta de un elemento a otro tiene sentido, y si un error de búsqueda explica con claridad qué salió mal. Si en algún punto el foco desaparece, se queda atrapado en un submenú o un mensaje de error solo dice "no se encontraron resultados" sin más contexto, esa superficie falla el criterio correspondiente, independientemente de lo accesible que sea el resto del sitio.
Por qué la navegación merece su propia auditoría
La mayoría de las revisiones de accesibilidad en restaurantes se concentran en el carrito de pedidos o en el formulario de reserva, porque ahí es donde ocurre la transacción. Pero antes de llegar a esos formularios, cualquier visitante tiene que atravesar el menú de navegación, quizás usar el buscador interno para encontrar "horario" o "menú vegano", y con frecuencia toca enlaces del pie de página para llegar a la carta en PDF o a la dirección física. Si esas tres superficies no son operables por teclado, el visitante nunca llega a probar si el sistema de reservas es accesible: simplemente abandona antes.
WCAG 2.2, publicado por el W3C, no distingue entre "navegación" y "checkout" como categorías separadas de conformidad. Los mismos criterios de éxito sobre teclado, foco y errores aplican a un menú desplegable de categorías de platos igual que a un botón de "confirmar pedido". Esta checklist existe porque, en la práctica, la navegación y el buscador quedan fuera de la mayoría de las auditorías orientadas a conversión, no porque WCAG las trate como secundarias.
El marco de las Tres Puertas de Entrada
Para ordenar la auditoría sin depender de herramientas automáticas, resulta útil pensar en la navegación de un sitio de restaurante como tres puertas de entrada independientes que un visitante debe poder abrir sin ratón: la puerta del menú principal, la puerta del pie de página y la puerta del buscador. Cada una se prueba con el mismo procedimiento de teclado, pero contra criterios ligeramente distintos según su función.
Puerta 1: Navegación principal
Incluye el menú superior, los submenús desplegables de categorías (entrantes, platos principales, bebidas) y cualquier menú hamburguesa en versión móvil. Aquí se comprueba sobre todo operabilidad por teclado, orden de foco y visibilidad del indicador de foco.
Puerta 2: Pie de página
Incluye enlaces a horarios, dirección, redes sociales, política de privacidad y, con frecuencia, un segundo acceso al menú o a la reserva. Aquí el riesgo típico no es la trampa de teclado sino el orden de foco desordenado y la falta de formas alternativas de llegar al mismo contenido.
Puerta 3: Buscador interno
Incluye el campo de búsqueda, los resultados y cualquier mensaje de "sin resultados" o de error de formato. Aquí el foco está en la identificación de errores: si una búsqueda falla, el visitante necesita saber por qué y qué puede intentar en su lugar.
Tabla de criterios WCAG 2.2 aplicados a cada puerta
| Criterio WCAG 2.2 | Qué comprueba | Cómo probarlo sin ratón |
|---|---|---|
| 2.1.1 Teclado | Que cada enlace, botón o menú desplegable se pueda activar solo con teclado | Recorrer todo el menú y el pie de página con Tab y activar cada ítem con Enter o barra espaciadora |
| 2.1.2 Sin trampas de teclado | Que el foco pueda salir de cualquier submenú o modal de búsqueda | Entrar en cada submenú desplegable y confirmar que Shift+Tab o Escape permiten salir |
| 2.4.3 Orden del foco | Que la secuencia de tabulación siga un orden lógico y predecible | Anotar en qué orden salta el foco y comparar con el orden visual de la página |
| 2.4.7 Foco visible | Que siempre haya un indicador visible de qué elemento tiene el foco | Verificar que cada enlace, botón y campo de búsqueda muestra un contorno o resaltado al recibir foco |
| 2.4.11 Foco no oscurecido (mínimo) | Que el elemento con foco no quede tapado por cabeceras fijas o banners | Tabular hacia elementos cercanos al borde superior o inferior de la pantalla con cabeceras pegajosas activas |
| 2.4.1 Evitar bloques repetidos | Que exista un mecanismo para saltar la navegación repetida e ir al contenido principal | Comprobar si el primer Tab revela un enlace "saltar al contenido" |
| 2.4.5 Múltiples vías | Que exista más de una forma de llegar a una página clave, como el menú de platos | Verificar que la navegación principal, el pie de página y el buscador pueden llevar todos al menú |
| 3.3.1 Identificación de errores | Que una búsqueda fallida o mal formada indique claramente el problema | Buscar un término inexistente y un término vacío, y leer el mensaje resultante |
| 3.3.3 Sugerencia ante errores | Que el mensaje de error, cuando aplica, sugiera una corrección | Comprobar si el buscador ofrece términos alternativos o instrucciones tras un error |
Checklist paso a paso
- Desconecta el ratón o cúbrelo; usa solo Tab, Shift+Tab, Enter, barra espaciadora, flechas y Escape durante toda la sesión de prueba.
- Desde la página de inicio, presiona Tab una vez y confirma si aparece un enlace para saltar directamente al contenido principal.
- Recor
Cómo documentar los hallazgos con una matriz de severidad
Pasar la checklist una vez no basta si los resultados no quedan registrados de forma que alguien pueda priorizar el arreglo. WCAG 2.2 define criterios de éxito como binarios —se cumple o no— pero en la práctica conviene clasificar cada fallo detectado por su impacto real en la navegación, para decidir qué se corrige primero.
Severidad Definición Ejemplo en las tres puertas Bloqueante El foco queda atrapado o un elemento no se puede activar por teclado en absoluto Un submenú de "Bebidas" que no se puede cerrar con Escape ni con Shift+Tab Alto El elemento es operable pero el foco es invisible o el orden es impredecible Un enlace del pie de página que recibe foco pero no muestra ningún contorno Medio Funciona por teclado pero un mensaje de error no orienta al usuario El buscador muestra "0 resultados" sin sugerir términos alternativos Bajo Cumple el criterio pero con friction menor, como pasos extra de tabulación Hay que tabular por diez enlaces repetidos antes de llegar al buscador Registrar la página, el criterio de éxito de WCAG 2.2 afectado y la severidad permite convertir la auditoría en una lista de trabajo, en lugar de un reporte de "accesible/no accesible" sin matices.
Casos límite que la checklist básica no cubre
Sugerencias de autocompletado en el buscador
Muchos buscadores internos muestran una lista de sugerencias mientras el usuario escribe. Esa lista suele comportarse como un widget aparte, con su propia lógica de flechas arriba/abajo y Enter. Al probarla sin ratón, verifica si las flechas mueven el foco dentro de la lista de sugerencias sin sacarlo del campo de texto, y si Escape cierra la lista sin cerrar también el buscador completo.
Banners de cookies y avisos emergentes
Si un aviso de cookies aparece al cargar la página, puede insertarse antes de la navegación principal en el orden de tabulación, o puede robar el foco de forma que el primer Tab no lleve al enlace "saltar al contenido" sino al botón de aceptar cookies. Esto afecta directamente el criterio 2.4.3 y debe probarse como parte del recorrido inicial, no como un elemento aparte.
Cabeceras fijas en vista móvil
En pantallas pequeñas, una cabecera pegajosa puede ocupar una porción mayor del viewport. Al tabular hacia enlaces cercanos al borde superior, confirma que el indicador de foco no queda parcial o totalmente oculto detrás de esa cabecera, lo que corresponde al criterio 2.4.11.
Widgets de terceros incrustados
Un chat de atención al cliente o un widget de reservas embebido dentro del pie de página puede tener su propio manejo de foco, independiente del resto del sitio. Pruébalo como una puerta adicional: entra con Tab, confirma que se puede salir, y no asumas que porque el sitio principal es operable por teclado el widget también lo es.
Límites del método manual de teclado
Esta checklist prueba operabilidad por teclado, orden de foco y manejo de errores, pero no verifica todo lo que exige WCAG 2.2. Quedan fuera, entre otros:
- Si el nombre, rol y valor de cada control se anuncian correctamente en un lector de pantalla: eso requiere una prueba separada con NVDA, JAWS o VoiceOver, no solo teclado.
- Si el contraste del indicador de foco cumple la relación mínima exigida: comprobar visualmente que "se ve" no sustituye una medición de contraste.
- Criterios de WCAG 2.2 que no se relacionan con navegación o búsqueda, como los de contenido multimedia o formularios de reserva, que exigen su propia auditoría.
Una auditoría de teclado aprobada en las tres puertas de entrada indica que esa superficie específica no presenta las barreras cubiertas por los criterios listados aquí; no equivale a una declaración de conformidad total con WCAG 2.2 en todo el sitio.
Cuándo repetir la auditoría
Repite este proceso cada vez que se rediseñe el menú principal, el pie de página o el buscador, y también cada vez que se incorpore un widget de terceros nuevo, ya que estos cambios pueden alterar el orden de foco sin que el equipo lo note durante el desarrollo.
Alcance frente a productos de ChefNet
Esta checklist es una guía general de auditoría basada en WCAG 2.2 y no describe una funcionalidad de ChefNet. ChefNet se encuentra desarrollando productos de descubrimiento y operación para restaurantes; si buscas saber qué capacidades de accesibilidad o auditoría están disponibles hoy en esos productos, verifica directamente con ChefNet cuáles funciones están activas en el momento de la consulta.
Fuentes primarias
FAQ
¿Se aplica WCAG 2.2 específicamente a la navegación de un sitio de restaurante?
WCAG 2.2 se aplica a todo el contenido web, incluidos los sitios de restaurantes, sin excepciones para la navegación, el pie de página o el buscador. Los criterios de éxito sobre operabilidad por teclado, orden de foco e identificación de errores rigen igual que en cualquier sitio con menús interactivos y formularios. Un operador debería tratar su navegación principal y su buscador como interfaces interactivas de pleno derecho, sujetas a los mismos criterios que los widgets de pedidos o reservas.
¿En qué se diferencia auditar la navegación de auditar los flujos de reserva o pedido?
La navegación, los enlaces del pie de página y el buscador interno suelen estar presentes en todas las páginas y se usan antes de que un visitante llegue a un menú, un carrito de pedidos o un formulario de reserva. Alguien que no puede recorrer el menú principal con el tabulador o recuperarse de una búsqueda fallida puede abandonar el sitio antes de llegar siquiera a las interfaces de pedido o reserva. Esta checklist aísla esas superficies previas en lugar de duplicar auditorías ya centradas en los flujos transaccionales.
¿Pueden los escáneres automáticos completar por sí solos este tipo de auditoría?
Las herramientas automáticas pueden detectar algunos problemas, como indicadores de foco ausentes en el código o textos de enlace duplicados, pero en general no pueden juzgar de forma fiable si el orden de foco es lógico, si los mensajes de error son comprensibles, o si existen trampas de teclado en widgets personalizados. Las pruebas manuales solo con teclado y, cuando sea posible, con tecnología de asistencia real, siguen siendo necesarias. Conviene tratar los resultados automáticos como punto de partida, no como veredicto de conformidad.
Divulgación editorial: ChefNet publica esta guía y desarrolla productos para el descubrimiento y las operaciones de restaurantes. Las recomendaciones operativas generales se separan de las afirmaciones sobre el producto. Las funciones pueden cambiar durante los programas piloto. Publicado 2026-08-03.