The EU AI Act Is Now in Force — Where Accessibility Hooks In

AI regulation news usually sounds like someone else’s problem. Banned use cases, fines as a percentage of revenue — that reads like legal’s department, not ours.

But a provision that takes effect on August 2 contains this sentence:

Ensure that high-risk AI systems comply with the accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882

Those two directives are the Web Accessibility Directive and the European Accessibility Act (EAA). In other words, an AI regulation has pulled accessibility standards into itself. Whether you’re building an AI system or deploying one, once it’s classified as high-risk, accessibility stops being “nice to have” and becomes a conformity assessment item.

This post is a record of what that provision actually says, and what changes for developers on the ground.

What this post covers

• What exactly starts on August 2 (and what doesn’t yet)
• Where and how the accessibility provision is embedded
• What counts as “high-risk” — and whether what you’re building qualifies
• What this actually means for developers here in Korea

What starts on August 2

Let’s start with the timeline. The EU AI Act didn’t switch on all at once — it’s been rolling out in phases.

What’s switching on this time is the Annex III high-risk list. It covers areas like employment, education, credit scoring, and access to public services — places where AI decides something about a person’s opportunities.

One thing worth flagging: systems already on the market before August 2 aren’t retroactively covered right away, as long as their design doesn’t change significantly. But anything newly built or substantially modified from here on is in scope.

And Annex I (high-risk systems embedded in products, like machinery or medical devices) still has a year to go. News coverage tends to lump this all together as “the AI Act is fully in force,” but strictly speaking, one piece is still missing.

Where the accessibility provision lives

The key is Article 16. It lists the obligations of providers of high-risk AI systems — quality management systems, technical documentation, conformity assessment, CE marking — and accessibility is tacked on at the end of that list.

The placement matters. It means accessibility sits in the same list as the other mandatory obligations, not in some separate recommendation document. Just as you can’t skip CE marking, accessibility now sits at the same level.

The two referenced directives are:

• (EU) 2016/2102 — the accessibility directive for public sector websites and apps
• (EU) 2019/882 — the European Accessibility Act (EAA), which extends accessibility obligations into the private sector: e-commerce, e-books, banking services, and more

The EAA in particular has already shown teeth. Back in June, a French court ordered the retailer Carrefour to make its website and app accessible within six months, rejecting the company’s defense that it was “71% compliant” — the ruling held that “somewhat accessible isn’t enough.” I covered that case in more detail in Inside the Carrefour Ruling.

So Article 16 of the AI Act isn’t inventing a new accessibility standard. It’s closer to pulling an already-enforced standard into the AI space and wiring it in.

What counts as “high-risk”

This is where most developers’ curiosity lands. Is what I’m building high-risk?

The AI Act sorts risk into four tiers: practices that are outright banned (like social scoring), high-risk uses (employment, education, credit scoring), uses with only transparency obligations (chatbots, for instance), and minimal risk (spam filters and the like).

Most frontend work — building a blog, a shopping site — isn’t high-risk. But if you’re building any of the following, it’s worth a second look:

• Hiring systems that screen or rank applicants
• Education services involved in exam scoring or admissions decisions
• Financial screens that show loan approval or credit assessment results
• Government services that determine eligibility for benefits or welfare

Look at that list and a pattern emerges: the person on the receiving end of the decision is often the more vulnerable party. Job seekers, students, loan applicants, welfare recipients. And naturally, some of those people have disabilities.

That’s why the accessibility provision landed specifically on high-risk systems. The more AI gets involved in deciding a person’s opportunities, the more everyone needs to be able to access that process and its outcome. If someone can’t read the decision well enough to appeal it, that’s an accessibility problem — and a rights problem at the same time.

What actually changes for developers

Enough about the law — let’s get down to code. What changes in practice is more concrete than you’d expect.

First, the output of AI features is also within scope for accessibility. That’s the point where the model’s result gets rendered on screen. Say a review result arrives asynchronously and only part of the page updates — to a screen reader user, nothing appears to have happened at all. This is a textbook case for announcing the change with a live region.

Second, “AI-generated UI” isn’t exempt either. It’s increasingly common to hand off UI code generation to AI, but there’s no guarantee the generated markup respects accessibility. Buttons built from <div>, alt text that misses the context, ARIA attributes sprayed on without need — these are the usual suspects. In fact, the growing gap in per-page accessibility errors across the top million sites over the past year points to this exact speed problem.

Third, documentation is required. Article 16 demands technical documentation alongside conformity assessment. That means it’s not enough to say “we handled accessibility” — there needs to be a record of what was checked, against what standard. Automated scan results alone aren’t sufficient; some items require human judgment. WCAG-EM 2.0 defines a standard methodology for exactly this kind of evaluation.

How Korea differs — comparing with the AI Framework Act

A natural question follows: Korea has its own AI Framework Act — is it similar?

Short answer: the areas covered are nearly identical, but accessibility sits in a different place.

The timing is the first interesting bit. Korea is ahead by about six months. The AI Framework Act has already been in force since January 22. Contrary to the impression that Europe leads on this, at least the clock started running here first.

The covered domains overlap substantially too. The EU’s Annex III high-risk list and Korea’s “high-impact AI” (AI with significant effects on life, body, or fundamental rights) point at similar territory — hiring, lending, student assessment, eligibility for public services. Both laws are worried about the same thing.

The real difference is in the last row.

The EU folded accessibility into the AI Act itself. So if you build high-risk AI, accessibility comes along as part of the conformity assessment. Skip it, and you don’t get your CE mark.

Korea split it across two laws. The AI Framework Act covers transparency, explainability, and human oversight, while accessibility falls to the Digital Inclusion Act, which took effect the same day. Splitting it isn’t necessarily bad design — each law can stay focused on its own job.

But in practice, this creates a gap. Building a single AI system, the EU side has accessibility built into one checklist, while in Korea you have to check two separate laws. That’s exactly the kind of situation where “we handled AI compliance, but nobody looked at accessibility” can slip through — especially when AI compliance and accessibility sit with different teams.

So the practical value the EU law offers Korean developers is this: borrow it as a checklist. What our own law splits into two tracks, the EU bundles into one line — a useful checkpoint for asking “did we actually look at accessibility on this AI screen?”

And if you’re shipping a service into the EU market or targeting EU users, this applies regardless of where you’re based. If a Korean company launches an app in Europe, this isn’t someone else’s problem.

Honestly, doing accessibility before the law forces you to is almost always cheaper. Carrefour’s 71% is the proof. Tabbing through a new component once, right when you build it, costs a lot less than getting a six-month court order to fix everything after the fact.

Summary

• August 2, 2026 brings most of the remaining EU AI Act provisions into force, including Annex III high-risk system obligations. Annex I (product-embedded systems) follows in August 2027
• Article 16 requires providers of high-risk AI to comply with accessibility requirements, directly referencing the Web Accessibility Directive (2016/2102) and the European Accessibility Act (2019/882)
• The key point: accessibility sits in the same list as CE marking and technical documentation. It’s a conformity assessment item, not a recommendation
• High-risk means domains like employment, education, credit scoring, and public services — places that decide people’s opportunities. People with disabilities are naturally among those affected
• In practice, three things change: accessibility of AI output screens (asynchronous result announcements), review of AI-generated markup, and documentation
• Compared with Korea: the covered domains are nearly identical, but accessibility sits in a different place. Korea’s AI Framework Act has been in force since January 22, 2026 (six months ahead of the EU), but accessibility is handled by the Digital Inclusion Act, not the AI law itself
• That means Korean teams need to check two separate laws, and the split creates room for accessibility to fall through the cracks. Borrowing the EU’s single checklist as a checkpoint is a practical workaround

A deadline, for once

One of the hard things about accessibility work has always been the lack of a deadline. With nothing due by a specific date, it kept sliding to the next sprint.

Now a few areas have a date attached. Not exactly a welcome way to get there, but at least “someday” has become “August 2.”

Of course, accessibility built only because the law demands it tends to end up exactly as good as the law requires — no more. Like that 71% compliance. Still, I think it’s not a bad place to start. Once there’s a deadline, it at least makes it onto the meeting agenda.