Accessible by Law: The European Accessibility Act Has Landed

Your mouse dies on a Tuesday afternoon. Not dramatically. The little light on the bottom just goes out, like a candle in a draught, and the spare batteries are in a drawer in a house you do not live in any more. You have one thing left to do today: renew your car registration before the late fee kicks in at midnight. How hard can it be? You have a keyboard. Keyboards are older than mice. Keyboards won the Cold War.¹

You open the site and press Tab. Something, somewhere, is now selected. You cannot see what. You press Tab again. Still nothing visible, but the page scrolls by itself, which feels like a sign. After eleven presses, a thin blue ring appears around the "Accessibility" link in the footer, which is either irony or a cry for help. You press Tab again and the ring vanishes into the cookie banner, which you cannot close, because its "X" is a picture of an X and the keyboard does not believe in pictures. Twenty minutes later you are on first-name terms with every link in the mega-menu, you have accidentally subscribed to a newsletter about road safety, and the form has rejected your postcode in red text that says only "Error". You begin to wonder whether a carrier pigeon could reach the registry by midnight, and whether pigeons count as a digital channel.

Put the kettle down for a moment. The site is not haunted, and you have not become bad at computers. You have spent one afternoon with the web the way many people use it every day. The World Health Organization estimates that 1.3 billion people, or 1 in 6 of us, experience significant disability. For them, the dead mouse is not a bad Tuesday. It is the default.

As of July 2025, it is also a legal matter. On 28 June, the European Accessibility Act (the EAA) started to apply across the European Union. The Commission's accessibility centre describes it as a law for "more than 440 million European citizens, especially the 100 million people with disabilities living in the EU". It covers banking apps, e-books, ticketing, phones, computers and, for most people reading this, online shops. You do not need an office in Europe for it to apply to you. I am writing this from Tasmania, which is about as far from Brussels as you can get without a spacesuit, and I still had to read it very carefully.

The web is not in great shape for this. In February 2025, WebAIM tested the home pages of the top million websites and found that 94.8% had detectable WCAG failures, at an average of 51 errors per page. Those are only the errors a machine can find.

So here is the plan. First, what kind of law the EAA is. Then the scope question, word by word, with a small Tasmanian tea cosy shop as our test case, and the microenterprise exemption, which is stricter than the summaries suggest. Then what "accessible" means when a lawyer says it, down to what a screen reader actually receives from your page. And finally, the five checks I would run on any site this week, no mouse required.

Let's get into it.

Part 1: A Directive, Not a Rulebook

The first thing to know about the EAA is that, strictly, you cannot break it. It is a directive: a law addressed to the 27 member states, not to you. It tells each country what result its own law must achieve, and leaves each country to write that law. That is different from a regulation, such as the GDPR, which applies directly and word for word in every member state. (I went through the GDPR's effect on analytics in an earlier post, and the contrast is useful: one law for everyone there, 27 national laws here.)

You already know this pattern. A head office sends every branch a memo: "By June, every branch will have a ramp at the front door." It does not say which builder to use, or what happens to a manager who ignores it. Each branch works that out. Most ramps end up about the same. A few get a handrail in the local football colours.

Directive (EU) 2019/882 was adopted on 17 April 2019. It set two dates that people often blur together. Member states had to adopt their national laws by 28 June 2022, and apply them from 28 June 2025.² So the three years between 2022 and 2025 were a runway. This June, the runway ran out.

Who enforces it, and with what

Because each country writes its own law, each country also chooses its enforcers and its penalties. The Directive only says that penalties must be "effective, proportionate and dissuasive", that they must come with remedial action, and that they must take into account how serious the failure is and how many people it affects.

The results vary. Greenberg Traurig's July summary notes that in Germany, authorities "may impose administrative fines of up to EUR 100,000" and can order non-compliant services off the market. Davis Wright Tremaine adds that in at least one member state, criminal penalties may be imposed. And as Covington's June briefing points out, there is no "one stop shop": many countries have appointed more than one authority.

For services, the model is complaint-driven. Each country must set up procedures to check compliance, follow up complaints and verify corrective action. Consumers can take action before the courts or the authorities, and associations or other bodies with a legitimate interest, such as disability organisations, can act on their behalf or in their support. Greenberg Traurig adds that competitors and consumer associations may bring competition-law claims.

So the risk does not arrive as an inspector at your door. It arrives as an email from a customer who could not finish checking out.

Part 2: Does It Cover Your Site?

The EAA's scope is set by a list and a handful of definitions. Most confusion comes from reading the list and skipping the definitions.

The list

The Directive's scope article has two halves. Products placed on the market after 28 June 2025: computers and their operating systems, smartphones and other consumer communications devices, devices for watching TV services, e-readers, and self-service terminals such as payment terminals, ATMs, ticket machines and check-in kiosks. Services provided to consumers after 28 June 2025: phone and messaging services, services that give access to TV and video, parts of air, bus, rail and waterborne passenger transport (websites, apps, e-tickets, travel information), consumer banking, e-books and their software, and e-commerce services.

That last item turns the EAA from "a law for banks and phone makers" into "a law for your website".

The definitions that do the work

Three definitions decide most cases.

E-commerce services are "services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract". Take it apart and you get four tests:

At a distance: you and the customer are not in the same place at the same time.
By electronic means: it happens through a website or app.
At the individual request of a consumer: the customer starts it, for example by adding an item to a cart.
With a view to concluding a consumer contract: the point of the thing is a sale.

A recital (the explanatory text at the front of a directive) then removes any doubt about what can be sold: the e-commerce obligations "should apply to the online sale of any product or service". Not only covered products. Any product. Tea cosies included.

Consumer means a person buying "for purposes which are outside his trade, business, craft or profession". So a purely business-to-business portal, where every buyer is buying for work, falls outside the e-commerce definition. A shop that sells to both businesses and the public does not get to hide behind its trade customers.

Service provider is the definition that reaches overseas. It means "any natural or legal person who provides a service on the Union market or makes offers to provide such a service to consumers in the Union". Nothing in it asks where you are based. Davis Wright Tremaine reads it the same way: the EAA covers economic operators "regardless of the economic operator's home country".

The Directive gives no checklist for "makes offers … to consumers in the Union". My reading, and it is a reading rather than a rule, is that the signs are practical ones: you ship to EU addresses, show prices in euros, offer an EU language or advertise to people in the EU. If a customer in Lyon can put a thing in your cart and have it arrive, you are very probably making an offer.

What is left out

The Directive also lists content it does not cover on websites and apps:

pre-recorded audio and video published before 28 June 2025;
office files (PDFs, spreadsheets and so on) published before 28 June 2025;
online maps, as long as the essential information for maps used for directions is also given in an accessible way;
third-party content that is "neither funded, developed by, or under the control of" the business;
archives: content that is not updated or edited after 28 June 2025.

That third-party exclusion is narrower than it looks. The review widget you pay for, the chatbot you configured and the checkout plug-in you installed are all funded or controlled by you.³

There are transition periods too. Products a service provider already used can stay in use until 28 June 2030, older service contracts can run for up to five years, and, where a member state allows it, existing self-service terminals can stay in use for up to 20 years after they were first used. None of these is a pause for a website you are still changing.

Wren's shop

Let's make it concrete with a made-up person. Wren runs a small online shop from Cygnet, south of Hobart, selling hand-knitted tea cosies.⁴ She sells through her own website. Last year a German tea blog featured her "Huon Pine Green" cosy, and since then about a third of her orders ship to Germany, France and the Netherlands. She added euro prices at checkout to make it easier.

Run the tests. Her site sells at a distance, by electronic means, at the request of a customer, to conclude a sale: it is an e-commerce service. Her customers are buying tea cosies for their kitchens, not for their trade: they are consumers. She ships to them and prices in euros: she is making offers to consumers in the Union. On the definitions alone, her shop is in scope.

A Bruegel-style harbour scene where a small island cottage shop hung with tea cosies sends a rowing boat of parcels across a wide sea towards a crowded distant continent, while a customs clerk with a ledger and a laptop studies a map on the jetty. — *Fig. 1* — It is a long way to row, but the parcels still count. Generated by OpenAI GPT Image.

The microenterprise exemption, read properly

Wren has heard that small businesses are exempt. Some summaries say microenterprises are "exempt from many EAA requirements". The Directive is more exact, which is both better and worse news.

The better news: "Microenterprises providing services shall be exempt from complying with the accessibility requirements" for services, and from the obligations that go with them. For a service provider that qualifies, it is a full exemption from the service requirements, not a partial one. The recital explains the reasoning, and it is rather charming for EU law: for microenterprises, even "demanding such an assessment … would in itself constitute a disproportionate burden". In other words, asking a tiny business to write a report on whether compliance is too much work is, itself, too much work.

The worse news comes in two parts. First, the full exemption covers services only. Microenterprises that make, import or distribute covered products get lighter duties, such as not having to write up certain assessments, but they are not exempt. Second, "microenterprise" is a defined term, and the definition is stricter than "we're pretty small".

The Directive defines a microenterprise as one that "employs fewer than 10 persons and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million". And a recital adds that, to benefit, businesses "must genuinely fulfil the requirements of Commission Recommendation 2003/361/EC", the EU's general definition of small businesses. That Recommendation is where the detail lives.

How the EU counts your staff

The Recommendation does not count people. It counts annual work units (AWU): one AWU is one person working full-time for the whole year. Part-time and seasonal staff count as fractions. Owner-managers count. Partners who work regularly in the business and share in its profits count. Apprentices and students on a vocational training contract do not, and parental leave is not counted.

Wren works full-time (1 AWU). Two knitters at half-time add 1 AWU, and a Christmas packer adds about 0.2. That is 2.2 AWU, well under 10, and her turnover is far below €2 million. So far, so micro.

How the EU counts your owners

Now the part that catches people. The Recommendation looks through your ownership. If another business holds 25% or more of yours, or you hold 25% or more of another, you are partner enterprises, and you must add in a share of their staff and money, in proportion to the holding. If one business controls another (a majority of the voting rights, the right to appoint most of the board, or a contract giving dominant influence), they are linked enterprises, and you add in all of their figures. There are carve-outs for some investors, such as business angels below a set amount and universities.

Suppose Wren's cousin's homewares company, with 60 staff, bought 60% of the shop last year to help with the German orders. The shop is now linked to a 60-person company. For the purposes of the definition, it is no longer a microenterprise, whatever the headcount at the cottage. One more rule protects against wobble: a business only changes category if it crosses a ceiling in two consecutive accounting periods. One excellent Christmas does not move you.

One more note before we leave Wren. The exemption is from the EU's law, not from her customers. A customer who cannot use her checkout still cannot use it, and if she grows past the ceilings, the law applies to whatever site she has on that day.

"Too hard" is a process, not an excuse

For everyone who is not a microenterprise, the Directive does have a safety valve. The requirements apply only to the extent that compliance does not require a change that results in "the fundamental alteration of its basic nature", and does not impose "a disproportionate burden".

This is a process with paperwork, not a box you tick. You assess against the criteria in Annex VI, which mostly compare the net cost of accessibility with your overall costs. You document the assessment and keep it for five years. For a service, you renew it when the service changes, when an authority asks, and at least every five years. You tell the authorities you rely on it. And if you received funding to improve accessibility, you cannot use the burden defence at all.

The page you probably have not written

One obligation is easy to miss because it is not about the interface at all. Service providers must explain how their services meet the accessibility requirements, and make that information public in written and oral form, in a way that is accessible itself. Annex V says where: "in the general terms and conditions, or equivalent document". It should describe the service in accessible formats, explain how it works, and describe how it meets the requirements.

So a page in your terms, or linked from them, now has to exist. It is also the first thing a complainant will read.

Part 3: What "Accessible" Means When a Lawyer Says It

So what does your site actually have to do? Most summaries wave a hand and say "WCAG". The chain from the law to your code has three links.

Link 1: the Directive's words

The Directive does not mention WCAG. For services, it says websites and apps must be made accessible "in a consistent and adequate way by making them perceivable, operable, understandable and robust". A recital defines the four words, borrowing them from the EU's earlier law for public sector websites. Perceivable: people can perceive the information and interface. Operable: people can use the controls and move around. Understandable: the information and the interface make sense. Robust: the content works reliably with a wide range of software, including assistive technologies.

Annex I goes a little further for services in general. Information must be available through more than one sense, with text alternatives for non-text content, fonts of adequate size, "sufficient contrast", and adjustable spacing between letters, lines and paragraphs. Support services such as help desks must give accessibility information in accessible ways. And for e-commerce specifically, the identification, security and payment functions must be perceivable, operable, understandable and robust.⁵ In plain terms: your login, your checkout and your payment step are named in the law.

Link 2: the standard

Nobody can build to "perceivable". So the Directive uses a long-standing EU mechanism: harmonised standards. If your service conforms to a harmonised standard whose reference is published in the EU's Official Journal, it is presumed to conform to the Directive, to the extent the standard covers the requirements. You do not have to use the standard. But if you do, the burden of proof shifts in your favour.

The Commission asked the European standards bodies to prepare harmonised standards for the EAA, and one of them is EN 301 549, the European standard for the accessibility of ICT products and services. The current version, V3.2.1 from March 2021, was written for the public sector website law, not the EAA. Covington notes that the Commission chose to update EN 301 549 to align with the EAA, and that the revision "is due to be adopted by September 2025". So as of July 2025, there is a well-known standard and a revision on the way.

A Flemish-style market square where a wheelchair user, a man with a cane, a blind pedlar with a guide dog and a mother with a pram pass up a wide ramp through a town gate, while a herald in a blue tabard with gold stars unrolls a scroll beside a glowing laptop on a trestle table. — *Fig. 2*

Link 3: the success criteria

Clause 9 of EN 301 549 is the web chapter, and it contains the sentence that ties everything together: conformance with WCAG 2.1 Level AA "is equivalent to conforming with all of clauses 9.1 to 9.4 and the conformance requirements of clause 9.6". Clause 9 repeats WCAG criterion by criterion ("Where ICT is a web page, it shall satisfy WCAG 2.1 Success Criterion 1.1.1 Non-text content"), and clauses 10 and 11 apply similar rules to documents and to software, including native apps.

WCAG, the Web Content Accessibility Guidelines, is the W3C's standard for accessible web content. It is organised under the same four principles, perceivable, operable, understandable and robust, and each guideline has testable success criteria at three levels: A (lowest), AA and AAA (highest). Level AA means meeting every A and AA criterion. AAA is not the target: EN 301 549 quotes the W3C's own advice that it is "not recommended that Level AAA conformance be required as a general policy for entire sites", because some content cannot meet all of it.

EN 301 549 clause 9.6 also carries over WCAG's five conformance requirements, and two of them matter more than people expect. Full pages: a page conforms only if all of it conforms, so an inaccessible widget fails the page. Complete processes: if a page is one step of a process, such as a checkout, every step must conform. An accessible product page followed by an inaccessible payment step is an inaccessible purchase.

WCAG 2.1 or 2.2?

WCAG 2.2 became a W3C Recommendation in October 2023 (the current edition is dated 12 December 2024). It is backwards compatible: "Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1". It adds nine success criteria. Four are at Level AA, and three of those matter on almost every commercial site:

2.4.11 Focus Not Obscured (Minimum): when something receives keyboard focus, it is not entirely hidden by author-created content. (Yes, that means your sticky header and your cookie banner.)
2.5.8 Target Size (Minimum): pointer targets are at least 24 by 24 CSS pixels, with some exceptions.
3.3.8 Accessible Authentication (Minimum): logging in does not depend on a cognitive function test, such as remembering a password or solving a puzzle, unless an alternative or a helping mechanism is available.

It also removes one: 4.1.1 Parsing is now "obsolete and removed". EN 301 549 V3.2.1 still lists it as clause 9.4.1.1, so for now it stays on the checklist.

My advice as of July 2025: treat WCAG 2.1 AA as the floor the current standard sets, and build to WCAG 2.2 AA. The W3C's working group recommends 2.2 as the target "even if formal obligations mention previous versions", and the extra work is small. (I wrote about ranking must-haves against nice-to-haves a while ago. Here, the must-haves are already written down for you.)

A Bosch-style cutaway of a hall: upstairs, gilded decorations and feasting nobles; in the cellar below, clerks hold plain wooden tags for each object while a blind scribe with an owl-eared creature listens, and one clerk shrugs over a blank tag beside a server cabinet. — *Fig. 3* — Upstairs is the website. Downstairs is what the screen reader gets. Generated by OpenAI GPT Image.

To understand why the checks in Part 4 work, you need to see the page the way assistive technology sees it. And you already know the idea, from any time you have described a room to someone over the phone. You do not describe the wallpaper. You say what things are and what they do: "There's a door on your left. It's locked. The light switch is next to it."

Your browser does the same for every page. From the HTML, it builds a second, invisible structure called the accessibility tree. The WAI-ARIA specification defines it as a tree of accessible objects that represents the structure of the user interface, where each node is one element (a button, a checkbox, a container) as exposed through the operating system's accessibility API. Those APIs have names only a developer could love: UI Automation and MSAA on Windows, AXAPI on macOS, ATK and AT-SPI on Linux. A screen reader never sees your pixels. It asks the API, and the API reads from the tree.

Each node carries a small set of facts. The two that matter most are the role (what kind of thing it is: link, button, text box, heading) and the accessible name (what it is called). The specification's own example is an "OK" button: when it receives focus, a screen reader may speak "push-button OK", which is the role and the name, joined.

That is the real mechanism under most accessibility failures. A button made of a picture of an X has a role but no name, so the screen reader says "button" and the user has to guess. A text box with only a grey hint inside has a role, but its name may be empty. A div styled to look like a button has no button role at all, and the keyboard skips it. The upstairs room is beautiful. The cellar has a clerk holding a blank tag.

WCAG turns this into criteria. 1.3.1 Info and Relationships says that structure shown visually "can be programmatically determined". 4.1.2 Name, Role, Value says that for all interface components, "the name and role can be programmatically determined". "Programmatically determined" is WCAG for "it is in the tree". Most of the fixes in Part 4 are ways of putting the right name and role in the tree.

A word on overlays

You will be offered a shortcut: one line of script, a small icon in the corner, and a promise of compliance. In April 2025, the US Federal Trade Commission finalised an order requiring accessiBe to pay $1 million, and it bars the company from representing that its automated products can make any website WCAG-compliant without evidence. That was a US consumer-protection case, not an EAA case, but the point carries: a script that paints over the upstairs room does not fix the cellar.

Part 4: The First Five Checks

A Flemish village street on inspection day where five black-hatted inspectors each test a shopfront differently: one pushes doors with his shoulder, one looks at a faded sign through smoked glass, one frowns at unlabelled jars, one describes a painting to a blindfolded apprentice, and one holds up a slate of words beside a singing minstrel. — *Fig. 4* — Five inspectors, no mouse between them. Generated by OpenAI GPT Image.

A full audit against WCAG 2.1 AA covers dozens of criteria. But you do not need an audit to find out whether you have a problem. Do these five checks by hand on your five most important pages: home, a product page, the cart, the checkout and the login. I picked them because they match the most common failures WebAIM found and the steps the law names.

WebAIM's warning applies here too: "not all conformance failures can be automatically detected". Run an automated checker as well, by all means. It is a smoke alarm, not a building inspection.

Check 1: Put the mouse in a drawer

This is the dead-mouse Tuesday, on purpose. The W3C's Easy Checks give the method: click in the address bar, put the mouse aside and do not use it, then press Tab to move forward through the page, Shift-Tab to go back, arrow keys inside menus and lists, and Enter or Space to activate things. (On a Mac, you may first need to turn on keyboard access to all controls in System Settings.)

Go through a whole purchase that way, and look for four things:

Can you reach and use everything? 2.1.1 Keyboard requires that "All functionality of the content is operable through a keyboard interface". Menus that open only on hover, and custom dropdowns built from divs, are the usual failures.
Can you always get out? 2.1.2 No Keyboard Trap: if focus can move into a component, it can move out with the keyboard. Embedded video players, date pickers and chat widgets are the classic traps.
Does the order make sense? 2.4.3 Focus Order: focus moves in an order that "preserves meaning and operability". If focus jumps from the header to the footer and back to the price, something in the layout is out of step with the HTML.
Can you see where you are? 2.4.7 Focus Visible requires a visible focus indicator. In my experience, the most common cause of an invisible focus is one line of CSS, outline: none, added years ago because someone found the outline ugly. Put a clear focus style back. And check 2.4.11 while you are there: does the sticky header or cookie banner cover the focused item?

If you do only one check this week, do this one.⁶

Check 2: Contrast, with a real number

Low-contrast text was the most common failure in the WebAIM Million, on 79.1% of home pages. It is also the one people argue about, because "it looks fine to me" is very persuasive to whoever picked the grey.

You already know that pale grey text on white is hard to read in sunlight or with tired eyes. Now give it a number. 1.4.3 Contrast (Minimum) requires "a contrast ratio of at least 4.5:1" for normal text, and at least 3:1 for large text, which WCAG defines as at least 18 point, or 14 point bold. 1.4.11 Non-text Contrast requires 3:1 for the parts of interface components and graphics that people need to see, such as the border of a text box or the icon in a button.

Now the mechanism. The ratio is not a matter of taste. It is arithmetic on relative luminance, which WCAG defines as the relative brightness of a colour, from 0 for black to 1 for white. The formula accounts for the fact that our eyes are far more sensitive to green than to blue: for a colour in the standard sRGB space, luminance is 0.2126 × R + 0.7152 × G + 0.0722 × B, after each channel has been converted from its 0 to 255 value to a linear light value. Then the contrast ratio is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter colour. The ratio runs from 1:1 (no contrast) to 21:1 (black on white).

Here it gets pleasingly exact. Grey #767676 on white works out at 4.54:1, and passes. Grey #777777, one step lighter in every channel, works out at 4.48:1, and fails. You cannot see the difference. The standard can.⁷ That is the reason to measure rather than to eyeball. Any contrast checker (there are good free ones, and your browser's developer tools will show the ratio for text) will do the arithmetic for you.

Check body text, text over images, placeholder text and the focus indicator you just restored.

Check 3: Forms that talk

Missing form labels turned up on 48.2% of home pages, and empty buttons (buttons with no accessible name) on 29.6%. Forms are also where the money is. Remember that the law names identification, security and payment, and WCAG requires complete processes.

The criteria are plain:

3.3.2 Labels or Instructions: "Labels or instructions are provided when content requires user input."
3.3.1 Error Identification: if an input error is detected, "the item that is in error is identified and the error is described to the user in text."
4.1.2 Name, Role, Value, from Part 3: every field and button has a name in the tree.

In practice:

Every field has a real label, connected to it in the HTML (a <label for="…"> element, or the field wrapped in its label). Placeholder text is not a label: it disappears as soon as someone starts typing.
Every icon button has a name. The magnifying-glass search button, the "X" on the cookie banner, the wishlist heart. With no visible text, each needs an accessible name, for example from aria-label.
Errors are in words, next to the field. "Error" in red at the top of the page is not enough. "Postcode must be four digits" beside the postcode field is. Colour alone is not enough either.
Login does not demand a memory test. Allow password managers to fill in the password field and allow paste. Offer an alternative to a puzzle CAPTCHA. That is WCAG 2.2's 3.3.8, and it is the sort of thing a frustrated customer mentions in a complaint.

A quick test with no tools: click the text of each label. If the cursor jumps into the field, they are connected. If nothing happens, a screen reader user may hear only "edit text".

Check 4: Alt text that does a job

Missing alternative text for images was on 55.5% of home pages. 1.1.1 Non-text Content requires that "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose". The words that matter are "equivalent purpose".

Go back to describing a room over the phone. You would not say "image, image, image, photo of product, DSC_0042.jpg". You would say what the listener needs. So:

Product photos describe the product as a customer would need it: "Green hand-knitted tea cosy with a cream pom-pom, on a brown teapot." Not "tea cosy", and not a paragraph of marketing.
Images that are links or buttons describe the destination or action. A logo that links home is "NEOBADGER home", not "logo".
Decorative images get an empty alt attribute (alt=""), which tells assistive technology to skip them. Leaving the attribute out entirely is different, and some screen readers may then fall back to reading the file name.
Images of text should usually be real text. If not, the alt text repeats the words.

Mechanically, the alt attribute becomes the image's accessible name in the tree. That is all it is, and that is why it matters.

Check 5: Captions that are actually right

Pre-recorded video published before 28 June 2025 is outside the EAA. Everything you publish from now on is not. 1.2.2 Captions (Prerecorded) requires that "Captions are provided for all prerecorded audio content in synchronized media". Level AA adds captions for live video and audio description: extra narration of visual information the soundtrack does not explain.

The trap is automatic captions. They are free and nearly right, and "nearly right" is the problem. The W3C is blunt about it: "Automatic captions are not sufficient for accessibility because they are not accurate enough." Use them as a first draft, then correct them by hand, especially names, numbers and product terms. A caption that turns "Huon pine" into "you on pine" is funny once.

While you are there, check that the video player itself passes Check 1: can you play, pause, turn captions on and adjust the volume with the keyboard alone?

Wren's week

Back to Cygnet. Suppose Wren decides that, exemption or not, she wants her shop to work for everyone who wants a tea cosy. Here is a realistic week:

Monday: she does the mouse-in-a-drawer test on her five pages. The "Add to cart" button works, but the size selector is a custom dropdown she cannot open from the keyboard, and the focus ring is invisible everywhere. She notes both.
Tuesday: she checks contrast. Her pale sage prices on cream fail at about 2.5:1. She darkens them until they pass 4.5:1 and, to her surprise, likes them better.
Wednesday: she clicks every form label. The newsletter field has only placeholder text, and the search button is a magnifying glass with no name. Both go on the list for her developer.
Thursday: she rewrites the alt text for her 40 product photos, which takes a pot of tea and a half. She sets the decorative knitting-pattern borders to alt="".
Friday: she corrects the automatic captions on her one "how to measure your teapot" video, and drafts a short accessibility page linked from her terms, saying what she has tested, what she has fixed, what is still in progress, and how customers can contact her if something does not work.

None of that is a full audit. All of it is real improvement, and her developer gets a list specific enough to quote on.

If you are not Wren

If you are larger than a microenterprise, sell a covered product, or run banking, ticketing or e-book services, the five checks are only the start. The next steps, in my order:

Confirm your scope in writing, service by service, using the definitions in Part 2. Keep the reasoning.
Commission a full audit against WCAG 2.1 AA via EN 301 549, including your apps and the documents you publish, and ask for 2.2 AA results as well.
Write the Annex V information into your terms, or a document your terms link to.
If you plan to rely on disproportionate burden anywhere, do the Annex VI assessment properly, document it, and diarise the renewal.
Build accessibility into your release process, because the Directive expects procedures that keep the service in conformity as it changes. A one-off fix decays the next time someone redesigns the checkout.

If you are an Australian business, the pattern may feel familiar from privacy law. When I wrote about Australia's privacy law overhaul, the lesson was the same one: read the definitions first, because they decide whether the rest of the law is about you.

Final Thoughts

Go back to the dead mouse and the registration site. Every failure that afternoon was one of our five checks: the invisible focus, the trap in the cookie banner, the "X" with no name, the red word "Error". None needed new technology. They needed someone to try the site without a mouse, once, and write down what went wrong.

If you remember one thing, make it this: the EAA is not about where your business is. It is about where your customer is. If you sell to consumers in the EU through a website or an app, the law now expects that site to be perceivable, operable, understandable and robust, and the practical meaning of that is WCAG 2.1 Level AA today, with 2.2 as the sensible target. The microenterprise exemption is real, but it covers services only, and it measures your staff in work units and looks through your owners.

So this week, put your mouse in a drawer and try to buy something from yourself. Then measure one grey, click one label, read one alt attribute and watch one video with the sound off. It will tell you more about your exposure than any summary, including this one.

Now, if you'll excuse me, I am going to go and check the focus ring on my own contact form. Then I am going to make a pot of tea, and I will be doing it without a mouse, because I have just realised where I put the spare batteries.

Notes

I promise this is only a small exaggeration. The Moscow–Washington "hotline", set up in 1963 after the Cuban Missile Crisis, was never a red telephone. It was a pair of teleprinters: text only, because speech might be misunderstood, typed on keyboards in Latin and Cyrillic. Wikipedia has the full story, including the move to fax in 1986 and to secure email in 2008. ↩
Some summaries say member states had to implement the EAA "by June 28, 2025". The Directive's text separates the two steps: adopt national laws by 28 June 2022, and apply them from 28 June 2025. ↩
The EAA's exclusion covers third-party content "neither funded, developed by, or under the control of" the business. A review widget you pay for, or a chatbot you configure, is funded or controlled by you, so the exclusion is unlikely to help. ↩
Wren and her shop are invented for this article. The tea cosies are, sadly, also invented, though I would buy a Huon Pine Green one without hesitation. ↩
The EAA's banking requirements go further on language: information must not be more complex than level B2 (upper intermediate) of the Council of Europe's language framework. That is a reading level, written into law, for consumer banking information. ↩
WCAG's definition of a keyboard interface covers more than keyboards: it includes software that sends keystrokes, such as handwriting and speech-to-text tools with keyboard emulation. So a keyboard failure can also lock out people who never touch a keyboard. ↩
By my arithmetic with the WCAG formula, #767676 is the lightest even grey (the same value in red, green and blue) that passes 4.5:1 on white. It is a small thing to know, and it settles more design meetings than you would think. ↩