Accessibility Audit for Journalism Sites

1. Why a news site needs an accessibility audit

A significant proportion of the population lives with a disability that affects how they use the web — visual impairments, motor impairments, deafness or hearing loss, cognitive and learning differences. Many rely on assistive technology: screen readers that speak the page aloud, screen magnifiers, keyboard-only navigation, or captions. If your news site is built without them in mind, it quietly excludes a large audience from the journalism you produce, which is a failure of the basic purpose of a news organisation: to inform the public.

An accessibility audit is a structured way to find out where your site falls short and to fix it. The good news is that accessibility and good web practice overlap heavily: many fixes also improve usability for everyone, help search engines, and make the site more robust across devices. Captions help commuters watching without sound; clear headings help every reader skim; good contrast helps anyone reading on a phone in bright light. Accessibility is not a niche compliance chore bolted on at the end — it is part of building the site well.

2. WCAG 2.2 and its four principles

The Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), are the internationally recognised standard. WCAG 2.2 is the current version. Its requirements are organised under four principles, often abbreviated POUR, and everything you audit maps back to one of them:

• Perceivable: users must be able to perceive the content. This covers text alternatives for images, captions and transcripts for media, sufficient colour contrast, and not relying on colour alone to convey meaning.
• Operable: users must be able to operate the interface. This covers full keyboard access, a visible focus indicator, enough time to read and use content, and navigation that does not depend on a mouse.
• Understandable: content and operation must be understandable. This covers readable text, predictable behaviour, clear labels and instructions, and helpful error messages on forms.
• Robust: content must be robust enough to work with current and future tools, including assistive technology. This mostly comes down to valid, well-structured markup that screen readers can interpret.

Each principle breaks down into guidelines and then into testable success criteria, each graded level A (essential), AA (the widely adopted target) or AAA (enhanced). Most organisations aim for level AA of the current version, and that is the sensible goal for a news site. WCAG 2.2 keeps everything from WCAG 2.1 and adds further criteria, particularly around focus visibility and interactions, so working to WCAG 2.2 AA covers the earlier version too.

3. The legal and ethical case

In the UK the Equality Act 2010 requires those who provide a service to the public to make reasonable adjustments so that disabled people are not placed at a substantial disadvantage. Most publishers offer a service to the public, and the duty is generally understood to extend to websites and apps. It is an anticipatory duty: you are expected to think ahead about disabled users rather than wait for someone to be excluded and complain. Failing to make reasonable adjustments can amount to unlawful discrimination.

On top of that, public-sector bodies are subject to specific accessibility regulations that require their websites and apps to meet a defined technical standard and to publish an accessibility statement describing how well they comply and how users can report problems. A commercial newsroom is not a public-sector body, but if your journalism operation includes any public-sector-funded or public-body element, check whether those regulations reach you. Either way, the WCAG 2.2 AA target is the practical benchmark both regimes point towards.

Beyond the law sits the ethical case, which for journalism is arguably stronger. A newsroom's purpose is to inform the public, and disabled people are part of that public. Reporting that a blind reader cannot hear, a deaf reader cannot follow, or a keyboard-only reader cannot navigate simply does not reach part of the audience it is meant to serve. Treating accessibility as a core part of editorial quality, rather than an optional technical extra, is consistent with the values most journalists already hold about serving the whole community.

4. The tools: axe, WAVE and Lighthouse

Three widely used, free tools give you a fast first pass. axe (from Deque) is an accessibility testing engine available as a browser extension and built into many developer tools; it flags issues and explains the relevant WCAG criterion. WAVE (from WebAIM) is a browser extension and online tool that overlays icons directly on the page, showing errors, alerts and structural features visually, which makes it very approachable for non-developers. Lighthouse is built into Chrome's developer tools and produces an accessibility score alongside its performance and SEO audits.

Run all three on a representative sample of your site: the home page, a standard article, a page with a video, a gallery, a form, and any interactive feature. Because these tools overlap but each catches slightly different things, using more than one is worthwhile. But treat their output as a starting point, not a verdict. Automated testing reliably catches issues like missing alt text, low contrast and unlabelled fields, yet it can only detect a portion of all accessibility barriers — the rest need human judgement, which the next sections cover.

5. Checking images and alt text

Every meaningful image needs a text alternative — alt text — that conveys what the image communicates, so a screen-reader user gets the same information. For a news photo, that means describing what is shown and why it matters in context, not just naming the subject. A chart or infographic needs alt text (or a nearby text description) that gives the actual data or finding, because the point of the graphic is the information, not its appearance. Purely decorative images should be marked so screen readers skip them, rather than being read out as noise.

Automated tools will tell you an image has no alt attribute, but only a human can judge whether the alt text that exists is any good. Auditing alt text therefore means reading it: is it descriptive, is it accurate, does it duplicate the caption pointlessly, is it stuffed with keywords? Watch particularly for image-heavy article templates that auto-generate useless alt text like a file name. Good alt text is a small piece of writing, and writing it well is an editorial skill worth building into the picture desk's routine.

6. Captions and transcripts for audio and video

Video needs captions so that deaf and hard-of-hearing viewers can follow the speech and important sounds, and it should not rely on sound alone to convey meaning. Audio content — a podcast, an interview clip — needs a transcript so the content is available to people who cannot hear it. Auto-generated captions from a video platform are a starting point but are often inaccurate, especially with names, jargon and accents, so they must be checked and corrected; inaccurate captions can be worse than none because they mislead.

These are not only accessibility features. Captions serve the large audience who watch video without sound, transcripts are searchable and quotable and improve how search engines understand your content, and both create a text record of your journalism. When auditing, check that every video has accurate captions, that audio content has a transcript, and that neither is buried where a user cannot find it. For visual storytelling specifically, our guide on accessibility in visuals goes deeper into charts, graphics and imagery.

7. Colour contrast and use of colour

Text must have enough contrast against its background to be readable by people with low vision or colour-vision deficiencies. WCAG sets minimum contrast ratios — higher for small body text, lower for large text — and the tools above, plus dedicated contrast checkers, will measure any pairing for you and tell you whether it passes at level AA. Common failures on news sites include pale grey timestamps and captions, low-contrast link colours, and text laid over a busy photograph without a scrim to guarantee legibility.

Just as important, meaning must never be carried by colour alone. A data visualisation that distinguishes categories only by colour is unusable to a colour-blind reader; add labels, patterns or direct annotation as well. A form field that signals an error only by turning red needs a text message too. When auditing, view key pages in greyscale to reveal anything that depends on colour, and check that charts and status indicators still make sense without it. Our guide to data visualisation covers designing charts that work for everyone.

8. Keyboard navigation and focus

Many disabled users, and plenty of others, navigate with the keyboard rather than a mouse. The single most revealing manual test you can run is to put the mouse aside and try to use your site with the Tab key alone. Can you reach every link, button, menu and form field in a sensible order? Can you operate interactive components — menus, carousels, video players, cookie banners — without a pointer? Can you always see where you are, or does the focus indicator vanish? If you get stuck or lost, so will a keyboard-only reader.

Watch for the classic problems: a visible focus outline removed for cosmetic reasons, so users cannot tell which element is selected; keyboard traps where focus enters a widget and cannot get out; custom controls built from generic elements that the keyboard cannot reach at all; and modal dialogs or menus that do not manage focus properly. WCAG 2.2 places particular emphasis on focus being visible and not obscured. This is exactly the kind of barrier automated tools struggle to catch, which is why hands-on keyboard testing is a non-negotiable part of any real audit.

9. Headings, link text and forms

Screen-reader users navigate a page by its structure, so headings must be real, properly nested headings rather than text merely styled to look big. There should be a single main heading, with subheadings in logical order and no levels skipped for visual effect. A correct heading outline lets a screen-reader user jump through an article the way a sighted reader skims it. When auditing, view the heading outline of each template (WAVE and browser extensions can show it) and confirm it makes sense read on its own.

Link text must make sense out of context, because screen-reader users often pull up a list of all links on a page. A page full of read more or click here links is useless in that list; the link text should describe its destination. Forms — newsletter sign-ups, comment boxes, search, contact and login — need every field properly labelled, with clear instructions and error messages that say what went wrong and how to fix it. Placeholder text alone is not a label. Together, sound headings, honest link text and labelled forms cover a large share of the understandable and robust principles.

10. Building accessibility into the workflow

A one-off audit fixes the site as it is today, but new articles are published every hour, and accessibility slips back unless it is built into how the newsroom works. The most durable approach is to fix the templates and the content management system so the accessible choice is the default. Require alt text before an image can be published. Ship article and component templates that already have correct heading structure, sufficient contrast and keyboard-operable controls. Make the caption and transcript step part of the video and audio publishing routine, not an afterthought.

Support that with people and process: a short accessibility item on the pre-publication checklist, basic training so editorial staff understand alt text, headings and link text, and a named owner responsible for accessibility. Re-run the automated tools on key templates whenever the site changes, and periodically repeat the manual keyboard and screen-reader checks. Because fixing a template fixes every future article built on it, effort spent upstream pays off far more than patching pages one by one. Treating accessibility as part of editorial governance keeps it from drifting.

11. Audit checklist

Work through this on a representative sample of pages — home page, article, video page, gallery and a form:

• Run axe, WAVE and Lighthouse on each sample page and log the issues found
• Read the alt text on every meaningful image; confirm decorative images are marked to be skipped
• Confirm every video has accurate captions and every audio item has a transcript
• Check text-to-background contrast passes WCAG AA, and that no meaning relies on colour alone
• Navigate the whole page with the keyboard only; confirm a visible focus indicator and no keyboard traps
• Review the heading outline of each template for a single logical structure with no skipped levels
• Check link text makes sense out of context, with no bare read more or click here links
• Confirm every form field is labelled, with clear instructions and helpful error messages
• Test at least one page with a screen reader to hear how the page is actually announced
• Build the fixes into templates, the CMS and the pre-publication checklist so they persist

12. Common mistakes that fail an audit

• Treating a clean automated score as done — tools catch only a portion of barriers; the meaning of alt text, caption accuracy and keyboard order all need a human.
• Auto-generated alt text left unchecked — file names and keyword-stuffed descriptions are worse than useless to a screen-reader user.
• Relying on inaccurate auto-captions — unchecked captions mislead deaf viewers, especially on names, jargon and accents.
• Removing the focus outline for looks — keyboard users then cannot see which element is selected, a direct WCAG 2.2 failure.
• Carrying meaning by colour alone — a chart or error state distinguished only by colour is lost to colour-blind readers.
• Styling text to look like a heading — screen readers navigate real headings, so visual-only headings break the page structure.
• Bare read more and click here links — these are meaningless in a screen reader's list of links pulled out of context.
• Fixing pages but not templates — patch the template and the CMS instead, so every future article inherits the fix.

Frequently asked questions