Introduction
Aletheia by Lonia AI targets conformance with EN 301 549 V3.2.1, the version referenced in the Official Journal of the European Union and in force as of this review date. EN 301 549 V3.2.1 incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. Aletheia's engineering target is WCAG 2.2 Level AA, which is a superset of WCAG 2.1 Level AA, so the product is built above the floor the current standard sets.
This document also prepares for EN 301 549 V4.1.1, which was published for public review as V4.1.0 in November 2025 and is expected to be referenced in the Official Journal in October 2026. V4.1.1 is expected to incorporate WCAG 2.2 Level AA. Because Aletheia already targets WCAG 2.2 Level AA, the additional success criteria V4.1.1 introduces are already in scope for the product. Their readiness is recorded in the V4.1.1 preparation section below.
Conformance status in this document is based on self-evaluation. A formal audit by an independent third party is planned and has not yet been completed. Where the product's status against a clause cannot be defended from current evidence, the status is recorded as "Under evaluation" or "Pending third-party audit" rather than claimed.
Scope
This mapping covers the following, together referred to as Aletheia:
- The Aletheia web application, where users process and remediate web pages and documents on their own device.
- The Aletheia marketing website at this domain.
- The institutional administration dashboards used by Campus and Enterprise account administrators.
Aletheia is delivered as web content and as software. The chapters of EN 301 549 that apply to it are primarily Chapter 5 (Generic Requirements), Chapter 9 (Web), Chapter 11 (Software), and Chapter 12 (Documentation and Support Services). Chapter 10 (Non-web Documents) applies to Aletheia's exported files. Chapters that describe hardware, two-way voice, video, and relay or emergency services do not apply and are marked accordingly below.
Standards referenced
- EN 301 549 V3.2.1 (March 2021), the harmonised European standard currently referenced in the Official Journal of the European Union. It incorporates WCAG 2.1 Level AA.
- WCAG 2.2 Level AA, the World Wide Web Consortium Recommendation of October 2023. This is Aletheia's engineering target.
- EN 301 549 V4.1.1 (expected October 2026), the forthcoming revision expected to incorporate WCAG 2.2 Level AA. Preparation for this version is documented, not claimed as current conformance.
Conformance approach
The sections below map the applicable chapters of EN 301 549 to Aletheia's current implementation, one clause or clause group at a time. Each row states whether the clause is applicable to Aletheia and records the product's status using the vocabulary in the legend below. Where a chapter's requirements reference WCAG success criteria, Chapter 9 gives the criterion-level detail and the other chapters reference it rather than repeat it.
Status legend
- Meets (self-assessed): the requirement is implemented and verified by Aletheia's own testing; not yet confirmed by a third-party audit.
- Partially meets: the requirement is met for most content or cases, with a specific known limitation recorded.
- Does not meet: the requirement is not currently satisfied.
- Under evaluation: Aletheia's status against the requirement has not yet been determined from evidence and is not claimed.
- Pending third-party audit: the requirement depends on formal test evidence that has not yet been produced.
- Not applicable: the requirement addresses a technology or function Aletheia does not have.
Chapter 4: Functional Performance Statements
Chapter 4 describes the outcomes a user with a given need should be able to achieve. It is addressed through the technical requirements in the later chapters. The table records how Aletheia addresses each functional performance statement.
| Clause | Functional performance statement | Status | Note |
|---|---|---|---|
| 4.2.1 | Usage without vision | Meets (self-assessed) | Semantic structure, name and role exposure, and full keyboard operation target screen reader use with NVDA, JAWS, and VoiceOver. |
| 4.2.2 | Usage with limited vision | Meets (self-assessed) | Text reflow, resize to 200 percent without loss, and contrast at or above 4.5:1 for normal text. |
| 4.2.3 | Usage without perception of colour | Meets (self-assessed) | Colour is never the only means of conveying meaning; state is also given as text, icon, or position. |
| 4.2.4 | Usage without hearing | Not applicable | No audio-only information is required to operate the product. User-initiated audio export is a text-to-speech convenience, not a required channel. |
| 4.2.5 | Usage with limited hearing | Not applicable | No required audio content. See row 4.2.4. |
| 4.2.6 | Usage without vocal capability | Meets (self-assessed) | No operation requires speech input. |
| 4.2.7 | Usage with limited manipulation or strength | Meets (self-assessed) | Full keyboard operation, no required dragging, and touch targets of at least 44 by 44 pixels. |
| 4.2.8 | Usage with limited reach | Meets (self-assessed) | Runs on the user's own device; layout reflows to a 375 pixel viewport so controls stay within reach on small screens. |
| 4.2.9 | Minimise photosensitive seizure triggers | Meets (self-assessed) | No content flashes more than three times per second. |
| 4.2.10 | Usage with limited cognition, language, or learning | Meets (self-assessed) | Plain-language copy, consistent navigation and help placement, clear error messages, and OAuth sign-in that removes password memory burden. |
| 4.2.11 | Privacy | Meets (self-assessed) | Accessibility features carry the same privacy protections as the rest of the product; on-device processing keeps document content local. |
Chapter 5: Generic Requirements
Chapter 5 covers requirements that apply across ICT regardless of its form. Most of Chapter 5 addresses physical hardware and closed systems, which do not apply to Aletheia. The clauses that do apply are recorded below.
| Clause | Requirement | Applicable | Status and note |
|---|---|---|---|
| 5.1 | Closed functionality | Not applicable | Aletheia runs on the user's own general-purpose device with the user's own assistive technology. It does not restrict the attachment or use of assistive technology, so it is not closed functionality. |
| 5.2 | Activation of accessibility features | Applicable | Meets (self-assessed). Aletheia does not obstruct platform accessibility features and honours operating system settings such as reduced motion. |
| 5.3 | Biometrics | Not applicable | Aletheia does not use a biological characteristic as the only means of user identification or control. Authentication is OAuth single sign-on. |
| 5.4 | Preservation of accessibility information during conversion | Applicable | Partially meets. When Aletheia produces remediated output it carries structure and alternative text through. For tagged PDF export, non-Latin scripts are a known limitation recorded in Chapter 10; plain text export preserves all Unicode content without loss. |
| 5.5 | Operable parts (5.5.1 means of operation, 5.5.2 tactile discernment) | Not applicable | Addresses physical operable parts on hardware. On-screen controls are covered in Chapter 9 and Chapter 11. |
| 5.6 | Locking or toggle controls (5.6.1 tactile or auditory status, 5.6.2 visual status) | Not applicable | Addresses hardware locking keys. On-screen toggle state is covered under name, role, and value in Chapter 9 and Chapter 11. |
| 5.7 | Key repeat | Not applicable | Aletheia provides no physical keyboard. Key repeat is controlled by the user's own platform. |
| 5.8 | Double-strike key acceptance | Not applicable | Aletheia provides no physical keyboard. See row 5.7. |
| 5.9 | Simultaneous user actions | Applicable | Meets (self-assessed). No function requires simultaneous user actions such as multiple keys or points of contact at once; every function is available through single-point activation. |
Chapter 6: ICT with Two-Way Voice Communication
Not applicable. Aletheia is not a real-time text, voice, or video communication service. Chapter 6 does not apply.
Chapter 7: ICT with Video Capabilities
Not applicable. Aletheia does not deliver video content with synchronised audio in the sense of the standard. The optional audio export is text-to-speech playback of remediated text, not video, so Chapter 7 does not apply.
Chapter 8: Hardware
Not applicable. Aletheia is software delivered as web content and a client application. It ships no hardware, so Chapter 8 does not apply.
Chapter 9: Web
Chapter 9 is the primary chapter for Aletheia. Under EN 301 549 V3.2.1, Chapter 9 requires web content to satisfy the WCAG 2.1 Level A and Level AA success criteria. Aletheia targets WCAG 2.2 Level AA, so the tables below map every WCAG 2.2 Level A and Level AA success criterion, grouped by the four WCAG principles. Criteria new in WCAG 2.2 are noted; they are not required by V3.2.1 but are in scope for V4.1.1 and for Aletheia's own target.
The status in these tables reflects self-evaluation of the marketing website and the web application. A formal third-party audit has not yet been completed. The product's overall conformance is partially conformant, driven by the exported-document limitations recorded in Chapter 10 and the documentation limitation recorded in Chapter 12. Five criteria (1.3.1, 1.3.2, 1.4.10, 2.4.1, and 2.4.11) are held at Partially meets pending scheduled manual verification (Workstream B29), matching the status held in the VPAT accessibility report and the EU Accessibility Statement; the remaining criteria are self-assessed as met below.
9.1 Perceivable
| WCAG SC | Name | Level | Status | Note |
|---|---|---|---|---|
| 1.1.1 | Non-text Content | A | Meets (self-assessed) | Images have alt text; decorative images are hidden from assistive technology. |
| 1.2.1 | Audio-only and Video-only (Prerecorded) | A | Not applicable | No prerecorded audio-only or video-only media in the product. Future media will ship with alternatives. |
| 1.2.2 | Captions (Prerecorded) | A | Not applicable | No prerecorded synchronised media. Future media will ship with captions. |
| 1.2.3 | Audio Description or Media Alternative (Prerecorded) | A | Not applicable | No prerecorded synchronised media. Future media will ship with audio description. |
| 1.2.4 | Captions (Live) | AA | Not applicable | No live synchronised media. |
| 1.2.5 | Audio Description (Prerecorded) | AA | Not applicable | No prerecorded synchronised media. |
| 1.3.1 | Info and Relationships | A | Partially meets | Semantic HTML conveys structure and automated testing passes with zero violations; ARIA is added only where semantic HTML is insufficient. End-to-end screen reader verification of exported tagged PDF output is pending (Workstream B29); see Chapter 10. |
| 1.3.2 | Meaningful Sequence | A | Partially meets | Reading and focus order follow the DOM order and pass automated testing. Manual verification of meaningful sequence is scheduled (Workstream B29). |
| 1.3.3 | Sensory Characteristics | A | Meets (self-assessed) | Instructions do not rely on shape, size, or position alone. |
| 1.3.4 | Orientation | AA | Meets (self-assessed) | Layout works in both portrait and landscape; no orientation is locked. |
| 1.3.5 | Identify Input Purpose | AA | Meets (self-assessed) | Input fields use appropriate autocomplete and type attributes. |
| 1.4.1 | Use of Color | A | Meets (self-assessed) | Colour is never the sole indicator of meaning. |
| 1.4.2 | Audio Control | A | Meets (self-assessed) | No autoplay audio. Audio export plays only on user request and can be stopped. |
| 1.4.3 | Contrast (Minimum) | AA | Meets (self-assessed) | At least 4.5:1 for normal text and 3:1 for large text. |
| 1.4.4 | Resize Text | AA | Meets (self-assessed) | Text resizes to 200 percent without loss of content or function. |
| 1.4.5 | Images of Text | AA | Meets (self-assessed) | Text is real text, not images of text, except where a logo is essential. |
| 1.4.10 | Reflow | AA | Partially meets | Content reflows to narrow widths and the site functions at 375 pixels and above; automated testing passes. Manual verification of reflow at 400 percent zoom with no two-dimensional scrolling is scheduled (Workstream B29). |
| 1.4.11 | Non-text Contrast | AA | Meets (self-assessed) | Interface components and focus indicators meet 3:1 against adjacent colours. |
| 1.4.12 | Text Spacing | AA | Meets (self-assessed) | No loss of content when users override line height, spacing, and margins. |
| 1.4.13 | Content on Hover or Focus | AA | Meets (self-assessed) | Content that appears on hover or focus is dismissable, hoverable, and persistent. |
9.2 Operable
| WCAG SC | Name | Level | Status | Note |
|---|---|---|---|---|
| 2.1.1 | Keyboard | A | Meets (self-assessed) | Every function is operable with a keyboard alone. |
| 2.1.2 | No Keyboard Trap | A | Meets (self-assessed) | Focus can always move away from a component with the keyboard. The mobile navigation trap is intentional and releases on Escape. |
| 2.1.4 | Character Key Shortcuts | A | Meets (self-assessed) | No single-character key shortcuts are imposed. |
| 2.2.1 | Timing Adjustable | A | Meets (self-assessed) | No time limits are placed on user interaction. |
| 2.2.2 | Pause, Stop, Hide | A | Meets (self-assessed) | No moving, blinking, or auto-updating content that runs longer than five seconds without a control. |
| 2.3.1 | Three Flashes or Below Threshold | A | Meets (self-assessed) | No content flashes more than three times per second. |
| 2.4.1 | Bypass Blocks | A | Partially meets | A skip-to-content link is the first focusable element on every marketing page, confirmed by automated testing. Manual verification of skip mechanisms across the web application and admin dashboards is scheduled (Workstream B29). |
| 2.4.2 | Page Titled | A | Meets (self-assessed) | Every page has a descriptive, unique title. |
| 2.4.3 | Focus Order | A | Meets (self-assessed) | Focus order preserves meaning and operability. |
| 2.4.4 | Link Purpose (In Context) | A | Meets (self-assessed) | Link text, with its context, describes its purpose. |
| 2.4.5 | Multiple Ways | AA | Meets (self-assessed) | Pages are reachable through navigation, the footer, and the sitemap. |
| 2.4.6 | Headings and Labels | AA | Meets (self-assessed) | Headings and labels describe topic or purpose; one H1 per page. |
| 2.4.7 | Focus Visible | AA | Meets (self-assessed) | Focus indicators are at least 3 pixels with offset. |
| 2.4.11 | Focus Not Obscured (Minimum) | AA | Partially meets | New in WCAG 2.2. Automated testing passes and the focused element is not designed to be hidden by sticky headers or overlays. Manual verification is scheduled (Workstream B29). |
| 2.5.1 | Pointer Gestures | A | Meets (self-assessed) | No multipoint or path-based gesture is required. |
| 2.5.2 | Pointer Cancellation | A | Meets (self-assessed) | Actions complete on the up-event and can be aborted. |
| 2.5.3 | Label in Name | A | Meets (self-assessed) | The accessible name of a control contains its visible label text. |
| 2.5.4 | Motion Actuation | A | Meets (self-assessed) | No function is operated only by device motion. |
| 2.5.7 | Dragging Movements | AA | Meets (self-assessed) | New in WCAG 2.2. No function requires dragging; single-pointer alternatives exist. |
| 2.5.8 | Target Size (Minimum) | AA | Meets (self-assessed) | New in WCAG 2.2. Targets are at least 44 by 44 pixels, exceeding the 24 by 24 pixel requirement. |
9.3 Understandable
| WCAG SC | Name | Level | Status | Note |
|---|---|---|---|---|
| 3.1.1 | Language of Page | A | Meets (self-assessed) | The page language is set in the HTML lang attribute. |
| 3.1.2 | Language of Parts | AA | Meets (self-assessed) | Passages in another language are marked where they occur. |
| 3.2.1 | On Focus | A | Meets (self-assessed) | Receiving focus does not trigger an unexpected change of context. |
| 3.2.2 | On Input | A | Meets (self-assessed) | Changing a setting does not trigger an unexpected change of context. |
| 3.2.3 | Consistent Navigation | AA | Meets (self-assessed) | Navigation is in the same relative order on every page. |
| 3.2.4 | Consistent Identification | AA | Meets (self-assessed) | Components with the same function are identified consistently. |
| 3.2.6 | Consistent Help | A | Meets (self-assessed) | New in WCAG 2.2. Contact and support links appear in the same relative place on every page. |
| 3.3.1 | Error Identification | A | Meets (self-assessed) | Errors are identified in text next to the field they belong to. |
| 3.3.2 | Labels or Instructions | A | Meets (self-assessed) | Every field has a label or instruction. |
| 3.3.3 | Error Suggestion | AA | Meets (self-assessed) | Where a fix is known, it is suggested in text. |
| 3.3.4 | Error Prevention (Legal, Financial, Data) | AA | Meets (self-assessed) | Financial actions are reversible or confirmable before submission. |
| 3.3.7 | Redundant Entry | A | Under evaluation | New in WCAG 2.2. Marketing flows do not ask users to re-enter information. A full review of every multi-step application flow is pending. |
| 3.3.8 | Accessible Authentication (Minimum) | AA | Meets (self-assessed) | New in WCAG 2.2. Authentication is OAuth single sign-on with no cognitive function test, no password to recall, and no puzzle. |
9.4 Robust
| WCAG SC | Name | Level | Status | Note |
|---|---|---|---|---|
| 4.1.1 | Parsing | A | Not applicable | Removed in WCAG 2.2 and treated as always satisfied. Aletheia produces valid, well-formed markup regardless. |
| 4.1.2 | Name, Role, Value | A | Meets (self-assessed) | Interface components expose name, role, state, and value to assistive technology. |
| 4.1.3 | Status Messages | AA | Meets (self-assessed) | Status messages are announced without moving focus. |
Chapter 10: Non-web Documents
Chapter 10 applies the WCAG success criteria to documents that Aletheia produces, chiefly its exported files. This is where Aletheia has known limitations, and they are documented honestly here rather than smoothed over.
| Export format | Expectation | Status | Note |
|---|---|---|---|
| Tagged PDF | Structure tags, alternative text, reading order, and outlines consistent with PDF/UA and the WCAG-based clauses of Chapter 10. | Partially meets | Exported PDF carries structure tags, alternative text, and outlines for Latin-script content. Non-Latin scripts may show fallback characters in the current build. |
| Tagged PDF (screen reader evidence) | Verified behaviour with NVDA, JAWS, and VoiceOver reading the exported file. | Pending third-party audit | Formal screen reader test evidence against exported PDF output has not yet been produced. |
| Plain text | Full preservation of content without loss. | Meets (self-assessed) | Plain text export preserves all Unicode content, including non-Latin scripts, without loss. It is the recommended format where scripts must be retained exactly. |
Chapter 11: Software
Chapter 11 applies to Aletheia's client-side application behaviour and, because Aletheia produces accessibility-remediated content, to its role as an authoring tool. Where a clause simply restates a WCAG success criterion for software, the status matches the corresponding row in Chapter 9.
| Clause | Requirement | Applicable | Status and note |
|---|---|---|---|
| 11.1 to 11.4 | Perceivable, operable, understandable, and robust software | Applicable | Meets (self-assessed). The application is built to WCAG 2.2 Level AA; see Chapter 9 for criterion-level detail. |
| 11.5 | Interoperability with assistive technology | Applicable | Meets (self-assessed). The application exposes name, role, state, and value through platform accessibility services and does not disrupt assistive technology. |
| 11.6 | Documented accessibility usage | Applicable | Meets (self-assessed). Accessibility features are documented in the accessibility statement and this mapping. |
| 11.7 | User preferences | Applicable | Meets (self-assessed). The application honours platform settings such as reduced motion and text size. |
| 11.8.1 | Content technology (authoring tool) | Applicable | Meets (self-assessed). Aletheia produces content in technologies that support accessibility, including tagged output and plain text. |
| 11.8.2 | Accessible content creation (authoring tool) | Applicable | Partially meets. Aletheia enables production of accessible content; exported PDF has the non-Latin limitation recorded in Chapter 10. |
| 11.8.3 | Preservation of accessibility information in transformations | Applicable | Partially meets. See clause 5.4 and Chapter 10. |
| 11.8.4 | Repair assistance (authoring tool) | Applicable | Meets (self-assessed). Detecting and repairing accessibility barriers in other content is the core function of Aletheia. |
| 11.8.5 | Templates (authoring tool) | Not applicable | Aletheia does not offer a template library that would fall under this clause. |
Chapter 12: Documentation and Support Services
| Clause | Requirement | Status | Note |
|---|---|---|---|
| 12.1.1 | Accessibility and compatibility features documented | Meets (self-assessed) | Documented in the accessibility statement, the EAA conformance statement, and this mapping. |
| 12.1.2 | Accessible documentation | Partially meets | Newer documentation follows the current heading discipline. Older articles are being brought up to the same standard. |
| 12.2.2 | Information on accessibility features of support | Meets (self-assessed) | Support channels and the accessibility contact are published on the accessibility statement. |
| 12.2.3 | Effective communication | Meets (self-assessed) | Support is offered by accessible email and accessible web forms. |
| 12.2.4 | Accessible documentation from support | Meets (self-assessed) | Written support responses are provided in accessible plain text and HTML email. |
Chapter 13: ICT Providing Relay or Emergency Services
Not applicable. Aletheia does not provide relay services or access to emergency services, so Chapter 13 does not apply.
Preparation for EN 301 549 V4.1.1
EN 301 549 V4.1.1 is expected to incorporate WCAG 2.2 Level AA, adding the success criteria new to WCAG 2.2 to the mandatory set. Because Aletheia already targets WCAG 2.2 Level AA, these criteria are already in scope. The table records readiness. Criteria at Level AAA sit outside Aletheia's Level AA target and are noted as such rather than claimed as a conformance obligation.
| Success criterion | WCAG SC and level | Readiness | Note |
|---|---|---|---|
| Focus Not Obscured (Minimum) | 2.4.11, AA | Partially meets | Automated testing passes and the focused element is not designed to be hidden by sticky headers or overlays. Manual verification is scheduled (Workstream B29). |
| Focus Not Obscured (Enhanced) | 2.4.12, AAA | Beyond target | Level AAA, outside Aletheia's Level AA target; not claimed as a conformance obligation. |
| Target Size (Minimum) | 2.5.8, AA | Meets (self-assessed) | Targets are at least 44 by 44 pixels, exceeding the 24 by 24 pixel requirement. |
| Dragging Movements | 2.5.7, AA | Meets (self-assessed) | No function requires dragging; single-pointer alternatives exist. |
| Accessible Authentication (Minimum) | 3.3.8, AA | Meets (self-assessed) | OAuth single sign-on with no cognitive function test. |
| Accessible Authentication (Enhanced) | 3.3.9, AAA | Beyond target | Level AAA, outside the Level AA target. The OAuth-only design supports it, but it is not claimed as a conformance obligation. |
| Redundant Entry | 3.3.7, A | Under evaluation | Marketing flows do not ask for re-entry. A full review of every multi-step application flow is pending. |
| Consistent Help | 3.2.6, A | Meets (self-assessed) | Contact and support links appear in the same relative place on every page. |
Testing methodology
This mapping is based on the following evaluation methods:
- Automated accessibility testing with axe-core, run continuously as part of development.
- Manual keyboard-only testing by the Aletheia team.
- Manual checks of semantic structure, focus order, contrast, and form labelling.
- A target of support for the NVDA, JAWS, and VoiceOver screen readers.
A formal audit by an independent third party is planned and has not yet been completed. Screen reader test evidence against exported PDF output is pending. This document will be updated when that evidence and that audit are available.
Contact
If you find an accessibility barrier, or need information from Aletheia in a format this mapping does not cover, please tell us. Aletheia treats accessibility issues as defects, not feature requests.
Email accessibility@lonia.ai.Related documents
- VPAT accessibility report (WCAG 2.2 AA and Section 508), also available as a tagged PDF.
- European Accessibility Act (EAA) Conformance Statement
- EU Accessibility Statement (Commission Implementing Decision (EU) 2018/1523 template)
- Accessibility statement
Review
This mapping was last reviewed on July 14, 2026. It is reviewed at least once a year and on every major product release. It will be amended when EN 301 549 V4.1.1 is referenced in the Official Journal of the European Union, expected in October 2026, at which point the V4.1.1 criteria move from preparation into the current conformance basis.