Website accessibility in the EU: what the rules mean for a small business

The European Accessibility Act is an EU directive transposed into national law across member states, and its requirements have applied since 28 June 2025. In Estonia this arrives through national accessibility legislation rather than as a separate EU rule you deal with directly.

It does not cover every website. It targets specific products and services sold to consumers, and the categories most relevant to ordinary businesses are e-commerce, banking, transport and ticketing services, telecoms, and e-books.

E-commerce is the broad one. If you sell goods or services to consumers online, you are in scope, whether the store is large or small.

There is a size exemption that many owners miss: micro enterprises providing services are exempt, meaning fewer than ten people and annual turnover or balance sheet total under two million euros. That covers a large part of the small business world, but it applies to services, not to products.

Public sector bodies are a separate story. They have been covered by the earlier Web Accessibility Directive since 2019, with stricter obligations including a published accessibility statement.

Important caveat: an exemption from the law is not an exemption from the users. Roughly one in four adults in Europe has some form of disability, and an inaccessible checkout loses those sales regardless of who is legally obliged to fix it.

The technical benchmark is EN 301 549, which for websites points to WCAG at level AA. That sounds intimidating, but the whole framework rests on four ideas.

Perceivable: everyone can register the content. Images have text alternatives, video has captions, and text contrasts enough with its background to be read.

Operable: everything works without a mouse. Every link, button and form field is reachable and usable with a keyboard alone, and nothing traps the user.

Understandable: the site behaves predictably. Navigation stays consistent, form errors say what went wrong in words, and the page declares its language.

Robust: assistive technology can interpret the page. Correct HTML elements, proper labels, and headings used for structure rather than for making text bigger.

Almost every real world failure falls into one of those four buckets, and most of them come from a handful of repeated mistakes rather than from anything architectural.

In practice a small number of changes resolve the majority of issues found on a typical business site.

• •Text contrast. Light grey on white is the single most common failure. Body text needs a contrast ratio of at least 4.5 to 1 against its background.
• •Alternative text on images. Describe the function or content, and mark purely decorative images as such so screen readers skip them.
• •Form labels. Every field needs a real label element, not just placeholder text that vanishes the moment someone starts typing.
• •Keyboard operation. Tab through your own site. If you cannot reach the menu, close a popup or complete the checkout, neither can a keyboard user.
• •Visible focus. Never remove the outline that shows which element is selected, unless you replace it with something equally clear.
• •Heading order. One H1 per page and no skipped levels, because screen reader users navigate by headings the way sighted users skim.
• •Meaningful link text. Read more tells nobody anything when links are listed out of context.
• •Video captions and a language attribute on the page. Both are quick and both are routinely missing.

Notice that none of these requires a redesign. They are corrections in markup and CSS, and on a normal small site the work is measured in days rather than weeks.

Start with automated tools, which are free and catch roughly a third of issues. Lighthouse is built into Chrome, and axe DevTools or WAVE give more detail.

Do not stop there. Automated testing cannot judge whether alt text is meaningful or whether a page makes sense in order, so manual checks matter more.

Run three manual tests on your most important pages. Unplug the mouse and complete a purchase or an enquiry using only the keyboard. Zoom the browser to 200 per cent and see whether anything breaks. Turn on a screen reader and listen to the homepage.

Prioritise by user journey rather than by page count. The homepage, the main service or product page, the contact form and the checkout carry almost all the risk, both legal and commercial.

Retest after each release. Accessibility regresses easily, because a new plugin, a redesigned button or an added popup can undo a fix silently.

If you are in scope legally, keep a short record of what you tested and when, and publish an accessibility statement. It is required for public sector sites and is a reasonable thing to have either way.

Accessible sites are usually better sites for everyone, and this is not a slogan. Sufficient contrast helps anyone reading a phone in sunlight, and captions help the large share of people who watch video with the sound off.

There is a direct commercial argument. An inaccessible checkout loses customers who wanted to buy, and that is revenue lost quietly, without a complaint to tell you it happened.

The overlap with SEO is substantial. Proper headings, descriptive link text, alt attributes and semantic HTML are exactly what search engines use to understand a page.

It also helps with AI driven search, which relies on structured, well marked up content to extract and cite answers accurately.

One warning: avoid overlay widgets that promise instant compliance with a single script. They do not fix the underlying code, they frequently interfere with the assistive technology people already use, and they have been the subject of legal complaints rather than a defence against them.

The honest approach is cheaper anyway. Fix the markup once and it stays fixed, whereas a subscription overlay costs money every month and leaves the actual problems in place.