Web accessibility: what the rules require and how to set up serious work

Since 28 June 2025, web accessibility is no longer just good practice for many private sites: the European Accessibility Act makes it a requirement for a range of digital services aimed at consumers, starting with e-commerce. The basic definitions are everywhere. Here I focus on what it really involves technically and how to set up work that holds up to an assessment.

The regulatory picture, with caution

I am not a lawyer and the exact scope must be checked with an adviser. The technical picture, however, is clear.

• Public sector: obligations in force for years, with an accessibility statement and a feedback mechanism.
• European Accessibility Act (Directive 2019/882): applies to products and services listed in the directive, including consumer e-commerce, banking services, transport, e-books and electronic communications. Microenterprises providing services are exempt.
• Technical reference standard: EN 301 549, which for the web points to WCAG 2.1 level AA.

The practical point: for those in scope, "doing your best" is not enough. You need conformance to verifiable criteria, documented and maintained over time.

What WCAG really asks

Level AA includes about fifty success criteria. The ones that, in my experience, most often make an audit fail:

• 1.4.3 and 1.4.11 – contrast of text and non-text components (field borders, icons, focus states);
• 2.1.1 – keyboard: everything must be usable without a mouse, including menus, modals, sliders and carousels;
• 2.4.7 and 2.4.11 – focus visible and not obscured by sticky headers or banners;
• 4.1.2 – name, role, value: every custom control must expose what it is and what state it is in;
• 3.3.1 and 3.3.3 – form errors identified and explained;
• 1.3.1 – info and relationships: heading structure, lists, tables and label-field association in the code, not just in appearance.

WCAG 2.2 adds criteria such as minimum target size and authentication without cognitive tests. Designing to 2.2 already costs little and anticipates the next revision of the standard.

Where problems come from

Accessibility is decided in three places, and fixing it downstream always costs more.

• In design: palettes with insufficient contrast, focus states never drawn, information conveyed by colour alone, small targets on mobile.
• In components: dropdowns, modals, tabs and carousels built from clickable divs instead of native elements, without focus management or correct ARIA. One wrong component repeats the mistake on every page.
• In content: missing or redundant alt text, headings chosen for looks, "click here" links, untagged PDFs.

For the detailed list of recurring mistakes, see Accessible website: the 10 most common mistakes.

Why overlays are not a solution

Widgets adding an "accessibility" button with high contrast, zoom and text-to-speech promise compliance with one line of code. That is not how it works: they do not change semantics, do not add correct accessible names, and do not fix focus management or forms. Screen reader users already have their own tools, often better ones, and an overlay can interfere with them. Several disability organisations explicitly advise against them.

How I set up an audit that holds up

1. Representative sample: not every page, but every template and every critical flow (sign-up, checkout, contact forms, account area).
2. Automated testing with axe or equivalent tools: it finds part of the problems, the mechanical part.
3. Manual keyboard testing on every flow, focusing on focus order and visibility, traps and modals.
4. Screen reader testing (VoiceOver, NVDA) on components and forms.
5. Zoom and reflow testing at 400% and with increased text spacing.
6. Report by WCAG criterion, prioritised: first whatever blocks a task, then the rest.
7. Fixes in the components, so the fix spreads across the whole site.
8. Accessibility statement and a review procedure for new pages.

Keeping it over time

Accessibility degrades with every new piece of content and every new component. What works are process measures: automated checks in the publishing pipeline, a checklist for content writers, a manual review for each new template, and a channel for user feedback.

My take

For me, accessibility is first of all a matter of code quality. If components are built with native elements, manage focus and respect preferences such as reduced motion, much of the criteria are met with no extra effort. That is what I aim for in my projects: components written once, with focus and error states already thought through, reused everywhere.

The problem with sites built by accumulation, with builders and plugins from different sources, is that each piece has its own idea of accessibility and there is no single place to fix things. There, the audit becomes an endless list. On a coherent component system, one fix applies to the whole site.

Finally, I see accessibility as a good indicator of a site's overall quality: when it is cared for, structure, performance and maintainability usually are too.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I run WCAG audits with automated tools, keyboard checks and screen readers, and fix problems where they start, in the components. I do not issue certifications: I deliver a report by criterion and the work done. For the legal scope, it is worth involving an adviser.

If you need to know where your site stands, get in touch: in a call of about 20 minutes we define the sample to check and the priorities. The service is in Web accessibility: WCAG audit and fixes.