News sites, magazines and digital publishers ship more accessibility surface area per day than almost any other sector: dozens of articles, embedded video, podcasts, image galleries, newsletters and a paywall gating all of it. Media publishing accessibility is therefore less about a one-time audit and more about templates and editorial workflows that produce compliant content automatically, at volume.
The legal floor is concrete. Under the European Accessibility Act (in force since 28 June 2025), audiovisual media access services and e-books are explicitly in scope, with WCAG 2.2 Level A and AA as the baseline via EN 301 549. This guide walks the parts of a publishing stack that break most often, with specific fixes you can hand to engineers and editors today. You can run a free scan of any article template to see where you stand.
Article structure: one H1, real headings, real landmarks
A news article is a document, and screen reader users navigate it the way sighted readers skim: by heading. That only works if your headings are semantic, not visual. Each article needs exactly one h1 (the headline), with subheads as h2/h3 in order, no skipped levels. A 'kicker' or section label styled big should not be an h1, and a pull quote sized larger than a subhead should not be a heading at all.
The most common publisher bug is a heading hierarchy fractured by widgets: a 'Most Read' sidebar injecting an h2 mid-article, or a related-links module starting at h4. Screen reader users hitting the heading list then see a jumble. Keep editorial headings in their own outline and give chrome (newsletter signup, ad labels, 'Related') its own landmark regions using aside and nav so they can be skipped.
- Wrap the masthead in header, primary nav in nav, the story in main, and the footer in footer so users can jump by landmark.
- Give bylines, timestamps and tag lists plain text, not heading tags, so the heading outline stays clean.
- Test the heading outline directly before a template ships, not after.
- For long-form and data journalism, render any table of results as a real table with th headers and scope attributes, not a screenshot or a grid of divs, so it survives reflow and screen reader table navigation.
Captions and transcripts: the audiovisual baseline
WCAG 1.2.x sets the media rules and they are not optional for in-scope publishers. Pre-recorded video needs synchronised captions (1.2.2, Level A) and audio description for visual information conveyed only on screen (1.2.5, Level AA). Live video, such as a streamed press briefing, needs live captions (1.2.4, Level AA). Podcasts and audio-only pieces need a transcript (1.2.1, Level A).
Captions and transcripts are different tools and you need both. Captions are time-synced and include speaker labels and relevant non-speech sound ('[applause]'); auto-generated captions are a starting point, not a finish line, because names, jargon and crosstalk are exactly what they get wrong. A transcript is a readable text alternative that also happens to be indexable by search engines, which is why accessibility and discoverability reinforce each other here.
- Ship captions as a real WebVTT track on the video element, not burned-in pixels, so users can toggle and resize them.
- Make the player itself operable: keyboard-reachable controls, visible focus, and labelled buttons.
- Publish a transcript on the page or one click away, with speaker turns; for interview-heavy outlets this doubles as quotable text.
Image alt text at editorial scale
Publishers move thousands of images a week, so alt text has to be a CMS field with editorial discipline, not an afterthought. The rule is purpose, not description: alt text should convey what the image contributes to the story. A photo of a politician at a podium is not 'man in suit'; it is 'Chancellor Müller announcing the budget at a Berlin press conference'.
- Decorative images (section dividers, pure mood shots that duplicate the caption) take empty alt="" so screen readers skip them, rather than reading a filename.
- Informative photos need alt that captures the news value; charts and infographics need the data point or trend stated in text, because the figure carries information the caption may not.
- A visible caption and the alt text serve different users and should not be identical; the caption is for everyone, the alt is the non-visual equivalent.
Set CMS rules so an article cannot publish with empty alt on a non-decorative lead image, and spot-check templates before they ship.
Paywalls, registration walls and newsletter signups
The paywall is where revenue and accessibility collide, and it is the most-skipped surface in audits because it appears only for some users. A paywall modal must be a true accessible dialog: focus moves into it when it opens, focus is trapped while it is open, Escape closes it, and focus returns to the trigger afterwards. A modal you cannot escape with a keyboard, or that leaves the article behind it focusable, locks out keyboard and screen reader users entirely.
Checkout and registration forms need the basics right: every field has a programmatic label, errors are announced and tied to their input, and you must not block password managers or paste. WCAG 2.2 sharpened this with 3.3.8 Accessible Authentication (no cognitive-function test like solving a puzzle to log in), 3.3.7 Redundant Entry (don't make users re-key data they already gave), and 3.2.6 Consistent Help (put support links in the same place across pages).
- Newsletter signups inline in articles still need a label on the email field and a status message (4.1.3) announcing success or error, not just a colour change.
- Validation that fires on the email input must meet 4.5:1 contrast for error text and never rely on red alone.
- 'Subscribe to read' overlays must keep the underlying page inert (aria-hidden plus inert) so assistive tech doesn't wander into hidden content.
Accessible e-content: e-books, EPUB and PDF
For publishers shipping e-books, the EAA covers e-books and e-readers directly, and the practical target is EPUB 3 with accessibility metadata: a logical reading order, real headings, alt text on images, and navigable structure (a proper table of contents and page-list). A reflowable EPUB with semantic markup serves screen readers, refreshable braille and text-to-speech; a fixed-layout EPUB of scanned pages serves none of them.
- Include accessibility metadata (schema.org accessibilityFeature, accessibilityHazard) so readers and stores can surface what the book supports.
- Avoid PDF-only distribution for primary content; if you must ship PDF, it has to be tagged, with a reading order, headings and alt text, not an image of text.
- Mathematical and tabular content needs MathML and real tables, not pictures.
Make it repeatable: templates, type and testing
At publishing volume, you fix templates, not articles. Get the article template, the video player, the paywall and the signup right once and every story inherits them. Then the editorial layer (alt text, captions, heading discipline) is the only per-article work, which is where checklists belong.
- Body text must support 1.4.4 Resize Text to 200% and 1.4.10 Reflow at 320 CSS px wide without horizontal scrolling, and stay readable under 1.4.12 Text Spacing overrides.
- Maintain 4.5:1 contrast for body copy and 3:1 for large text and UI; verify brand colours before they reach a template.
- Keep focus visible (2.4.7) and not obscured by sticky headers or cookie bars (2.4.11, new in WCAG 2.2), a frequent failure on media sites with pinned navigation.
Bake automated checks into your build and a manual pass into editorial QA. Work through your accessibility checklist, then publish an accessibility statement describing your conformance and how readers can report barriers.