First-pass accessibility checks for a small business website

Some visitors use a keyboard instead of a mouse, a screen reader that reads the page aloud, or zoom to make text bigger. A few simple checks can show you whether your website puts obvious barriers in their way.

This guide is for owners of small service businesses with a live website. It walks you through a first pass you can run yourself, how to record what you find, and when to get expert help. It includes an accessibility finding log you can copy, with a hypothetical worked example.

A first pass can find obvious problems. It can't show that there are none. The W3C's Easy Checks are clear about this: "A web page could seem to pass these checks, yet still have significant accessibility barriers." This guide doesn't tell you whether your site meets any legal requirement.

1. Choose a few pages and decide how you'll record what you find

Don't try to check the whole site at once. Start with the pages that matter most to your customers:

• the home page
• one main service page
• the contact page or enquiry form
• any page with a video

Run each check on each page, and record the result as pass, fail or not tested. "Not tested" is an honest answer, for example if a page has no video. The log in section 7 gives you a format.

If you're launching a new or redesigned site, our website redesign checklist includes a shorter keyboard and phone check for launch. This guide is a fuller first pass for a site that's already live.

2. Use the keyboard only

Put the mouse aside and use these keys:

• Tab moves to the next link, button or field, and Shift+Tab moves back.
• Enter follows a link. Enter or Space presses a button.
• Space ticks or unticks a checkbox.
• Arrow keys move between the options inside some controls, such as a set of radio buttons or a menu.
• Escape closes an open menu or pop-up window. You can also use its close button.

The W3C's guidance on keyboard conventions explains that Tab and Shift+Tab move between controls, while other keys, mainly the arrow keys, move inside controls that have several parts. So if Tab jumps past the options in a group of radio buttons, that's expected. Use the arrow keys to move between them.

Now work through the page:

• Can you see where you are? The W3C's check for visible keyboard focus explains that people navigating by keyboard need an indication of which link, button or field they've moved to. If the highlight disappears, record a fail.
• Can you reach and use everything? Try every menu item, link, button and form field. Tick a box, choose an option and open any menu, using the keys above.
• Is there a skip link? The W3C's skip link check explains that a link at the start of the page lets keyboard users jump past the menu to the main content. It can be hidden until it's focused, as long as it then becomes highly visible.
• Can you close things and move on? A pop-up window that covers the page is designed to keep Tab inside it until you close it. The W3C's guidance on modal dialogs describes this, with Escape as the key that closes it. Check you can close it with Escape or its close button and get back to the page.

Record a fail if you can't operate a control, or can't get out of it, with any of these keys. If you're not sure how a control is meant to work, note it and ask your web supplier.

3. Zoom in

The W3C's zoom check suggests making your browser window quite narrow, then pressing Ctrl (or Cmd on a Mac) with + to enlarge the page to 200%. Then look for these:

• all text is still readable
• text isn't hidden behind other text or images
• you don't need to scroll sideways to read the content

The W3C says it's fine if the navigation menu changes into an icon you press to open it.

Also open the same pages on a phone, and check you can read them and use the menu and form.

4. Check page titles, headings, images and link text

• Page titles. Look at the text in the browser tab. The W3C's page title check explains that screen readers read the title first, so it should say which page you're on. If every tab shows the same title, such as just your business name, record a fail.
• Headings. The W3C's headings check says headings should describe the section that follows and be nested by level. The main heading is usually level 1, and levels shouldn't be skipped. Screen reader users can jump from heading to heading.
• Images. The W3C's image text check describes alt text as a short description that conveys the purpose of an image, for people who can't see it.
• Link text. Read your links on their own. "Click here" or "Read more" doesn't say where a link goes. Our guide to writing a services page covers clear link and button wording.

Headings and alt text are hard to check by eye. The W3C's check pages include small bookmark tools that show them on the page. Only add browser tools from sources you trust. Otherwise, ask your web supplier to check these for you.

5. Check forms: labels, required fields and errors

If customers get in touch through a form, check it carefully.

• Labels. The W3C's form label check explains that each field needs a label telling people what to enter. It also needs to be linked to the field in the code, so screen readers can announce it. You can see the visible label, but your supplier may need to confirm the code.
• Required fields. The W3C's required fields check says the best way is to include the word "required" in the label. An asterisk is often not announced to screen reader users. Another approach is to say all fields are required unless marked "optional".
• Errors. Leave one required field empty and try to send the form. Is the error message clear, and can you tell which field it refers to?

Our guide on what to ask on an enquiry form covers which questions to include and how to label optional fields.

6. Check colour contrast and video captions

• Contrast. As a rough check, the W3C's colour contrast check suggests viewing the page in greyscale to see whether text is still easy to read. That's only a rough check. Tools can measure contrast precisely, so ask your supplier if anything looks faint.
• Captions. The W3C's captions check suggests playing each video and checking captions are available in the language of the audio. The W3C says auto-generated captions alone are not sufficient. Check the captions:
  • are punctuated
  • are in time with the speech
  • say who is speaking
  • include important sounds

If a page has no video, record captions as "not tested" for that page.

7. Record, prioritise, fix and retest

Use one card for each finding. A finding is anything that failed, or that you couldn't check.

1. Copy the blank card into a document or spreadsheet.
2. Record what you actually saw, in plain words, with the page and the date.
3. Give it a priority using the guide below.
4. Name who will fix it: you, for content such as alt text, headings and link wording, or your supplier, for code and design.
5. After the fix, repeat the same check on the same page and record the retest result. A fix on one page doesn't prove the same problem is fixed elsewhere.

This priority guide is an editorial suggestion for a first pass, not a standard:

When to get expert help

A first pass by an owner is only a start. The GOV.UK Service Manual's guidance on testing for accessibility is written for government services, but one point applies to any website: "you'll miss some issues if you only do automated testing." It recommends both automated and manual testing, and testing with assistive technologies.

Consider expert help when:

• you find problems you can't fix yourself
• you rely on your forms or bookings for new work
• you're planning a redesign, so issues can be fixed in the new design
• you want a fuller assessment than a first pass can give, including testing with people who use assistive technology

Don't treat a plug-in or widget as a substitute for fixing what you find.

8. A note on legal duties

Quick checks can't tell you whether your website meets a legal requirement, and this guide doesn't cover legal duties. What applies depends on where and how your business operates. If you need to know, get advice.

Standards written for government services, such as those in the GOV.UK Service Manual, aren't automatically the test for a private business.

Common questions

If my site passes these checks, is it accessible?

Not necessarily. The W3C says a page could seem to pass these checks yet still have significant barriers. A first pass finds obvious problems. A fuller assessment is needed to evaluate accessibility properly.

Can an automated checker do this for me?

Automated tools can help, but the GOV.UK Service Manual says you'll miss some issues if you only use automated testing. Use them alongside manual checks like the ones in this guide.

Which pages should I check first?

Start with the pages customers rely on most: the home page, a main service page, your contact page or form, and any page with video.

Who should fix what I find?

You may be able to fix content yourself, such as alt text, headings, link wording and captions. Code and design issues, such as keyboard focus, form labels in the code and colour contrast, may need your web supplier.

How often should I run these checks?

There's no fixed schedule. Run them after any significant change to your site, such as a new page, form or design. Our website maintenance checklist covers agreeing who checks what after changes.

ScalePass helps service businesses build and refine websites that explain what they do and make the next step easy. If you'd like help acting on what your first pass finds, see how we approach websites.

In short

Choose a few key pages and check them with the keyboard only, at 200% zoom and on a phone. Look at page titles, headings, image text, link wording, form labels, required fields, error messages, contrast and captions. Record each finding with what you saw, a priority, who fixes it and a retest. Remember that a first pass can't show a site is accessible, or that it meets any legal requirement. Get expert help for a fuller assessment.