Accessibility · Caregiving Atlas

Our commitment

Caregiving Atlas targets WCAG 2.1 Level AA across all editorial pages and interactive tools. WCAG AA is the level US Department of Justice ADA guidance has consistently pointed to for public-facing websites, and the level we believe responsible publishers should hold themselves to regardless of legal requirement.

Accessibility is part of the editorial brief, not an afterthought. New components and new article templates go through a manual accessibility pass before they ship. Style tokens enforce minimum contrast at the design-system level so authors can’t accidentally introduce non-AA-compliant color combinations.

What we’ve done, concretely

Generalities are easy. The list below is what readers can actually verify on the site today:

Skip-to-content link.The first focusable element on every page is a “Skip to main content” link that jumps past the sticky header. Visible only on focus. Try pressing Tab from any page.
Semantic HTML.Headings (h1–h4) reflect actual document structure, not visual size. Articles use <article>, navigation uses <nav>, callouts use role="note". Lists are lists; tables have <th scope> set correctly for row and column headers.
Visible focus indicators. Every focusable element receives a 2px accent-color outline with 2px offset. Cards add a 2px inset on the left edge for additional affordance. Focus is never hidden, even on hover-styled elements.
Color contrast.Primary ink on the cream canvas runs about 13:1 — well over the AA target of 4.5:1 for body text and 3:1 for large text. Secondary ink on cream runs about 6:1. Callout tints, tag pills, and link-caption colors are all audited against their actual background to clear AA on small text.
Reduced motion. The site honors prefers-reduced-motion: reduce. All transition durations collapse to ~10ms when the user has expressed that preference in their OS or browser. The site is largely motion-free already, but the override is in place.
Keyboard navigation. All interactive elements (links, buttons, form fields, the StateChip modal, the privacy notice dismiss) are reachable and operable from the keyboard. Modal-style overlays trap focus and restore it on close.
Alt text on functional images. Reviewer portraits, illustrative figures, and tool diagrams have descriptive alt text. The site logo and wordmark have programmatic name set through their text content (no phantom logo image to alt).
Decorative-only treatment for state silhouettes. The 51 US state silhouettes used throughout the site are decorative when paired with a visible state name in adjacent text. They render with empty alt and aria-hidden="true" in that context, so screen readers announce the state name once (from the label) rather than twice. State silhouettes used in interactive cards remain focusable through their wrapping link.
Form labels and field hints. All form fields (the homepage intake flow, tool inputs) have explicit <label> elements, hint text associated via aria-describedby, and error messages associated via aria-errormessagewhere applicable.
Document language. The root document declares lang=“en”, so screen readers and translation tools select the correct voice and dictionary.

Where we still fall short

We have not yet user-tested with screen-reader users. Our compliance work to date is technical (semantic markup, ARIA correctness, focus management). We have not run a structured session with a JAWS, NVDA, or VoiceOver user walking through a real caregiving task on the site. That work is on the calendar.
Image alt text on state silhouettes is empty. This is intentional — the silhouettes are decorative when paired with text labels — but a screen-reader user navigating in image-list mode will hit empty alts. We’re considering whether to flip these to role="img" with descriptive labels in non-paired contexts.
Interactive tools lack live-region status announcements. The cost estimator and move comparison currently update results without an aria-live region. A screen-reader user has to re-navigate to the results area to hear changes. Slated for the next tools pass.
Long-form articles don’t expose a table of contents to assistive tech beyond the visual in-page ToC. A bookmark-style mechanism for jumping between H2s programmatically would help users on longer articles.
We have not formally certified against WCAG 2.2. Our target remains 2.1 AA. WCAG 2.2 added focus-appearance and dragging-movement criteria that we believe we meet, but we have not done the audit. On the roadmap.

How to report a barrier

If something on Caregiving Atlas keeps you from accessing the content — missing alt text on an article image, a tool that doesn’t work with your screen reader, contrast that falls short on a specific element, anything — please tell us.

Report an accessibility barrier. Describe what you tried to do, what happened, and (if comfortable sharing) the assistive technology you were using. Specific reports get fixed; we appreciate the time it takes to write one.

We aim to acknowledge accessibility reports within 48 hours and to triage critical issues (anything that fully blocks access to content) within a week. Lower-priority issues land in the next quarterly audit cycle.

Standards we reference

Audit history

May 21, 2026 — Internal audit. Manual keyboard walk-through of every published page; contrast audit of the design-system token palette; semantic structure review of articles, state-topic guides, and comparison pages. Findings: items listed in “Where we still fall short” above.

Next audit due: August 2026.