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 TalkBack. Tested with NVDA on Windows 11 and TalkBack on Android. |
| 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 read-aloud playback 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 and no required dragging. Interactive targets meet SC 2.5.8 Target Size (Minimum), Level AA, at 24 by 24 CSS pixels. Inline targets that would fall below that size qualify under the spacing exception, with an 18 pixel gap between adjacent links. The mobile navigation menu meets 44 by 44 pixels, which is the Level AAA metric of SC 2.5.5. |
| 4.2.8 | Usage with limited reach | Meets (self-assessed) | Runs on the user's own device; layout reflows to a 320 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 read-aloud playback 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. Read-aloud playback 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 this site functions at 320 CSS px and above, the width this criterion specifies, which is the equivalent of 400 percent zoom of a 1280 pixel viewport. Automated testing measures every route at that width on every build and records no two-dimensional scrolling. Manual verification across the web application and the admin dashboards 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. Interactive targets meet SC 2.5.8 Target Size (Minimum), Level AA, at 24 by 24 CSS pixels. Inline targets that would fall below that size qualify under the spacing exception, with an 18 pixel gap between adjacent links. The mobile navigation menu meets 44 by 44 pixels, which is the Level AAA metric of SC 2.5.5. |
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 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) | Interactive targets meet SC 2.5.8 Target Size (Minimum), Level AA, at 24 by 24 CSS pixels. Inline targets that would fall below that size qualify under the spacing exception, with an 18 pixel gap between adjacent links. The mobile navigation menu meets 44 by 44 pixels, which is the Level AAA metric of SC 2.5.5. |
| 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 testing is carried out by the Lonia AI product team on Windows 11 with NVDA and on Android with TalkBack, iteratively during development rather than as a single scheduled audit, continuously since May 2026. It covers targeted keyboard navigation, WCAG 2.2 Level AA colour contrast, responsive layout, high-contrast mode, and confirming that each accessibility setting changes real behaviour. The fix commits in the Aletheia application repository are the audit trail; there is no separate manual-testing report and none is claimed.
- Manual checks of semantic structure, focus order, contrast, and form labelling, on the tested platforms and no others.
- A target of support for the NVDA, JAWS, and TalkBack screen readers. NVDA and TalkBack have been tested; JAWS has not.
- Aletheia has not been tested on Apple platforms. No iOS, iPadOS, or macOS device, no version of Safari, and no VoiceOver session has been part of any testing pass to date. Aletheia is a standards-based web application and is expected to work there, but an expectation is not evidence, and nothing published here should be read as a claim that it has been verified on those platforms.
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.
Platforms not tested
Aletheia has not been tested on Apple platforms. No iOS, iPadOS, or macOS device, no version of Safari, and no VoiceOver session has been part of any testing pass to date. Aletheia is a standards-based web application and is expected to work there, but an expectation is not evidence, and nothing published here should be read as a claim that it has been verified on those platforms.
- iOS and iPadOS, on any device.
- macOS, on any device.
- Safari, on any platform.
- VoiceOver, on any platform.
- JAWS. JAWS is named as a support target because the product is built to the interfaces JAWS uses, and no JAWS session has been run.
Tested platforms are listed above and are limited to Windows 11 with NVDA and Android with TalkBack.
If you use one of these platforms and hit a barrier, tell us at support@lonia.ai. A report from an untested platform is more useful to us than one from a tested platform, and it is treated as a defect.
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 support@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
Change history
| Date | Version | Change |
|---|---|---|
| October 4, 2026 | 1.6 | Reflow (1.4.10) is now measured at 320 CSS px, the width the criterion specifies, rather than at the 375 pixel phone width the sweep used. The HECVAT response overflowed horizontally by 18 pixels at that width, because the question list could not shrink below the longest URL in it; the list now reflows and every route measures zero. The remarks that named the phone width now name the criterion's width. |
| September 17, 2026 | 1.5 | Label in Name (9.2.5.3) correction on the marketing website: the accessible name of every link and button whose aria-label had replaced its visible text now begins with that visible text (39 controls across 22 source files). The Meets verdict now describes the corrected state, and a build-time test walks every generated page to hold it. |
| September 17, 2026 | 1.4 | Contact address consolidated to support@lonia.ai. Remarks now describe read-aloud playback in the browser rather than an audio export. The tagged-PDF export remark names NVDA only. |
| August 26, 2026 | 1.3 | Compatibility list corrected to tested platforms only. Added an explicit list of the platforms Aletheia has not been tested on, and a statement of who carries out the manual testing, on what, how, and since when. |
| August 23, 2026 | 1.2 | Corrected the target-size remarks in clause 4.2.7, in success criterion 2.5.8, and in the V4.1.1 readiness table. All three stated a measured 44 by 44 pixel figure the stylesheet contradicts. The conformance verdict is unchanged and remains correct: targets meet the Level AA 24 by 24 minimum, and inline targets qualify under the spacing exception. Added explicit version and last-updated stamping, enforced by a build-time guard. |
| August 5, 2026 | 1.1 | Aligned the WCAG conformance level labels with the VPAT. |
| July 14, 2026 | 1.0 | Initial publication of the EN 301 549 conformance mapping. |
Review
This mapping was last reviewed on October 4, 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.