Our commitment
We target WCAG 2.2 Level AA conformance across the entire site. Where we fall short, we treat it as a bug to fix, not a limitation to live with.
Cancer-information sites are read by people in distress. They are often read on a phone in a hospital waiting room, by an older relative with a low-end Android, by a partner translating for someone whose first language is not English, by a journalist on deadline, by a screen-reader user, or by all of the above. Designing for the median web visitor would fail many of these readers. We design for the harder cases.
How we test
Accessibility is enforced as part of the build process, not retrofitted later. The current verification stack:
- Automated checks in CI.
axe-coreruns against every page on every pull request. Builds fail on any critical or serious WCAG violation. A pull request cannot merge until axe passes. - Color contrast verification. The Tailwind palette in
tailwind.config.mjsis calibrated for ≥ 4.5:1 contrast on body text and ≥ 3:1 on large text; axe verifies actual rendered contrast. - Keyboard navigation. Every interactive element is reachable by Tab, focus is always visible, and there are no keyboard traps. The site includes a "Skip to content" link at the top of every page.
- Screen-reader passes. Manual testing with NVDA on Windows and VoiceOver on macOS for each release that adds or substantially changes a page. We document any issues found and fix them before release.
- Reading-level checks for public-layer pages. Each patient-facing page is tested against a Hemingway-style readability target (grade ≤ 10) before publication.
- Performance budgets. Largest Contentful Paint ≤ 2.5 s on a mid-tier device over 4G; total page weight ≤ 200 KB gzipped (excluding images). Slow sites are accessibility failures for visitors on older devices and limited connections.
Specifically, what we have done
- Semantic HTML throughout: real
<header>,<nav>,<main>,<article>,<aside>,<footer>landmarks on every page. - A visible "Skip to content" link at the top of every page that becomes visible on keyboard focus.
- Headings in logical order (one
<h1>per page, no skipped levels). - All interactive controls reachable by keyboard with visible focus rings.
- Form controls with explicit
<label>associations. - External links marked with
rel="noopener"and opening in a new tab when they leave the site. - Decorative elements marked with
aria-hiddenso screen readers skip them. - Citations in the patient-layer pages use real
id/hrefanchors with back-references, navigable by keyboard. - The bibliography library uses an accessible table component (Grid.js, with semantic
<table>); column sorting and pagination are keyboard-accessible. - Color is never the only signal — OA-status pills carry text labels alongside their color codes; retracted records carry an explicit "RETRACTED" text marker, not just a red border.
Known limitations
Honest framing of where we are:
- Mobile review for the bibliography library is still pending. The seven-column filter grid on /research/library/ works on a tablet and on a phone in landscape but is likely cramped on a narrow phone in portrait. A small-screen redesign is on the roadmap.
- The bibliography asset is large (~40 MB JSON, served from Cloudflare R2). Visitors on slow connections will wait several seconds on first load. A planned search-backend migration (Typesense) will reduce this dramatically.
- Some external links in the references and library go to publisher pages we don’t control. Those destinations vary widely in their own accessibility. We cannot guarantee anything about them; we can only flag that the link is external.
- No language alternatives yet. The site is currently English-only. Translation infrastructure is reserved in the URL structure and a Spanish translation is planned post-launch.
- No customizable text-size controls beyond browser defaults. The site respects browser zoom and prefers-reduced-motion, but does not (yet) offer in-page font-size or contrast controls.
How to report a barrier
If anything on this site is inaccessible to you — for any reason, including reasons not specifically listed above — please tell us. We treat accessibility reports as high-priority bugs.
- Email accessibility@tnbc.info.
- Include the URL of the page, what assistive technology or device you were using if relevant, and what went wrong.
- Reports are acknowledged within 5 business days. Confirmed accessibility issues are fixed as quickly as feasible — typically within 14 days for critical or serious blockers, sooner if they prevent reaching health-critical content.
- If a report identifies a recurring problem (not just a one-off page), the fix and its rationale are recorded in the errata and changelog.
Standards conformance
This statement and the underlying practices are intended to align with:
- The Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA
- Section 508 of the US Rehabilitation Act
- The EU Web Accessibility Directive and the European Accessibility Act
- The Americans with Disabilities Act (ADA)
We have not commissioned a formal third-party accessibility audit yet; one is planned. The current state reflects our own internal testing using the tools listed above.
Other ways to access the same content
Bulk downloads of the bibliography (CSV, JSONL, BibTeX, RIS) and a programmatic REST API are planned for a future release, useful for anyone who would prefer to work with the data in their own tools rather than through the web interface.
Patient-layer pages are designed to print legibly without their navigation chrome. If you would prefer to read a page on paper or save a PDF, the browser’s built-in print function should produce a clean output.
Last reviewed: 2026-05-18. This statement is updated whenever our testing practices, known limitations, or conformance targets change.