EN 301 549 for apps is not just WCAG

Most teams treat app accessibility under the European Accessibility Act as WCAG, but in an app. Clause 11 of EN 301 549, the part for non-web software, starts with WCAG and then keeps going. V4.1.1, published on 2 September, changed enough of it that a checklist from last year is wrong in at least four places.

Which apps are in scope

All of them, for the services the EAA covers. Annex I asks every covered service to make "mobile device-based services, including mobile applications" perceivable, operable, understandable and robust. The definitions name apps again for e-commerce, for e-books, and for air, bus, rail and waterborne transport. Urban and regional transport are the exception.

On the legal status: V4.1.1 is not yet cited in the Official Journal, so it doesn't give a presumption of conformity yet. V3.2.1 is cited, but only under the Web Accessibility Directive. For an app that falls under the EAA, V4.1.1 is the version that describes what is coming.

The WCAG part, 11.1 to 11.4

Clauses 11.1 to 11.4 follow WCAG, rewritten for software. In V3.2.1 that was 44 of the WCAG 2.1 criteria at levels A and AA. In V4.1.1 it is 50 of the 55 in WCAG 2.2, and a count like that should come with its list of the missing five.

Four of them are about sets: bypass blocks, multiple ways, consistent navigation and the new consistent help assume a group of pages, and "sets of software programs" are, in the standard's words, extremely rare. The fifth is language of parts. Parsing is gone from the web side as well, so it doesn't count here.

Two changed in V4.1.1, and a checklist based on V3.2.1 misses both. Page titles, 2.4.2, used to be void for software. Now, on a platform that supports titles for windows or screens, the app "shall provide titles that describe the name, topic or purpose of each window or screen." On iOS and Android, the screen title is what a screen reader can announce when the screen changes.

Consistent identification, 3.2.4, used to apply only to sets. Now "components that have the same functionality within the non-web software program shall be identified consistently." A share button is a share button on every screen of the app, with the same name.

The new WCAG 2.2 criteria came along with V4.1.1. Target size is the one with a unit problem: 24 by 24 CSS pixels makes no sense in an app. The W3C's WCAG2ICT note translates CSS pixels to the platform's density-independent unit, points on iOS and dp on Android. So 24 pt and 24 dp.

Resize text is the other one that reads differently. The app has to support text "up to 200 percent or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform." The platforms scale unevenly on purpose. In Apple's type scale, body text goes from 17 to 53 points at the largest accessibility size, over 300 percent. The large title goes from 34 to 60, which is 176. Headings are already big, so they grow less, and the standard allows exactly that.

Web views count as app

The note I'd put at the top of every app audit is in 11.0: "When parts of non-web software, such as mobile apps, are implemented with web views, these web views are embedded in the app and thus do not meet the definition of a web page. The clause 11 'Non-web software' requirements are the appropriate requirements to be applied to these web views." And: "Where there is any doubt, clause 11 requirements have precedence."

So the checkout that is really a web page inside the app gets tested as app. Screen titles, system text size, the platform's accessibility services. The web team that built it usually tested it as web.

Where clause 11 stops being WCAG

Clause 11.5.2 is about the platform's accessibility services. The app has to expose each element's "role, state(s), boundary, name, and description" to assistive technology through the platform's accessibility API. Then the rest: rows, columns and headers of table cells, current values with their minimum and maximum, label relationships, parent and child, available actions that assistive technology can trigger, focus and selection it can track and change, and notifications when any of that changes. V4.1.1 softened one clause, 11.5.2.3, from "shall use" the documented platform services to "should use," but the requirements after it still say "by using the services as described in clause 11.5.2.3."

Native controls give you most of this for free. A custom view drawn on a canvas, or a UI from a game engine, starts with none of it.

Clause 11.6.2 is shorter: the app may not disrupt "documented platform accessibility features" unless the user asks for it. Custom gesture handling that swallows the screen reader's gestures fails here.

Clause 11.7 covers user preferences. In V4.1.1 the user interface "shall follow the values of the user preference settings for documented platform accessibility features unless it is essential to the function of the non-web software to not follow a user preference setting." Note 6 lists what that can include: "colour filters, contrast, text size, pointer size, and text cursor." Note 5 allows the app its own settings, as long as one mode follows the system.

The standard names no platform. I read Dynamic Type and Increase Contrast on iOS, and font size and color correction on Android, as exactly the documented platform features 11.7 means. An app that fixes its font size, or draws its own colors over a system color filter, doesn't follow them.

These three clauses aren't extras. Table A.3, the one that maps clause 11 to the EAA, lists 11.5.2, 11.6 and 11.7 next to 11.1 to 11.4.

Testing it

If you write the test plan for an app, these are five checks a WCAG-only audit skips:

1. Set the largest text size in the system settings and go through every screen. Nothing cut off, nothing overlapping.
2. Turn on increased contrast and a color filter. The app follows them, or offers a mode that does.
3. Open every web view with VoiceOver or TalkBack, and check the screen title and text size there too.
4. Go through custom views with the screen reader. Every element has a role, a name and a state.
5. Connect a hardware keyboard. The standard says an on-screen keyboard alone "does not satisfy this requirement," because the keyboard requirement is about the platform's keyboard interface.

None of the five show up in a WCAG report, and all of them are in the standard's own table for the EAA.