One Year of BFSG: Accessibility as a Quality Feature, Not a Checklist

The most effective accessibility measures are general quality measures at the same time. A clear heading hierarchy helps screen reader users and everyone who skims pages. Sufficient contrast helps people with visual impairments and anyone looking at their phone in the sun. Keyboard operability helps users with motor impairments and power users. Plain language helps people with cognitive impairments and your conversion rates.

There is another beneficiary nobody should ignore in 2026: AI systems. Semantic HTML, described images and clear structure are exactly what language models need to capture content correctly. Accessibility and GEO share the same technical foundation: one budget, double effect.

This is rarely cleanly isolatable in numbers, but the direction is consistent in our projects: after accessibility rebuilds, abandonment in form journeys drops, and support requests of the kind "I can't find the submit button" disappear. Nobody complains about a website that is easier to use.

Purchased "accessibility widgets" do not repair broken HTML, they only put a layer on top. In tests with real screen reader users they fail regularly, and as the sole measure they do not hold up legally.

What that looks like in practice, a test in a client project showed us (anonymised, the pattern is typical): a mid-sized company had licensed an overlay and considered the topic done. We walked through the website together with a screen reader user. The widget announced itself verbosely, then came the actual problem. In the contact form, the fields were only audible as "input" because labels were missing, and the submit button was unreachable by keyboard. The overlay's "screen reader mode" changed nothing, because the missing information simply was not in the HTML. The user gave up after four minutes. Every affected person who wants to inquire there experiences those four minutes.

The consequence in that project: the overlay was cancelled and the budget went into repairing forms and navigation. That sounds like more effort, but it was the more sustainable investment. The problems are fixed rather than covered up, and the recurring widget fee is gone.

The inventory is usually bigger than expected, the effort smaller. Most problems concentrate in a few reused components: navigation, forms, teaser cards. If you work component-based (in Drupal as in any modern frontend), you fix one component and heal a hundred pages.

A typical example from one of our projects is the main navigation. Before: menu items as clickable div elements, submenus reachable only by mouse hover, no visible focus. For keyboard users, half the website was out of reach. After: real buttons with aria-expanded, submenus that open and close by keyboard, a clear focus ring. The rebuild affected a single component and took a few development days. It was effective on several hundred pages at once, because they all embed the same navigation. Forms and teaser cards followed the same pattern.

Important for planning: count components, not pages. An audit report with two thousand individual findings often shrinks to 15 to 20 component tickets, and only that number works as the basis for an effort estimate.

Accessibility checks belong in the CI pipeline, otherwise the state is gone again six releases later. At arocom, axe-core runs in Playwright tests against representative page types: homepage, service page, article, form journey. Checked are, among others, contrast, form labels, alt texts, ARIA roles and the heading hierarchy.

This is what a catch looks like: a new teaser card variant came out of design alignment with light text on a light background. The pipeline reported the contrast error right on the pull request, and it was fixed before the merge. Without the check it would have surfaced months later in an audit, spread across dozens of pages. Setting up such checks is manageable: ours were running after a few days, and since then every check costs only compute time.

The automatable third of the WCAG criteria catches exactly these frequent regressions. For the rest, you need periodic manual audits, ideally with people who use assistive technologies every day.

If you start today and have not had an audit yet, this order has proven itself in our projects:

• Week 1: survey the inventory. Do not check all pages, but page types and core journeys: homepage, most important service page, contact or ordering journey. An automated scan plus one manual pass using only the keyboard reveals the most serious barriers.
• Week 2: implement quick wins. Form labels, alt texts for content-bearing images, visible focus states, contrast via central design variables. These points affect most users and are feasible without a redesign.
• Week 3: prioritise components. Map the remaining findings to components and sort by reach: navigation and forms first, rarely used elements later.
• Week 4: lock it in. Add automated checks to the deployment pipeline and, if your offering falls under the BFSG, set up the accessibility statement.

For the budget, as an order of magnitude from our projects: the audit sits in the low five-figure range, the quick wins usually below that, and the component rebuild depends on the state of the frontend. Also name a responsible person from the start who prioritises findings and schedules follow-up work. Without a clear owner, the topic stalls again after week 4.

The very first step costs nothing: put the mouse away and try to submit an inquiry on your own website using only the Tab key. What you experience doing that is your starting point.