# An accessibility checklist for website templates

By HTMLPick
Published: 2026-09-11
Updated: 2026-10-03

Review a template with a keyboard, enlarged text, real content, and its main forms before you choose it. Record each problem by page and action. An attractive preview alone cannot establish accessibility.

This is an initial review. It does not establish WCAG conformance or replace evaluation by people with relevant expertise and access needs. W3C's [Easy Checks](https://www.w3.org/WAI/test-evaluate/preliminary/) explains the purpose and limits of a first review.

## Choose a useful sample

Start with a landing page, a content page, and a page that contains a form. Include any navigation menu, dialog, or tab control that the website depends on.

Use the template version you plan to adapt. A vendor's demonstration can contain changes that the download does not include. Record the version and the URL beside each finding.

Replace at least one page with your own content. Long headings, translated labels, and larger images can expose problems that a carefully prepared demonstration avoids.

## Complete a task without a mouse

Put the mouse aside. Use the keyboard to reach the main navigation and complete a simple task, such as opening a project or sending an enquiry.

Check whether the current control remains visible as focus moves. Check the return path after opening a menu or dialog. Record any point where you cannot reach an action or leave a component.

W3C's [Focus Visible explanation](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html) describes why a visible keyboard focus indicator matters. A hover style alone does not show keyboard users where an action will occur.

For each problem, record an exact sequence. “The menu is difficult” gives a developer little information. “After the menu opens, Tab moves behind the panel” identifies a repeatable action.

## Review names and form instructions

A visitor should understand a field before entering a value. Look for visible labels, clear required-field instructions, and error messages that explain a correction.

Do not rely on placeholder text as the only field label. W3C's [form label tutorial](https://www.w3.org/WAI/tutorials/forms/labels/) explains how labels connect to controls and support their use.

Use a short form record:

| Question | Record |
| --- | --- |
| What information does the field request? | The visible label |
| Is the field required? | The instruction before submission |
| What happens after invalid input? | The error and correction |
| Does the form retain valid values? | The observed result |
| What happens after success? | The confirmation and next step |

Check each form state. The initial design can look clear while the error state leaves a visitor without an explanation.

## Check headings and reading order

Read the page as an outline. The main heading should identify the page. Section headings should describe the content that follows them.

Check that heading levels express the structure. Do not choose a heading level only because it has the desired font size. A design change should not turn every card label into a main page heading.

Compare the visible order with the document order when a layout uses several columns. Keep the main explanation before an action that depends on it. Ask a reviewer with assistive technology experience to check the result when the reading order is uncertain.

## Enlarge the text and inspect narrow layouts

Increase the text size and inspect the page at a narrow width. Check whether labels disappear, buttons overlap, or an important instruction leaves its panel.

Use real content during this review. A short word in the demonstration may fit where your actual service name does not.

Keep a record of the viewport and the text setting with each issue. Avoid a general “mobile pass” label when you only checked one page at one size. Our [mobile layout guide](/guides/mobile-website-template-checklist) provides a separate review sequence.

## Give images a clear purpose

For each image, decide what information it adds. Write alternative text that conveys that information in context. Decorative images should not repeat nearby text to a screen reader.

A linked image also needs a clear destination through the link's accessible name. Check the complete card or link, not only the image attribute in isolation.

Avoid writing “image of” before every description. Describe the relevant information. For a project chart, that may require a text explanation beside the chart rather than a long alternative text attribute.

## Record limits before you choose

Separate problems in the template from problems introduced by your content. Ask whether the person who maintains the website can correct each issue.

A useful record contains the page, the action, the expected result, the observed result, and the owner of the correction. Add a date so a later reviewer can identify the version you checked.

Do not convert an automated score into a conformance statement. Combine tool findings with manual review and appropriate expert evaluation.

If two templates support the same content, prefer the one whose interactions you can understand and maintain. Continue with the [template selection guide](/guides/choose-a-website-template) to compare the wider editing and hosting requirements.