Accessibility: European Accessibility Act and EN 301 549

Status 31-10-2026: specification only. Nothing in this document is built yet. It says which requirements apply to EUZOS as an operating system, what exists today, and a phased plan with estimates and owner decisions.

This is not legal advice. It is the project's own reading of public texts. The questions a lawyer has to answer are in LEGAL-CHECK.md, item LC-3, and summarised in §2.3.

How to read the marks.

• [T] read in a public text, listed in §9 and in SOURCES.md.
• [2] from a secondary source only (a commentary or vendor site). Not verified in the primary text.
• [P] proven from this tree: read in the code or found with grep on 31-10-2026.
• [N] not found by grep. That is weaker than proof of absence.
• [E] estimate, with the sum shown.
• [S] suspected: not checked.
• [O] the project's own interpretation of a text. A lawyer or an auditor may read it differently.

Summary

1. EUZOS is very likely within the product category "consumer general purpose computer hardware systems and operating systems for those hardware systems" as soon as it is offered to consumers [T][O]. Whether it is in scope while it is offered to organisations only is a legal question (LC-3). The microenterprise exemption in the Directive covers services, not products [T].
2. The largest gap is architectural. EN 301 549 clause 11.5.2.1 requires platform software to provide documented accessibility services [T]. EUZOS apps draw pixels and keep a list of click rectangles [P], so an assistive technology has nothing to read. An accessibility tree in libs/ui is the core of this plan.
3. Today: a tested colour contrast in both themes, a pointer size setting, 34 languages, and keyboard handling in part of the screens. Missing: a shared focus model, high contrast, a text size setting, a screen reader, an accessibility API and accessibility documentation (§3).
4. Estimate: about 106 agent-days with a licensed speech engine, about 146 with an own one (§5). Braille and the external conformity work are on top. The first 30 agent-days (phases A0 to A3) give the largest gain per day for sighted keyboard users and users with low vision.
5. The speech engine is the hardest owner decision (§7, A-3): it collides with the rule of own code.

1. The texts and their status

This plan uses V4.1.1. Clause numbers below are from that edition; some differ from V3.2.1 (11.5.2.2 is now void, for example) [T].

The standard is one voluntary means of conforming [T]. Annex ZB maps clauses to the Directive, and its own note says the tables in clause A.2 are the practical way to assess a product [T].

2. What applies to EUZOS

2.1 Which parts of the Directive [T]

• Article 2(1)(a): "consumer general purpose computer hardware systems and operating systems for those hardware systems".
• Article 4(2): all products meet Annex I Section I; products other than self-service terminals also meet Section II.
• Annex I Section I, point 1: information on the product and instructions for use, available through more than one sense, with readable fonts, and describing the user interface and accessibility features. Point 1(b)(ix) asks for a list of assistive devices tested with the product.
• Annex I Section I, point 2: user interface and functionality. For EUZOS mainly: (a) more than one sense, (c) flexible magnification, brightness and contrast, (d) an alternative to colour, (e) an alternative to audible signals, (f) flexible ways of improving clarity, (g) user control of volume, (h) sequential controls and no simultaneous actions, (j) no seizure triggers, (k) privacy of accessibility features, (l) an alternative to biometrics, (m) consistency and enough time, (n) software and hardware for interfacing with assistive technologies.
• Annex I Section II: packaging and instructions for installation, maintenance, storage and disposal.
• Article 14: the requirements apply only as far as they cause no fundamental alteration and no disproportionate burden. The assessment follows Annex VI and is kept for five years. Microenterprises dealing with products need not document it, but must give the facts if an authority asks. Relying on it must be notified, except by a microenterprise.
• Article 3(23): a microenterprise has fewer than 10 persons and at most EUR 2 million turnover or balance sheet.
• Article 4(5): the microenterprise exemption is for those providing services. It does not exempt products.
• Article 15: presumption of conformity through cited harmonised standards.

Not read for this document: the recitals, Annex II to VI in full, the manufacturer's duties in detail (Article 7, CE marking, technical documentation), and any national transposition.

2.2 Which clauses of EN 301 549 V4.1.1

EUZOS is "platform software" and "non-web software that provides a user interface" [T][O]. Note 4 of 11.5.2.1 names operating systems explicitly [T]. The tables are A.3 (non-web software), A.5 (all ICT), and A.1 or A.2 for what EUZOS publishes on the web or as documents. Table A.4 (hardware) applies to whoever sells a machine, which raises question 3 of LC-3.

2.3 Where legal advice is needed

These are questions, not answers. Each is in LC-3.

1. Is EUZOS "consumer"? docs/BUSINESS-PLAN.md targets organisations. The Directive defines a consumer by purpose outside trade or business [T]. Whether a general-purpose OS sold to businesses, but obtainable by a private person, is in scope is not something this reading can settle.
2. Who is the economic operator, and which duties follow: the EUZOS project, a reseller, a hardware partner. Which company form and size counts, and whether EUZOS is a microenterprise when it first sells.
3. Software without hardware. Which duties apply to an OS installed by the customer on a machine they already own, and is a free download "placed on the market"?
4. Article 14: can a young OS rely on disproportionate burden, for example for a screen reader in 34 languages, and for how long? What exactly must be notified, and to whom?
5. The transition: the state of the rules for versions delivered before accessibility is complete, and for test releases to a small circle.
6. National law: the Member States of first sale, starting with the Netherlands. No transposition has been read.
7. Chromium: responsibility for accessibility inside a component shipped under exception U-16.
8. Services: do the profile server, mail or the update service fall under Article 2(2)? Not assessed here.

3. What exists today

Checked in this tree on 31-10-2026 by grep and by reading. Grep of 101 source files in libs/ui/src does not replace an audit; phase A0 is that audit.

4. Architecture

4.1 Focus: one model in libs/ui

Every screen already builds a list of click rectangles during its draw. A new Focus type takes the same list, extended with an order and a kind (button, field, list item), and handles Tab, Shift+Tab, arrows, Enter, Space and Esc in one place. Screens stop keeping their own booleans over time. It draws one shared ring, tested for non-text contrast (11.1.4.11) against the tokens, and scrolls the focused item into view (11.2.4.11).

Not a retained widget toolkit: the immediate-mode style of libs/ui stays.

4.2 The accessibility tree in libs/ui

During a draw, a screen emits a node next to what it paints. A node maps to EN 301 549 like this:

Rules:

• No cost when nothing listens. Building the tree is behind a flag read once per frame. The display work of docs/SMP-SCALABILITY.md must not pay for it. Measure with perf.
• Secrets. A password field exposes its role and a character count, never its text, as the login screen draws it today (libs/ui/src/login.rs). 4.2.11 and Annex I 2(k) [T].
• Shared helpers first. button, card, segmented and so on emit their own node, so most screens need only names for icon-only parts.
• Change notification comes from comparing two trees with stable ids, so a screen does not have to report changes.

4.3 The service

• Kernel-drawn screens (shell, login, installer, kernel-drawn apps) hand their tree to a kernel a11y service directly.
• App packages send theirs over EAP. New wire messages in libs/eap, libs/eapp sends them on request, and the app host checks them like any other app input: bounded, strict decoding, fuzzed.
• svc.a11y gives an assistive technology the tree of the focused window and the notifications. Reading other apps' screens is as sensitive as the screen capture rules (docs/SCREEN-SECURITY.md): a privileged capability, allowed only for signed assistive packages, with the user's consent, and logged.
• This service is the "documented platform accessibility service" of 11.5.2.1, so the wire format gets a public document. That document is a deliverable, not an afterthought.
• Actions go through the tree's action list, not through fake key events.

4.4 The screen reader

screen (draw) -> tree -> a11y service -> reader (package, own process) -> speech engine -> sound
                                                                       -> braille display (later)

• A normal app package without a window, so it can be updated separately and revoked (docs/LAYERED-UPDATES.md).
• It has to work before sign-in (5.1, 5.2). The installer, login and screen lock must carry the reader and one voice, and a key combination plus a sound must announce the mode with no screen at all. This is a size cost for the boot stick.
• Speech: see A-3. Interruption and rate control are 5.1.3.4 and 5.1.3.5 [T].
• Sound must work early; on a machine whose sound driver fails, the reader has no output. State this honestly in the tested-hardware list.
• Braille: a USB HID profile, no earlier than after the first reader version. Own code from the public USB HID Braille usage page. No GPL reader or braille driver is read (rule of docs/drivers/CLEANROOM.md).

4.5 Chromium

Chromium keeps its own accessibility tree. Getting it to the EUZOS reader needs a bridge on the Linux layer; how much of that Chromium's existing Linux code path expects is unknown [S]. Phase A8 starts with one read-only study from public Chromium documentation and only then estimates the build. Until then, web content is inaccessible to the EUZOS reader, and this must be said in the documentation. libs/web (the own browser) gets a tree from its layout, at less cost.

4.6 High contrast and text size as system preferences

• High contrast is a palette in color.rs, on the same path as set_theme and set_custom, so every token follows. Brand colours in fixed constants need a review; color.rs says they stay the same in all themes [P].
• Text size is a factor in Metrics::font, stored in the profile, so it follows the user. Layouts that assume a text height are the real work: 200 % (11.1.4.4) breaks many rows and buttons, and 11.1.4.10 asks for reflow.
• Both are handed to Chromium as far as its flags allow (11.7 Note 4), and to apps through libs/eapp so packages follow by construction.

5. Phases

Each phase ends with host tests in the style of libs/ui (draw every screen, assert the tree, the order and the contrast), translations in all 34 languages, and notes here. Dependencies are in the last column.

Sum. 3 + 17 + 4 + 6 + 15 + 4 + 20 + 16 + 12 + 4 + 5 = 106 agent-days with a licensed speech engine; with an own engine A7 is 56 instead of 16, so 146. Braille (about 10) and any speech language beyond the first two are not in this. Per language a licensed voice costs little; an own voice costs roughly 10 agent-days and listening tests by native speakers, so "all 34 languages" for an own engine is not credible in any near plan.

Confidence. A0-A5: medium to good, they resemble earlier work on libs/ui. A6: medium. A7 with an own engine and A8: low.

Not agent work. Tests with people who use assistive technology, an external audit, and a lawyer. Automated tests cannot show that a blind person can actually use EUZOS. No claim of conformance should be made without those.

Suggested order: A0, A1, A2, A3, A5, A4, A6, A7, A8, A9, A10. A3 and A5 before A4 because they are cheap and A4 touches every layout. Other work continues in parallel; a new screen from A1 on uses Focus, and from A6 on emits nodes.

6. Risks

• Late work on the tree is more expensive with every new screen. Agreeing on the shared helpers early is the cheapest part.
• Text at 200 % is likely to expose fixed heights throughout. The estimate may grow after A0.
• The boot stick size and sound: the reader before sign-in needs a voice and a working sound driver in the installer.
• Security: a reader sees everything. A compromised one is a keylogger with a screen. See §4.3.
• Chromium: a bridge may depend on behaviour that changes between Chromium versions.
• Claims: "accessible" on a website without evidence is a risk in itself.

7. Owner decisions

8. Honest limits of this document

• The Directive was read through the legislation.gov.uk copy of the adopted text, because the EUR-Lex page did not come through the fetching tool. It should be the same text. For anything legal, use the Official Journal.
• The Directive's articles were read by way of article summaries with short quotes, not word by word. Annex I likewise.
• EN 301 549 V4.1.1 was read directly, for the clauses named. Clause numbers and titles in §2.2 are from that PDF. Not every row of tables A.3, A.5 and ZB.1 to ZB.5 was checked one by one, so A0 goes through them.
• The citation status in the Official Journal rests on commercial accessibility sites, which disagree with each other on dates. No Commission page or Official Journal page was read.
• Which clauses apply in the end is for an auditor. "Unknown" in §2.2 means not checked, not failed.

9. Sources

See SOURCES.md, "Accessibility". Primary: Directive (EU) 2019/882; ETSI EN 301 549 V4.1.1 (2026-09), with Annex ZB and clause A.2. Secondary, for the citation status only: Legalithm, Deque, EqualWeb and others, read 31-10-2026.