Accessibility Statement

1. Our Commitment

25 Alpha LLC is committed to ensuring that NoteVUE is accessible to all users, including students, teachers, and families who use assistive technologies or who navigate the web in non-standard ways. We believe that every teacher deserves to receive appreciation, and every student deserves the ability to express it — regardless of disability status or the assistive technology they rely on.

Accessibility is not a compliance checkbox at NoteVUE; it is a design requirement integrated into our engineering and product workflows. We evaluate accessibility at every stage of feature development and conduct regular audits to identify and remediate barriers.

2. Conformance Status

NoteVUE targets full conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the World Wide Web Consortium (W3C). WCAG 2.1 Level AA is the internationally recognized standard for digital accessibility and is referenced by the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, and analogous laws in other jurisdictions.

We conduct regular automated accessibility audits using Google Lighthouse (run in both CI and production environments) and the axe DevTools browser extension. We supplement automated testing with manual keyboard navigation testing and screen reader testing using NVDA on Windows and VoiceOver on macOS and iOS. Our goal is to achieve a Lighthouse Accessibility score of 100 on all primary page routes.

Where known limitations exist (described in Section 4), we provide text-based alternatives to ensure that all meaningful content is available to all users.

3. Technical Specifications

Keyboard Navigation

All interactive elements on NoteVUE — including buttons, links, form inputs, and modal dialogs — are reachable using the Tab key and activated using Enter or Space, consistent with WCAG 2.1 Success Criterion 2.1.1 (Keyboard). No keyboard traps are present; pressing Escape will always close modal dialogs and return focus to the triggering element.

Skip Navigation

A “Skip to main content” link appears at the top of every page and becomes visible on keyboard focus. This allows keyboard and screen reader users to bypass repetitive navigation elements and proceed directly to the page’s primary content, consistent with WCAG 2.1 Success Criterion 2.4.1 (Bypass Blocks).

Screen Readers

All icon-only buttons carry descriptive ARIA labels. All page sections have appropriate ARIA landmark roles (main, nav, banner, contentinfo). Dynamic content regions — such as the live note feed and leaderboard — use ARIA live regions (aria-live and aria-atomic) to announce updates to screen reader users without requiring page navigation.

Modal dialogs follow the WAI-ARIA Authoring Practices Guide (APG) dialog pattern: focus is moved to the dialog on open, a visible close button is provided, focus is trapped within the dialog while open, and focus is returned to the triggering element on close.

Color Contrast

All normal text on NoteVUE meets the WCAG 2.1 Level AA minimum contrast ratio of 4.5:1. Large text (18pt and above, or 14pt bold and above) and UI component boundaries meet the 3:1 minimum. We verify contrast ratios for all color combinations, including hover and focus states, using the WebAIM Contrast Checker. Our brand color palette was selected with contrast compliance as a primary constraint.

Focus Indicators

All interactive elements display a clearly visible focus ring when keyboard-focused. Our focus indicators use the focus-visible CSS pseudo-class to appear only for keyboard navigation, not pointer interaction, providing a clean visual experience for mouse users while maintaining full keyboard accessibility. Focus rings are styled with sufficient contrast against the element and its background, consistent with WCAG 2.1 Success Criterion 2.4.11 (Focus Appearance, Level AA).

Images and Alternative Text

All meaningful images include descriptive alt text that conveys the purpose of the image. Decorative images — icons and illustrations that are purely presentational — are marked with empty alt="" and aria-hidden="true" so that screen readers skip them. Teacher avatar initials are supplemented with aria-label attributes that include the teacher’s full name for screen reader users.

Forms and Error Handling

All form fields on NoteVUE have associated <label> elements or descriptive aria-label attributes. Error messages are programmatically associated with their corresponding fields using aria-describedby. Required fields are indicated both visually and programmatically via aria-required. Form validation errors are announced to screen reader users via ARIA live regions.

Motion and Animation

NoteVUE uses Framer Motion for UI animations. All animations respect the user’s prefers-reduced-motion media query. When a user has configured their operating system to prefer reduced motion, all decorative animations — entrance transitions, hover effects, and loading shimmer effects — are disabled or minimized to simple opacity fades. This is implemented at the component level using Framer Motion’s useReducedMotion hook, consistent with WCAG 2.1 Success Criterion 2.3.3 (Animation from Interactions, Level AAA) and best practices for users with vestibular disorders.

Language

The <html> element of every page on NoteVUE includes the lang="en" attribute, enabling screen readers to correctly pronounce page content, consistent with WCAG 2.1 Success Criterion 3.1.1 (Language of Page).

4. Known Limitations

The following known limitation exists as of the date of this statement:

• Share Card Generator: The appreciation wall share card feature uses an HTML Canvas element to generate a shareable image of a teacher’s wall. Canvas-based content is not inherently accessible to screen readers. As a mitigation, we provide a text-based alternative that presents all information contained in the share card — including the teacher’s name, school, note count, and milestone tier — in a readable format that is accessible to screen readers and keyboard users. We are investigating a CSS/SVG-based replacement for the Canvas implementation in a future release.

We are committed to remediating known limitations on a reasonable timeline. If you encounter an accessibility barrier not described here, please contact us using the information in Section 5.

5. Accessibility Feedback

We welcome accessibility feedback from all users. If you experience difficulty accessing any feature of NoteVUE due to a disability, or if you believe a feature does not meet WCAG 2.1 Level AA standards, please contact us at:

We commit to responding to accessibility feedback within 2 business days. In your message, please describe the barrier you encountered, the assistive technology or browser you were using, and the page or feature affected. This information helps us reproduce and remediate issues efficiently.

6. Formal Complaints

If you are not satisfied with our response to your accessibility concern, you may file a complaint with the U.S. Department of Education Office for Civil Rights (OCR), which enforces Section 504 of the Rehabilitation Act and Title II of the ADA with respect to educational institutions and programs. Information about filing a complaint with OCR is available at ed.gov/about/offices/list/ocr/complaintintro.html.

Additionally, individuals with disabilities may file complaints with the U.S. Department of Justice Civil Rights Division regarding ADA Title III compliance for public accommodations and commercial facilities. We encourage you to contact us directly first so we can address your concern promptly.

7. Assessment Approach

NoteVUE’s accessibility is assessed through the following methods:

• Automated CI testing: Google Lighthouse accessibility audits are run automatically on each production deployment via our CI/CD pipeline. Accessibility regressions block deployment.
• axe DevTools: The axe browser extension is used during development to identify and resolve WCAG violations before code is merged.
• Manual keyboard testing: All primary user flows — sending a note, browsing the leaderboard, viewing a teacher wall — are tested via keyboard navigation prior to each major release.
• Screen reader testing: Core flows are tested using VoiceOver on macOS (Safari) and NVDA on Windows (Chrome) on a scheduled basis.
• Third-party audits: We plan to engage an independent accessibility consultant for a comprehensive manual audit on an annual basis, with the first engagement planned for Q4 2026.