Accessibility basics a small business can check itself

A website is accessible when people with different abilities, devices and settings can use it. That includes someone who cannot use a mouse, someone who zooms in because the text is small, and someone who hears the page read aloud. You do not need to be a developer to find the most common problems. You need a browser, a keyboard and a list.

The list below follows the Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C Web Accessibility Initiative. WCAG has three levels, A, AA and AAA, and AA is the middle one. These checks are a first pass. The W3C says its own quick checks are not a complete evaluation, and a page that passes them can still have real barriers. Nothing here is legal advice or proof that a site meets any law.

1. Text contrast

Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text needs 3:1, and WCAG defines large as at least 18 point (about 24 pixels) or at least 14 point bold (about 18.5 pixels). Buttons, form-field borders and icons that carry meaning need 3:1 against their surroundings.

Light grey text on white is the usual failure. Use a free contrast checker, enter the two colours, and read the ratio. The ratio is compared exactly, so 4.499:1 fails.

2. Keyboard use

Put the mouse aside. Press Tab to move forward and Shift+Tab to move back. Every link, button, menu and form field should be reachable and usable with the keyboard alone. Also confirm you can always leave a component. A pop-up or video player that you can enter but not exit is a keyboard trap, and it fails the guidelines at the most basic level (A).

3. Visible focus

While tabbing, you should always see where you are. WCAG 2.4.7 requires that a keyboard focus indicator is visible, and it is an AA requirement. WCAG 2.2 added a related AA rule: a focused item must not be entirely hidden by content you added yourself, such as a sticky header or a cookie banner. Tab down a long page and watch whether a focused link slides under a fixed bar.

4. Headings

Headings describe what each section is about, and they should be marked up as real headings, not just bold text. WCAG asks that headings and labels "describe topic or purpose." The W3C's quick checks suggest the page outline starts with a level 1 heading and does not skip levels, and treats both as strongly suggested rather than required. Many browsers and free tools can show a page's heading outline. Read only the headings: do they tell the story of the page?

5. Link text

The purpose of a link should be clear from its text, or from the text around it. "Click here" and "Read more" repeated down a page tell a screen-reader user nothing. "Download the price list (PDF)" does. Scan your links as a list and ask whether each one makes sense alone.

6. Images and alt text

Every meaningful image needs a text alternative that does the same job as the image. Three rules cover most cases:

• A photo that adds information gets a short description of what matters in context.
• An image that is a link gets text that describes where the link goes, not what the picture looks like.
• A purely decorative image gets an empty alt attribute (alt=""), so assistive technology skips it.

A chart usually needs a short name plus a longer description, ideally with the numbers in a table. Text that is baked into an image, such as a menu saved as a picture, must be repeated as real text.

7. Form labels

Every field needs a visible label or instruction that says what to enter, including optional fields. Placeholder text that disappears when you type is a weak substitute. Submit the form empty and with a wrong value on purpose. Good errors say which field failed and how to fix it, and keep what the person already typed.

8. Zoom and small screens

Zoom the text to 200%. All text should enlarge, nothing should overlap, and nothing should be cut off. Then check reflow: at a width of 320 CSS pixels (a 1280-pixel window at 400% zoom) the page should work without scrolling sideways as well as down. Data tables, maps and diagrams are the stated exceptions. Also check that tap targets are at least 24 by 24 CSS pixels, or have enough space around them, which is the WCAG 2.2 minimum.

A fictional example

Take a fictional bakery site, written up like this after one pass:

• Contrast: the pale grey opening-hours text measures 3.1:1. Darken it.
• Keyboard: the order form cannot be submitted with Enter. Ask the builder to fix it.
• Focus: the sticky banner hides the focused "Order" link. Add scroll padding or move the banner.
• Links: three "Read more" links. Rename them to name their pages.
• Zoom: at 200% the menu overlaps the logo. Report it with a screenshot.

Each line names the check, the finding and the next step. That is enough for a builder to act on.

When to bring in help

A self-check finds the obvious. It does not replace testing with assistive technology or an expert review. If your site takes bookings, payments or applications, or if a customer or regulator has asked about accessibility, get a proper evaluation. Put the target in your brief to a designer from the start, for example "meets WCAG 2.2 level AA," so it is built in rather than patched later.

Prepared with AI assistance. Examples are fictional unless stated.