Accessibility Statement

CoreNotes is a browser-based study tool. Accessibility is built in from the start, not bolted on afterward. Our baseline target is WCAG 2.2 Level AA, with selected AAA criteria treated as hard targets.

This statement was last reviewed on 2 August 2026.

Our commitment

CoreNotes is a study tool used by students, and students include people who rely on screen readers, keyboard navigation, magnification, voice control, and high-contrast display modes. We take WCAG 2.2 Level AA as our minimum baseline across both the marketing site and the app shell at /app/.

If you find a barrier, we want to know. Accessibility defects are treated as bugs, not feature requests.

What we do on every page

Real contrast ratios. All text meets or exceeds WCAG 4.5:1 (normal text) and 3:1 (large text and UI components). The Cornell red (#C0392B) on white passes 5.3:1.
Keyboard navigation. Every interactive element is reachable and operable by keyboard alone. Tab order follows visual reading order.
Skip link. "Skip to content" is the first focusable element on every page, linking to the main content landmark.
Semantic HTML. We use native HTML elements (<nav>, <main>, <header>, <footer>, <section>, <article>, <h1>–<h6>, <button>) so assistive technologies receive correct role information without relying on ARIA overrides.
Landmarks. Every page has a single <main> with a matching skip-link target. Navigation regions carry aria-label. The footer has its own navigation landmark.
Image alt text. Meaningful images carry descriptive alt. Decorative images and SVG icons carry aria-hidden="true" and focusable="false".
Reduced motion respected. All transitions and animations are suppressed when the operating system prefers-reduced-motion: reduce is active.
44×44 px touch targets. All interactive controls meet WCAG 2.5.8 minimum touch target size.
Forced-colors mode. The site adapts to Windows High Contrast and other forced-colors environments. Key interactive elements use forced-color-adjust to preserve legibility.
aria-hidden on decorative SVGs. All purely decorative inline SVGs carry both aria-hidden="true" and focusable="false" to prevent spurious announcements in IE/Edge legacy mode.
lang="en" on <html>. Every page declares its language so screen readers apply the correct pronunciation engine.
Color is never the only carrier of meaning. Active navigation items are distinguished by weight and underline, not only by colour. Status indicators carry a label, not just a colour dot.
aria-current="page" on active nav links. The current page is announced to screen readers by attribute, not only by visual styling.

WCAG 2.2 new criteria we test

WCAG 2.2 introduced several criteria beyond 2.1. We test all of them:

2.4.11 Focus Not Obscured (AA). Focused elements are never fully hidden behind the sticky header or other persistent UI. We apply scroll-padding-top and scroll-margin-top to prevent sticky chrome from covering the focused element.
2.4.12 Focus Not Obscured — Enhanced (AAA). We treat this as a hard target: focused elements must be entirely visible, not merely partially. We audit this manually with keyboard-only navigation.
2.5.7 Dragging Movements (AA). Every action that involves dragging (note reorder, schedule block creation) also has a single-pointer alternative that does not require dragging.
2.5.8 Target Size Minimum (AA). All clickable/tappable targets are at least 44×44 CSS pixels. Inline text links are exempt per the specification; all others are tested.
2.4.13 Focus Appearance (AAA). We aim for focus indicators that meet the enhanced colour contrast and minimum area requirements, using a 3 px Cornell-red ring with 3 px offset.

How we test

We use a combination of automated tools and manual inspection:

Automated: Lighthouse accessibility audit, axe DevTools browser extension, WAVE (WebAIM).
Keyboard-only navigation: Full interaction walk-through with no mouse input.
Screen readers: VoiceOver on macOS and iOS, NVDA on Windows.
Browser zoom: Layouts tested at 100%, 150%, 200%, and 400% zoom. No content clips or overlaps at 200%.
Reduced-motion OS setting: All animations and transitions verified to be suppressed.
Forced-colors / High Contrast mode: Windows High Contrast (black and white modes) via Edge and Chrome forced-colors emulation.

App-specific notes

The CoreNotes app shell at /app/ stores all data locally in IndexedDB. Nothing is uploaded unless you switch on sync, which is optional and off by default.

Cue-column toggle. The button to show or hide the cue column is keyboard-accessible and announces its expanded/collapsed state via aria-expanded.
Recite mode. Activating recite mode (which masks note answers for active recall) is a keyboard-accessible button with clear labelling.
Drag-to-reorder notes. Notes can be reordered by drag and drop. A keyboard alternative using Up/Down move buttons is available for all reorder operations — no drag is required.
Schedule draw-to-create. Time blocks in the 168-hour planner can be created by clicking and dragging. A click-to-create alternative is also available: clicking an empty slot opens a dialog to set the block's start time, end time, and label without requiring any drag.
Pomodoro timer. Timer controls are standard <button> elements with aria-label text. Timer state changes are announced via a live region.

Known limitations

We are transparent about areas that are not yet fully conformant:

Pagefind search UI. The compiled-site search widget is generated by the Pagefind library. Its internal DOM markup is outside our control. We have reported accessibility issues upstream and apply CSS fixes where possible. Keyboard navigation of results works; some ARIA labelling inside the widget is not ideal.
Drag-and-drop reorder. While a keyboard alternative (move buttons) is always available, the drag interaction itself does not expose live position feedback via ARIA during the drag. Users who prefer drag may not receive in-progress announcements on all screen reader / browser combinations. The keyboard path is fully accessible.
Schedule draw-to-create on touch. Creating a schedule block by touch-dragging does not provide haptic feedback at the start and end of a block. A tap alternative is available and recommended for touch-primary users.

Standards and regulations

CoreNotes targets conformance with:

WCAG 2.2 Level AA — Web Content Accessibility Guidelines, W3C Recommendation.
Section 508 of the US Rehabilitation Act (ICT standards, incorporates WCAG 2.0 AA by reference).
EN 301 549 — European accessibility standard for ICT products and services (references WCAG 2.1 AA).
ADA Title III — Americans with Disabilities Act, as applied to websites providing goods and services to the public.

Assistive technology tested

Assistive technology	Platform	Browser
VoiceOver	macOS	Safari
VoiceOver	iOS	Safari
NVDA	Windows	Chrome, Firefox
TalkBack	Android	Chrome
Keyboard-only navigation	macOS, Windows	Chrome, Firefox, Safari, Edge
Browser zoom to 400%	macOS, Windows	Chrome, Firefox
Windows High Contrast (forced-colors)	Windows	Edge, Chrome

Conformance status

CoreNotes is partially conformant with WCAG 2.2 Level AA. "Partially conformant" means that some parts of the content do not fully conform to the accessibility standard.

Specifically: drag-and-drop interactions have keyboard alternatives but are not purely keyboard-driven (the drag path does not provide full screen-reader announcements mid-drag). All other AA criteria are met to the best of our knowledge.

Contact us

If you encounter an accessibility barrier on CoreNotes, please contact us:

Email: Contact via email — use subject line "Accessibility"

We aim to respond to accessibility reports within 5 business days and to resolve confirmed barriers within 30 days where technically feasible. If a fix requires a third-party library change, we will provide an interim workaround and track the upstream issue.