AIM Voluntary Product Accessibility Template (VPAT) 2.5 — Accessibility Conformance Report
Version 1.0 · Published April 23, 2026 · Vendor The Freedom Project, LLC
Product information
- Product name
- Architectural Insight for Modernization (AIM)
- Product version
- Continuous (SaaS) — release of record as of April 23, 2026
- Vendor
- The Freedom Project, LLC
- Contact
- [email protected]
Standards referenced
- Web Content Accessibility Guidelines (WCAG) 2.2 — Level A and Level AA
- Revised Section 508 standards (36 CFR Part 1194), as adopted by the U.S. Access Board
- EN 301 549 V3.2.1 (2021-03), Chapter 9 — Web (by reference to WCAG 2.1; AIM additionally targets the WCAG 2.2 superset)
WCAG 2.2 Report (Level A and Level AA)
Principle 1 — Perceivable
Information and user-interface components must be presentable to users in ways they can perceive.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Partially Supports | Functional images carry text alternatives. Decorative images use empty alt text plus role="presentation" and are skipped by assistive technology. The translator preserves alt text from user-uploaded source documents and marks images without authored alt text as decorative — AIM does not invent descriptions for images it did not author. The remaining gap is icon-font glyphs in a small number of legacy components, which are being audited and replaced with accessible name patterns. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | A | Not Applicable | AIM does not deliver audio-only or video-only content as a feature of the product. |
| 1.2.2 Captions (Prerecorded) | A | Not Applicable | AIM does not embed prerecorded video with audio as a feature of the product. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | A | Not Applicable | AIM does not deliver synchronized media as a feature of the product. |
| 1.2.4 Captions (Live) | AA | Not Applicable | AIM does not deliver live audio content. |
| 1.2.5 Audio Description (Prerecorded) | AA | Not Applicable | AIM does not deliver prerecorded video with audio. |
| 1.3.1 Info and Relationships | A | Supports | Generated reports use semantic HTML throughout: heading hierarchy, list markup, and tables that include <caption> elements with sequentially numbered titles plus scope="col" on every column header. A markdown post-processor promotes pre-table italic captions emitted by the report engines into proper HTML <caption> elements before rendering. The architecture diagram canvas exposes an equivalent table view of every component, integration, and zone. |
| 1.3.2 Meaningful Sequence | A | Supports | Reading order in the DOM matches the visual order on every page reviewed in the audit. |
| 1.3.3 Sensory Characteristics | A | Supports | Instructions never rely solely on shape, color, or position. Status indicators carry both color and a text label or icon with an accessible name. |
| 1.3.4 Orientation | AA | Supports | AIM is responsive and supports both portrait and landscape orientations on touch devices. |
| 1.3.5 Identify Input Purpose | AA | Supports | Authentication and account-management form fields use HTML autocomplete attributes that match the WCAG 2.2 input-purpose list. |
| 1.4.1 Use of Color | A | Supports | Color is never the only means of conveying information. Status, errors, and required-field indicators all carry text labels in addition to color. |
| 1.4.2 Audio Control | A | Not Applicable | AIM does not auto-play audio. |
| 1.4.3 Contrast (Minimum) | AA | Supports | Body text and interactive controls meet the 4.5:1 contrast ratio against their background; large text meets 3:1. Verified by automated accessibility scans across public and authenticated routes. |
| 1.4.4 Resize Text | AA | Supports | Browser zoom up to 200% does not cause loss of content or function. The interface uses relative units throughout. |
| 1.4.5 Images of Text | AA | Supports | Text is delivered as text, not as raster images. Architecture diagram labels are rendered as SVG text and exposed in the alternative table view. |
| 1.4.10 Reflow | AA | Supports | Single-column reflow is supported at 320 CSS pixels viewport width without two-dimensional scrolling for content that does not require it. |
| 1.4.11 Non-text Contrast | AA | Supports | Interactive controls and meaningful graphical objects meet the 3:1 contrast ratio against adjacent colors. Focus indicators are designed with a 3:1 outline-to-background ratio. |
| 1.4.12 Text Spacing | AA | Supports | User-applied text spacing overrides do not cause loss of content or function. |
| 1.4.13 Content on Hover or Focus | AA | Supports | Tooltips and popovers are dismissible, hoverable, and persist until dismissed or focus moves away. |
Principle 2 — Operable
User-interface components and navigation must be operable by all users.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 2.1.1 Keyboard | A | Partially Supports | All forms, navigation, dialogs, menus, and the in-product assistant are fully keyboard operable. The architecture diagram canvas itself is not directly keyboard operable; an equivalent table view and an accessibility editor view provide full add, edit, and delete operations through the same save pipeline as the visual canvas. Section 508 502.2 (Interoperability with Assistive Technology) is satisfied via this equivalent facilitation per 36 CFR 1194.5. |
| 2.1.2 No Keyboard Trap | A | Supports | Focus can always be moved away from any component via standard keyboard commands. Modal dialogs constrain focus while open, release on close, and return focus to the control that opened them. |
| 2.1.4 Character Key Shortcuts | A | Supports | AIM does not implement single-character key shortcuts. |
| 2.2.1 Timing Adjustable | A | Supports | Authenticated session expiry follows an 8-hour idle timeout (collaborator sessions follow the same model). Users receive notice before expiry and can extend by interacting with the application. There are no other time limits on user input. |
| 2.2.2 Pause, Stop, Hide | A | Supports | Animated transitions on the architecture diagram and elsewhere honor the prefers-reduced-motion media query and fall back to static rendering. |
| 2.3.1 Three Flashes or Below Threshold | A | Supports | No content flashes more than three times in any one-second period. |
| 2.4.1 Bypass Blocks | A | Supports | Skip-to-content links are present on every authenticated layout. The architecture diagram canvas additionally exposes a skip link to its alternative table view. |
| 2.4.2 Page Titled | A | Supports | Every page has a unique, descriptive <title>. Generated PDF reports carry their title in the document Info dictionary and the catalog enables /ViewerPreferences /DisplayDocTitle so the viewer chrome shows the document title rather than the file name. |
| 2.4.3 Focus Order | A | Supports | Tab order matches the visual and DOM order on every page reviewed in the audit. When a modal dialog opens, focus is moved into the dialog and constrained inside it; on close, focus is returned to the control that opened the dialog. |
| 2.4.4 Link Purpose (In Context) | A | Supports | Link text is descriptive of the destination, either alone or in combination with its programmatically determined context. |
| 2.4.5 Multiple Ways | AA | Supports | Authenticated users can reach any feature through both the persistent left navigation and the in-app search/assistant. Public site provides primary navigation, footer navigation, and on-page anchor links. |
| 2.4.6 Headings and Labels | AA | Supports | Headings and form labels describe the topic or purpose. Heading hierarchy is enforced by code review. |
| 2.4.7 Focus Visible | AA | Supports | A visible focus indicator with sufficient contrast is provided on every focusable element. |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Supports | When an element receives keyboard focus it is not entirely hidden by author-created sticky headers, banners, or other overlays. |
| 2.5.1 Pointer Gestures | A | Supports | No multipoint or path-based gestures are required to operate AIM. |
| 2.5.2 Pointer Cancellation | A | Supports | Activation of single-pointer functionality occurs on the up-event, allowing users to abort by moving off the target. |
| 2.5.3 Label in Name | A | Supports | Visible labels match the start of the accessible name on every interactive control. |
| 2.5.4 Motion Actuation | A | Not Applicable | AIM does not require device motion or user motion to operate any function. |
| 2.5.7 Dragging Movements | AA | Supports | The architecture canvas drag-to-reposition gesture has a single-pointer alternative through the table editor and the accessibility editor view. |
| 2.5.8 Target Size (Minimum) | AA | Supports | Interactive targets are at least 24 by 24 CSS pixels, or have sufficient spacing per the exception clause. |
Principle 3 — Understandable
Information and the operation of the user interface must be understandable.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 3.1.1 Language of Page | A | Supports | The default human language of every page is set on the <html lang> attribute. Generated PDF reports carry the same language declaration on the document catalog (/Lang). |
| 3.1.2 Language of Parts | AA | Supports | AIM is delivered in English; foreign-language passages, where present, are marked with a lang attribute. |
| 3.2.1 On Focus | A | Supports | Focusing a component does not initiate a change of context. |
| 3.2.2 On Input | A | Supports | Changing the setting of any user-interface component does not automatically cause a change of context unless the user has been advised of the behavior beforehand. |
| 3.2.3 Consistent Navigation | AA | Supports | Navigational mechanisms appear in the same relative order across pages. |
| 3.2.4 Consistent Identification | AA | Supports | Components with the same functionality are identified consistently. |
| 3.2.6 Consistent Help | A | Supports | Help mechanisms (the assistant launcher and the support email) are positioned consistently across the application. |
| 3.3.1 Error Identification | A | Supports | Form errors are identified in text and announced to assistive technology via aria-live regions and aria-invalid on the failing field. |
| 3.3.2 Labels or Instructions | A | Supports | Every input has either a visible label, an aria-label, or a programmatically associated description. |
| 3.3.3 Error Suggestion | AA | Supports | When validation fails on a known pattern, the error message includes a suggested correction. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Supports | Destructive operations (subscription change, billing actions, organization deletion) require explicit confirmation and provide a review step before submission. |
| 3.3.7 Redundant Entry | A | Supports | Information previously entered by the user within a multi-step process is auto-populated where appropriate. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Supports | Authentication does not require a cognitive function test other than identifying objects (passwords) or memorized secrets supported by paste-from-password-manager. Users may also enroll a TOTP authenticator and use a hardware-backed credential. |
Principle 4 — Robust
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
| Criterion | Level | Conformance | Remarks |
|---|---|---|---|
| 4.1.2 Name, Role, Value | A | Supports | For every user-interface component, the name and role can be programmatically determined. States, properties, and values that can be set by the user can be programmatically set, and notification of changes is available to assistive technology. |
| 4.1.3 Status Messages | AA | Supports | Status messages — including save confirmations, inline validation feedback, processing status for the in-product assistant, and rate-limit notices — are announced through polite live regions without requiring focus change. |
Revised Section 508 (36 CFR Part 1194)
| Section | Title | Conformance | Remarks |
|---|---|---|---|
| 501.1 | Scope (General) | Supports | AIM is software with a user interface. The applicable WCAG 2.2 Level A and AA success criteria are addressed in the WCAG portion of this report. |
| 502.2 | Interoperability with Assistive Technology | Supports | AIM is delivered as a web application using standard HTML, ARIA, and platform accessibility APIs. It interoperates with mainstream screen readers, screen magnifiers, and switch-control assistive technology across Windows and macOS. |
| 502.3 (Object Information) | Programmatically determinable name, role, state, properties, and value | Supports | Covered by WCAG 4.1.2. |
| 502.3.13 | Modification of values, states, and properties / Programmatically determinable purpose | Supports | Generated documents (HTML and PDF) include programmatically determinable structural relationships: heading hierarchy, list markup, table captions, and column header scope. |
| 503 | Applications | Supports | AIM does not disrupt platform-level accessibility features. User preferences such as system contrast settings and reduced-motion preferences are honored. |
| 504 | Authoring Tools | Supports | AIM generates content (assessments, reports, PDFs). Generated PDF output is tagged, carries a document language, and includes PDF/UA-1 oriented metadata across all export pipelines. |
| 602 | Support Documentation | Supports | Public learn pages, the in-product help assistant, and this Accessibility Conformance Report are delivered through the accessible AIM web application and are subject to the same WCAG 2.2 Level A and AA criteria. |
| 603 | Support Services | Supports | Accessibility-specific support is reachable at [email protected]. Acknowledgement is provided within five business days; remediation is prioritized by severity. |
Notes
Revision history
Version 1.0 (April 23, 2026): initial publication.
Conformance basis
This Accessibility Conformance Report (ACR) is a self-attestation by The Freedom Project, LLC. It is based on automated accessibility scanning across public and authenticated routes, automated lint-level enforcement of accessibility patterns, targeted manual review with mainstream screen readers on Windows and macOS, and continuous validation of the PDF export pipeline. An independent third-party evaluator audit is on the published roadmap; once complete, this report will be re-issued with the third-party verification.
Scope of evaluation
The evaluation covers the AIM web application and its generated outputs, including all PDF export pipelines. The evaluation excludes user-uploaded source documents (which AIM ingests but does not author) and third-party content embedded by reference.
No warranty of perfect conformance
Where this report indicates "Supports", AIM has implemented and tested the relevant accessibility patterns and they pass automated and manual review. We do not represent that every page in the application is free of every accessibility defect at every moment in time. Defects are addressed through the response process described under "Reporting an accessibility barrier".
Reporting an accessibility barrier
If you encounter a barrier in AIM, please report it to [email protected]. Include the page or feature, what you were trying to do, what happened, and the browser and assistive technology you were using if known. We acknowledge accessibility reports within five business days and prioritize remediation by severity. Critical barriers (those that block completion of a core task) are addressed in the current development sprint.