Most accessibility checklists live in a developer's backlog and never reach the person who actually writes the page. This WCAG content checklist is built for that person, and because several of its checks are things Google asks for too, running it doubles as an accessibility SEO audit. Run it on a page template once, and you have found the fixes a screen reader needs and the fixes a search crawler needs, in one pass.
This is not a full WCAG or ADA compliance audit. It focuses on the content-structure checks a marketing lead or editor can actually run: link purpose, reading order, form labels, form feedback, and a way to skip repeated navigation. Alt text and heading hierarchy are real accessibility work too, but they deserve their own pass and are not covered here.
The checklist
Copy this table into a spreadsheet or your CMS's content-ops tracker. Use one row per page and per instance, since a page can have several ambiguous links or more than one form. Record a status of Pass, Fail, Not applicable, or Needs human review for each row, and keep a reason on hand for any Not applicable (something like "no form on this page," not an assumption).
| Check | Manual pass test and evidence to record | Relevant WCAG criterion | SEO or AI-search connection | Likely owner |
|---|---|---|---|---|
| Link destination is understandable | Read each link alone and with its surrounding text. Note any label that could point to more than one destination. | 2.4.4 Link Purpose (In Context), Level A | Anchor text tells both people and Google what a link leads to. | Editor, developer if labels are template-generated |
| Links are real, crawlable links | Inspect an internal link in the HTML. It should be an anchor with a working href, not a clickable div. Tab to it and activate it. | Supports operable, named controls | Google can generally crawl an anchor with an href and not much else. | Developer |
| Internal links are relevant, not stuffed | Confirm the destination genuinely helps with the sentence's topic, and the label is concise rather than keyword-packed. | Supports 2.4.4 where purpose is unclear | Google recommends contextual internal links, not forced keywords. | Editor |
| Meaning survives a linear reading | Read the page top to bottom in its underlying order, ignoring visual columns. Confirm intros and calls to action still make sense. | 1.3.2 Meaningful Sequence, Level A | No confirmed ranking or citation effect. | Editor and developer |
| Keyboard focus preserves meaning | Tab through every link and control, especially anywhere content has been visually reordered. Note any confusing jump. | 2.4.3 Focus Order, Level A | Not a known ranking factor. | Developer and QA |
| Every form field has a real label | Check the visible label and the control's programmatic name, and confirm they're tied together, including each option in a radio or checkbox set. | 3.3.2 Labels or Instructions; 4.1.2 Name, Role, Value | Accessibility and task completion, not a ranking lever. | Editor for wording, developer for markup |
| Instructions appear before they are needed | Check required-field cues and unusual formats, and confirm help text is actually reachable, not just placed nearby on screen. | 3.3.2 Labels or Instructions, Level A | No established direct ranking effect. | Editor and developer |
| Form errors can be found and fixed | Submit a form empty, then with an invalid value. Check whether the error names the field and offers a fix. | 3.3.1 Error Identification; 3.3.3 Error Suggestion | Mostly accessibility and usability. | Editor, developer, QA |
| Repeated navigation can be bypassed | Press Tab once from the top of the page and look for a working bypass link. Confirm it lands in the main content. | 2.4.1 Bypass Blocks, Level A | No established direct ranking effect. | Template developer and QA |
| A person reviewed the findings | Confirm someone checked links, order, and forms by hand rather than trusting an automated scan alone. | Conformance requires evaluating the criteria, not just running a scanner | Don't treat an accessibility score as an SEO score. | Marketing lead and accessibility owner |
Add these tracking columns around the table so it works across a whole site, not just one page: Page or template, Check, Instance or element, Status, What happened, Required change, Owner, Retest result.
How to run the link checks
The Level A rule for link purpose is more forgiving than most people assume. WCAG allows a link's purpose to come from the link text alone, or from the link text together with its surrounding context: a sentence, a list item, or a table heading. A page of "Read more" links isn't automatically failing this check. Still, the stronger editorial default is a label that means something on its own. "Read the content audit checklist" tells a reader more than "Read more" does.
Anchor text SEO and link purpose ask two different questions, even when a good fix answers both. Link purpose asks whether a person can tell what will happen if they click. Anchor text SEO asks whether that same crawlable link clearly describes a relevant destination. A descriptive anchor usually satisfies both, but they aren't interchangeable checks. Google can generally crawl an anchor element that has a real href attribute, and cannot reliably follow links built from script events instead of markup, so the crawlable-link test and the accessible-link test share the same starting point: open the page's HTML and look.
When you find a vague link, fix the verb along with the label. If a card links the words "Click here" to a download, change the label to something like "Download the checklist template," but only if the destination really is a download.
How to check reading order
WCAG's meaningful sequence rule only applies when the order content is presented in actually changes what it means. It does not require the underlying code to match the visual layout exactly. An article and an unrelated sidebar can appear in either order without breaking anything. What does break the rule is a form field appearing before the sentence that explains it, or a set of steps whose visual order looks right while their underlying order reads wrong. This is the core of an accessible content structure: the order things exist in underneath the design, not just how the design arranges them on screen.
Test this by having one person read the page in linear order, ignoring the columns, and having someone else check the underlying structure and tab through it with a keyboard. Do this on the desktop layout, the narrow responsive layout, and anywhere cards or steps have been visually reordered.
Keep this separate from focus order, its own Level A criterion. Focus order is the sequence a keyboard user's cursor moves through when they tab, and it doesn't have to match reading order exactly, just stay logical and keep the page usable. Passing one doesn't mean the other passes too, so test both.
How to check form labels, instructions, and error feedback
A form field needs a label a person can read, and that label needs to be tied to the field in the code, not just placed near it visually. The reliable version is a native label element whose "for" value matches the field's id, something like a label reading "Work email" pointed at an input with the matching id. Placeholder text is not a safe substitute for a label: it disappears once someone starts typing.
Required-field notes and unusual formats need to show up before someone fills the field in, not after they've already gotten it wrong. Don't pile format instructions onto every ordinary field, just the ones that actually need them.
Test error handling by submitting a form empty, then with a clearly invalid value. "Enter an email address in the format you'd use to sign in" tells someone what to fix. A red border with no text does not. Check that the message names the affected field and that a screen reader would actually hear it.
This is where content and development responsibilities split cleanly. The editor owns the wording; the developer owns the code that connects a label to its field and announces a dynamic update. Approved copy sitting in a design file is not evidence the check passed.
How to check skip navigation
The bypass-blocks rule requires some working way to skip repeated content, like a header and a long menu, but it does not require a specific "Skip to main content" link. That link is just the most common pattern, and it's the easiest one to test: load the page, press Tab once, see whether a skip link appears, and activate it with the keyboard.
A link that stays hidden until it receives keyboard focus is fine, as long as it becomes clearly visible once focused. What matters more is where it lands. Confirm it actually moves focus past the repeated menu into the main content, and keep tabbing to make sure the next stop isn't back inside that same menu. A missing or broken skip link is a template-level problem, so fix it once at the template and it's fixed everywhere that template is used.
Worked example: a blog post with a newsletter form
Here is what running this checklist against one hypothetical article page turns up. None of these are results from a real DeepSmith customer; it's a sample walkthrough showing what a finding looks like once it's written down.
Three related-resource cards each say "Read more" but point to different pages, so their destinations aren't clear without guessing. Logged as Needs human review, with a fix of giving each card its own specific label.
The visual layout puts the article's introduction above a newsletter signup box, but the underlying order puts the signup request before the explanation of what a subscriber gets. That's a Fail, since the order changes what the request means, and the fix is moving the explanation ahead of the request in the underlying sequence.
The newsletter field shows the word "Email" next to the input, but that text was never tied to the input in the code, so it fails the label check. The fix is a proper label association, confirmed on the rendered page rather than the design file.
Submitting the form with a bad email address returns only a red border with no text, failing the error-feedback check. The fix adds a message naming the field and explaining what to fix, tested with a keyboard and a screen reader.
A "Skip to main content" link appears on the first Tab press, which is good, but activating it leaves the next Tab stop back inside the global menu. Logged as Fail pending bypass review, with a fix of repairing where the link lands.
The related-resource cards turn out to be built as clickable containers rather than real anchor elements, which is both an accessibility problem and a crawlability one. The fix is switching them to real, keyboard-operable links with working hrefs.
Adapting the checklist to your team's size
On a small site, run every check against each major page template first, since that's where a fix reaches the most pages at once. Then sample a handful of populated pages to catch link and label problems that came from the writer, not the template.
On a larger publishing operation, split the work the way the checklist already splits it: put the copy checks (link labels, form wording, error messages) into editorial review, and put the template and behavior checks (crawlable markup, focus order, label associations, skip-link destination) into design or development QA. Recheck anything that touches the CMS template, navigation, responsive layout, or a form implementation.
An automated scanner has a role here too, but a limited one. It can flag a missing label and help you find which pages to look at first. It cannot tell you whether a link label actually describes its destination, or whether an error message is understandable. Keep the manual test notes next to whatever the scanner reports.
What this checklist does not claim
This is a focused content-structure audit, not a complete WCAG or ADA compliance content evaluation. WCAG 2.2 covers far more than these five checks, and meeting all of them does not mean a page meets full Level AA conformance.
Version and audience matter here too. If your organization is a state or local government covered by the ADA's Title II web rule, the standard specified there is WCAG 2.1 Level AA, not 2.2, with listed compliance dates of April 26, 2027 for governments serving 50,000 people or more, and April 26, 2028 for smaller governments and special district governments. Those dates apply to covered government entities, not to every private business site, so don't borrow them as a deadline for a company blog. If your organization's legal obligations aren't clear, that's a question for legal counsel, not an editorial checklist.
The SEO connection is real for the link checks specifically. Google documents that it wants crawlable anchors, descriptive anchor text, and contextual internal links, for the same reasons this checklist tests for them. Google's own guidance on AI Overviews and AI Mode says a page has to be indexed and eligible to appear in a search snippet before it can be surfaced there, and that there are no special AI-only technical requirements beyond ordinary SEO fundamentals. Nothing in that guidance says WCAG conformance itself is a ranking or citation factor, and this checklist shouldn't be sold to your team as one. The accessibility reasons for fixing form labels, reading order, and skip navigation stand on their own, whether or not an SEO effect ever gets proven.
How to know the audit is working
You'll know this checklist is doing its job when retests start passing instead of new failures piling up, and the same template stops generating the same row every quarter. Track the retest column as closely as the first pass, since a checklist that only ever finds problems isn't closing the loop.
Start with whatever blocks a task outright: a form nobody can submit, a link nobody can tell apart from three others, a menu nobody can get past. Once the page templates are clean, this becomes a lighter recurring pass, something you run again after any template, navigation, or form change.
