Product information
| Name of product | Aletheia by Lonia AI |
|---|---|
| Version | 1.0.0 |
| Report date | July 14, 2026 |
| Report version | 1.6, last updated October 4, 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 or plain text and reads it aloud in the browser. It exists so that a disabled person does not have to wait for a publisher to fix inaccessible content. |
| Contact information | Accessibility inquiries: support@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 | Two separate automated evidence records, one per surface, each named with the artifact that backs it. Aletheia web application and admin dashboards: axe-core, September 20, 2026, covering 73 runs across desktop and mobile viewports, including the Settings route that carries the data-export control. Zero violations. Evidence: test-results/axe/a11-2026-09-20/ in the Aletheia application repository. Held in the application repository and not committed here, which is why it is named separately from the marketing-site record. Aletheia marketing website (this site): axe-core 4.12.1, October 16, 2026, covering all 31 public routes of the site revision named beside it. Zero violations at every severity across the full WCAG 2.0, 2.1, and 2.2 Level A and AA rule sets plus axe best-practice rules. The results axe records as incomplete rather than pass or fail are colour-contrast checks that axe cannot compute against the site's background gradient; they are resolved separately by measuring the rendered pixels, and that resolution is committed alongside the sweep. Evidence: test-results/axe/m17-2026-10-16/ One JSON record per route plus _aggregate.json, committed to this repository. Each record carries the page title the origin served at scan time, so a reader can confirm the sweep ran against Aletheia and not against another site sharing the preview port. Site revision c2b6329aa097. Both are supplemented by manual testing. 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. 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 third-party audit and formal JAWS testing sessions are planned and have not been 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. Self-evaluation. No third-party accessibility audit has been conducted, and no SOC 2 or comparable certification is claimed. A formal audit by an independent third party is planned and has not yet been carried out. Self-evaluation is stated plainly wherever it is the basis for a status. Taken as a whole, Aletheia is partially conformant with WCAG 2.2 Level AA.
Which evidence backs which claim
Two automated evidence records inform this report. They cover different surfaces, their route counts are close enough to be mistaken for each other, and earlier revisions of this report cited them as one. They are separate records and are named separately here.
| Surface | Run | Coverage | Result | Evidence artifact |
|---|---|---|---|---|
| Aletheia web application and admin dashboards | axe-core, September 20, 2026 | 73 runs across desktop and mobile viewports, including the Settings route that carries the data-export control. The batches before it were a13-2026-09-20 and a12-2026-09-19; five tracked batches exist since the July 14, 2026 sweep, and this record cites the latest. | Zero violations. | test-results/axe/a11-2026-09-20/ in the Aletheia application repository. Held in the application repository and not committed here, which is why it is named separately from the marketing-site record. |
| Aletheia marketing website (this site) | axe-core 4.12.1, October 16, 2026 | all 31 public routes of the site revision named beside it. None. The route set is derived from src/pages by scripts/lib/routes.mjs and the build fails if committed evidence does not cover every route. | Zero violations at every severity across the full WCAG 2.0, 2.1, and 2.2 Level A and AA rule sets plus axe best-practice rules. The results axe records as incomplete rather than pass or fail are colour-contrast checks that axe cannot compute against the site's background gradient; they are resolved separately by measuring the rendered pixels, and that resolution is committed alongside the sweep. | test-results/axe/m17-2026-10-16/ One JSON record per route plus _aggregate.json, committed to this repository. Each record carries the page title the origin served at scan time, so a reader can confirm the sweep ran against Aletheia and not against another site sharing the preview port. Site revision c2b6329aa097. |
The ten minor best-practice notes returned by the product sweep 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.
Manual testing behind this report
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.
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.
5 criteria are held at Partially Supports pending manual verification that is scheduled for the post-launch smoke test (Workstream B29): 1.3.1 Info and Relationships (Level A), 1.3.2 Meaningful Sequence (Level A), 2.4.1 Bypass Blocks (Level A), 1.4.10 Reflow (Level AA), 2.4.11 Focus Not Obscured (Minimum) (Level AA). Each will be amended to Supports if and when the scheduled manual test passes. The reason each is held is given in its row below and, in plain language, on the accessibility statement.
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
WCAG 2.2 Level A. Success criterion, conformance level, and remarks. 31 criteria. 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 and JAWS 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. Read-aloud playback 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
WCAG 2.2 Level AA. Success criterion, conformance level, and remarks. 24 criteria. 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 marketing 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 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. 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. Verified against the stylesheet by manual measurement. 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.
WCAG 2.2 Level AAA. Selected criteria relevant to Aletheia's design. 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
Section 508 Chapter 3. Functional performance criteria, conformance level, and remarks. Criterion Conformance level Remarks and explanations 302.1 Without Vision Partially Supports The product is operable without vision using a screen reader. Aletheia is tested with NVDA on Windows 11 and TalkBack on Android, targets support for JAWS, and has not been tested with VoiceOver or on any Apple platform. 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 320 CSS px, the equivalent of 400 percent zoom, is measured on every route of the marketing site on every build, and manual verification across the web application and the admin dashboards is scheduled (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 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. 302.8 With Limited Reach and Strength Supports The product runs on the user's own device and reflows to a 320 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
Section 508 Chapter 5. Software requirements, conformance level, and remarks. Requirements 501.1 and 504.1 are scope statements and are addressed by the rows below. 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
Section 508 Chapter 6. Support documentation and services, conformance level, and remarks. 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
Change history
Change history for this Accessibility Conformance Report. 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. The open mobile navigation drawer, which rested on backdrop-filter over a translucent panel and let page text read through it, is now opaque and covers the viewport, and the contrast sweep measures that state. September 21, 2026 1.5 The product evidence record now cites the application's latest tracked axe batch (a11-2026-09-20: 73 runs across desktop and mobile viewports, zero violations, including the Settings route that carries the data-export control) in place of the July 14, 2026 sweep. September 17, 2026 1.4 Label in Name (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), so speech-input users can activate each control by saying its label. The Supports verdict now describes the corrected state. A build-time test walks every generated page and fails on any link or button whose aria-label does not contain its visible text. September 17, 2026 1.3 Contact address consolidated to support@lonia.ai. Product description and criterion remarks now describe read-aloud playback in the browser rather than an audio export. August 26, 2026 1.2 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.1 Corrected the 2.5.8 Target Size and 302.7 remarks, which stated a measured 44 by 44 pixel figure the stylesheet contradicts. The Supports verdict is unchanged and remains correct: targets meet the Level AA 24 by 24 minimum, and inline targets qualify under the spacing exception. Separated the two automated evidence records that were previously cited as one, and named the artifact backing each. Added an explicit report version and this change history. July 14, 2026 1.0 Initial publication in the ITI VPAT 2.5 format.
Review cadence
Last review date: October 4, 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 support@lonia.ai owns the review and the republication.
Related documents