Accessibility in Content: The Most Common Accessibility Errors in Editorial Work

Many barriers do not begin in code. They begin where content is planned, written, maintained, and approved: with unclear headings, missing or unhelpful alt text, vague link text, videos without reliable captions, or CMS workflows that allow structures that work visually but fail semantically.

This matters because accessibility is not only a technical discipline. It is also shaped by editorial decisions: How is content structured? How is an image described? Is a link understandable without its visual context? Is a video published in a way that remains usable without sound? These are the points where teams decide whether content is accessible to everyone or whether avoidable barriers are created.

The WebAIM Million Report 2026^[1] shows how widespread these problems still are. In February 2026, WebAIM tested the home pages of the top 1,000,000 websites using the WAVE accessibility engine. The report only includes automatically detectable barriers, so the results do not capture every accessibility issue. Still, they provide a useful overview of recurring patterns.

53.1% of the tested home pages had missing alternative text for images. 15.2% contained ambiguous link text such as “more,” “continue,” or “click here.” 41.8% skipped heading levels, and 7.5% of pages had no headings at all.^[1] Some of these problems originate in templates, components, or design systems. But many of them also reflect editorial practice: which text authors enter, which content editors approve, and which quality checks happen before publication.

Accessibility should therefore not be checked only at the end of a publishing process. It belongs inside editorial work itself: in briefs, CMS fields, approval processes, image selection, video production, and quality assurance. Accessibility becomes more robust when content is structured, described, and prepared for different usage contexts from the start.

What Counts as a Content Accessibility Problem?

For this article, a content accessibility problem is any editorial decision that makes information harder to find, understand, navigate, or use. It can appear in the structure of content, in wording, in media descriptions, or in the publishing workflow.

This focus is different from a technical accessibility audit. A technical audit primarily checks implementation details: markup, keyboard operation, focus management, ARIA usage, contrast, component behavior, or interaction with browsers and assistive technologies. This article focuses instead on the areas that content creators, editorial teams, content designers, marketing teams, technical writers, and CMS owners can directly influence.

Typical content accessibility problems include:

Content defines structure, orientation, instructions, meaning, and often the actual purpose of a page. The markup can be correct. The components can work. The publishing workflow can still exclude users if the content is vague, misleading, incomplete, or understandable only through one specific mode of perception.

Titles, Headings, and Document Structure

Page titles and headings are not formatting details. They help determine whether people can quickly understand, scan, and use a page.

A good page title makes clear which page someone is on — in browser tabs, history, search results, and screen reader contexts. Good headings show how the content is organized. They help users scan, jump to relevant sections, and understand the hierarchy of information.

That is exactly why many avoidable barriers arise here. Common examples include generic titles such as “Overview,” “Resources,” or “Update”; headings that sound interesting but do not name the topic; or missing section headings because the page looks “clear enough” visually. It is also problematic when text in a CMS is merely bolded or enlarged instead of being marked up as a real heading. If headings such as “More information” or “Details” are repeated across a page, the outline also loses its value.

The problem is not only technical markup. It is information architecture. A heading is a promise: it tells users what the next section is about. If it is vague, interchangeable, or misleading, the page becomes harder to navigate — even if the HTML is formally correct.

The practical rule is simple: titles identify the page. Headings describe the content and its structure. If someone only scans the title and headings, they should still understand what the page is about, which sections it contains, and where the information they need is likely to be.

Link Text

Link text is small copy with a large responsibility. It tells users where a link leads, what action will follow, and whether the destination is worth their attention. That makes it a central part of orientation, not decorative microcopy.

Yet editorial workflows still produce ambiguous links again and again:

These phrases often only make sense when the visual context is included: the card, the preceding paragraph, the image beside it. That is fragile. Screen reader users can list links and navigate them outside the visible layout. People using voice control rely on identifiable link names. And anyone scanning a page quickly benefits when links clearly state their destination.

Good link text does not need to be long. It only needs to carry meaning. “Download the accessibility checklist (PDF, 2 MB)” is much more useful than “Download here.” “Read more about accessible image descriptions” is stronger than “Learn more.”

The practical rule: a link should remain understandable without the surrounding paragraph. Not every link needs to include every detail, but users should know what to expect before activating it.

That makes good link text more than a compliance issue. It improves orientation, trust, and task completion — for people with disabilities and for everyone else as well.

Alternative Text for Images

Alt text is often treated as a mandatory field: fill it in, save, publish. The result is often text that exists formally but helps very little. Good alt text does not come from describing an image somehow. It comes from understanding what role the image plays in the content.

The basic principle is simple: text alternatives should replace the information or function that would otherwise only be available through the image. A decorative image does not need to be described. An informative image needs the relevant message. A functional image, such as a linked icon, needs an understandable link destination. And for complex visuals such as charts or infographics, short alt text is usually not enough; the actual meaning also belongs in the surrounding text, a table, or a more detailed description.

In practice, this rarely fails because of bad intent. More often, the editorial decision is missing. Authors describe what can be seen instead of clarifying why the image is there. Stock photos receive unnecessary descriptions and create noise. Charts are published with a one-line alt text that omits the key message. Linked images inherit filenames, empty placeholders, or generic terms. CMS fields treat every image the same, even though a decorative hero image, product photo, linked icon, and infographic serve different purposes.

The WebAIM Million Report 2026 shows how common these problems still are. On the tested home pages, 16.2% of all images had no alternative text. Another 10.8% of existing alt text was flagged as questionable or repetitive. Particularly critical: 45% of images without alt text were linked images. In those cases, what is often missing is not only an image description, but also an understandable name for the link destination.

The better editorial question is therefore not: “What can be seen in this image?” It is: What would be missing if this image were not visible?

If nothing would be missing, the image is probably decorative. If something would be missing, the text alternative needs to carry exactly that meaning.

Multimedia Accessibility Is Publishing Work

Video, webinars, podcasts, and social clips have become standard content formats. Their accessibility therefore belongs in the standard publishing process. Captions, transcripts, and descriptions of important visual information are not after-the-fact enhancements. They determine whether the content is fully accessible at all.

The most common mistakes do not start in the player, but in the workflow. Podcasts are published without transcripts. Videos receive automatically generated captions that no one reviews. Speaker changes, important sounds, or relevant visual information are missing. Transcripts are linked somewhere, but not where users would expect them. Or they reproduce only the spoken words and leave out what happens visually.

Automatic captions show particularly clearly why media accessibility needs editorial quality assurance. They can be a useful starting point. But they are not a finished result until they have been checked and corrected. Caption errors are not just cosmetic issues. They can distort names, make technical terms unrecognizable, change instructions, or reverse the meaning of a sentence.

Transcripts deserve the same status. They do not only help deaf and hard-of-hearing people. They are also useful for people who prefer reading, want to search content quickly, find quotes, look up technical terms, or use media without sound. WAI therefore recommends making transcripts easy to find — ideally on the same page as the media or linked directly below it.

For content operations, the consequence is clear: captions and transcripts belong in publication criteria. A video is not “done” when the edit, thumbnail, and description are ready. It is ready to publish only when the accessible text version of the content is present, accurate, and easy to find.

Clear Instructions and Plain Language Reduce Cognitive Load

Content accessibility does not end with screen readers, keyboard support, or media alternatives. It also depends on whether people can understand information quickly and apply it safely.

This does not only concern “simple” content. Complex topics in particular need clear language, a logical order, and unambiguous instructions. WAI recommends, among other things, short sentences, short text blocks, clear wording, and a structure that makes the purpose of a page quickly recognizable. Plain language guidance from CDC and Digital.gov follows the same idea: content should be written so people can find, understand, and use it the first time they encounter it.

For content teams, this has direct consequences. Acronyms should be written out the first time they appear. Long process descriptions should be split into individual steps, not buried in dense paragraphs. Requirements should be explained before input, not only in the error message. Examples help when a format might be misunderstood. And concrete verbs are usually better than abstract organizational language: “Submit the application by June 15” is clearer than “Timely submission is required.”

This is especially important for people with cognitive and learning disabilities, for people reading in a second language, and for users under stress, fatigue, or time pressure. But it also improves the experience for everyone else: people understand faster, make fewer mistakes, abandon tasks less often, and find the next step more easily.

Plain language is often misunderstood. It does not mean artificially simplifying a topic or removing expertise. It means removing unnecessary complexity from the expression. A medical notice, legal condition, or technical instruction can remain precise. It simply should not be harder to understand than the subject requires.

In accessibility terms, dense language is therefore more than a style issue. It can become a barrier when people need to understand instructions, deadlines, benefits, forms, or product decisions. Clear language is not a simplification of the content. It is part of whether the content is usable.

Conclusion

Accessible content creation is not a specialist discipline next to the actual work of writing. It is part of the editorial craft: helping people find information, understand it, and act on it safely.

That is why content decisions deserve the same attention as semantic HTML or component behavior. A technically clean interface is of limited use if titles remain vague, links hide their destination, images lose their meaning, or media is fully accessible only to people who can both see and hear it.

The most important shift in perspective is this: accessibility is not added at the end. It emerges where content is planned, structured, described, and published.

Flo Winkler

Software Engineer