The report usually looks the same. Someone from outside writes that the contact form cannot be filled in with a keyboard, or the legal department sends an email about the obligation to provide accessibility. The company’s first reflex? Find a plugin that will settle the matter over the weekend. And WCAG for companies is an engineering matter, not a legal one – the criteria describe specific interface behaviors that are either in the code or are not.
In audits of company websites built without a thought for accessibility I see the same picture over and over: a nice layout, visually flawless, and underneath it divs pretending to be buttons, a form with no labels and a modal that a screen reader cannot get out of. The fix is not about adding a separate “version for people with disabilities”. It touches templates, shared components and the way the editorial team publishes content.
Table of contents
Where to start: an audit that tells you what to fix
A sensible audit separates two layers. Automated tests catch part of the technical problems: missing attributes, contrast that is too low, fields with no associated label, errors in the structure of the document. A cheap and fast layer, the one I run first. But it closes only a fragment of the list.
The rest calls for human judgment. No scanner will tell you whether the alternative text really describes the chart. Or whether the focus order matches the visual logic of the page. Or whether the label “Select” means anything to someone who cannot see the layout next to it. And the criteria on understandability and on avoiding redundant entry have no automated rules at all.
A typical mistake is treating a report from a tool as a task list sorted by number of occurrences. It is better to do it differently: a website audit for key templates limited to the ones that matter, the home page, a listing, a service page and the contact form, meaning the paths a user actually walks. Instead of grinding through every subpage.
Accessibility overlays and widgets: why they do not work
An overlay is a script that, once the page has loaded, changes how it looks in the browser: it enlarges the font, inverts colors, adds a panel with sliders. The source HTML stays untouched. Which means everything that follows from a bad document structure is still broken: wrong semantics, missing labels in forms, focus traps, modals that cannot be closed with the Escape key.
On top of that comes the maintenance risk nobody mentions at the point of sale. The script overrides styles and intercepts events, so subsequent frontend releases start behaving unpredictably, and diagnosing such a conflict can cost more than the fix itself. Compare that with the alternative: the same money spent on components stays in the project for good and works on every following subpage. I take the same approach to modernizing older web applications, where patching symptoms usually comes back after a few months.
The technical layer: what exactly we change in the code
The foundation is HTML semantics. Headings form a hierarchy that describes the document, lists are lists, a button is a button element, and a link is an a tag with a meaningful address. Boring? Maybe. But that single decision removes more barriers than any number of ARIA attributes glued on later.
The second area is forms, the place where a company loses leads. The label has to be associated with the field programmatically, the error message has to appear next to the field and be announced by the screen reader, and the state of a field cannot depend on the color of its border alone. The third area is the keyboard: visible focus, a predictable tab order, a skip link, correct opening and closing of modals and menus.
The set of fixes I start with in a typical WordPress project or in a frontend application:
- cleaning up the heading hierarchy in theme templates and in editor blocks,
- replacing clickable divs and spans with native buttons and links,
- labels, descriptions and error messages in every form, including the newsletter and the search box,
- restoring the visible focus style removed by a CSS reset,
- keyboard support in menus, carousels, tabs and modals,
- contrast of text and of interface elements, including hover and disabled states,
- checking the layout at 200 percent zoom and with content reflowing on a narrow screen.
Content and editing: this is where accessibility breaks after launch
The contractor hands over a clean template, and six months later the site has hundreds of errors again. The reason is mundane: alternative texts are written by the editorial team, not by a developer. A decorative photo should have an empty alt attribute so that the screen reader skips it. An infographic with data needs a description conveying the same information as the graphic. Two different situations, two different decisions.
The second typical regression is headings used as a formatting tool. An editor picks H3 because it has the right size, and the structure of the document stops meaning anything for heading navigation. Video material without captions, scanned PDFs and graphics with embedded text, published over the years, also tend to become permanent debt.
The solution is a matter of process, not technology. Validation in the CMS that blocks publishing an image without a decision about its description, a short checklist at publication time, training for the editorial team. That gives a more durable effect than a one-off audit closed with a PDF report.
Maintenance: accessibility as part of the process
Regression is the norm, not an accident. Every new campaign landing page, every plugin and every integration can undo earlier fixes, usually quietly. That is why automated accessibility tests wired into CI pay off even with a modest scope. They catch the most common errors before they reach production, and they cost a fraction of a manual review.
The second thing is a definition of done extended with keyboard support and semantics, checked at handover rather than at the next audit. And then a separate category: elements the site’s contractor does not fully control. Chat widgets, maps, booking systems, payment gateways. Usually the weakest link in the whole conversion path, which is why with API and third-party service integrations I check the provider’s accessibility before choosing, not after the rollout.
Costs and order of work: what drives the budget
The cost splits into four parts: the audit, fixes in shared components, fixes in the content, and tests together with regression control. The proportions between them depend mainly on how the frontend is built. The number of subpages matters less here than everyone assumes.
The budget goes up when there is no component system and the same button exists in several variants. Then: many template variations made ad hoc for campaigns, an old theme with layers of overridden styles, unusual interactive elements written from scratch. It goes down in the opposite situation, where one fix in a component propagates to every view, and architectural decisions made at the design stage cost many times less than a correction after launch. For the same reason, building websites with accessibility in the requirements works out cheaper than adding it later.
It also happens that fixes stop paying off. If the theme is unsupported and every change breaks the layout somewhere else, it is more reasonable to plan a frontend rebuild and close the performance and security topics along the way.
Summary: what to do first
The practical shortcut looks like this: an audit of the key templates instead of the whole site, fixes in components instead of on individual subpages, an orderly content publishing process and regression control wired into the team’s daily work.
Keep your expectations realistic while you are at it. Accessibility reduces the number of barriers and the legal risk, but it is not a certificate issued once and for all, it is a state maintained together with the site. If you are planning an audit, frontend fixes, integrations or the modernization of an existing system, write to us and let’s go through the scope in concrete terms. If what matters to you is ending up with websites that meet WCAG rather than with a report alone, let’s start with a review of the key templates.
