Back to Home
Accessibility
JurisNote is committed to making legal-education tools usable by everyone, including people who rely on assistive technology. This page states what we aim for, what is supported today, where we fall short, and how to tell us about a barrier — honestly.
Conformance target
We measure JurisNote against the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, the standard referenced by Section 508 of the Rehabilitation Act (Revised 2017) and by the European standard EN 301 549. Level AA is our target; we are not yet fully conformant, and the report below is an honest, per-criterion account of where we stand.
Because a published conformance report is a representation we take seriously, we mark a criterion “Supports” only where our now-live automated conformance gate reports zero violations for the matching check across the scanned pages and shared components. Criteria that still depend on manual evaluation, or that carry a known residual, are reported as “Partially Supports”; unmet criteria as “Does Not Support”; and inapplicable ones as “Not Applicable”. An independent third-party audit is still pending.
What is supported today
- A skip-to-content link (the first focusable element on the page) that jumps keyboard and screen-reader users to the main content landmark.
- An Accessibility menu with Large Text, High Contrast, and Focus Mode preferences that persist between visits.
- Reduced-motion support: animations are minimized when your operating system requests reduced motion.
- Keyboard alternatives to drag-and-drop for organizing flashcards, cases, and outlines into folders.
- Accessible dialogs and menus built on Radix primitives, with managed focus and ARIA roles.
- A live automated accessibility gate: on every change, axe-core (WCAG 2.x AA) scans our public, dashboard, and admin routes — including the landing page, sign-in / sign-up, every dashboard section, the outline editor, and forms — in both light and dark themes. The gate now runs with an EMPTY allowlist (zero tolerated violations), so the build fails on any new violation of any kind. Over 100 component-level jest-axe tests additionally cover our shared building blocks.
- Design-token color contrast proven by a deterministic test that computes the WCAG ratio directly from our CSS variables in both themes.
Known limitations
We would rather tell you where we fall short than overstate our conformance. The following are known gaps we are actively working to close.
- Prerecorded video does not yet ship synchronized captions or audio descriptions (WCAG 1.2.2 / 1.2.5). Accessible-media work is in progress.
- A full-app automated route scan (public, dashboard, and admin routes in light and dark) is part of the gate, and its allowlist is now empty — every violation node it originally surfaced (unnamed controls, unlabeled inputs, color-only in-text links, ~180 color-contrast cases, two ARIA-attribute issues, and the user-manual scroll region) has been fixed, which is why nine criteria moved to “Supports.” Two automated-but-partial items remain: full keyboard operability (2.1.1) still needs a manual assistive-technology pass beyond the clean axe signal, and one legacy button does not reach the stricter AAA (7:1) contrast used by our optional High-Contrast mode (our conformance target is AA / 4.5:1, which it meets).
- The gate scans every top-level route but drives them with an empty test account, so states that only appear with real data are not yet exercised; and it is not a substitute for a manual assistive-technology pass of all 194 routes.
- PDF exports are not yet tagged for PDF/UA.
- This report is a self-assessment. It is now backed by a live automated axe-core scan (representative pages, both themes) and component-level tests, but it has not yet been validated by a manual screen-reader evaluation of every page or an independent third-party audit.
Conformance report (VPAT / ACR)
A per-Success-Criterion account modeled on the VPAT 2.5 (WCAG 2.x) format. The conformance values are defined as: Supports — the criterion is met across the pages our automated gate scans, evidenced by zero matching-rule violations plus component-level tests; Partially Supports — some functionality does not meet the criterion; Does Not Support — the criterion is not met; and Not Applicable — the criterion does not apply to our content (see “Conformance target” above).
WCAG 2.1 — Level A
| Success Criterion | Conformance | Remarks & remediation |
|---|---|---|
| 1.1.1 Non-text Content | Supports | Icon-only buttons and links, and select/combobox triggers, carry accessible names across the public, dashboard, and admin surfaces (the last unnamed icon buttons and dropdown triggers were named in this wave); decorative images use empty alt text, informative images carry real alt text, and charts expose role="img" labels with a data-table alternative. The live axe gate reports no button-name, link-name, or image-alt violations across the scanned surface, backed by component jest-axe tests. |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Partially Supports | Recorded lecture audio has machine-generated transcripts, but transcript availability and accuracy are not verified for all media. |
| 1.2.2 Captions (Prerecorded) | Does Not Support | Synchronized captions for prerecorded video are not yet provided. Accessible-media (captions) work is in progress and tracked separately. |
| 1.3.1 Info and Relationships | Supports | Every scanned route reaches a single <main id="main"> landmark with semantic, correctly-ordered headings, and every form control — inputs, select/combobox triggers, and sliders — is programmatically associated with a label (an associated <label>, aria-label, or aria-labelledby); the remaining unlabeled inputs and slider thumbs the earlier scan found were fixed this wave. The live axe gate reports no region, heading-order, label, or aria-input-field-name violations across the scanned surface, backed by component tests. |
| 1.3.2 Meaningful Sequence | Partially Supports | Reading and DOM order generally follow visual order; not exhaustively verified with an assistive-technology pass on every route. |
| 1.3.3 Sensory Characteristics | Partially Supports | Instructions generally do not rely on shape/color/position alone; not exhaustively verified. |
| 1.4.1 Use of Color | Supports | Status, validity, and presence indicators that previously relied on color alone now also carry text or an icon (e.g. online-presence and issue-status include visually-hidden or visible text), remediated with component tests, and inline text links are distinguishable from surrounding text without relying on color — an always-on underline replaced hover-only styling on the flagged in-text links. The live axe gate reports no use-of-color (link-in-text-block) violations across the scanned surface. |
| 2.1.1 Keyboard | Partially Supports | Drag-and-drop has keyboard 'Move to folder' alternatives (flashcards/cases/outlines), the scheduler calendar and MCQ option groups are keyboard-operable (component keyboard tests), sortable headers are real buttons, and the user-manual scroll regions were made keyboard-focusable — the live axe gate now reports no keyboard (scrollable-region-focusable) violations across the scanned surface. A full assistive-technology pass of every interactive control is still pending, so this is not asserted product-wide. |
| 2.1.2 No Keyboard Trap | Partially Supports | Radix dialogs manage and restore focus; no trap observed, but not verified with an assistive-technology pass on every flow. |
| 2.4.1 Bypass Blocks | Supports | A skip-to-content link is the first focusable element and resolves to a single <main id="main" tabIndex={-1}> landmark on every route, including the standalone marketing/legal pages remediated in this wave (skip-link + landmark regression tests). The live axe gate reports no region violations across the scanned surface. |
| 2.4.2 Page Titled | Supports | Every scanned route sets a descriptive <title>, and the live axe gate reports no document-title violations across the public, dashboard, and admin surfaces in both light and dark themes. |
| 2.4.3 Focus Order | Partially Supports | Confirmation dialogs restore focus to the invoking control and skip targets are focusable; global focus order is not exhaustively verified on every route. |
| 2.4.4 Link Purpose (In Context) | Supports | Overlay/back links and icon links carry descriptive accessible names across the public, dashboard, and admin surfaces; the last unnamed icon link was named this wave and the live axe gate reports no link-name violations across the scanned surface, backed by component tests. |
| 3.3.1 Error Identification | Partially Supports | Form errors are identified in text and fields expose aria-invalid + aria-describedby (e.g. registration); component tests cover the common forms, but coverage across every form is not yet complete. |
| 3.3.2 Labels or Instructions | Supports | Inputs, select/combobox triggers, and sliders across the public, dashboard, and admin surfaces are programmatically labeled (an associated <label>, aria-label, or aria-labelledby), and shared form components carry jest-axe tests. The live axe gate reports no label, aria-input-field-name, or unnamed-control (button-name) violations across the scanned surface. |
| 4.1.2 Name, Role, Value | Supports | Radix Dialog/AlertDialog ARIA is correct, icon-only controls and select/combobox triggers carry accessible names, toggles expose state (aria-pressed / aria-expanded), custom widgets use correct roles, and the last two ARIA-attribute issues (a dialog-trigger card role on brief-templates, an outlines view-toggle tab's aria-controls) were fixed. The live axe gate reports no name/role/value violations — button-name, link-name, aria-allowed-attr, aria-valid-attr-value, aria-input-field-name — across the scanned surface, backed by 125+ component jest-axe tests. |
WCAG 2.1 — Level AA
| Success Criterion | Conformance | Remarks & remediation |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | JurisNote does not broadcast live/synchronous audio or video content. |
| 1.2.5 Audio Description (Prerecorded) | Does Not Support | Audio description tracks for prerecorded video are not yet provided; tracked with accessible-media work. |
| 1.4.3 Contrast (Minimum) | Supports | Text and UI colors meet the WCAG AA thresholds (4.5:1 for normal text, 3:1 for large text and graphics) across the scanned public, dashboard, and admin surfaces in both light and dark themes. Tuned design tokens (a dedicated error-text token; darkened muted-foreground/border/ring) plus a full sweep of the remaining hardcoded-color nodes — status badges, funnel bars, dimmed achievement cards, the consent banner, admin subtitles, the outline editor — cleared the residual, and the live axe color-contrast rule now runs with an EMPTY allowlist (zero tolerated nodes), so any new low-contrast color fails the build. A deterministic contrast-token test additionally proves the token ratios, and a High Contrast theme is offered. |
| 1.4.4 Resize Text | Partially Supports | Layouts are responsive and a Large Text preference is available in the Accessibility menu; not verified at 200% zoom on every page. |
| 1.4.10 Reflow | Partially Supports | Recent mobile hardening improved reflow on small viewports; not exhaustively verified against the 320 CSS-pixel target on all pages. |
| 1.4.11 Non-text Contrast | Supports | The form-control border/input tokens and focus ring meet the 3:1 non-text-contrast threshold in both light and dark themes, proven by a deterministic contrast-token test that derives the WCAG ratio from the CSS custom properties; the live axe gate reports no non-text-contrast violations across the scanned surface. |
| 1.4.12 Text Spacing | Partially Supports | No fixed-height text containers were found to clip; not verified with a text-spacing bookmarklet across all pages. |
| 1.4.13 Content on Hover or Focus | Partially Supports | Tooltips/popovers are largely Radix-based (dismissible, hoverable); focus triggers were made focusable where flagged. Not exhaustively verified. |
| 2.4.5 Multiple Ways | Partially Supports | Navigation, search, and direct links provide multiple ways to reach content; not verified for every content type. |
| 2.4.6 Headings and Labels | Supports | Headings are descriptive and correctly ordered (no skipped levels) and labels are descriptive. The live axe gate reports no heading-order violations across the scanned surface. |
| 2.4.7 Focus Visible | Partially Supports | Every shared UI primitive (menus, selects, command palette, slider, checkbox, links) now shows a visible focus-visible ring that meets 3:1 against its surface, asserted by component tests, plus a high-contrast skip-link affordance. Focus visibility on every bespoke control is not yet exhaustively verified, so this is not asserted product-wide. |
| 2.5.3 Label in Name | Supports | Accessible names include the visible label text (e.g. the passkey control was corrected, and controls named this wave reuse their visible label). The live axe gate reports no label-in-name (label-content-name-mismatch) violations across the scanned surface, backed by component tests. |
| 3.2.3 Consistent Navigation | Partially Supports | Global navigation and footer are consistent across pages; not exhaustively verified. |
| 3.2.4 Consistent Identification | Partially Supports | Repeated components are identified consistently; not exhaustively verified. |
| 3.3.3 Error Suggestion | Partially Supports | Many forms suggest corrections in text; coverage is not complete. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Partially Supports | Billing and destructive actions use confirmation dialogs; not audited against every legal/financial flow. |
| 4.1.3 Status Messages | Partially Supports | Asynchronous status and error regions flagged in the audit (e.g. email verification, in-game status, support chat) were given role="status"/aria-live with component tests; live-region coverage across every dynamic surface is not yet exhaustively verified. |
How this report was produced
This is a self-assessment. It is grounded in an internal static source-code review, a full per-page audit and remediation, a live automated axe-core (WCAG 2.x AA) scan of a representative set of pages in both light and dark themes, and over 100 component-level jest-axe tests. That automated scan is now committed as a per-change gate that fails the build on new violations. It has not yet been validated by a manual screen-reader evaluation of every page or an independent third-party audit.
As the remaining residual is cleared and an independent audit is completed, the conformance values in this report will be updated accordingly.
Report a barrier & get help
If you encounter an accessibility barrier on JurisNote, please tell us — your report helps us prioritize fixes. Contact support@jurisnote.net and, if you can, include the page, what you were trying to do, and the assistive technology you were using.
We aim to acknowledge accessibility reports within five business days and to provide a remediation timeline for confirmed barriers. See also our Trust & Security and Privacy Policy pages.