Accesibilidad web para restaurantes en California: las reglas y el problema del menú

Una clienta ciega quiere saber si tienes algo sin lácteos. Tu menú es un PDF que alguien exportó de un archivo de diseño en 2019. Su lector de pantalla lo abre y no lee nada, porque no hay nada que leer: es una foto de palabras.

Esa es la falla de accesibilidad más común en el sitio de un restaurante, y también la más barata de arreglar. Este artículo trata solo de esa mitad del problema, la que vive en tu código. Tu edificio es un asunto aparte con un especialista aparte, y la última sección lo dice sin rodeos.

Nada de esto es asesoría legal. Es lo que dicen las fuentes originales, enlazadas para que las revises.

¿El sitio de un restaurante tiene que ser accesible?

Sí, y el razonamiento tiene dos pasos.

El paso federal: el ADA cubre los lugares de acceso público, y los restaurantes están nombrados en la ley. En el Noveno Circuito, que es California, Robles contra Domino's Pizza sostuvo que un sitio web y una app quedan cubiertos cuando su inaccesibilidad "impide el acceso a los bienes y servicios de sus pizzerías físicas". Un restaurante con comedor y una página para ordenar en línea es la versión de libro de texto de esa conexión. La Corte Suprema decidió no tomar el caso.

Puede que alguien te ofrezca una decisión de California de 2022, Martínez contra Cot'n Wash, que sostiene que un negocio que existe solo en línea no es un lugar de acceso público. Ese caso es sobre empresas sin ubicación física. Tú tienes comedor. No es tu defensa.

El paso de California es donde está el dinero. Bajo la Ley Unruh de Derechos Civiles, una violación del ADA es automáticamente una violación estatal, y Unruh trae un mínimo legal de $4,000 por cada ocasión en que se le negó el acceso a una persona, más los honorarios de su abogado. En corte federal esos mismos hechos dan una orden de arreglarlo y el pago de honorarios. En corte estatal de California dan un piso de cuatro dígitos, sin necesidad de probar un daño de bolsillo.

Una cosa que no hay que dar por hecho: la vía de daños reducidos de la que habla la gente, la que baja la cifra a $1,000 o $2,000 después de una inspección certificada, está escrita para reclamos relacionados con la construcción. La ley define esos estándares como los que sirven para "hacer accesibles las construcciones nuevas y las instalaciones existentes". No existe un programa de inspectores certificados para sitios web ni un refugio publicado equivalente. Si alguien te dice que una inspección de tu edificio cubre tu sitio, pídele que te señale la disposición.

Qué estándar aplica, cuando ninguna regla federal nombra uno

Aquí está la parte que confunde a todo el mundo: no hay un estándar técnico federal dirigido a tu sitio web.

El Departamento de Justicia escribió uno en 2024, pero aplica a gobiernos estatales y locales bajo el Título II, no a la iniciativa privada, y en abril de 2026 recorrió esas fechas hasta abril de 2027 y 2028. La reglamentación del Título III para negocios privados sigue detenida.

California ha estado dos veces a punto de escribir uno en la ley estatal y dos veces no ha terminado. La AB 1757, que habría hecho de WCAG 2.1 AA un requisito legal, murió en la Comisión de Presupuesto del Senado el 30 de noviembre de 2024. Todavía vas a encontrar blogs de proveedores que la describen como ley. No lo es. Su sucesora, la AB 2190, fijaría WCAG 2.1 AA ahora y WCAG 2.2 AA a partir de enero de 2027, y exigiría una página de accesibilidad enlazada. Pasó al archivo inactivo el 21 de mayo de 2026 a petición de su autor, Greg Wallis, que representa a Palm Springs, Palm Desert, Cathedral City, Rancho Mirage, La Quinta, Indian Wells y Desert Hot Springs. La iniciativa que habría fijado la regla para los restaurantes del valle la escribió el propio asambleísta del valle, y está guardada.

Así que lee bien esa ausencia. Que ninguna regla nombre un estándar no es lo mismo que no tener obligación. Los reclamos se siguen presentando, y cuando llegan se argumentan contra WCAG, porque WCAG es la única vara que existe. Construye a WCAG 2.1 AA como piso y a 2.2 AA si de todos modos vas a hacer el trabajo; 2.2 es hacia donde apunta la iniciativa guardada, y es donde sostenemos este sitio.

Qué alegan en realidad las demandas de California sobre sitios web

La Comisión de California sobre Acceso para Personas con Discapacidad publica las violaciones alegadas en las demandas que los abogados están obligados a mandarle. En el primer semestre de 2025, de 5,047 violaciones alegadas, cuatro de las diez más comunes eran problemas de sitio web, y suman 1,681. Un tercio de todo lo alegado.

Lee bien qué son esas cuatro. Falta de texto alternativo, es decir imágenes sin descripción. Contenido sin marcado semántico, es decir encabezados, listas y tablas que solo parecen encabezados, listas y tablas. Orden de navegación que no es lógico. Texto de enlace que no dice a dónde lleva. No son problemas exóticos de ingeniería. Son las primeras cuatro cosas que cualquier construcción decente hace bien, y son las fallas web más alegadas del estado precisamente porque tantos sitios no las hacen.

Vale la pena ser claro en algo: estos datos vienen de demandas que también alegan barreras físicas, así que estos señalamientos web suelen llegar acompañados de una visita al restaurante. Eso no los hace más baratos de perder. Significa que la revisión del sitio y el recorrido del local llegan en el mismo sobre.

Las cinco que le pegan a los restaurantes en particular

1. El menú como PDF o como imagen. La grande. Un menú exportado como foto es invisible para un lector de pantalla, ilegible al 200% de zoom, y una tortura en el teléfono desde un estacionamiento. Pon el menú en texto HTML real, en una página real. Lo mismo para las sugerencias del día publicadas como foto de un pizarrón, y para los horarios metidos dentro de una imagen. Además, y no es casualidad, es lo mejor que puedes hacer por tu búsqueda y por los asistentes de IA, que tampoco pueden leer tu menú. Un restaurante cuyo menú es una foto es invisible para la herramienta a la que tu cliente le acaba de pedir una recomendación.

2. El widget de pedidos y reservaciones. Toast, OpenTable, Resy, el botón de entrega a domicilio. Está en tu página y es tu problema, y es exactamente el patrón de hechos de Robles: ahí el reclamo era no poder completar un pedido. Pruébalo tú. Suelta el ratón, usa Tab, Enter y las flechas, e intenta llegar del menú a un pedido hecho. Si te quedas atrapado en una ventana de la que no puedes salir, también le pasa a todo el que usa teclado.

3. Fotos de comida sin texto alternativo. La violación web más alegada del estado, justo sobre el tipo de contenido que más publican los restaurantes. Describe el platillo, no el nombre del archivo. Las fotos decorativas de fondo pueden llevar un atributo alt vacío, que es una respuesta real y no un descuido.

4. Contraste. A los sitios de restaurante les encanta la letra delgada y clara sobre fotografía oscura. Tus ojos frente a una laptop brillante en una oficina con aire no son la prueba. Mídelo: 4.5:1 para el texto normal, 3:1 para el texto grande, y revisa el texto que va encima de las fotos grandes, que es donde casi siempre falla.

5. Ninguna información de acceso en el sitio. Dónde está el estacionamiento accesible, cuál entrada es a nivel, si la terraza tiene ruta, si el baño sirve. Publicarlo no es en sí un requisito legal, simplemente es útil, y evita la llamada telefónica. También es justo el tipo de respuesta local y específica que hace que nombren a un restaurante cuando alguien le pide a un asistente un lugar al que su mamá pueda entrar.

El widget que promete hacerlo por ti

No lo hace. En abril de 2025 la Comisión Federal de Comercio finalizó una orden de $1 millón contra accessiBe, que le prohíbe a la empresa afirmar que su producto automatizado puede hacer que cualquier sitio cumpla con WCAG, y presentar reseñas pagadas como opiniones independientes.

El argumento práctico contra los overlays es más simple que el legal. Un script que se monta al cargar la página no puede saber qué muestran tus fotos de comida, no puede convertir un menú en PDF en texto legible, y no puede arreglar un flujo de pedidos que no construyó. Lo que sí puede hacer es estorbarle al lector de pantalla que dice ayudar, y por eso los demandantes siguen presentando reclamos contra sitios que tienen uno instalado. Si ya tienes uno, no es un plan de corrección. Es una línea en la factura.

Qué arreglar, en orden

1. Saca el menú del PDF. Encabezados reales, texto real, precios reales. Todo lo demás en esta lista es más chico que esto.
2. Texto alternativo en cada foto de comida, y alt vacío en las decorativas.
3. Arregla el texto de los enlaces. "Haz clic aquí" y once enlaces que dicen todos "menú" son dos de las cuatro fallas más alegadas del estado, y se resuelven en una tarde de buscar y reemplazar.
4. Revisa encabezados y estructura. Un solo h1, sin saltarse niveles, listas marcadas como listas.
5. Mide el contraste del texto normal y de todo lo que va encima de una foto.
6. Prueba con teclado el flujo de pedidos y reservaciones, hasta el pedido completo.
7. Publica una página de accesibilidad que diga a qué te apegas y cómo reportar una barrera. Es lo que exigiría la iniciativa guardada, y cuesta una hora.

Del dos al cinco son casi las cuatro filas de la CCDA, y un sitio chico puede terminar todo eso en un par de días.

Sobre el edificio

No voy a fingir que este artículo cubre toda tu exposición. La parte física, la pendiente y el pintado del estacionamiento, la ruta desde el cajón, las alturas de mostradores y mesas, los baños, es un problema real y que se litiga aparte, y en California sigue siendo donde empieza la mayoría de los reclamos. Ese trabajo le toca a un Especialista Certificado en Acceso (CASp), un inspector certificado por el estado, y ninguna agencia web, incluida esta, está calificada para certificar una rampa. Si ya llegó una carta de reclamo, esa es llamada de abogado y no es de las que se dejan para después.

Lo que sí te puedo decir es que la mitad del sitio web es la que los restaurantes más ignoran, es un tercio de lo que se alega, y el mismo trabajo paga dos veces. Un menú en texto real, imágenes descritas, encabezados en orden sensato y un sitio que se pueda usar con el teclado son al mismo tiempo el arreglo de accesibilidad, el arreglo de SEO, y la razón por la que un asistente de IA puede leer tu menú lo bastante bien como para recomendarte. El marcado accesible y el marcado que las máquinas leen son el mismo marcado.

Si quieres que revisemos esa mitad, eso es lo que hacemos.

Preguntas que hacen los dueños de restaurante

¿De verdad tiene que cumplir el sitio de un restaurante chico? El ADA no tiene una exención para negocios pequeños, y la obligación se pega al negocio, no a su tamaño. Lo que el tamaño cambia es qué va a considerar razonable un juez esperar de ti, no si te pueden poner un reclamo. En la práctica, lo que más se alega, texto alternativo, texto de enlaces, encabezados y contraste, cuesta más o menos lo mismo arreglarlo en un sitio de cinco páginas que en uno de cincuenta, es decir, muy poco.

¿Qué versión y nivel de WCAG le pido a un desarrollador? WCAG 2.1 nivel AA como piso, y 2.2 nivel AA si vas a reconstruir. AA es el nivel que aparece en prácticamente todos los acuerdos, en las reglas de gobierno y en las dos iniciativas de California. Deja el objetivo por escrito en el contrato, y pregunta cómo se va a verificar, porque las herramientas automáticas detectan por su cuenta como un tercio de los problemas.

Mi menú está en una plataforma de pedidos de terceros. ¿Es problema de ellos? El reclamo te va a nombrar a ti. Si tu proveedor te debe algo por eso es una pregunta sobre tu contrato con ellos, no sobre tu responsabilidad ante un cliente. Pídele a la plataforma su documentación de conformidad, por escrito, y prueba tú mismo el flujo con el teclado antes de darlo por bueno.

¿Un widget de accesibilidad me protege? No, y puede empeorar las cosas. La orden de la Comisión Federal de Comercio de abril de 2025 contra accessiBe le prohíbe a ese proveedor afirmar que su herramienta automatizada hace que cualquier sitio cumpla con WCAG. Los overlays seguido rompen la tecnología de asistencia que dicen ayudar, y los demandantes con frecuencia presentan reclamos contra sitios que traen uno. La corrección de verdad ocurre en el código.

¿Ya hay una ley de California que fije un estándar para sitios web? No al momento de escribir esto. La AB 1757 murió en noviembre de 2024 y la AB 2190 pasó al archivo inactivo en mayo de 2026. Esa ausencia no es permiso: los reclamos se presentan bajo el ADA y la Ley Unruh de todos modos, y se argumentan contra WCAG porque es el único estándar contra el cual se puede argumentar.