30-minute accessibility audit: red to green for SMEs

It is 14:50 on a Tuesday. The marketing lead at a forty-person engineering firm in Eindhoven forwards you a screenshot. A consultant ran their site through an accessibility scanner. Forty-seven errors, three of them flagged "critical". The European Accessibility Act came into force last June. The board wants a green badge by Friday.

You have thirty minutes before the next standup.

This post is the audit you run in those thirty minutes. It will not make the site WCAG 2.2 AA conformant by itself. It will move a typical Dutch SME site from "scanner red" to "scanner green", clear the most embarrassing failures, and give you a defensible toegankelijkheidsverklaring to point at while you plan the deeper work.

Why this matters in June 2026

The European Accessibility Act (Richtlijn 2019/882) has been enforceable on private-sector digital services since 28 June 2025. The Dutch implementation lives inside the Wet toegankelijkheid digitale producten en diensten. Enforcement runs through the AFM and the consumer authority. The teeth are complaints, public registers, and the slow but real threat of being barred from public-sector tenders.

Most Dutch SMEs we audit fail on the same five things. Fix those and the colour bar in any scanner flips. The deeper work (proper keyboard semantics, screen-reader review with NVDA or VoiceOver, reduced-motion handling) is the next sprint, not the next thirty minutes.

Tools to install before the timer starts

Two browser extensions and one webpage. That is the whole kit.

• axe DevTools for Chrome or Firefox, by Deque. The free tier is enough.
• WAVE by WebAIM. Free.
• WebAIM Contrast Checker. No install.

Open the client site, open the panel, run the scan. axe will catch colour contrast, missing alt text, missing form labels, and ARIA misuse. WAVE surfaces the same problems with a different visual model. Running both takes ninety seconds and one will spot something the other missed.

Minutes 0 to 5: scan and triage

Run axe on the homepage and on two other high-traffic pages. The product detail page and the contact form, usually. Export the result to JSON if you want a paper trail. Group the findings into four buckets:

1. Contrast failures
2. Missing alternative text
3. Missing or broken form labels
4. Everything else (heading order, link purpose, ARIA noise)

The first three buckets are eighty percent of the red. They are also the cheapest to fix.

Minutes 5 to 12: contrast

Contrast failures are the most common reason a Dutch SME site is "red". The cause is almost always the brand palette. A designer picked a soft grey on white for body copy because it "feels modern". It fails WCAG 2.2 AA at 4.5:1.

Open the contrast checker. Paste the foreground and background hex codes. If the ratio is under 4.5:1 for body text or 3:1 for large text, you have a finding.

The fix is usually one CSS variable.

:root {
  /* was: #9aa0a6 on #ffffff = 2.85:1, fails AA */
  --color-text-muted: #5f6368; /* on #ffffff = 5.74:1, passes AA */
  --color-link:       #1a56db; /* on #ffffff = 6.36:1, passes AA */
}

This is the single highest-leverage edit in the audit. One variable, twenty problems gone.

Do not "fix" contrast by darkening the brand colour everywhere. If the marketing site uses brand orange on white for buttons, change the text on the button to white and keep the brand colour as the background. White on #d97706 sits at 4.51:1. Just inside.

Minutes 12 to 18: alt text

Open the page in dev tools. Run this in the console.

[...document.images]
  .filter(img => !img.alt && !img.getAttribute('aria-hidden'))
  .map(img => img.src);

Every URL it prints is an image with no alternative text and no instruction to skip it. For each one, decide: is this image content or decoration?

Content images get a short, factual alt. Decoration images get alt="". Never alt="image" and never the filename.

In WordPress, the alt text lives in the media library, not in the post editor. A plugin can bulk-fill, but the auto-generated text is wrong for product photos. Edit the top twenty by hand.

<!-- bad -->
<img src="/img/team-photo.jpg">

<!-- worse -->
<img src="/img/team-photo.jpg" alt="image">

<!-- good, content image -->
<img src="/img/team-photo.jpg"
     alt="The engineering team outside the Eindhoven office, May 2026">

<!-- good, decorative flourish -->
<img src="/img/divider-swirl.svg" alt="" aria-hidden="true">

Minutes 18 to 24: form labels

Every form input needs a programmatic label. Placeholder text does not count. A floating label that disappears on focus does not count.

<!-- bad: scanner red, screen reader silent -->
<input type="email" placeholder="Email">

<!-- good -->
<label for="contact-email">Email address</label>
<input id="contact-email" type="email" name="email"
       autocomplete="email" required>

While you are in there, add autocomplete hints. They are part of WCAG 2.2 success criterion 1.3.5 and they make life easier for everyone with a password manager.

Required fields need both required and a visible indication. An asterisk in the label, with a legend at the top of the form that explains what the asterisk means. Do not rely on a red border alone. Colour cannot be the only channel for information.

Minutes 24 to 28: the keyboard pass

Put the mouse down. Press Tab from the address bar. Walk the page.

Three things to look for.

The first Tab should land on a "Skip to main content" link, or on the first interactive element of the header. If you Tab into a header that has eleven nav items and a mega-menu, you have failed the keyboard test before you reach the hero.

Every interactive element should have a visible focus ring. Many themes ship with *:focus { outline: none } because the designer thought it looked tidy. Remove that line. Add a real focus style.

:focus-visible {
  outline: 2px solid #1a56db;
  outline-offset: 2px;
}

You should never get "trapped" inside a widget. If you Tab into a cookie banner, you must be able to Tab out without dismissing it.

This is the test that catches what scanners cannot. axe will not flag a missing focus ring on a custom button. A real human pressing Tab will.

Minutes 28 to 30: verify and write the verklaring

Re-run axe. Confirm green. Screenshot the result for the client. Then write a four-line accessibility statement and link it from the footer.

<a href="/toegankelijkheid">Toegankelijkheidsverklaring</a>

The statement names the standard you target (WCAG 2.2 AA), what is not yet conformant, and an email address where users can report problems. The Dutch government publishes a template at toegankelijkheidsverklaring.nl. Use it. The mere presence of a statement satisfies one of the EAA's procedural requirements.

What we keep finding on Dutch SME sites

Three patterns repeat across the legacy sites we audit. The cookie banner traps keyboard focus and has no programmatic role. The custom dropdown built in jQuery in 2017 is unreachable by keyboard. The PDF brochure linked from the footer was exported from InDesign with no tags, so a screen reader hears one continuous wall of text.

The cookie banner is usually the worst offender because it is the first thing a keyboard or screen-reader user meets. If the client uses a managed provider (Cookiebot, Iubenda), upgrade to the current major version. Every one of them shipped accessibility fixes between 2023 and 2025. If the banner is hand-rolled, replace it with a native <dialog> element and a focus trap you can actually reason about.

Closing the loop with the client

When we rebuilt the marketing site for a Dutch industrial supplier last autumn, the in-house team had spent two weeks chasing axe findings one by one. We collapsed forty of them with a single change to the design tokens and another twelve by replacing a jQuery accordion with a native <details> element. Real WCAG conformance still took a full sprint after that. The first ninety minutes of website work bought back more compliance ground than the prior fortnight had.

Open the client site now, run axe on the homepage, and email yourself the four colour-contrast pairs it flags. Tomorrow morning you will know exactly which CSS variables to change.