Accessibility statement
Last updated
Our commitment
MenuWebStudio LLC builds websites that people can actually use, including people who navigate by keyboard, who use a screen reader, who need larger text, who cannot distinguish certain colors, or who find movement on a page uncomfortable. A restaurant website is often read one-handed, on a phone, in poor light, by somebody who is hungry and in a hurry. Designing for that is the same work as designing for accessibility, and we treat it as part of the build rather than as a later audit.
Conformance target
We build menuwebstudio.com and the sites we build for clients with WCAG 2.1 Level AA in mind. We say "in mind" deliberately rather than claiming full conformance, and the distinction matters. Accessibility is a property of a living site, not a certificate: content changes, a client sends us a photograph without a description, a third-party booking widget updates itself overnight. Claiming a permanent conformance status for something that changes weekly would not be honest. What we commit to is building to that standard, checking against it, and fixing what is reported.
The standard itself is published by the W3C: W3C, Web Content Accessibility Guidelines (WCAG) 2.1.
What we build in
- Contrast. Text and interface colors are chosen as pairs and checked against the surface they sit on, in both the light and dark appearance this site offers, rather than checked once on the default.
- Keyboard operation. Every control can be reached and operated from a keyboard, focus is always visible, and focus never gets trapped somewhere it cannot leave.
- Structure. One main heading per page, headings in a sensible order, real lists, real tables with proper headers, and a skip link to the main content.
- Text over images. We do not lay text over a photograph without a scrim. On this site, photographs carry captions and credits rather than headlines.
- Touch targets. Interactive controls are sized for a thumb, with real space between adjacent ones.
- Text size. Form inputs are set large enough that a phone does not zoom on focus, and the site reflows without loss of content when text is enlarged.
- Motion. Animation respects the reduced-motion setting in your operating system. With it on, reveals become instant and the decorative drift behind the hero stops.
- Images. Every photograph carries alternative text describing what is actually in it, and decorative marks are hidden from assistive technology rather than read aloud as noise.
- Color is never the only signal. Anything communicated by color is also communicated by a label, an icon or a shape.
Known limitations
Stating these is part of an honest statement rather than an admission that undermines one.
- Where a page embeds a third-party booking or scheduling tool, that tool's accessibility is controlled by its provider and not by us. We choose providers carefully and will raise problems with them, but we cannot fix their code.
- Photographs supplied by clients occasionally arrive without a description. We write one from what we can see, which is less accurate than a description from the person who took the photograph.
- Long menu tables and wine lists scroll horizontally inside their own container on a narrow screen. That is a deliberate choice over shrinking the text below a readable size, but it is still a horizontal scroll.
Sites we build for clients
Every site we build ships with its own accessibility statement, written for that restaurant, naming the same conformance target and giving the restaurant's own contact route for reporting a barrier. We build the site with WCAG 2.1 Level AA in mind and we tell the client plainly what they control: their own menu wording, the photographs they supply, and any third-party tool they ask us to embed. We do not tell a client that their site is certified compliant, and we would treat any studio that did with suspicion.
This is a description of how we build. It is not legal advice about your obligations as a business, and we are not a law firm. If accessibility law in your state is a live concern for your restaurant, take advice from a lawyer there.
Assistive technology and browsers
We build to web standards rather than to one assistive technology, and we check with the keyboard, with browser zoom at 200 per cent, with the reduced-motion setting on, and in both light and dark appearance. We do not claim to have tested every combination of screen reader, browser and operating system, because no studio our size honestly could.
Reporting a barrier
If something on this site stopped you doing what you came to do, tell us and we will fix it. Email with the page address, what you were trying to do, and what happened instead. Tell us what you are using if you can, for example a screen reader name or that you were navigating by keyboard, because it makes the problem far faster to reproduce.
A person replies within one working day. Accessibility reports are not treated as feature requests and they do not go into a queue behind other work.
How this was assessed
This statement reflects our own review of menuwebstudio.com rather than a third-party audit. It was last reviewed on the date shown at the top of this page. If we commission an independent audit we will say so here, along with who carried it out and what it found.