Accessibility

ProvenBrief aims to meet WCAG 2.2 level AA. We have not been independently audited against it, so this page says what is actually in place and what we have not yet checked.

What is in place

• Keyboard access. Every control is reachable and operable with a keyboard, and focus is always visible — we style :focus-visible rather than removing outlines. A “Skip to content” link is the first thing in the tab order on every page.
• Screen readers. Pages declare their language, use real landmarks (header, nav, main, article, footer), and label each navigation region so they can be told apart. Every image carries alternative text; story artwork uses the headline, which is what the image depicts.
• Heading structure. One h1 per page and no skipped levels, so heading-to-heading navigation reflects the actual structure of a story.
• Reduced motion. If your system asks for less animation, transitions and the scroll-driven reading indicator are switched off rather than merely shortened.
• Light and dark. Both themes are designed rather than inverted, and the site follows your system setting unless you override it.
• Text, not images of text. Body copy is real text at relative sizes, so browser zoom and larger default font sizes reflow it instead of clipping it.
• No traps. Nothing autoplays, nothing steals focus, and nothing blocks the article behind a dialogue you cannot dismiss.

What we have not checked

Being straight about this is the point of the page:

• No independent audit. Our WCAG 2.2 AA target is self-assessed. We have not commissioned a third-party evaluation and do not claim formal conformance.
• No systematic assistive-technology testing. We have not tested against a matrix of screen readers, magnifiers and voice-control software. Reports from people who use them are worth more to us than anything we can infer, which is why the address below is real.
• Colour contrast is designed for, not measured everywhere. Body text and controls are set to clear the AA ratio, but we have not verified every state of every component in both themes.
• Advertising is outside our control. Ads and the consent dialogue are rendered by Google inside frames we do not author. We choose to run them, so we own that decision — but we cannot fix their markup, and an accessibility problem inside an ad is one we can only report upstream or stop showing.
• Data tables. Our trackers and data studies use tables that scroll sideways on narrow screens. They are marked up as real tables with header cells, but complex tabular data is hard to make genuinely pleasant with a screen reader and we would not claim we have.

Reporting a barrier

If something on this site stopped you reading a story, please tell us — email hello@provenbrief.com. It helps if you can say what page you were on and what you were using, but a one-line “this doesn't work” is welcome and we would rather have that than nothing.

We treat an accessibility barrier the same way we treat a factual error: it is a defect, it gets fixed, and the fix is visible. Our approach to corrections is in our editorial standards.

If you need a specific story in a different format in order to read it, ask and we will send it. There is no charge and you do not need to explain why.