WCAG Accessibility for Your Own Website: A Fix-It Checklist for Contrast, Keyboard Navigation and Screen Readers

The WCAG Fix-It Kit: Contrast Thresholds, a Keyboard Navigation Walkthrough and a Screen Reader Semantics Checklist

WCAG Accessibility for Your Own Website: A Fix-It Checklist for Contrast, Keyboard Navigation and Screen Readers

Bottom line first: Accessibility work on a B2B website is not about chasing perfection, it is about hitting one baseline: WCAG 2.2 AA. There are only three hard numbers: body text contrast of at least 4.5:1, every clickable element reachable with the Tab key with a visible focus ring, and a descriptive alt text on every meaningful image with no skipped heading levels. If you work alone, schedule it as half a day for contrast and heading levels, one day for keyboard focus, and two days for aria and alt. That clears all your P0 issues in about four days. The counterintuitive part: accessibility work and semantic SEO, the kind that makes AI more likely to cite you, are the same batch of work.

1. Why a B2B website needs accessibility too

Many people assume accessibility is a charity project for users with disabilities and has nothing to do with a B2B site that sells equipment and collects inquiries. That is only half right. There are three real drivers: supplier questionnaires from large Western customers now include a standard question on whether your site meets WCAG; some US states and EU public procurement contracts carry accessibility requirements; and more practically, semantic HTML is just as friendly to search engines and AI crawlers.

Here’s the counterintuitive judgment:Accessibility work is not extra cost. It is the same code you already need for SEO, structured data and AI citations. Swapping div buttons for real button elements, adding alt text to images, sorting out your font-size hierarchy: screen readers need these, and Google and large language models get a better read on your page structure from them too. For where to draw the line on scope, see Website accessibility (WCAG) for what you must do and what can wait.

Fix category	WCAG 2.2 AA hard requirement	Common failure today	Cost to fix
Text contrast	Body text ≥ 4.5:1, large text ≥ 3:1	Light gray text on white, about 2.5:1	Half a day
Keyboard focus	Every interactive element reachable by Tab with visible focus	outline:none removed the focus ring	One day
Image alt text	Descriptive alt on informative images, empty alt on decorative ones	alt is always “image” or empty	Two days
Heading hierarchy	h1 to h2 to h3 with no skipped levels	Jumps straight from h2 to h4	Half a day
Form labels	Every input has a visible label	Placeholder used as the only label	One day

2. First task: get contrast to 4.5:1

Contrast is the easiest thing to measure and the easiest to check yourself. The rules are simple: large text at 18pt (about 24px) or larger, or 14pt (about 18.66px) bold, needs 3:1; everything else — body text, small text, button labels — needs 4.5:1. Gray small text on a light background is the most common failure point on independent stores: a designer chasing a “premium” look sets body text to #888 on #f5f5f5, and the actual contrast is only around 2-something to 1.

You don’t need to buy a tool to check this yourself. Install the axe or WAVE extension in your browser, run a one-click scan, and it will flag every element that fails contrast. When you fix them, don’t redesign the whole thing — just darken the specific colors that fail: bumping body text from #888 to #555 usually clears 4.5:1 at almost zero cost. It’s the same idea as picking the low-hanging fruit first in performance optimization, see Core Web Vitals for how to rank fixes by payoff.

Element type	AA contrast requirements	How to judge	Common fixes
Body and small text	≥ 4.5:1	axe/WAVE flags it automatically	Darken the text color one step
Large headings	≥ 3:1	Same as above	Usually already passes
Button text	≥ 4.5:1	Test against the background too	Darken the button text or background
UI borders and icons	≥ 3:1	Contrast against the adjacent background	Darken the border color
Disabled state text	Exempt	Confirm it’s really disabled	No need to force a fix

Step two: put the mouse away and walk the whole site with the keyboard

There’s only one way to test keyboard navigation: unplug the mouse and go through the homepage, product listing, product detail, and contact form from start to finish using only Tab, Shift+Tab, Enter, and Esc. You’ll immediately find three kinds of problems: focus rings killed by CSS with outline: none, so you can’t see where you are; dropdown menus written in pure JS that the keyboard can’t reach; and modals that trap focus inside with no way out — that’s called a keyboard trap.

Scenario one: a “fake button” built with a div. The designer took a shortcut and used a div with a click handler, so keyboard users can’t Tab to it and Enter doesn’t trigger it. The fix isn’t to add JS — just swap it for a native button, which supports the keyboard by default and comes with an accessible name.Scenario two: the focus ring is invisible. Many global stylesheets include *:focus { outline: none }, which removes the browser’s default focus outline. The right approach is to keep a clear focus style, like a 2px blue outline, rather than deleting it entirely. For how semantics and structured data work together, see Structured data Schema.

Keyboard audit checklist	Pass criteria	What failure looks like	Fix
Tab order	Matches the visual reading order	Jumps around, can’t reach buttons	Adjust the DOM order or tabindex
Visible focus	The focused element has a clear outline	Outline removed, nothing visible	Add a :focus-visible style
Dropdown	Arrow keys expand and select	Mouse only	Switch to a native select or add keyboard support
Modals	Focus moves into the modal, Esc closes it	Focus gets trapped with no way out	Implement focus trap and release
Skip links	Long pages have a “skip to main content” link	Dozens of tab stops every time you navigate	Add a skip to content link

Part 3: Make it readable by screen readers

Screen reader users hear the semantic skeleton of your HTML, not the design you see. Three things shape that skeleton: alt text, heading hierarchy, and ARIA labels. Alt text is not a filename for the image; it is one sentence that states what the image conveys. Decorative divider images should get alt=””, so the screen reader skips them instead of reading out the word “button.”

Heading hierarchy is another trouble spot. To make a heading render large, many pages wrap an h4 or even a p tag in CSS, so a screen reader jumps from h2 straight to h4 and the user loses all sense of the document structure. The rule is mechanical: one h1 per page, h2s at the same level beneath it, h3 for subsections, and never skip a level. Icon buttons (a magnifying glass, a hamburger menu) have no text, so they need an aria-label; otherwise the screen reader only says “button” and the user has no idea what it does. For which wording works best with overseas buyers, see website copy tone guide.

Checklist	The right way	Common mistake	Tool check
Infographic alt	Describe the key takeaway	alt=”product image”, no information	What the screen reader hears
Alt for decorative images	alt=”” left empty	Reads out a meaningless filename	Check whether it is skipped
Heading hierarchy	h1 > h2 > h3, level by level	h2 straight to h4	axe flags the skipped level
Icon button	Add aria-label=”Search”	Only reads “button”	NVDA/VoiceOver
Tables	Mark headers with th	Built entirely from td	Check whether headers are read with each row

Part 5: Acceptance: run the automated scan, then finish by hand

The last misconception is that a green axe scan means you are compliant. Automated tools catch only about 30% to 40% of accessibility issues. They find mechanical errors like contrast, missing alt text, and skipped heading levels, but they cannot test keyboard traps, focus order, or the actual screen reader experience. A complete acceptance pass needs three things: an automated axe scan, a manual keyboard walkthrough of four key pages, and a listen-through of the homepage with NVDA (Windows) or VoiceOver (Mac).

On priority, start with the items that do not affect design and are pure code fixes: contrast, heading hierarchy, alt text, and focus rings. These need no designer involvement, and a developer can finish them in two days. Items that require reworking interactions (custom dropdowns, focus management in modals) go in the second batch: more work, but fewer of them. Aim for WCAG 2.2 AA, not AAA. AAA requires 7:1 contrast for body text, which in real designs usually means sacrificing the visuals, and the return is not worth the effort.

How to check	What it catches	Coverage	Frequency
Automated axe / WAVE scan	Contrast, missing alt text, skipped heading levels	About 30% to 40%	Before every launch
Manual keyboard walkthrough	Focus order, keyboard traps	Automation cannot test it	Once a month
NVDA / VoiceOver listen-through	Screen reader experience, aria naming	Automation cannot test it	Once a quarter
Real user feedback	Pain points in actual use	Most accurate, but slowest	Ongoing collection

FAQ

WCAG 2.1, 2.2, AA, AAA — which one should you pick?

Go with WCAG 2.2 AA. AA is the baseline that European and US government procurement, enterprise vendor questionnaires, and most actual lawsuits reference. AAA requires 7:1 body text contrast, which puts too many constraints on design, and most commercial sites don’t need it. Lock your target at AA: 4.5:1 for body text, 3:1 for large text, and you’ll handle 95% of questionnaires and compliance requirements. 2.2 adds new details on focus appearance and dragging movements compared to 2.1, so just build to the latest version.

Our site isn’t big. How many days does accessibility remediation take?

One person or a small team can clear the P0 issues in about four days: half a day for contrast and heading hierarchy, one day for keyboard focus, two days for image alt text and aria on icon buttons. No redesign needed, just code fixes. Start with the mechanical items that don’t affect visuals, and put interaction rewrites (custom dropdowns, modal focus) in the second batch. If the whole site runs on a mainstream theme plus a few plugins, many issues get fixed by theme updates, so the actual effort may be less than four days.

If the axe plugin scans all green, does that mean we’re compliant?

No. Automated tools only catch about 30% to 40% of issues. They can catch mechanical errors like contrast, missing alt text, and skipped heading levels, but they can’t test keyboard traps, whether focus order makes sense, or whether a screen reader reads the page smoothly. You have to add two steps: unplug your mouse and Tab through four key pages, then listen to the entire homepage with NVDA or VoiceOver. A green automated scan only means you’re a third of the way there.

How long should image alt text be, and what should it say?

The principle: when a screen reader reads it aloud, none of the information the image carries is lost. For a product hero image, write alt=”stainless steel flange, model X, PN16 pressure rating” instead of “product image.” If the image is a chart, put the key conclusion directly in the alt text, like “18% year-over-year growth in 2024.” For purely decorative dividers and background textures, use alt=”” so screen readers skip them. Don’t write redundant words like “image:” or “click” in alt text.

We use an off-the-shelf theme. Do we still need to fix accessibility ourselves?

Yes, but the work is small. First check whether the theme’s official site states WCAG support; most mainstream commercial themes already pass AA. What you need to do: your own page templates, custom form plugins, and custom icon buttons — these are areas the theme can’t cover, and where things most often go wrong. Scan just the pages you built with axe and fix those issues. You don’t need to modify the theme’s core files.

Does accessibility conflict with SEO? Will I have to give up my design?

No conflict — in most cases they’re the same job: switching to semantic tags, adding alt text, and fixing heading hierarchy all help search engines and large language models understand the page just as much. The only real trade-off is AAA-level contrast requirements; building to AA costs you nothing in design. The one thing you might change is deleting that global outline:none style and replacing the focus ring with one in your brand colors — visually it’s nearly identical.

Final thoughts

Accessibility work is most often turned into a box-ticking exercise — run a plugin scan, grab a few screenshots, drop them in the delivery doc, done. What actually works is breaking it into a P0 checklist you can finish in three days: first sort out contrast and heading hierarchy, then make keyboard focus work end to end, and finally fill in the alt text and aria. Once that’s done, your site is usable with screen readers and easier for search engines and AI crawlers to understand.

Three steps to get it done: first, run axe across the whole site and list every contrast issue, missing alt text, and skipped heading level in one table; second, unplug your mouse and tab through the homepage, product pages, and form pages, noting everywhere focus gets stuck; third, run an automated scan before every monthly release and listen through the homepage with a screen reader once a quarter. For multilingual sites, also make sure alt text and headings are fully translated — see Charts and tables on multilingual sites.

One line worth remembering: accessibility isn’t a patch for a special group of people — it’s writing your pages in plain language. If screen readers can understand it, search engines can read it, and AI can cite you.