Accessibility Statement

Our Commitment

The ZTTK SON-Shine Foundation is committed to making this website usable by everyone who needs it — including parents and family members who may be navigating it during a medical crisis, and people who rely on assistive technology to read the web.

We target Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as our standard and aim to exceed it where we reasonably can. We do not claim to be “fully compliant” or “certified” — those are not honest claims for any live website. We describe below exactly what we have verified, what we are still verifying, and what we know is not yet right.

Current Conformance State

This website partially conforms to WCAG 2.2 Level AA. “Partially conforms” means most of the site meets the standard, and specific items we know about do not yet.

Target standard

WCAG 2.2 Level AA — the current consensus accessibility standard maintained by the World Wide Web Consortium. The full criteria are published at w3.org/WAI/WCAG22/quickref.

Assessment approach

We evaluate this site’s conformance through a combination of automated testing that runs continuously and a manual review that runs periodically. The most recent full manual-plus-automated audit was completed June 3–6, 2026. The site’s visual design has since gone through three rounds of rebrand (most recently the “2026 Brand Guide,” September 2026). Automated checks (below) have run on every code change through that redesign without interruption, but the full manual review has not yet been repeated against the current design — we note that honestly rather than imply a June finding still describes today’s site everywhere it doesn’t.

What has been verified

• Automated, on every pull request: an axe-core accessibility scan (via Playwright), checking WCAG 2.0, 2.1, and 2.2 Level A and AA rules, across a representative set of pages spanning every page template on the site — including the homepage, the donation page, the contact form, family story pages, research and foundation content, the ambassador map, the remembering/memorial page, and this page. A pull request is blocked from merging if it introduces a critical-impact violation.
• Automated, on every code change (write time): an ESLint rule set (eslint-plugin-jsx-a11y) that catches common accessibility mistakes — missing labels, invalid ARIA, unreachable interactive elements — before code is even committed.
• From the June 2026 baseline audit (one-time, not part of ongoing testing): Pa11y CI and axe-core scans across the full site as it existed then, plus a deeper axe-core, keyboard, focus-order, and zoom/reflow (200%, 400%, and 320 CSS-pixel) pass on 13 representative pages, plus Lighthouse accessibility scoring on six key pages. See Audit Trail below for what that audit found and what was fixed as a result.

What is still being verified by humans

• Real screen reader experience (VoiceOver, NVDA, JAWS) — automated tools can flag missing accessible names, but only a person can judge whether the announced content tells a coherent story.
• Cognitive accessibility for families in crisis — particularly the Newly Diagnosed page, which a newly-diagnosed-parent reviewer will read in context.
• Content review of family stories by reviewers familiar with bereaved-family and rare-disease-family experience.
• Reading-level appropriateness across patient-facing pages, with a target of an ~8th-grade reading level on the highest-stakes content.

Known limitations

We are aware of these specific items and are working through them:

Accessibility Features Actively in Place

Concrete things we have built into the site today:

• Visible focus indicators on every interactive element — a high-contrast orange ring that stays visible against both dark and light/cream backgrounds.
• Skip-to-main-content link, reachable on the first Tab press from page load, that moves real keyboard focus into the main content region — not just the scroll position.
• End-to-end keyboard operability — every menu, link, form field, and button is reachable and operable without a mouse.
• Descriptive alt text on meaningful images; decorative images are hidden from screen readers so they do not add noise.
• Form labels and error announcements — every form field has an associated visible label, and validation errors are announced through ARIA live regions.
• Browser zoom support up to 400%, and reflow at a 320-pixel viewport width without horizontal scrolling — verified in June 2026 after a header- and body-copy fix; not yet independently re-verified since the July–September redesign.
• Reduced-motion support — the site honors the prefers-reduced-motion operating-system setting and suppresses animation for users who request it.
• Color contrast — most body text meets or exceeds WCAG AA (4.5:1). See Known Limitations above for the current gaps our automated scan is still flagging.
• Semantic HTML landmarks (header, main, nav, footer) on every page so screen reader users can jump straight to the content they want.
• Unique, descriptive page titles and a correctly declared page language (lang="en").
• Clean heading outlines — exactly one H1 per page, no skipped heading levels.

Continuous Monitoring

Every pull request against the main branch runs two automated accessibility gates before it can merge: an ESLint pass scoped to jsx-a11y rules, and an axe-core scan (via Playwright) across the representative page set described above. A pull request is blocked from merging if it introduces a critical-impact violation. Serious-impact violations — like the color-contrast items described in Known Limitations — are surfaced in the test log for visibility but do not yet block a merge on their own; tightening that gate is on our list.

The same checks can be re-run at any time to confirm closure of known items and to catch new regressions as the site grows.

Report a Barrier

If something on this site is not working for you — a missing label, a control you cannot reach with your keyboard or screen reader, content you cannot read, anything at all — please tell us. We treat accessibility reports the same way we treat any other site problem: as a real bug to fix.

Helpful information to include if you can:

• The page URL where you ran into the problem.
• What you were trying to do.
• What happened instead.
• The assistive technology you use, if any (for example: VoiceOver on iPhone, NVDA on Windows, keyboard only, browser zoom at a certain percentage).

We aim to acknowledge accessibility reports within 5 business days and to resolve identified issues within a reasonable timeframe based on severity.

Audit Trail

We maintain a detailed internal audit record so we can answer specific questions from partners, grant reviewers, or anyone who wants to understand exactly what was tested and when.

• Most recent comprehensive audit: June 3–6, 2026 — Pa11y CI and axe-core across the full site as it existed then (78 pages), plus a deeper axe-core, keyboard, focus, and zoom/reflow pass on 13 representative pages covering every template, plus Lighthouse scoring on six key pages. Every finding from that audit — including the skip-link focus behavior, the chat-widget focus trap, the 320-pixel reflow overflow, and six site-wide color-contrast patterns — was fixed the same week.
• Since then: automated axe-core and jsx-a11y checks have run on every pull request (see Continuous Monitoring above), including through two rounds of visual rebrand. The full manual-plus-automated audit has not yet been repeated against the current design — see Assessment Approach above.
• Records: per-page audit notes, a criterion-by-criterion WCAG 2.2 scorecard, and a written process document from the June 2026 audit are maintained internally and are available on request to partners and reviewers with a legitimate need.

Technical Specifications

The site is built with HTML5, WAI-ARIA 1.2, CSS (including the prefers-reduced-motion media query), and JavaScript (Next.js 16 / React 19, with progressive enhancement). Accessibility is tested continuously with axe-core (via Playwright) and the eslint-plugin-jsx-a11y static-analysis rule set. The June 2026 baseline additionally used Pa11y CI and Lighthouse as one-time, full-site sweeps rather than ongoing checks. Manual keyboard-only navigation and screen reader testing (VoiceOver, NVDA) is planned as part of the human-verification pass described above and has not yet been completed.

Formal Complaints

If you are not satisfied with our response to your accessibility feedback, you may contact the relevant accessibility authority in your jurisdiction. In the United States, you may file a complaint with the U.S. Department of Justice (ADA.gov).