A B2B website accessibility checklist is most useful when it follows a real task: find the right offering, understand the evidence, open a document, and complete an inquiry. A passing automated scan of a homepage cannot show whether someone can finish that path with a keyboard, understand a form error, or use the page at a narrow viewport. This guide turns accessibility review into a repeatable release decision for marketing, content, design, and development teams.

Use the checklist as a first review and a handoff record. It is not a full WCAG conformance evaluation. The W3C’s Easy Checks explicitly describes preliminary checks as a way to find some barriers, while noting that a page can pass them and still have significant issues. A broader evaluation should combine tools, human judgment, and relevant users or specialists where the risk calls for it.

Accessibility checklist in brief

  • Choose representative buyer tasks and the page states needed to complete them.
  • Check titles, headings, reading order, links, images, and instructions for meaning.
  • Complete each task with a keyboard and observe focus throughout the journey.
  • Check text readability, contrast, zoom, and narrow-screen behavior.
  • Complete forms with valid and invalid inputs; inspect labels, errors, and confirmation.
  • Review media and documents that carry essential information.
  • Record each barrier with a reproducible path, owner, fix, and retest result.

This is a buyer-task acceptance checklist, not a substitute for the broader pre-redesign website audit. The audit decides what the site needs to change; this page tests whether people can perceive and operate a chosen path before release. The B2B Website Strategy cluster connects this test to the wider site decision.

Start with tasks and states, not a homepage score

List the journeys that matter to the page’s purpose. A practical B2B sample might include a home-to-offering path, an offering-to-evidence path, a resource download, and an inquiry path. Record the start URL, intended action, expected end state, and the components encountered. This sample is a CHCZ editorial method; it is not a W3C prescription or a claim about any particular site.

Cover states as well as page templates: unopened and expanded navigation, dialogs, validation errors, successful completion, responsive menus, and any consent or embedded widget that interrupts the task. A repeated component may need only one deep test plus spot checks elsewhere, but a different configuration can create a new barrier. If a PDF or video contains information needed for the decision, include it in the task rather than treating the HTML page as the whole experience.

Keep the boundaries clear. The B2B landing-page checklist owns campaign message, form handoff, and measurement. Here the form is examined for perceivability, operation, and understandable feedback. The website governance framework owns standing roles and change controls; this checklist supplies evidence for a particular release.

Run the checks in the order a person encounters the page

1. Confirm orientation and content structure

Open each selected URL without relying on an internal preview. Does its title identify this page rather than repeat a generic site title? Can a reader understand the main purpose from the opening and navigate the headings in a sensible sequence? Do visible headings describe their sections, and does the underlying structure preserve that order? The W3C page-structure tutorial explains how headings, regions, and other structure help people find and understand content. A decorative text block styled like a heading does not carry the same structural meaning.

Check the page at its initial state and after opening a menu or dialog. Record ambiguous section labels and reading-order surprises with the exact component and URL. If the page is translated, repeat the check in each published language; a translated visual label does not by itself prove the accessible name or page language is correct.

2. Inspect links, images, and non-text information

Read the links out of context. A link such as “View the specification” tells the reader more than a repeated “Learn more.” Check whether icons and controls have names that express their actions. Inspect the purpose of each meaningful image and its alternative text. A decorative image can have an empty alternative; a diagram carrying a decision needs its meaning available in text. The W3C images tutorial distinguishes informative, functional, decorative, and complex images.

Do not assume that adding a longer alt attribute solves a complex diagram. If the diagram has a sequence or relationship needed to make a decision, explain that relationship in adjacent prose as well. If a linked image is the only label for an action, test the link’s accessible name. Keep the visible call to action and its destination consistent with what the link says will happen.

3. Test keyboard operation and visible focus

Start at the browser address bar and use the keyboard to move through the task. Can you reach, activate, and leave the navigation, filters, tabs, dialogs, document links, and inquiry action? Is focus visible at every step and in an order that matches the task? Does opening a dialog move focus to useful content, and can the person leave it without being trapped? WCAG 2.2 includes keyboard operation and visible-focus criteria; W3C’s Easy Checks provides a practical first keyboard review.

Test interactive states, not just static links. A menu that opens by pointer but cannot be reached from a keyboard, or a sticky banner that hides the focused control, can block the path even when the page looks correct. Record the exact key sequence and state that reproduces the failure. Automated reports can point to candidate issues, but the actual task needs a human run-through.

4. Read and operate the page at smaller sizes

Review the page at a real narrow viewport and with increased text size or zoom. Can the reader follow the order, understand labels, and use controls without losing content or being forced into page-level horizontal scrolling? Check contrast for text and controls in their actual states, including focus, error, disabled, and hover where those states carry information. WCAG provides the relevant success criteria; use its Quick Reference to map an observed issue to the criterion rather than declaring a page conformant from a visual impression.

Do not treat one screenshot as a complete mobile test. Open the menu, scroll through a long page, rotate if the task warrants it, and try the form with the on-screen keyboard. A table may scroll within its own container while the page stays within the viewport. If content is hidden behind an overlay or requires a precise gesture, record the interaction rather than only the viewport width.

5. Complete the form, including a recoverable error

Start the inquiry task without filling any fields. Do visible labels describe the requested information, and are required fields clear before submission? Enter an invalid value where the page expects validation. Can you locate the error, understand how to correct it, retain other entered values where practical, and submit successfully? Does the completion state communicate what happened? The W3C Forms Tutorial covers labels, grouping, instructions, validation, and user notifications. Its notification guidance recommends understandable correction messages and confirmation of success.

Keep the form test distinct from business-system verification. A visible success message is evidence of the page’s feedback, not proof that routing, email delivery, or qualification worked. The landing-page checklist covers those downstream states. For this accessibility review, capture the field, error wording, focus destination, corrected input, and completion feedback.

6. Include media, documents, and embedded tools

When a video, chart, PDF, scheduler, or third-party widget is part of the path, check it as part of the task. Can essential information be obtained in a usable form? Can controls be reached and understood? Does an embedded tool change focus or language unexpectedly? W3C’s evaluation overview distinguishes quick checks from a more thorough evaluation and points to methods that involve tools and people.

Assign the owner who can change each surface. An inaccessible embedded step is still a barrier to the journey even if its code is supplied elsewhere. The release decision should record that dependency and the path available to the visitor while the issue is unresolved.

Use a reproducible acceptance record

A useful record lets another person repeat the test and decide whether the fix worked. The following fields are a CHCZ editorial template; adjust them to the team’s release process:

  • Journey and URL: the buyer task, start page, and expected end state.
  • State and input: viewport, browser, input method, menu or dialog state, and any test values used.
  • Observed barrier: what happened, where, and the steps that reproduce it.
  • Expected behavior: what the visitor needs to perceive or do; link the relevant W3C criterion or tutorial when applicable.
  • Impact and owner: whether the task is blocked, degraded, or merely confusing, and who can fix the component.
  • Retest evidence: the changed version, result, reviewer, and remaining exception.

Example, not a measured CHCZ finding: a visitor submits an inquiry form with one invalid field, the page changes that field’s border color, and no text explains the correction. Record the field, input, visible and announced feedback, then retest the corrected version. A screenshot alone would miss whether the error is announced and whether focus reaches it.

Decide what blocks release

Prioritize barriers by the task they stop and by how broadly the component is reused. A keyboard trap on a site-wide navigation element deserves attention before a low-impact wording improvement on a rarely used page. A broken form error on the primary inquiry path may require a release hold. These are editorial prioritization examples, not a universal severity formula or a claim that any current CHCZ page has these defects.

For each blocker, record a fix owner and a retest condition. If a full evaluation is needed, bring in an accessibility specialist and relevant user testing rather than declaring success from a short checklist. Preserve the previous working version and the acceptance record so a release can be assessed against what actually changed.

Frequently asked questions

Is an automated accessibility scan enough?

No. A scan can flag some code-level candidates, but it cannot establish that a person can finish the selected journey or understand every piece of content and feedback. Use it to support manual checks of keyboard operation, structure, images, form recovery, and responsive states. W3C describes preliminary checks as limited and recommends deeper evaluation when a complete assessment is needed.

Which B2B pages should be checked first?

Start with the journeys that support the site’s real decisions: finding an offering, evaluating its evidence, accessing a needed resource, and reaching a usable inquiry path. Include reused navigation and form components. Then sample other templates and states. The exact order is a site-specific release choice, so document why the chosen pages represent the current buyer journey.

Does this checklist prove WCAG conformance?

No. It provides a bounded first review and a reproducible defect record. WCAG conformance is a broader assessment against applicable success criteria and the complete page or process. Use the W3C standard and evaluation resources for that scope, and seek qualified review when the decision requires a formal conclusion.

How should a team track progress?

Track the tested journey and release version, open barriers, their task impact, responsible owner, and retest evidence. Keep “issue found,” “fix merged,” and “visitor path verified” as different states. A falling count of automated warnings is useful context, but it does not replace evidence that the task now works for the people and input methods included in the test.

Next step

Choose one high-value buyer path and run it end to end with the checklist above. Bring the observed barrier, the affected URL, and the decision it blocks to a B2B growth diagnostic; the discussion can start from the evidence you already have.

Source and method note: W3C WCAG 2.2, WAI Easy Checks, the page-structure, images, and forms tutorials, and WAI evaluation guidance were checked on 24 September 2026. Statements about those resources are source-grounded facts. The buyer-journey sampling plan, acceptance-record fields, and release prioritization are CHCZ editorial methods, not W3C requirements or claims of first-hand test results.