Last updated: June 13, 2026

Image: ASTHO

Imagine a screen reader landing on your carefully crafted page and encountering an image labelled “image001.jpg”. No alt text. No context. Just a filename. For the millions of people who rely on assistive technology, that’s not a minor inconvenience – it’s a locked door. Content teams create this kind of barrier every single day, not out of malice, but because nobody handed them a plain-English web accessibility content checklist they could actually use.

That changed in June 2026, when ASTHO (the Association of State and Territorial Health Officials) published two accessibility review guides designed specifically for non-developer content creators. The guides align with WCAG 2.1 – Web Content Accessibility Guidelines, the internationally referenced technical standard cited by the 2024 ADA Title II Web Rule – and crucially don’t require you to know what a DOM is to use them.

What WCAG 2.1 Demands From Your Content Team

Image: ASTHO

WCAG 2.1 is the technical standard these guides are built around. Whether it’s the right standard for every jurisdiction, or whether a future version takes precedence, is a separate debate – but it’s the one currently written into US federal rules and referenced by accessibility frameworks across the UK and EU. It’s organised around four principles: content must be Perceivable, Operable, Understandable, and Robust – abbreviated to POUR. Think of POUR as a four-point test for whether anyone, on any device, using any assistive technology, can actually use what you’ve published.

Here’s where content teams get consistently left out of the conversation: most WCAG documentation is written for developers. It talks about ARIA attributes (labels embedded in HTML that assistive technologies read), semantic markup, and contrast ratios expressed in hex codes. Useful for engineers. Near-useless for the person writing the press release or uploading the infographic.

ASTHO’s two new guides reframe the problem entirely. One is a standards-driven checklist, structured around the W3C’s Preliminary Easy Checks, which maps each item to a specific WCAG requirement and indicates whether manual review suffices or whether you’d benefit from automated tools such as the ANDI accessibility checker – a free browser extension from the US Social Security Administration. The other is a content-driven checklist, organised by document content, structure, and multimedia. It’s explicitly described as less technical, designed for the writer, editor, or communications officer who owns the page but never touches the code.

Two Checklists, Two Mindsets – Which One Fits Your Workflow?

The standards-driven checklist is the right tool when you want a rigorous audit aligned directly to WCAG success criteria. Before ASTHO’s guide, a content reviewer confronted with the raw W3C specification would typically close the tab and give up. Now, items are presented as actionable prompts – “Does every image have a meaningful text alternative?” rather than “Ensure conformance with Success Criterion 1.1.1 Non-text Content.”

The content-driven checklist is better suited to day-to-day editorial workflows. Organising checks by content type – headings, links, images, tables, video – means a writer can run through it the same way they’d use a copy-editing style guide. Before: upload the video, publish, move on. After: upload the video, verify captions exist, confirm audio description is available for visual-only content, check that the media player can be operated by keyboard alone. Three steps. Under a minute. A page that works for everyone.

The analogy I keep coming back to: building regulations. Nobody expects an interior designer to calculate load-bearing ratios, but they absolutely need to know that the door must be a minimum width and the step must have a contrasting nosing. The content-driven checklist is that practical equivalent for digital publishing.

Both guides were funded by the CDC through the OE22-2203 grant – Strengthening U.S. Public Health Infrastructure, Workforce, and Data Systems – and produced with contributions from the Alaska Department of Health PHIG team and ASTHO’s Heidi Westermann, MPH. That public-health lineage matters: these guides were built to serve organisations handling life-critical information, which means the bar for plain-language clarity was non-negotiable.

What a Content Editor Can Fix – And Where to Hand Off to a Developer

This is the question most accessibility training dodges, so here it is directly. Content editors can resolve most of the highest-frequency issues without touching a line of code.

Fix these yourself:

• Headings – Use a logical hierarchy (H1 > H2 > H3). Don’t skip levels. Don’t use heading styles to make text look big – use them to signal structure. Check: does the heading outline of your page make sense if you read only the headings?
• Links – “Click here” fails. “Read more” fails. Every link text should make sense in isolation. “Download the ASTHO accessibility guide (PDF)” passes. Takes thirty seconds per page to audit.
• Images – Write alt text that conveys the image’s purpose in context, not just what it depicts. A chart alt text should summarise the data trend, not say “bar chart”. Decorative images get an empty alt attribute (alt=""), not a filename.
• PDFs – The single most commonly broken content type. Before uploading, check: does the document have a title set in properties? Is text selectable (not a scanned image)? Are there bookmarks for long documents? These are settings in Word or InDesign before you export, not developer tasks.

Hand off to a developer:

• Colour contrast on designed components (buttons, badges, navigation)
• Keyboard focus order and visible focus styles
• ARIA landmark regions and roles
• Video player keyboard operability
• Form field labelling in the HTML

The dividing line is roughly this: if you can see it in the CMS or word processor, it’s probably yours to fix. If it lives in the template, stylesheet, or JavaScript, it belongs to the developer. The content-driven checklist respects that boundary – it doesn’t ask writers to audit CSS.

The Deadline Myth That Could Catch Your Organisation Out

Here is the myth worth busting directly: “We have time.” The 2024 ADA Title II Web Rule set binding accessibility requirements for US state and local government entities. In April and May 2026, the DOJ and HHS each issued rulings pushing compliance deadlines back by approximately one year – giving most entities a revised target of around April 26, 2027 for WCAG 2.1 conformance. Breathing room, it seems.

Treat it with caution. The National Federation of the Blind filed a legal challenge in May 2026 disputing those extensions [citation needed], which means the regulatory landscape is still shifting. Deadline dates are worth monitoring, but building your strategy around the extension is a risk. More importantly, remediating an inaccessible archive of hundreds of pages takes months. Changing the publishing habits of an entire content team takes longer still.

For UK and EU organisations, the picture is also evolving. The UK Public Sector Bodies Accessibility Regulations reference WCAG 2.1, and the EU European Accessibility Act – which has a broader commercial scope – also draws on WCAG as its technical framework, though specific conformance levels and product categories vary by directive and implementation date. The common thread: WCAG fluency is worth building now regardless of your jurisdiction.

For developers, the lesson is to stop treating accessibility as a post-launch retrofit. If you’re working through your technical SEO checklist or evaluating full-stack frameworks for a new build, accessibility decisions made at the architecture stage cost a fraction of what they cost after deployment. Website performance and accessibility are increasingly evaluated together by search engines and regulators – optimise one, and you’re already working on the other.

The Answer Was Simpler Than the Jargon Made It Seem

The central paradox of web accessibility is that most barriers aren’t technically complex to fix – they’re invisible to the people creating them. An empty alt attribute. A heading hierarchy that jumps from H1 to H4. A PDF with no tagged structure. None of these require specialist engineering knowledge to prevent. They require awareness, habit, and a checklist.

ASTHO’s content-driven web accessibility content checklist is that habit made portable. It won’t replace a full technical audit, and it won’t satisfy every WCAG success criterion in isolation. But it gives content teams something they’ve never really had: a credible, standards-aligned reference they can own without a developer in the room. Use the standards-driven checklist for formal audits. Use the content-driven checklist for your publishing workflow. Use both together to build a team where accessibility is genuinely everyone’s responsibility – not just the engineer handed a remediation report six months after launch.

If you’re building or redesigning a website and want accessibility built in from the ground up rather than bolted on afterwards, DRS Web Development builds custom websites and web applications for businesses of all sizes, with performance and accessibility treated as first-class requirements from day one. Visit drs-web.co.uk/contact to arrange a free consultation.

Frequently Asked Questions

Q: What is WCAG 2.1 and why does it matter for content teams?
A: WCAG 2.1 (Web Content Accessibility Guidelines) is a widely adopted technical standard for web accessibility, organised around four principles – Perceivable, Operable, Understandable, and Robust. It matters for content teams because legislation like the ADA Title II Web Rule and the UK Public Sector Bodies Accessibility Regulations references it, and many of its requirements – alt text, heading structure, captions – are content decisions, not code decisions.

Q: What is the difference between ASTHO’s two accessibility checklists?
A: The standards-driven checklist is structured around the W3C’s Preliminary Easy Checks and suits comprehensive audits, specifying which items can be checked manually and which benefit from automated tools. The content-driven checklist is organised by content type – headings, images, links, multimedia – and is explicitly designed to be less technical, making it accessible to writers and editors without a development background.

Q: When do US state and local government websites need to comply with ADA Title II?
A: As of mid-2026, federal rulings from the DOJ and HHS have extended most compliance deadlines to around April 26, 2027. However, the National Federation of the Blind filed a legal challenge to those extensions in May 2026, so the regulatory picture remains in flux. Monitoring official DOJ guidance is advisable rather than relying on any single published date.

Q: Can automated accessibility tools replace manual content review?
A: No. Tools like the ANDI accessibility checker identify many technical issues quickly, but they cannot evaluate whether alt text is meaningful, whether link text makes sense out of context, or whether heading structure reflects the actual content hierarchy. Manual review by content teams is essential alongside automated scanning.

Q: Does a WCAG 2.1 checklist apply outside the US?
A: Yes, broadly. The UK Public Sector Bodies Accessibility Regulations and the EU European Accessibility Act both draw on WCAG as their technical reference, though the specific requirements, conformance levels, and entities covered vary by directive and jurisdiction. A checklist aligned to WCAG 2.1 provides a sound working foundation across most contexts, but always verify the applicable regulations for your specific situation.

Source: https://www.astho.org/topic/resource/2026/guide-for-meeting-wcag-web-accessibility-standards/