Accessibility in iOS 27: Apple has added AI, but that doesn't make you EAA-compliant

Every time Apple announces accessibility updates, the same line resurfaces in product meetings: "Apple makes the app accessible for us, right?" And this year it sounds more convincing than ever, because the new features run on AI and look like magic.

It's false. And it can cost you dearly.

Apple gives you excellent system-level tools so your users can work better. Your app's conformance with the EAA, however, still depends entirely on what you build. An auditor doesn't assess whether iOS ships with VoiceOver — it does — but whether your app is operable with those technologies. And that isn't switched on in Settings: it's built, control by control, in your code.

I've worked on mission-critical accessibility — at Juegos ONCE, the Spanish national organisation for the blind, where VoiceOver isn't an extra but the primary mode of use for a huge share of the user base — and I also audit the accessibility of apps before they reach production. From those two seats, let me separate what's a gift from Apple from what's going to land on your desk.

What Apple has announced (and yes, it's good)

The iOS 27 accessibility updates lean heavily on Apple Intelligence, and almost everything runs on-device, which is good news for GDPR too:

• VoiceOver with rich image descriptions. You can swipe up on an image with a custom VoiceOver action and get a description without leaving the app, and even ask follow-up questions about what's in it. For photos, receipts or documents, it's a real leap.
• Live Recognition: from the Action button, ask the system what's in the camera viewfinder.
• Voice Control with natural language. Instead of rigid control names, you can describe anything on screen in natural language. For users with reduced mobility, it's a category change.
• A more customisable Accessibility Reader (introduced in iOS 26): a system tool that launches from any app to consume long-form text in whatever style each person prefers, integrated with spoken content.
• On-device generated subtitles for personal videos: the transcription and translation model lives on the device and subtitles appear automatically during playback, with nothing for you to implement.

One item deserves rigorous framing: the video interpretation feature in FaceTime was announced at WWDC, but at the time of writing it is not available in the iOS 27 betas and has no public APIs — no details on entitlements or restrictions. If someone sells it to you as something you can integrate today, be sceptical.

All of this is great. And it doesn't move you a single millimetre closer to EAA conformance. Here's why.

The distinction almost nobody explains properly

The EAA has been in force across the EU since June 2025. Each member state has transposed it into national law with its own enforcement regime, and the penalties are no rounding error — in several member states the fines run into six or seven figures. For services that already existed, the directive allows a continuity period until 28 June 2030, though some national transpositions set earlier deadlines for existing apps, so check the rules in each market where you operate. The technical reference standard is EN 301 549.

Here's what matters: EN 301 549 doesn't assess the operating system. It assesses your product. The fact that iOS ships an excellent screen reader says nothing about whether a VoiceOver user can complete an onboarding flow, sign a contract or pay a bill in your app.

And here's the nuance that gets lost in the AI noise: Apple's new features improve how the system interprets your interface, but they don't repair an interface that's badly exposed. If a custom control doesn't publish its role, its value and its actions, no on-device AI will guess them reliably. VoiceOver's image descriptions help with a photo; they don't turn your transfer form into something operable.

EAA conformance is the developer's responsibility. Full stop. Apple provides the platform; you provide the conformant app.

Where the serious failures are (and why they're yours)

After auditing a fair few apps, I can tell you where the serious problems almost always appear: almost never in native controls, almost always in custom UI. A SwiftUI Button, Toggle or Slider comes properly exposed out of the box. The disaster arrives when someone builds a custom control and marks it as "accessible" by giving it an accessibilityLabel… and nothing else.

The WWDC session on custom controls sums it up in four principles that should be your mental checklist: purpose, value, actions and feedback. A label only covers the first. Take the typical case — a coffee dispenser adjusted by dragging:

// ❌ What you usually find: "accessible" with just a label.
struct CoffeeDispenser: View {
    @State private var ounces = 6

    var body: some View {
        CupShape(fill: ounces)
            .gesture(dragToAdjust)
            .accessibilityLabel("Coffee dispenser")
        // VoiceOver announces the name, and that's it.
        // No value, no way to change it, no feedback.
    }
}

For VoiceOver this is a dead end: it knows what it is, but the user can't tell how much coffee there is or change it. Here's the fix — adding a value, an adjustable action and feedback:

// ✅ Purpose + value + action + feedback.
struct CoffeeDispenser: View {
    @State private var ounces = 6

    var body: some View {
        CupShape(fill: ounces)
            .gesture(dragToAdjust)
            .accessibilityElement()
            .accessibilityLabel("Coffee dispenser")
            .accessibilityValue("\(ounces) ounces")
            .accessibilityAdjustableAction { direction in
                switch direction {
                case .increment: ounces = min(ounces + 1, 12)
                case .decrement: ounces = max(ounces - 1, 0)
                @unknown default: break
                }
            }
    }
}

Now a VoiceOver user selects the control, swipes up or down and hears "7 ounces… 8 ounces". The same pattern — exposing role, value and actions — is also what makes Voice Control and Switch Control work, because they share the same accessibility layer underneath. Fix one thing and you fix three.

For controls with more than one axis (an equaliser pad, say, where .adjustable falls short), the tool is accessibilityAction with custom actions ("move up", "move down", "left", "right"). And for highly gestural controls that don't fit VoiceOver's swipe model, iOS 27 lets you mark a direct touch area that passes touches straight through to the control. The golden rule: wherever you can, offer an actions-based route as well, because not everyone can perform precise gestures.

The other great forgotten one: Dynamic Type

If you ask me where to start when a large app has never touched accessibility, my answer — and that of Apple's accessibility team — is the same: Dynamic Type. It's what affects the most users and what exposes a fragile UI fastest.

The classic sin is hard-coded values: fixed font sizes (size: 12 instead of the semantic style .caption) and rigid widths that truncate text as soon as it grows. The solution is always the same — semantic styles and flexible constraints — and when the accessibility size breaks the layout at its root, don't force the original design: change it. SwiftUI allows this with AnyLayout, which switches between horizontal and vertical arrangements depending on the type size without duplicating the view. It's exactly what iOS's own Control Centre does: with large text, controls grow and rearrange. That's the standard an auditor — and your users — will expect from your app.

One concrete novelty this cycle: Dynamic Type arrives on tvOS 27. If you have a TV app, this same work now applies there.

What this means in practice for your team

If you have an app in production that has never been through this, the realistic path isn't "rewrite it with accessibility": it's audit → prioritise → fix incrementally. An audit with VoiceOver and large text across the critical flows (onboarding, login, payment, signing) gives you a concrete backlog. You prioritise by criticality for the user, not just by volume: a failure that blocks payment weighs more than twenty improvable labels on secondary screens. And the fixes go into normal sprints, alongside features, without halting development. It's bounded, measurable work — not the black hole many teams fear — and with 2030 on the horizon, the earlier you start, the cheaper it gets.

How to verify it properly (and a new API that helps)

Marking things as accessible is worthless if you don't test with the real technologies. Three practical things:

Start with VoiceOver. It's the best return per hour invested: because many assistive technologies share the same layer underneath, a good VoiceOver experience carries much of Voice Control and Switch Control with it. That's no excuse not to test the others, but it's the best starting point. Field trick: put VoiceOver on the accessibility shortcut (triple-click) so you can toggle it without getting lost in Settings.

Automate so you don't regress. UI tests (XCUITest) rely on the accessibility hierarchy: if your app isn't accessible, your tests break. That turns your UI suite into a near-free safety net against accessibility regressions. This year there's also a new XCTest API for driving VoiceOver from the Mac against the simulator or a device, so you can validate that VoiceOver reaches the elements and announces the right things in an automated way. (It's in the early betas; treat it as exactly that — very new.)

Lean on the Accessibility Inspector to audit elements and catch empty labels, and — if you can — get feedback from real users of assistive technologies. Nobody will find the holes like someone who lives inside VoiceOver every day.

A note for anyone working with Xcode 27: there are new AI skills in the coding assistant aimed specifically at accessibility. You can ask it to "make this view accessible for VoiceOver" or "what's missing from this file for Dynamic Type" and it suggests and edits the code. Useful as an accelerator — but, as with everything an LLM generates, the validation is still yours. Compiling doesn't mean the flow is operable.

Accessibility Nutrition Labels are still voluntary

There's noise this year around Accessibility Nutrition Labels, and it's worth clearing up because misinformation is circulating: they're the way a user can know, before downloading, which accessibility features your app supports (VoiceOver, Dynamic Type, contrast, and so on). In iOS 27 they're being expanded, and you can even declare large-text support for tvOS.

But they are voluntary and have no mandatory deadline. They are not part of the EAA's legal mechanism. If you come across an article that gives you a deadline for Nutrition Labels, be sceptical: it's making it up.

That said, I find them useful for two reasons that aren't legal. One: they come with criteria and guidelines from Apple, so they give you a concrete yardstick to test against. Two: they're a superb internal negotiating lever — I've seen teams use "we want to be able to display this label" to finally secure budget and priority for the accessibility work they'd been postponing for years. The label doesn't make you EAA-conformant, but the work you do to earn it moves you closer.

In short

The AI-powered accessibility features in iOS 27 are a gift for your users, not a compliance shortcut. The auditor doesn't test iOS: they test your app. And your app is only operable if you expose every control with its purpose, its value, its actions and its feedback, if your text scales with Dynamic Type, and if you verify it with the real technologies.

The other lesson — the one Apple's entire accessibility team keeps repeating: accessibility is built in from the start, not bolted on at the end. Treating it as a first-class category — at the level of security or privacy — in the planning phase costs far less than patching it in at the last minute. And with 2030 on the horizon, it's the difference between an app that ages conformant and one that piles up accessibility debt until a penalty arrives or, worse, a user who simply can't use it.

Frequently asked questions

Does switching on VoiceOver or the iOS 27 accessibility features make my app EAA-compliant?

No. EN 301 549 assesses your app, not the operating system. The fact that iOS ships an excellent screen reader says nothing about whether a VoiceOver user can complete an onboarding flow, sign a contract or pay a bill inside your app. Conformance is something you build, control by control.

When did the EAA become mandatory and what are the penalties?

It has been in force across the EU since 28 June 2025. Penalties are set by each member state's national transposition and reach six or seven figures in several countries. For services that already existed, the directive allows a continuity period until 28 June 2030, although some national laws set earlier deadlines for existing apps — check each market where you operate.

Are Accessibility Nutrition Labels mandatory?

No. They're voluntary, have no deadline, and are not part of the EAA's legal mechanism. If an article gives you a deadline for them, it's making it up. They're useful as a testing yardstick and as an internal negotiating lever, not as proof of conformance.

Where should you start making a large iOS app accessible?

With Dynamic Type and VoiceOver: they affect the most users and expose a fragile UI fastest. Good VoiceOver support also carries much of Voice Control and Switch Control with it, because they share the same accessibility layer underneath.

Sources (WWDC 2026 sessions)

• Refine accessibility for custom controls
• Enhance the accessibility of your reading app
• Prepare your tvOS apps for Dynamic Type
• Discover generated subtitles and subtitle styles

---

Need to make your iOS app accessible and EAA-compliant? At AtalayaSoft we've implemented accessibility in apps with millions of users, including environments where VoiceOver is the primary mode of use.

Let's talk →