Accessibility on a Cafe Website: Contrast, Alt Text, Keyboard
Someone asked me recently whether fixing accessibility issues on a cafe website would help it rank higher in Google. Short answer: there is no documented Google ranking factor for accessibility, and I am not going to pretend otherwise. What accessibility actually does is let more of your actual customers use your site. That includes an older guest reading a menu in bright sunlight, someone with low vision zooming a page on their phone, and a person navigating entirely by keyboard because a mouse is not an option for them.
This post is not legal advice, and it does not try to tell you what any law requires. It sticks to four things you can check yourself in about ten minutes: color contrast, alt text on images, keyboard use, and a short testing routine to catch problems before a customer finds them for you. Every rule cited here comes from the W3C Web Content Accessibility Guidelines, known as WCAG, or from Google's own documentation, and I will name the source and version each time.
WCAG organizes its guidance into levels, labeled A, AA and AAA, with AA generally treated as the working standard most organizations aim for. The success criteria named in this post, contrast, non text content and keyboard, all sit at the A or AA level, which is why they are the four basics worth checking first rather than a longer, more exhaustive list. None of this requires a developer or a paid audit to start. A phone, a laptop keyboard and two free tools are enough to check the four things this post covers, and every one of them is described below with the exact terms to search for if you want to read the source documentation yourself.
Contrast
WCAG 2.2 sets a minimum contrast ratio for normal body text against its background, commonly stated as 4.5 to 1, under the success criterion labeled 1.4.3 Contrast (Minimum), with a lower bar of 3 to 1 allowed for large text such as headings. A ratio is just a measurement of how far apart two colors sit in brightness. Light gray text on a white background often fails this test badly, even though it looks fine to someone with typical vision sitting close to a bright screen.
The fastest way to check your own homepage is a free contrast checker tool such as the one WebAIM publishes, where you paste in your text color and your background color and it tells you the ratio and whether it passes. A common failure on cafe sites is a light tan or cream text color placed over a white or pale background, used to look soft and on brand, which often lands well under the 4.5 to 1 minimum. The fix is almost always the same: darken the text color, or darken the background behind it, until the checker shows a pass.
Contrast problems are not limited to body copy. Menu prices set in a thin, light font over a photo background, or a call to order button in pale color on a pale background, both fail the same test and both cost you customers who simply cannot read what you have written. A quick pass through your homepage, your menu page and your contact page with a contrast checker tool, checking every text and background pair you can find, takes a few minutes and catches most of what matters.
Think about who actually benefits from this fix, beyond anyone formally diagnosed with a vision condition. An older guest reading your hours on a phone screen outdoors, in full sun, with the brightness turned down to save battery, is fighting the exact same contrast problem as someone with low vision reading indoors. A parent scrolling your menu one handed while holding a coffee and a toddler is in a hurry and will not squint at pale text to figure out what a latte costs before giving up and calling instead, or leaving. Contrast is not an edge case feature. It is a baseline that determines whether a normal, busy person can read your page on the first try.
If your site was built a few years ago and the color palette has not been touched since, it is worth running every page through the checker once, not just the homepage. A seasonal promotion banner, an about page written by a designer chasing a particular aesthetic, and a footer with faded contact details are three of the most common places a contrast failure hides on an otherwise solid cafe website.
Alt Text
Alt text is the written description attached to an image in the code of a page, read aloud by a screen reader and shown when an image fails to load. WCAG 2.2's success criterion 1.1.1 Non text Content requires that images convey their information in text form for anyone who cannot see the image itself. Google's own Search Central documentation on image best practices makes a related but separate point: alt text should describe the image plainly, because it also helps Google understand what an image shows.
A common failure looks like alt text left completely blank on a meaningful photo, or filled with something like image1 or IMG_4021, both of which tell a screen reader user nothing at all about a photo of your espresso bar or your patio. Another common failure is the opposite problem, alt text stuffed with a long string of keywords such as best coffee shop downtown espresso latte cappuccino, which is unpleasant to hear read aloud and does not describe the actual image.
A passing example is short and plain: a barista pouring a heart shape into a latte at the counter, or a wooden patio table with two chairs under string lights. One sentence, describing what is in the photo, is usually enough. For a purely decorative image that adds nothing informational, such as a repeating background texture, WCAG guidance allows an empty alt attribute, which tells a screen reader to skip it rather than describe it, so the listener is not interrupted by something that carries no meaning.
A useful habit is to write alt text the way you would describe a photo out loud to a friend on the phone who cannot see it and only has a few seconds to picture it. You would not read them a string of search terms, and you would not say nothing at all. You would say something like two people sitting at a window counter with laptops and coffee cups, because that is what tells them what the photo shows. Applying that same habit to every meaningful image on your site, one sentence at a time, is the whole method, and it works whether you have five photos on your homepage or fifty spread across a gallery page.
Keyboard
WCAG 2.2's success criterion 2.1.1 Keyboard requires that every function on a page be usable from a keyboard alone, without needing a mouse or a touchscreen. This matters for anyone who cannot use a mouse precisely, whether because of a physical condition, a temporary injury, or simply a broken trackpad on an old laptop.
You can test this yourself in a few minutes. Load your homepage, then press Tab repeatedly to move forward through every link and button, and Shift plus Tab to move backward. Watch for two things: does a visible outline or highlight show you where you currently are on the page, and does every link, button and form field get reached this way. Then try pressing Enter on a focused button, such as an order now or call now button, to confirm it activates the same way a click would.
A common failure is a menu or a navigation dropdown that opens fine with a mouse hover but simply cannot be reached or opened using Tab and Enter alone, which quietly locks out anyone navigating by keyboard from an entire section of your site. Another common failure is a focus outline that has been removed for looks, in a stylesheet rule, leaving a keyboard user with no visible sign of where they currently are on the page at all. Both are usually fixable by a site builder support team once you know exactly what to describe.
The keyboard walk through also catches a problem contrast and alt text checks never will: an order button, a phone number link or a directions link that exists visually but is not built as a clickable element in the page's code, so a mouse click happens to land on it by luck of positioning while a keyboard user has no way to reach it at all. This kind of gap is easy to miss just by looking at a page, because it looks completely normal, and it is exactly why the Tab key test matters even on a site that otherwise looks polished and finished.
Testing
A short testing routine, repeated every few months or after a redesign, catches most problems before a customer runs into them. Run your homepage through the accessibility audit built into your browser's developer tools, often labeled Lighthouse, which flags many contrast and alt text issues automatically and explains each one in plain language.
Follow that with the manual keyboard walk through described above, and a manual scan of your images asking whether each one has alt text that describes what is shown. If your website platform offers a built in accessibility tool, such as Wix's accessibility wizard or Squarespace's accessibility guidance, read what that tool's own help page says it checks and, just as importantly, what it says it does not check, since automated tools reliably catch contrast and missing alt text but cannot judge whether alt text is well written.
One more note on a product you may have been pitched: an overlay widget that claims to make a site instantly compliant by adding a script on top of existing pages. WebAIM and other accessibility organizations have published public positions that these overlay tools do not reliably fix the underlying problems and can sometimes interfere with the very screen reader and keyboard tools they claim to support. The fixes described in this post, contrast, alt text and keyboard reachability, address the page itself rather than papering over it, and that is the more durable approach.
None of this needs to happen all at once. Pick one section of your homepage, run the contrast checker and the keyboard walk through on it this week, fix what fails, and move to the next section next month. A cafe site that passes these four basics is easier to use for a wider range of the actual people walking through your door, which was the whole point before any search engine ever entered the conversation.
Keep a simple running note of what you have checked and what you have fixed, even if it is just a few lines in a notes app: date checked, page checked, what failed, what you changed. That small habit turns accessibility from a one time scramble into a maintenance routine, the same way you would keep a note of when the espresso machine was last serviced. A site rebuild, a new photo gallery or a seasonal page added six months from now can undo a fix you already made once, so the short note tells you, quickly, whether it is worth another ten minute pass.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Is accessibility an SEO factor?
There is no documented Google ranking factor for accessibility as such. What is documented is that Google's image guidance asks for descriptive alt text because it helps Google understand what an image shows, which is a separate claim from a ranking boost. Treat accessibility as a customer basic first, checked with a contrast tool and a keyboard walk through, not as a search shortcut.
What contrast ratio does WCAG require?
WCAG 2.2's success criterion 1.4.3 Contrast (Minimum) sets 4.5 to 1 for normal body text against its background, with a lower 3 to 1 minimum allowed for large text such as headings. A free contrast checker tool, such as the one WebAIM publishes, lets you paste in your actual text and background colors and see the ratio and whether it passes, in under a minute.
What should alt text say?
Alt text should describe what the image plainly shows in one short sentence, such as a barista pouring latte art at the counter. Google's Search Central image best practices documentation and WCAG's 1.1.1 Non text Content criterion both point the same direction: description, not a keyword list, and not a blank left where a description belongs.
Should every image have alt text?
Every image that carries meaning should. Purely decorative images, such as a repeating background pattern that adds nothing informational, can carry an empty alt attribute under WCAG guidance, which tells a screen reader to skip it rather than read something meaningless aloud. The judgment call is whether the image itself is telling the visitor something or just decorating the page.
How do I test keyboard navigation myself?
Load your homepage and press Tab repeatedly to move forward through links and buttons, Shift plus Tab to move backward, watching for a visible outline showing your current position. Then press Enter on a focused button, such as an order or call button, to confirm it activates. This takes a few minutes and needs no special tool beyond your own keyboard.
Do overlay widgets fix accessibility automatically?
WebAIM and other accessibility organizations have published public positions that overlay widgets, scripts added on top of an existing page claiming instant compliance, do not reliably fix underlying contrast, alt text or keyboard problems, and can sometimes interfere with the screen reader and keyboard tools they claim to support. Fixing the page itself is the more durable approach.
Does my website platform have a built in accessibility checker?
Some do. Wix offers an accessibility wizard and Squarespace publishes its own accessibility guidance; read what each tool's own help page says it checks and what it does not, since these tools reliably catch things like missing alt text and low contrast but cannot judge whether the wording of your alt text is actually good.
Is this post legal advice?
No. This post does not state what any accessibility law requires of a business, and questions about legal compliance should go to an actual attorney or the official government sources that cover it. What is covered here is the practical, customer facing side: contrast, alt text, keyboard use and testing, sourced from WCAG and Google documentation.
What is the fastest first check I can run today?
Run your homepage through the accessibility audit built into your browser's developer tools, usually labeled Lighthouse, which flags many contrast and missing alt text issues in under a minute and explains each finding in plain language. Then do the keyboard walk through: press Tab to move forward and Shift plus Tab to move back, checking that a visible outline follows you and that every button activates with Enter. That second step covers WCAG 2.2 criterion 2.1.1 Keyboard, which automated checks cannot fully judge.
Where can I learn more about accessibility technology and tools like Hillcane offers?
The primary references are the W3C Web Content Accessibility Guidelines, WCAG 2.2, especially criteria 1.4.3 Contrast (Minimum), 1.1.1 Non text Content, and 2.1.1 Keyboard, plus Google Search Central's image best practices and WebAIM's free contrast checker. Hillcane builds and audits coffee shop websites with these same basics in mind, alongside the broader search and Maps work the studio does. If you want a second set of eyes on your homepage's contrast, alt text, and keyboard use, reach out at hillcane.co/contact or call (256) 384-2449.
Work with Hillcane
Someone asked whether fixing accessibility would help a cafe rank higher in Google. It will not, documented, but it will let more actual customers use the site.
Want a second set of eyes on your homepage's contrast, alt text and keyboard use? Reach out at hillcane.co/contact or call (256) 384-2449.
Comments