Skip to main content
AccessibleNotes wordmark AccessibleNotes

VPAT 2.5 · Voluntary Product Accessibility Template

Accessible Notes Accessibility conformance report

Self-evaluation against WCAG 2.1 Level AA and Section 508. Conformant on 72 criteria, partial on 5, not applicable on 25. No criteria fail.

Standards
WCAG 2.1 AA, Section 508
Version
1.0
Generated
2026-04-29
Evaluator
Normal Thought Technologies LLC

Self-evaluation by Normal Thought Technologies LLC. Independent third-party audit not yet conducted.

Download PDF Download YAML
About this report

What is a VPAT? The Voluntary Product Accessibility Template is the standard format for reporting how a product meets accessibility standards. Federal agencies, U.S. higher-education procurement, and many enterprise buyers expect a current VPAT during vendor review. We use VPAT 2.5, which covers WCAG 2.1 Level AA and Section 508.

Self-evaluation, plainly stated. This report is a self-evaluation by Normal Thought Technologies LLC — not an independent third-party audit. Each criterion lists the formal evaluator note, when it was last verified, and (where applicable) a plain-English explanation. An independent audit is on our roadmap; we'll publish that report here when it's complete.

Automated checks we run on every change. Continuous integration runs axe-core across application routes for WCAG violations, validates exported PDFs against PDF/UA with veraPDF, and runs a Playwright accessibility suite covering keyboard navigation, focus management, and ARIA semantics. These checks block deploys when they fail. Automation catches regressions; the criterion-by-criterion judgments below come from human review.

Refresh cadence. We regenerate the VPAT when UI or accessibility-affecting code ships, with a target of monthly review even when no code changes. The Generated date in the hero and the Last verified line on each criterion make staleness visible.

Report metadata and methodology

Product description

Accessible Notes is a web application that helps educators, students, and accessibility professionals produce documents in accessible formats. Authors upload source materials (handwritten notes, scanned PDFs, image-based documents), the application transcribes them into editable markdown, the editor surfaces an accessibility audit, and the document can be exported as a tagged PDF, DOCX, or HTML.

Evaluation methods used

  • Self-review of source templates, components, and styles against WCAG 2.1 AA and Revised Section 508 success criteria.
  • Automated browser-based accessibility checks (axe-core) executed in CI across the application's primary public and authenticated routes.
  • Automated keyboard, focus-visible, and skip-link probes executed in CI on the same routes.
  • PDF/UA-1 conformance check against a representative exported document, performed by veraPDF in CI.

Terms

The terms used in this report are those defined in the ITI VPAT 2.5 template:

Supports
The functionality of the product has at least one method that meets the criterion without known defects, or meets it 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.

Contact information

Accessibility feedback and accommodation requests: Email: accessibility@accessiblenotes.com Web: https://accessiblenotes.com/compliance

Notes

This report is a self-evaluation by Normal Thought Technologies LLC. It has not been validated by an independent third-party accessibility auditor. Each criterion lists the conformance level and a plain-language explanation of how the product satisfies (or fails to satisfy) the requirement. Accessibility is an ongoing commitment; this report is refreshed as the product changes and as additional evaluation methods are added.

Conformance by accessibility principle

WCAG organizes accessibility around four principles: Perceivable, Operable, Understandable, Robust. Section 508 adds Functional Performance Criteria covering specific user outcomes.

Perceivable

Information must be presentable in ways every user can perceive.

  • 11 supported
  • 3 partial
  • 6 N/A

Jump to Perceivable

Operable

Every interface control must be reachable and usable by every user.

  • 16 supported
  • 1 N/A

Jump to Operable

Understandable

Information and how the interface works must be understandable.

  • 9 supported
  • 1 N/A

Jump to Understandable

Robust

Content must work reliably with current and future assistive technologies.

  • 3 supported

Jump to Robust

Functional performance (Section 508 Chapter 3)

User-outcome criteria for people with specific disabilities, drawn from Section 508.

  • 5 supported
  • 1 partial
  • 3 N/A

Jump to Functional performance (Section 508 Chapter 3)

Hardware (Section 508 Chapter 4)

Hardware criteria from Section 508. Not applicable to a software-as-a-service product, but listed per the ITI VPAT 2.5 template.

  • 0 supported
  • 10 N/A

Jump to Hardware (Section 508 Chapter 4)

Software (Section 508 Chapter 5)

Software-product criteria from Section 508, including authoring-tool obligations for a product that exports accessible documents.

  • 23 supported
  • 1 partial
  • 3 N/A

Jump to Software (Section 508 Chapter 5)

Support documentation and services (Section 508 Chapter 6)

Section 508 criteria for the support documentation and customer-facing services that surround the product.

  • 5 supported
  • 1 N/A

Jump to Support documentation and services (Section 508 Chapter 6)

What we're working on

These criteria are partially supported today. We surface them up front because honest gaps are more useful to evaluators than glossy claims.

  • 1.1.1

    Non-text Content

    Alt text is the written description that goes with an image, so people who can't see it still understand what's there.

    Read details →
  • 1.4.3

    Contrast (Minimum)

    Contrast ratio measures how much a text color stands out from its background. The minimum requirement is 4.5:1 for normal text and 3:1 for large text, so that people with low vision can read comfortably.

    Read details →
  • 1.4.11

    Non-text Contrast

    Non-text contrast covers the visual boundaries of interactive controls — buttons, input fields, checkboxes, and focus indicators — which must stand out from their background at a 3:1 ratio even without any text involved.

    Read details →
  • 302.2

    With Limited Vision

    The application supports browser zoom to at least 400% without horizontal scrolling or loss of content on primary views, using a responsive layout with relative units throughout.

    Read details →
  • 504.2.1

    Preservation of Information Provided for Accessibility in Format Conversion

    Author-supplied accessibility metadata — alt text, heading structure, language declarations — is preserved through format conversion to PDF, DOCX, and HTML.

    Read details →
Filter & sort
Status
Standard
Principle

Functional performance (Section 508 Chapter 3)

9 criteria
  • 302.1 Supports FPC Without Vision

    Evaluator's note

    The application provides the structural conditions for screen-reader use — landmark regions, a skip-to-main-content link, a heading hierarchy, programmatic labels on form controls in the components reviewed, and ARIA live regions for dynamic status messages so updates are announced without moving focus. Exported documents are tagged PDFs; PDF/UA-1 conformance is checked against a representative sample export in CI rather than per individual export. End-to-end operability with screen-reader software has not been verified; this conformance statement rests on source review and automated CI probes rather than on assistive-technology walkthroughs.

    Last verified:
  • 302.2 Partial FPC With Limited Vision

    Evaluator's note

    The application supports browser zoom to at least 400% without horizontal scrolling or loss of content on primary views, using a responsive layout with relative units throughout. The design system targets the WCAG 4.5:1 minimum for normal text and 3:1 for large text; the axe-routes probe checks contrast in the default rendered states for the routes it covers. A complete contrast audit across all component interaction states (hover, focus, disabled, placeholder) has not yet been performed, so contrast conformance is reported as partial outside the default state. A dark theme is available system-wide. Exported PDFs are tagged and structured so assistive technology and zoom tools can reflow document content.

    Last verified:
  • 302.3 Supports FPC Without Perception of Color

    Evaluator's note

    The application never uses color as the sole means of conveying information. Form validation errors combine a colored border with an exclamation-circle icon and a text error message; alert and flash components pair a color-coded border with a labeled icon. Automated accessibility checks across application routes validate the presence of non-color indicators programmatically.

    Last verified:
  • 302.4 Not applicable FPC Without Hearing Not applicable — Accessible Notes does not produce audio output of any kind.

    Evaluator's note

    Accessible Notes does not produce audio output of any kind. All information is presented visually and programmatically, so no accommodation for users without hearing is required.

    Last verified:
  • 302.5 Not applicable FPC With Limited Hearing Not applicable — Accessible Notes produces no audio output, so no captions, transcripts, or volume controls are needed.

    Evaluator's note

    Accessible Notes produces no audio output, so no captions, transcripts, or volume controls are needed. Users with limited hearing experience no functional difference from users with full hearing.

    Last verified:
  • 302.6 Not applicable FPC Without Speech Not applicable — No feature in Accessible Notes requires voice or speech input.

    Evaluator's note

    No feature in Accessible Notes requires voice or speech input. All operations — uploading documents, editing notes, managing account settings, and exporting — are fully available via keyboard and pointer without any speech interaction.

    Last verified:
  • 302.7 Supports FPC With Limited Manipulation

    Evaluator's note

    All application features are operable through a keyboard alone. Modal dialogs are dismissed with the Escape key and do not trap focus; an automated probe confirms correct focus management on the note editing view. A separate probe confirms visible focus indicators across application routes, and the skip-to-main-content link reduces repetitive navigation for keyboard users. Interactive controls activate on pointer release, allowing users to cancel by moving the pointer away before releasing.

    Last verified:
  • 302.8 Supports FPC With Limited Reach and Strength

    Evaluator's note

    The application does not use motion actuation (no device-orientation or device-motion APIs) and does not require simultaneous or sustained physical input. All operations have keyboard equivalents, so users who cannot operate a pointer can accomplish every task with single-keypress actions. Interactive controls use standard touch-target sizing and activate on pointer release.

    Last verified:
  • 302.9 Supports FPC With Limited Language, Cognitive, and Learning Abilities

    Evaluator's note

    Navigation is consistent across all views — the same main navigation, skip link, and layout structure appear on every page. Destructive and financial actions require explicit confirmation before proceeding. Inline error messages pair a descriptive text label with an icon so that users who struggle with color perception or abstract symbols still receive actionable guidance. Decorative animations are suppressed when the operating system reports a preference for reduced motion, reducing cognitive distraction.

    Last verified:

Support documentation and services (Section 508 Chapter 6)

6 criteria
  • 601.1 Supports 508 Scope (Support Documentation and Services)

    Evaluator's note

    Support documentation and services for Accessible Notes consist of the public compliance pages, the embedded help and documentation links, and the responsive support email address. The criteria in §602 and §603 are addressed in the rows below.

    Last verified:
  • 602.2 Supports 508 Accessibility and Compatibility Features

    Evaluator's note

    A user-facing accessibility-features page in the help site enumerates the app's accessibility features in plain language — keyboard support, screen-reader semantics, authoring prompts, themes and contrast, dyslexic-friendly font, resize and reflow behavior, document-export accessibility, and assistive-technology compatibility. The formal compliance report and the embedded in-product help cover known gaps and remediation guidance.

    Last verified:
  • 602.3 Supports 508 Electronic Support Documentation

    Evaluator's note

    Support documentation is delivered electronically through the same accessible web interface as the rest of the application. The published VPAT is also available as a tagged PDF and as a downloadable YAML.

    Last verified:
  • 602.4 Not applicable 508 Alternate Formats for Non-Electronic Support Documentation Not applicable — Accessible Notes does not produce non-electronic support documentation, so this criterion does not apply.

    Evaluator's note

    Accessible Notes does not produce non-electronic support documentation, so this criterion does not apply.

    Last verified:
  • 603.2 Supports 508 Information on Accessibility and Compatibility Features

    Evaluator's note

    The public compliance pages identify the application's accessibility features, known gaps, and the email address customers can contact to discuss accommodation needs.

    Last verified:
  • 603.3 Supports 508 Accommodation of Communication Needs

    Evaluator's note

    A monitored accessibility-feedback email address is published on every compliance page; customers can use it to request accommodations or alternate communication arrangements.

    Last verified:

Software (Section 508 Chapter 5)

27 criteria
  • 501.1 Supports 508 Scope (Software)

    Evaluator's note

    Accessible Notes is web-based software. The Software requirements in §502, §503, and §504 are addressed in the rows below.

    Last verified:
  • 502.2.1 Supports 508 User Control of Accessibility Features

    Evaluator's note

    The application does not override or disable platform-level accessibility features. Operating-system and browser settings such as zoom, system text size, and color filters are honored by the responsive layout, and the application does not call APIs that would suppress assistive-technology delivery of content.

    Last verified:
  • 502.2.2 Supports 508 No Disruption of Accessibility Features

    Evaluator's note

    The application does not call browser APIs that would suspend, disable, or replace native focus management, keyboard navigation, or accessibility-tree exposure. Source review of the layout and component code confirms no such overrides are present.

    Last verified:
  • 502.3.1 Supports 508 Object Information

    Evaluator's note

    Object information is exposed to assistive technology through native HTML semantics and ARIA roles, names, and states. See WCAG 4.1.2 (Name, Role, Value) for the supporting evaluation.

    Last verified:
  • 502.3.2 Supports 508 Modification of Object Information

    Evaluator's note

    When assistive technology activates a control programmatically, the application updates both the visible state and the accessible state. See WCAG 4.1.2 for the supporting mechanism.

    Last verified:
  • 502.3.3 Supports 508 Row, Column, and Headers

    Evaluator's note

    Where tabular data is displayed, the application uses semantic table markup with header rows. See WCAG 1.3.1 (Info and Relationships).

    Last verified:
  • 502.3.4 Supports 508 Values

    Evaluator's note

    Form controls expose their current values to assistive technology through native HTML form semantics and ARIA state attributes. See WCAG 4.1.2.

    Last verified:
  • 502.3.5 Supports 508 Modification of Values

    Evaluator's note

    Form controls accept and reflect value changes from assistive technology. See WCAG 4.1.2.

    Last verified:
  • 502.3.6 Supports 508 Label Relationships

    Evaluator's note

    Form inputs and their labels are programmatically associated. See WCAG 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).

    Last verified:
  • 502.3.7 Supports 508 Hierarchical Relationships

    Evaluator's note

    Hierarchical relationships are exposed through landmark and heading semantics. See WCAG 1.3.1 (Info and Relationships).

    Last verified:
  • 502.3.8 Supports 508 Text

    Evaluator's note

    All visible text content in the interface is exposed as text to assistive technology, not as images of text. See WCAG 1.4.5 (Images of Text).

    Last verified:
  • 502.3.9 Supports 508 Modification of Text

    Evaluator's note

    Text fields accept programmatic modification from assistive technology. See WCAG 4.1.2.

    Last verified:
  • 502.3.10 Supports 508 List of Actions

    Evaluator's note

    Available actions are exposed through standard HTML element roles. See WCAG 4.1.2.

    Last verified:
  • 502.3.11 Supports 508 Actions on Objects

    Evaluator's note

    Assistive technology can programmatically activate interactive controls. See WCAG 2.1.1 (Keyboard) and 4.1.2 (Name, Role, Value).

    Last verified:
  • 502.3.12 Supports 508 Focus Cursor

    Evaluator's note

    Keyboard focus is both visually distinguishable and exposed to assistive technology. See WCAG 2.4.7 (Focus Visible).

    Last verified:
  • 502.3.13 Supports 508 Modification of Focus Cursor

    Evaluator's note

    Assistive technology can programmatically move focus using platform-standard mechanisms. See WCAG 2.1.1 and 2.4.3 (Focus Order).

    Last verified:
  • 502.3.14 Supports 508 Event Notification

    Evaluator's note

    Status changes are announced to assistive technology through ARIA live regions. See WCAG 4.1.3 (Status Messages).

    Last verified:
  • 502.4 Supports 508 Platform Accessibility Features

    Evaluator's note

    The application uses platform accessibility features made available by the browser and operating system. It does not implement parallel or replacement accessibility infrastructure.

    Last verified:
  • 503.2 Supports 508 User Preferences

    Evaluator's note

    The application honors operating-system preferences for color scheme (dark/light mode) and reduced motion. Other system preferences (font size, contrast) flow through the browser's normal user-agent behavior.

    Last verified:
  • 503.3 Supports 508 Alternative for Visual Information

    Evaluator's note

    Text alternatives are provided for non-text visual information in the interface. See WCAG 1.1.1 (Non-text Content) and 1.4.5 (Images of Text).

    Last verified:
  • 503.4.1 Not applicable 508 Caption Controls Not applicable — The application does not include audio or video content in its user interface, so caption controls do not apply.

    Evaluator's note

    The application does not include audio or video content in its user interface, so caption controls do not apply.

    Last verified:
  • 503.4.2 Not applicable 508 Audio Description Controls Not applicable — The application does not include audio or video content in its user interface, so audio description controls do not apply.

    Evaluator's note

    The application does not include audio or video content in its user interface, so audio description controls do not apply.

    Last verified:
  • 504.2 Supports 508 Content Creation or Editing (Authoring Tools)

    Evaluator's note

    Accessible Notes is purpose-built as an authoring tool for accessible documents. The editor surfaces an accessibility audit on the source content, and the export pipeline produces tagged PDF/UA-2, DOCX, and HTML output.

    Last verified:
  • 504.2.1 Partial 508 Preservation of Information Provided for Accessibility in Format Conversion

    Evaluator's note

    Author-supplied accessibility metadata — alt text, heading structure, language declarations — is preserved through format conversion to PDF, DOCX, and HTML. A representative PDF export passes PDF/UA-1 conformance in CI; a comprehensive verification across every rendering path (including placeholder fallbacks) has not yet been completed end-to-end.

    Last verified:
  • 504.2.2 Supports 508 PDF Export

    Evaluator's note

    Exported PDFs are tagged and declare PDF/UA-1 conformance metadata. A representative export is validated against PDF/UA-1 by veraPDF in CI rather than per individual export.

    Last verified:
  • 504.3 Supports 508 Prompts

    Evaluator's note

    The Edit Figure panel prompts authors for alt text whenever they add or edit a figure. An in-product accessibility audit view further surfaces missing or low-quality accessibility metadata across the document and prompts authors to address it before export.

    Last verified:
  • 504.4 Not applicable 508 Templates Not applicable — Accessible Notes does not provide author-facing document templates, so the criterion does not apply.

    Evaluator's note

    Accessible Notes does not provide author-facing document templates, so the criterion does not apply.

    Last verified:

Hardware (Section 508 Chapter 4)

10 criteria
  • 402 Not applicable 508 Closed Functionality Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 403 Not applicable 508 Biometrics Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 404 Not applicable 508 Preservation of Information Provided for Accessibility Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 405 Not applicable 508 Privacy Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 406 Not applicable 508 Standard Connections Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 407 Not applicable 508 Operable Parts Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 408 Not applicable 508 Display Screens Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 409 Not applicable 508 Status Indicators Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 410 Not applicable 508 Color Coding Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:
  • 411 Not applicable 508 Audible Output Not applicable — Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Evaluator's note

    Accessible Notes is a software-as-a-service product delivered through a web browser; this hardware criterion does not apply.

    Last verified:

Robust

3 criteria
  • 4.1.1 Supports A Parsing

    Evaluator's note

    Markup is generated through Phoenix LiveView's component system, whose HEEx compiler enforces well-formed tag nesting at compile time and whose server-side diff engine controls all runtime DOM mutations. The axe-routes probe checks rendered routes for parsing-class violations such as duplicate element identifiers and passes on every CI run for the routes it covers.

    Last verified:
  • 4.1.2 Supports A Name, Role, Value

    Plain English

    Name, Role, Value means every interactive element must have an accessible name (what it's called), a role (what kind of thing it is — button, checkbox, dialog), and its current state or value exposed to assistive technology.

    Why it matters

    Screen readers rely on this information to announce controls correctly. A button without a name is announced as "button" with no context; a custom switch without a checked state leaves the user guessing whether their action had any effect.

    What we do

    Accessible Notes uses native HTML semantics and ARIA attributes to expose names, roles, and states across all interactive components — including dialogs, form fields, tabs, the auto-renew toggle, and the sidebar note list.

    Evaluator's note

    Interactive components expose accessible names, roles, and states through native HTML semantics or ARIA. Dialogs use `role="dialog"` with `aria-labelledby` and `aria-describedby` associations and a focus trap; tabbed sections implement `role="tablist"` with `role="tab"` and `aria-selected` for keyboard navigation; auto-renew controls are implemented as `role="switch"` widgets with `aria-checked` and `aria-disabled`; the active item in navigation lists is marked with `aria-current="page"`. The axe-routes probe checks rendered routes for accessible-name and role-state violations and passes for the routes it covers; the custom switch and tablist patterns rest on source review rather than on interaction testing with assistive technology. PDF/UA-1 validation of a representative sample export passes in CI.

    Last verified: W3C reference
  • 4.1.3 Supports AA Status Messages

    Plain English

    Status messages are dynamic updates — "File saved," "3 errors found," "Processing complete" — that need to reach screen reader users without moving keyboard focus away from where they're working.

    Why it matters

    In a dynamic application like Accessible Notes, important state changes happen constantly. Without live regions, screen reader users must interrupt their work and manually navigate to find out what changed — or simply miss the update entirely.

    What we do

    Accessible Notes delivers all status messages through ARIA live regions. Informational updates use a polite region (announced at the next opportunity); errors use an assertive region (announced immediately). This covers the audit panel, upload manager, export section, and subscription state.

    Evaluator's note

    Status messages are delivered through ARIA live regions so assistive technology announces them without moving keyboard focus. A global flash region provides a polite live region for informational messages and an assertive `role="alert"` region with `aria-atomic="true"` for errors. Individual views add inline `role="status"` regions for subscription state, usage meters, export progress, and processing steps; incremental results are surfaced through a non-atomic polite region so screen readers announce updates as they arrive.

    Last verified: W3C reference

Understandable

10 criteria
  • 3.1.1 Supports A Language of Page

    Evaluator's note

    The web interface declares the document's primary language on the root HTML element using the runtime locale resolved by Gettext. The exported document pipeline declares language explicitly for every format — HTML and DOCX exports carry a language metadata declaration, and exported PDFs include the language entry in the PDF catalog as required for PDF/UA conformance.

    Last verified:
  • 3.1.2 Not applicable AA Language of Parts Not applicable — Accessible Notes ships with a single English locale.

    Evaluator's note

    Accessible Notes ships with a single English locale. There are no in-product passages in languages other than the declared page language, so this criterion does not apply.

    Last verified:
  • 3.2.1 Supports A On Focus

    Evaluator's note

    Moving focus into a component does not initiate navigation, submit a form, or otherwise change context. Context changes occur only on explicit user action such as pressing a button or submitting a form.

    Last verified:
  • 3.2.2 Supports A On Input

    Evaluator's note

    Changing a form field value triggers inline validation for immediate feedback but does not navigate away, open a new window, or otherwise change context. Form submission always requires an explicit user action on the submit control.

    Last verified:
  • 3.2.3 Supports AA Consistent Navigation

    Evaluator's note

    Navigation regions appear in the same relative order and location on every page that includes them. The global navigation and footer are defined once in the shared layout and reused across all pages without variation.

    Last verified:
  • 3.2.4 Supports AA Consistent Identification

    Evaluator's note

    Components that perform the same function — dismiss buttons, form submit controls, navigation items — are identified consistently across the application through shared reusable components with fixed accessible names and roles.

    Last verified:
  • 3.3.1 Supports A Error Identification

    Plain English

    Error identification means that when a form submission fails, each field with a problem is clearly identified and a text description of the error is provided — not just a color change or a generic "please fix the highlighted fields" message.

    Why it matters

    Users with cognitive disabilities, screen reader users, and anyone who can't perceive color rely on clear text descriptions to understand what went wrong and what to fix. Vague or color-only error states leave them stuck.

    What we do

    Accessible Notes renders a descriptive error message and a status icon adjacent to each failed field. Application-level errors use a live region with the alert role so assistive technology announces them immediately.

    Evaluator's note

    Form-field errors render a descriptive text message and an exclamation-circle icon adjacent to the failed field. Application-level errors are exposed through a global live region with `role="alert"` and `aria-live="assertive"`, so assistive technology announces them immediately without requiring user navigation.

    Last verified: W3C reference
  • 3.3.2 Supports A Labels or Instructions

    Evaluator's note

    Every form input is paired with a programmatically-associated label using an explicit `for` attribute. Fields requiring specific formatting include in-context helper text adjacent to the input.

    Last verified:
  • 3.3.3 Supports AA Error Suggestion

    Evaluator's note

    Validation errors describe the specific problem with actionable language — required-field messages name the field, format errors describe the expected pattern, and uniqueness violations indicate the conflict. Where a correction is knowable, the error message guides the user toward the fix.

    Last verified:
  • 3.3.4 Supports AA Error Prevention (Legal, Financial, Data)

    Evaluator's note

    Actions with financial or data consequences require an explicit confirmation step. Note deletion uses a two-step in-page confirmation flow; seat removal from teams presents a confirmation prompt before proceeding; subscription cancellation is performed through an explicit auto-renew toggle with labeled state. Payment transactions are handled through the Paddle checkout interface, which presents the transaction amount and period for user review before authorization.

    Last verified:

Operable

17 criteria
  • 2.1.1 Supports A Keyboard

    Plain English

    Keyboard accessibility means every function you can do with a mouse you can also do using only a keyboard — Tab to move, Enter or Space to activate, arrow keys to navigate within components.

    Why it matters

    People with motor disabilities, repetitive strain injuries, or power users who prefer the keyboard cannot use the application if any feature requires a mouse. Keyboard support is also the foundation for switch access and other assistive input devices.

    What we do

    Accessible Notes implements full keyboard support across all interactive controls, including custom widgets like the document reorder control and figure editor, which provide explicit arrow-key, Tab, and Enter handlers alongside pointer input.

    Evaluator's note

    Interactive controls in the application are built on native HTML elements that accept keyboard input by default. Custom interactive widgets — including a marketing-page comparison slider, a list reordering control, and the figure metadata editor — provide explicit keyboard handlers (arrow keys, Tab, and Enter) in addition to pointer input. Reorderable items expose screen-reader-only instruction text describing the keyboard interaction available on each item. End-to-end keyboard-only operability has been verified for in-product dialogs and the billing overlay by automated probes; broader manual keyboard-only walkthrough of every interactive control has not been completed.

    Last verified: W3C reference
  • 2.1.2 Supports A No Keyboard Trap

    Evaluator's note

    In-product dialogs use a focus wrapper with Escape key handling that moves focus into the dialog on open and restores it to the invoking element on close. The third-party billing checkout overlay is reachable by Tab; keyboard focus can be moved away from it by either Tab (which eventually leaves the iframe) or Escape (which closes the overlay). Both exit paths are confirmed by an automated keyboard probe against the billing overlay.

    Last verified:
  • 2.1.4 Supports A Character Key Shortcuts

    Evaluator's note

    Accessible Notes does not implement any single-character keyboard shortcuts. All keyboard shortcuts in the editor surface require a modifier key (Ctrl or Cmd). Arrow-key and Enter navigation inside interactive widgets is scoped to those widgets and does not conflict with assistive technology shortcuts.

    Last verified:
  • 2.2.1 Supports A Timing Adjustable

    Evaluator's note

    The application does not impose time limits on any user task. Document processing is an async background operation that users can monitor at their own pace; there is no deadline to complete editing, reviewing, or exporting a note.

    Last verified:
  • 2.2.2 Supports A Pause, Stop, Hide

    Evaluator's note

    The processing view provides an explicit "Pause animations" button that halts the scanning animation. The application stylesheet includes a prefers-reduced-motion media query that disables decorative pulse animations for users with that system preference set.

    Last verified:
  • 2.3.1 Supports A Three Flashes or Below Threshold

    Evaluator's note

    The application does not contain any content that flashes more than three times per second. All animations are slow CSS transitions and pulse effects with multi-second cycles, well below the general flash threshold.

    Last verified:
  • 2.4.1 Supports A Bypass Blocks

    Evaluator's note

    Every page provides a visually-hidden "Skip to main content" link that becomes visible on keyboard focus, letting keyboard and screen-reader users bypass the global navigation and jump directly to the main content area. All three layout variants (public marketing, app, and sidebar) include the skip link and a matching main landmark with the corresponding id.

    Last verified:
  • 2.4.2 Supports A Page Titled

    Evaluator's note

    Each page sets a unique descriptive document title that updates dynamically as the user navigates between views. Titles follow the pattern "Page Name · AccessibleNotes" so both the page context and the product name are always present.

    Last verified:
  • 2.4.3 Supports A Focus Order

    Plain English

    Focus order means that when you Tab through a page, focus moves in a logical sequence that matches the visual and reading order — and dialogs receive focus when they open, returning it to the trigger element when they close.

    Why it matters

    When focus jumps to an unexpected location — like appearing behind an open dialog, or skipping past the heading — keyboard and screen reader users lose their place and may miss important content or controls.

    What we do

    Accessible Notes ensures focus moves in the natural DOM order throughout the interface. Dialogs move focus to the first interactive element on open and restore it to the invoking control on close.

    Evaluator's note

    Focus order follows the visual and reading order throughout the application. Dialogs move keyboard focus to the first interactive element on open and restore it to the invoking control on close, so users do not lose their place in the page.

    Last verified: W3C reference
  • 2.4.4 Supports A Link Purpose (In Context)

    Evaluator's note

    Every link and button carries an accessible name through visible text or an explicit aria-label. Icon-only controls include an aria-label that matches the visible tooltip or purpose. Automated accessibility checks across application routes verify no unlabeled interactive elements are present.

    Last verified:
  • 2.4.5 Supports AA Multiple Ways

    Evaluator's note

    Authenticated users can reach any note through the persistent list of their notes in the workspace or through primary navigation. Unauthenticated visitors can navigate through the main navigation bar and footer links. The application does not have a single navigational path to any content.

    Last verified:
  • 2.4.6 Supports AA Headings and Labels

    Evaluator's note

    Headings in the web interface describe their sections using semantic heading elements, and form inputs have programmatically associated labels. Exported PDFs carry a complete heading structure; PDF/UA-1 conformance of that structure is checked against a representative sample export by veraPDF in CI rather than per individual export.

    Last verified:
  • 2.4.7 Supports AA Focus Visible

    Plain English

    Focus visible means keyboard users can always see which element currently has focus — typically shown as a visible outline or border change around the active control.

    Why it matters

    Without a visible focus indicator, keyboard users have no way of knowing where they are on the page. They have to Tab blindly and hope the page responds to keystrokes — a frustrating and unreliable experience.

    What we do

    Accessible Notes applies visible focus rings and accent borders from the design system to all interactive elements. The skip navigation link becomes visible on focus even though it is visually hidden at rest.

    Evaluator's note

    All interactive elements display a visible focus indicator through focus ring styles applied by the design system. The "Skip to main content" link becomes visible on focus even though it is visually hidden at rest. An automated focus-indicator probe across application routes confirms no interactive element loses its focus indicator.

    Last verified: W3C reference
  • 2.5.1 Supports A Pointer Gestures

    Evaluator's note

    The image-comparison slider and the drag-to-reorder document list both support single-pointer drag and keyboard alternatives (arrow keys). No functionality requires multi-point gestures (e.g., pinch-to-zoom) that lack a single-pointer equivalent.

    Last verified:
  • 2.5.2 Supports A Pointer Cancellation

    Evaluator's note

    Single-pointer activations (buttons, links, form submissions) are triggered on pointer up rather than pointer down, allowing users to cancel by moving off the target before releasing. The image-comparison slider is a continuous drag interaction, not a discrete activation, and is not subject to the up-event requirement.

    Last verified:
  • 2.5.3 Supports A Label in Name

    Evaluator's note

    Controls with visible text use that text as their accessible name. Icon-only controls carry an aria-label whose value matches the visible tooltip or the described action. Speech-control users can activate controls using the words they see on screen.

    Last verified:
  • 2.5.4 Not applicable A Motion Actuation Not applicable — Accessible Notes does not use device motion or orientation sensors.

    Evaluator's note

    Accessible Notes does not use device motion or orientation sensors. No functionality is triggered by shaking, tilting, or other physical device movement.

    Last verified:

Perceivable

20 criteria
  • 1.1.1 Partial A Non-text Content

    Plain English

    Alt text is the written description that goes with an image, so people who can't see it still understand what's there.

    Why it matters

    Screen readers read alt text aloud. Without it, blind and low-vision users hear only "image" or nothing — they miss whatever the image was meant to communicate.

    What we do

    When an author adds or edits a figure in Accessible Notes, the Edit Figure panel surfaces alt text as a required field. Notes pass through to export without a separate publish step, and the export pipeline does not re-validate alt text at the export boundary, so the alt-text guarantee lives at the authoring surface rather than at export time.

    Evaluator's note

    The Edit Figure panel surfaces alt text as a required field when an author adds or edits a figure. Author-provided alt text is carried into every export format. In PDF, figures without rendered images currently render as a styled placeholder box that displays the alt text as visible content — this preserves the description for screen-reader users but is not the canonical PDF/UA tagged-Figure mechanism. In DOCX, alt text is applied to the image object through a custom Pandoc style; in HTML, alt text is set as the `alt` attribute on `<img>`. Decorative icons in the interface use `aria-hidden` to suppress them from assistive technology. The export request path does not re-validate figures for alt-text completeness; a representative export containing a placeholder figure passes PDF/UA-1 in CI. End-to-end verification across every figure type and every rendering path has not yet been completed.

    Last verified: W3C reference
  • 1.2.1 Not applicable A Audio-only and Video-only (Prerecorded) Not applicable — Accessible Notes does not include any prerecorded audio-only or video-only content in its user interface or its exported documents.

    Evaluator's note

    Accessible Notes does not include any prerecorded audio-only or video-only content in its user interface or its exported documents.

    Last verified:
  • 1.2.2 Not applicable A Captions (Prerecorded) Not applicable — Accessible Notes does not include any prerecorded synchronized media that would require captions.

    Evaluator's note

    Accessible Notes does not include any prerecorded synchronized media that would require captions.

    Last verified:
  • 1.2.3 Not applicable A Audio Description or Media Alternative (Prerecorded) Not applicable — Accessible Notes does not include any prerecorded synchronized media that would require audio description or a media alternative.

    Evaluator's note

    Accessible Notes does not include any prerecorded synchronized media that would require audio description or a media alternative.

    Last verified:
  • 1.2.4 Not applicable AA Captions (Live) Not applicable — Accessible Notes does not deliver any live audio content.

    Evaluator's note

    Accessible Notes does not deliver any live audio content.

    Last verified:
  • 1.2.5 Not applicable AA Audio Description (Prerecorded) Not applicable — Accessible Notes does not include any prerecorded video content.

    Evaluator's note

    Accessible Notes does not include any prerecorded video content.

    Last verified:
  • 1.3.1 Supports A Info and Relationships

    Plain English

    Semantic structure means using the right HTML elements so that assistive technology can understand how your content is organized — headings, lists, tables, and form labels all need to carry meaning, not just appearance.

    Why it matters

    When structure is only visual, screen reader users can't navigate by headings or understand which label goes with which field. Proper semantic markup lets them jump directly to sections and understand relationships without reading everything on the page.

    What we do

    Accessible Notes uses semantic HTML throughout the interface — landmark regions, labeled form fields, and table captions — and configures the document export pipeline to produce tagged PDFs and DOCX files that preserve heading, list, and table structure.

    Evaluator's note

    The web interface uses semantic HTML with landmark regions (navigation, main content, sidebar) and programmatic associations between form fields and their labels, headings and their sections, and dialogs and their titles. Dynamic status regions and tabbed panels expose role and live-region attributes to assistive technology. For exported documents, Pandoc with LuaLaTeX is configured to emit tagged PDF/UA output preserving heading, list, and table relationships, including per-header Scope (Row, Column, Both) for table headers. An automated CI export check validates a representative export that contains a markdown table against PDF/UA-1 via veraPDF; veraPDF's rule set enforces correct table and table-header tagging.

    Last verified: W3C reference
  • 1.3.2 Supports A Meaningful Sequence

    Evaluator's note

    Reading order matches visual presentation throughout the interface; page layouts use flow-based CSS that keeps DOM order and visual order aligned. Exported documents preserve the source order of the note body as produced by the editor.

    Last verified:
  • 1.3.3 Supports A Sensory Characteristics

    Evaluator's note

    Instructions and error messages do not depend solely on shape, size, visual location, orientation, or sound. Validation errors include both a descriptive text message and a status icon rather than relying on color or position alone.

    Last verified:
  • 1.3.4 Supports AA Orientation

    Evaluator's note

    The application does not restrict display to a single screen orientation. All views use responsive, flexible layouts that adapt to portrait and landscape orientations without loss of content or functionality.

    Last verified:
  • 1.3.5 Supports AA Identify Input Purpose

    Evaluator's note

    Form fields whose purpose maps to a WCAG input-purpose category declare the corresponding HTML autocomplete token. Account and contact forms use autocomplete values for name, email, organization, and organization-title, enabling assistive technology and credential managers to recognize field purpose and offer appropriate assistance.

    Last verified:
  • 1.4.1 Supports A Use of Color

    Evaluator's note

    Color is not used as the sole means of conveying information. Validation errors pair a colored border with a descriptive text message and an icon; status indicators combine color with a textual label so all information is available to users who cannot distinguish colors.

    Last verified:
  • 1.4.2 Not applicable A Audio Control Not applicable — Accessible Notes does not play any audio automatically or on demand.

    Evaluator's note

    Accessible Notes does not play any audio automatically or on demand.

    Last verified:
  • 1.4.3 Partial AA Contrast (Minimum)

    Plain English

    Contrast ratio measures how much a text color stands out from its background. The minimum requirement is 4.5:1 for normal text and 3:1 for large text, so that people with low vision can read comfortably.

    Why it matters

    Poor contrast makes text hard or impossible to read for people with low vision, color blindness, or anyone using a screen in bright sunlight. It is the most frequently cited WCAG failure in accessibility lawsuits.

    What we do

    Accessible Notes uses a design system palette built around perceptually-uniform color space, with primary text and error states selected to meet the 4.5:1 minimum. A full programmatic audit is ongoing.

    Evaluator's note

    The design system uses a curated palette in perceptually-uniform OKLCH color space with separate light and dark themes; primary body text, brand text, and error states are selected to meet the 4.5:1 minimum ratio for normal text. Automated axe scans of representative routes pass without contrast violations. A complete audit across all component interaction states (hover, disabled, placeholder) has not yet been performed, so conformance is reported as partial pending that review.

    Last verified: W3C reference
  • 1.4.4 Supports AA Resize Text

    Evaluator's note

    Text sizes are expressed in relative units and layout containers use flexible sizing. Content and functionality are preserved when text is scaled to 200% using standard browser zoom.

    Last verified:
  • 1.4.5 Supports AA Images of Text

    Evaluator's note

    All interface text is rendered as real HTML text rather than images. Icons are vector SVG sprites that carry no textual content, and all labels and headings use the web font stack.

    Last verified:
  • 1.4.10 Supports AA Reflow

    Evaluator's note

    The interface uses responsive, flexible layouts that reflow content to a single column at narrow viewports. No critical content requires two-dimensional scrolling at a 320 CSS pixel viewport width.

    Last verified:
  • 1.4.11 Partial AA Non-text Contrast

    Plain English

    Non-text contrast covers the visual boundaries of interactive controls — buttons, input fields, checkboxes, and focus indicators — which must stand out from their background at a 3:1 ratio even without any text involved.

    Why it matters

    People with low contrast sensitivity may not be able to see where a button ends and the background begins, making it impossible to identify or click controls. Focus rings that fade into the background leave keyboard users unable to track their position.

    What we do

    Accessible Notes styles interactive component boundaries and focus rings using the themed palette so they stand out against adjacent backgrounds. A formal per-component audit is in progress.

    Evaluator's note

    Interactive controls receive a globally-applied :focus-visible outline and component borders are styled with the themed palette to stand out against adjacent backgrounds. A complete per-component non-text contrast audit measuring all boundary ratios against the 3:1 minimum has not yet been completed, so conformance is reported as partial.

    Last verified: W3C reference
  • 1.4.12 Supports AA Text Spacing

    Evaluator's note

    Layout containers use flexible, relative spacing and do not impose fixed heights that would clip text when users override line-height, letter-spacing, word-spacing, or paragraph-spacing. Content remains readable and no information is lost when these properties are changed by a user stylesheet.

    Last verified:
  • 1.4.13 Supports AA Content on Hover or Focus

    Evaluator's note

    Tooltip content uses `role="tooltip"` and remains visible while the pointer remains over either the trigger element or the tooltip itself. Content can be dismissed by moving focus away, and pointer users can hover over the tooltip content without it disappearing.

    Last verified:

Questions, or found a defect?

For procurement questions, accommodation requests, audit reference requests, or to report an accessibility issue, email accessibility@accessiblenotes.com . We respond within two business days.