Technology

WCAG 2.2: A Practical Accessibility Guide for Digital News

A newsroom-focused guide to WCAG 2.2 explains clearer structure, scalable text, keyboard focus, and usable controls while preserving the standard’s limits.

Editorial note: This original explainer was prepared with AI assistance and human editorial review from the source documents cited below. It is not personalized professional advice and does not report a new event.

Digital news is consumed in many settings: on phones, large monitors, keyboards, touchscreens, and with assistive technologies. WCAG 2.2 offers a shared way to think about that range. It is a W3C Recommendation with technology-neutral, testable success criteria intended to make web content more accessible across devices and for people with different disabilities.[1]

That description is useful precisely because it is practical rather than tied to one publishing platform. For a newsroom, WCAG 2.2 can inform article templates, headline hierarchies, multimedia controls, navigation, and the behavior of overlays. It should not, however, be treated as a promise that every reader will experience a site equally well.

What WCAG 2.2 measures

WCAG 2.2 is organized around four principles: content should be perceivable, operable, understandable, and robust. Those principles contain 13 guidelines and three conformance levels: A, AA, and AAA.[1] The levels describe progressively broader sets of success criteria; they are not labels that turn accessibility into a one-time accomplishment.

The standard added nine success criteria compared with WCAG 2.1. At the same time, Success Criterion 4.1.1, Parsing, is obsolete and removed in WCAG 2.2.[2] This publication history matters when a newsroom documents its accessibility work or compares requirements across projects. The W3C Recommendation page is dated 12 December 2024, while the W3C Web Accessibility Initiative’s “What’s New” page records the initial WCAG 2.2 Recommendation publication as 5 October 2023.[1][2]

The success criteria are normative: they define what must be satisfied at a given conformance level. W3C also publishes informative understanding material and techniques. Those techniques can help teams implement a criterion, but they should not be confused with the criterion itself or treated as the only possible implementation.

Start with the article’s structure

A readable article is not simply one with short sentences. Its structure should help readers locate information and understand how sections relate to one another. Success Criterion 2.4.6, Headings and Labels, requires headings and labels, when provided, to describe their topic or purpose.[3] W3C explains that descriptive headings help users find information and understand relationships between content sections.[3]

For an article template, that points toward a meaningful progression from the headline to subheads and then to paragraphs, rather than using visual styling alone to imply hierarchy. Labels for search, newsletter, comments, or related-story controls should likewise communicate what each control is for. These choices support scanning readers and can also make page relationships clearer when content is interpreted through assistive technology.

Text size is another concrete check. Under Success Criterion 1.4.4, Resize Text, text must be resizable to 200 percent without loss of content or functionality and without requiring assistive technology, with exceptions for captions and images of text.[4] A news site should therefore test enlarged article text, menus, captions, buttons, and surrounding layout. The goal is not merely to enlarge letters; it is to preserve access to the story and its controls.

Check focus and controls around the story

News pages often place sticky headers, consent interfaces, share tools, or subscription prompts near the reading surface. WCAG 2.2 adds the Level AA criterion Focus Not Obscured (Minimum). It requires that a keyboard-focused user-interface component is not entirely hidden by author-created content.[2] In practice, keyboard users should be able to see which link, button, or field is active, even when fixed or layered page elements are present.

WCAG 2.2 also adds the Level AA Target Size (Minimum) criterion. Pointer-input targets generally have a minimum size of 24 by 24 CSS pixels, subject to listed exceptions, including spacing, equivalent controls, inline targets, user-agent controls, and essential presentations.[2] This is relevant to small icon buttons for audio playback, menus, galleries, and article sharing. The exceptions mean a team must evaluate the criterion’s conditions rather than apply a simplistic rule to every visible element.

A useful review cycle combines automated checks with keyboard and resizing tests on representative article pages. Teams can inspect whether headings describe their sections, whether text at 200 percent remains functional, whether focus is visible, and whether pointer targets meet the applicable requirement. The standard supplies the testable outcomes; it does not prescribe one technical stack or one newsroom workflow.

Understand what conformance cannot promise

WCAG 2.2 can make accessibility work more specific and discussable, but conformance is not the same as universal accessibility. W3C states that even Level AAA does not address every type, degree, or combination of disability.[1] Access also depends on browsers, user agents, assistive technologies, and authoring tools.[1]

That caveat should shape editorial quality assurance. A successful checklist is evidence about the criteria tested, not a guarantee about every person’s experience. Newsrooms should preserve the distinction between normative requirements and informative techniques, test with the technologies their audiences use, and revisit templates as interfaces change. Used that way, WCAG 2.2 becomes a disciplined accessibility reference for publishing—not a certification, a law, or personalized professional advice.