Product information
| Name of product | Aletheia by Lonia AI |
|---|---|
| Version | 1.0.0 |
| Report date | July 14, 2026 |
| Product description | Aletheia is a user-side accessibility tool that makes web pages and documents usable on a person's own device. It runs optical character recognition, generates image descriptions, restructures content, and labels forms, then exports the result as tagged PDF, plain text, or audio. It exists so that a disabled person does not have to wait for a publisher to fix inaccessible content. |
| Contact information | Accessibility inquiries: accessibility@lonia.ai |
| Notes | This report covers Aletheia's web application, marketing website, Campus admin dashboard, and Enterprise admin dashboard. Per-surface differences are noted in the Remarks and Explanations column where they apply. |
| Evaluation methods used | Automated testing with axe-core across 21 of 26 routes (evidence dated July 14, 2026), which found zero critical, serious, or moderate violations. Manual testing by the Aletheia team covering keyboard navigation, colour contrast, high-contrast mode compatibility, and browser text-size scaling. A third-party audit and formal NVDA, JAWS, and VoiceOver testing sessions are planned but not yet conducted at the time of publication. |
Applicable standards and guidelines
| Standard or guideline | Included in report |
|---|---|
| WCAG 2.2 Level A | Included |
| WCAG 2.2 Level AA | Included |
| WCAG 2.2 Level AAA | Not included as a conformance target. Documented for reference where evidence exists. |
| Revised Section 508 standards (published January 18, 2017) | Included |
| EN 301 549 | Addressed separately in the EAA Conformance Statement and the EN 301 549 Conformance Mapping, referenced here rather than re-mapped. |
Terms
The report uses the following terms to describe conformance with each criterion.
- Supports: The functionality of the product has at least one method that meets the criterion without known defects, or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This is used only for WCAG 2.2 Level AAA criteria.
Scope, coverage, and honest limitations
Aletheia's status against each criterion below is based on self-evaluation. No third-party accessibility audit has been conducted, and no SOC 2 or comparable certification is claimed. Self-evaluation is stated plainly wherever it is the basis for a status.
Automated testing with axe-core covered 21 of the product's 26 routes and returned zero critical, serious, or moderate violations. Five routes were not covered by that automated pass: the Family invite full flow, the Professional bring-your-own-key flow, Scan Results with a real artifact, the Viewer with a real document, and Campus admin (Campus admin is evaluated separately for its own surface). The ten minor best-practice notes returned by automated testing all originate in a third-party user-interface component library (a deprecated presentation role) and do not affect WCAG 2.2 Level AA conformance; they are recorded here for completeness only and are not treated as a Level AA defect.
The success criterion 4.1.1 Parsing was removed in WCAG 2.2 and is therefore not listed in the tables below.
Five criteria are held at Partially Supports pending manual verification that is scheduled for the post-launch smoke test (Workstream B29): 1.3.2 Meaningful Sequence, 2.4.1 Bypass Blocks, 1.4.10 Reflow, and 2.4.11 Focus Not Obscured (Minimum), together with 1.3.1 Info and Relationships, which is held partial because end-to-end screen reader verification of exported PDF output is still pending. These will be amended to Supports if and when the scheduled manual tests pass.
WCAG 2.2 Report
The tables below cover Aletheia across all four surfaces. Where a status differs by surface, the difference is stated in the Remarks and Explanations column.
Table 1: Success Criteria, Level A
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | All surfaces. Images carry alternative text; decorative images are hidden from assistive technology. In the web application, on-device MobileVLM generates image descriptions; description quality depends on device hardware capability, and Professional and Enterprise tiers can connect their own AI key for higher-quality descriptions. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | No prerecorded audio-only or video-only media is present on any surface. Any future media will ship with a text alternative. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | No prerecorded synchronised media is present on any surface. Any future media will ship with captions. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | No prerecorded synchronised media is present on any surface. Any future media will ship with audio description or a full text alternative. |
| 1.3.1 Info and Relationships | Partially Supports | All surfaces. The web application, marketing website, and admin dashboards convey structure with semantic HTML, verified by automated testing with zero violations. Exported tagged PDF carries structure tags and reading order, but end-to-end verification of the exported PDF with NVDA, JAWS, and VoiceOver is pending (scheduled smoke test, Workstream B29). Plain text export preserves content without loss. |
| 1.3.2 Meaningful Sequence | Partially Supports | All surfaces. Reading and focus order follow the document order and pass automated testing. Manual verification of meaningful sequence is scheduled (Workstream B29). |
| 1.3.3 Sensory Characteristics | Supports | All surfaces. Instructions do not rely on shape, size, or position alone. |
| 1.4.1 Use of Color | Supports | All surfaces. Colour is never the only means of conveying meaning; state is also given as text, icon, or position. Confirmed by manual review by the Aletheia team. |
| 1.4.2 Audio Control | Supports | All surfaces. No autoplay audio. Audio export in the web application plays only on user request and can be stopped. |
| 2.1.1 Keyboard | Supports | All surfaces. Every function is operable with a keyboard alone. Verified by manual keyboard-only testing by the Aletheia team. |
| 2.1.2 No Keyboard Trap | Supports | All surfaces. Focus can always move away from a component with the keyboard. The mobile navigation drawer trap is intentional and releases on Escape. |
| 2.1.4 Character Key Shortcuts | Supports | All surfaces. No single-character key shortcuts are imposed. |
| 2.2.1 Timing Adjustable | Supports | All surfaces. No time limits are placed on user interaction. |
| 2.2.2 Pause, Stop, Hide | Supports | All surfaces. No moving, blinking, or auto-updating content runs longer than five seconds without a control. |
| 2.3.1 Three Flashes or Below Threshold | Supports | All surfaces. No content flashes more than three times per second. |
| 2.4.1 Bypass Blocks | Partially Supports | All surfaces. 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 | Supports | All surfaces. Every page has a descriptive, unique title. |
| 2.4.3 Focus Order | Supports | All surfaces. Focus order preserves meaning and operability. |
| 2.4.4 Link Purpose (In Context) | Supports | All surfaces. Link text, with its context, describes its purpose. |
| 2.5.1 Pointer Gestures | Supports | All surfaces. No multipoint or path-based gesture is required. |
| 2.5.2 Pointer Cancellation | Supports | All surfaces. Actions complete on the up-event and can be aborted. |
| 2.5.3 Label in Name | Supports | All surfaces. The accessible name of a control contains its visible label text. |
| 2.5.4 Motion Actuation | Supports | All surfaces. No function is operated only by device motion. |
| 3.1.1 Language of Page | Supports | All surfaces. The page language is set in the HTML lang attribute. |
| 3.2.1 On Focus | Supports | All surfaces. Receiving focus does not trigger an unexpected change of context. |
| 3.2.2 On Input | Supports | All surfaces. Changing a setting does not trigger an unexpected change of context. |
| 3.2.6 Consistent Help | Supports | New in WCAG 2.2. All surfaces. Contact and support links appear in the same relative place on every page. |
| 3.3.1 Error Identification | Supports | All surfaces. Errors are identified in text next to the field they belong to. |
| 3.3.2 Labels or Instructions | Supports | All surfaces. Every field has a label or instruction. |
| 3.3.7 Redundant Entry | Partially Supports | New in WCAG 2.2. Marketing flows do not ask users to re-enter information. A full review of every multi-step flow in the web application and admin dashboards is pending. |
| 4.1.2 Name, Role, Value | Supports | All surfaces. Interface components expose name, role, state, and value to assistive technology. |
Table 2: Success Criteria, Level AA
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | No live synchronised media is present on any surface. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | No prerecorded synchronised media is present on any surface. |
| 1.3.4 Orientation | Supports | All surfaces. Layout works in both portrait and landscape; no orientation is locked. |
| 1.3.5 Identify Input Purpose | Supports | All surfaces. Input fields use appropriate autocomplete and type attributes. |
| 1.4.3 Contrast (Minimum) | Supports | All surfaces. At least 4.5:1 for normal text and 3:1 for large text. Verified by manual colour-contrast checking by the Aletheia team. |
| 1.4.4 Resize Text | Supports | All surfaces. Text resizes to 200 percent without loss of content or function. Verified by manual browser text-size scaling by the Aletheia team. |
| 1.4.5 Images of Text | Supports | All surfaces. Text is real text, not images of text, except where a logo is essential. |
| 1.4.10 Reflow | Partially Supports | All surfaces. 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 | Supports | All surfaces. Interface components and focus indicators meet 3:1 against adjacent colours. Verified by manual review by the Aletheia team. |
| 1.4.12 Text Spacing | Supports | All surfaces. No loss of content when users override line height, spacing, and margins. Verified by manual text-spacing override testing by the Aletheia team. |
| 1.4.13 Content on Hover or Focus | Supports | All surfaces. Content that appears on hover or focus is dismissable, hoverable, and persistent. |
| 2.4.5 Multiple Ways | Supports | All surfaces. Pages are reachable through navigation, the footer, and the sitemap. |
| 2.4.6 Headings and Labels | Supports | All surfaces. Headings and labels describe topic or purpose; one H1 per page. |
| 2.4.7 Focus Visible | Supports | All surfaces. Focus indicators are at least 3 pixels with offset. |
| 2.4.11 Focus Not Obscured (Minimum) | Partially Supports | New in WCAG 2.2. All surfaces. 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.7 Dragging Movements | Supports | New in WCAG 2.2. All surfaces. No function requires dragging; single-pointer alternatives exist. |
| 2.5.8 Target Size (Minimum) | Supports | New in WCAG 2.2. All surfaces. Targets are at least 44 by 44 pixels, exceeding the 24 by 24 pixel requirement. |
| 3.1.2 Language of Parts | Supports | All surfaces. Passages in another language are marked where they occur. |
| 3.2.3 Consistent Navigation | Supports | All surfaces. Navigation is in the same relative order on every page. |
| 3.2.4 Consistent Identification | Supports | All surfaces. Components with the same function are identified consistently. |
| 3.3.3 Error Suggestion | Supports | All surfaces. Where a fix is known, it is suggested in text. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | All surfaces. Financial actions are reversible or confirmable before submission. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | New in WCAG 2.2. All surfaces. Authentication is OAuth single sign-on with no cognitive function test, no password to recall, and no puzzle. |
| 4.1.3 Status Messages | Supports | All surfaces. Status messages are announced without moving focus. |
Table 3: Success Criteria, Level AAA
Aletheia's conformance target is Level AA. Level AAA criteria are not a conformance obligation. The rows below record the WCAG 2.2 Level AAA criteria most relevant to Aletheia's design. Every other WCAG 2.2 Level AAA success criterion is Not Evaluated because Level AA is the target.
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 2.4.12 Focus Not Obscured (Enhanced) | Not Evaluated | Level AAA, outside Aletheia's Level AA conformance target. Not formally evaluated. |
| 2.4.13 Focus Appearance | Not Evaluated | Level AAA, outside the Level AA target. Focus indicators meet the Level AA Focus Visible requirement; the enhanced Level AAA appearance metrics have not been formally evaluated. Manual verification is scheduled alongside Workstream B29. |
| 3.3.9 Accessible Authentication (Enhanced) | Not Evaluated | Level AAA, outside the Level AA target. The OAuth-only design is consistent with this criterion, but it has not been formally evaluated. |
Revised Section 508 Report
This section reports against the Revised Section 508 standards published January 18, 2017. Chapters 3, 5, and 6 apply to Aletheia. Chapter 4 (Hardware) does not apply.
Chapter 3: Functional Performance Criteria
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 302.1 Without Vision | Partially Supports | The product is operable without vision using a screen reader; Aletheia targets support for NVDA, JAWS, and VoiceOver, and full keyboard operation is manually verified. End-to-end screen reader verification of exported PDF output is pending (Workstream B29). Plain text export is available without loss. |
| 302.2 With Limited Vision | Supports | Text resizes to 200 percent without loss, contrast meets at least 4.5:1 for normal text, and content reflows to narrow viewports. Resize and contrast are manually verified; reflow at 400 percent zoom is scheduled for manual verification (Workstream B29). |
| 302.3 Without Perception of Color | Supports | Colour is never the only means of conveying meaning. |
| 302.4 Without Hearing | Supports | No audio-only information is required to operate the product. |
| 302.5 With Limited Hearing | Supports | No required audio content is present. |
| 302.6 Without Speech | Supports | No operation requires speech input. |
| 302.7 With Limited Manipulation or Strength | Supports | Full keyboard operation, no required dragging, and touch targets of at least 44 by 44 pixels. |
| 302.8 With Limited Reach and Strength | Supports | The product runs on the user's own device and reflows to a 375 pixel viewport so controls stay within reach on small screens. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Supports | Plain-language copy, consistent navigation and help placement, clear error messages, and OAuth sign-in that removes password memory burden. |
Chapter 4: Hardware
Not Applicable. Aletheia is software delivered as web content and a client application. It ships no hardware, so Chapter 4 does not apply.
Chapter 5: Software
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 502.2.1 User Control of Accessibility Features | Supports | The product does not disrupt or override platform accessibility features and honours operating system settings. |
| 502.2.2 No Disruption of Accessibility Features | Supports | The product does not disrupt assistive technology or platform accessibility services. |
| 502.3 Accessibility Services | Supports | Interface components expose name, role, state, value, and relationships through platform accessibility services. See WCAG 4.1.2 Name, Role, Value. |
| 502.4 Platform Accessibility Features | Supports | The product honours platform settings such as reduced motion and text size. |
| 503.2 User Preferences | Supports | The product respects user platform settings for colour, contrast, font type, font size, and focus cursor where the platform exposes them. |
| 503.3 Alternative User Interfaces | Not Applicable | The product does not provide an alternative user interface that functions as assistive technology. |
| 503.4 User Controls for Captions and Audio Description | Not Applicable | The product does not display synchronised media, so caption and audio description controls do not apply. |
| 504.2 Content Creation or Editing (Authoring Tool) | Partially Supports | Aletheia produces remediated content in technologies that support accessibility, including tagged output and plain text. Tagged PDF export has the screen reader verification and non-Latin script limitations recorded in this report; plain text export preserves all content without loss. |
| 504.2.1 Preservation of Accessibility Information in Transformations | Partially Supports | When Aletheia produces remediated output it carries structure and alternative text through. For tagged PDF export, non-Latin scripts may show fallback characters in the current build; plain text export preserves all Unicode content without loss. |
| 504.3 Prompts (Authoring Tool) | Supports | Detecting and repairing accessibility barriers in other content, and guiding the user toward accessible output, is the core function of Aletheia. |
| 504.4 Templates (Authoring Tool) | Not Applicable | Aletheia does not offer a template library that would fall under this clause. |
Requirements 501.1 (Scope) and 504.1 (Scope for authoring tools) are scope statements rather than testable criteria. Aletheia is software that provides a user interface and also functions as an authoring tool for accessibility remediation, so both sets of software requirements apply and are reported above. Where a clause restates a WCAG success criterion, the status matches the corresponding row in the WCAG 2.2 report.
Chapter 6: Support Documentation and Services
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 602.2 Accessibility and Compatibility Features | Supports | Accessibility and compatibility features are documented in the accessibility statement, the EAA conformance statement, the EN 301 549 mapping, and this report. |
| 602.3 Electronic Support Documentation | Partially Supports | Newer documentation follows the current heading discipline and conforms to WCAG 2.2 Level AA as web content. Older articles are being brought up to the same standard. |
| 602.4 Alternate Formats for Non-Electronic Support Documentation | Not Applicable | Support documentation is provided electronically; there is no non-electronic documentation. |
| 603.2 Information on Accessibility and Compatibility Features | Supports | Support channels and the accessibility contact are published on the accessibility statement. |
| 603.3 Accommodation of Communication Needs | Supports | Support is offered by accessible email and accessible web forms, in accessible plain text and HTML. |
Legal disclaimer
Review cadence
Last review date: July 14, 2026. Next review: annually, or on a major product release, whichever comes first. The review process and triggers are recorded internally and are re-run when a review is due: re-run automated testing with axe-core, re-verify manual testing, update the table entries, and republish this page and the PDF. The accessibility contact at accessibility@lonia.ai owns the review and the republication.