Accessibility basics for small business websites

In England, Wales and Scotland, the Equality Act 2010 places a duty to make reasonable adjustments on providers of services to the public, whether those services are paid for or free. Section 29 applies that duty to service providers. Section 20 describes steps to avoid substantial disadvantage for disabled people, including providing information in an accessible format where relevant.

For services, Schedule 2 frames the duty around disabled people generally. It is anticipatory, so do not wait for a customer to complain before considering barriers. If your website is how people find information or access your service, include it in that work. You cannot charge a disabled customer for the cost of meeting the adjustments duty.

The Act does not prescribe WCAG 2.2 AA as a universal technical checklist for every private business website. Separate public-sector accessibility regulations have their own requirements. Northern Ireland uses different legislation, including the Disability Discrimination Act 1995. What is reasonable depends on the circumstances, so check your situation with a legal adviser if your duties are unclear, particularly for a members-only organisation or public-sector work.

WCAG means Web Content Accessibility Guidelines. The World Wide Web Consortium, usually called W3C, publishes them. They describe how people should be able to perceive content, operate controls, understand information and use assistive technology, such as software that reads a page aloud.

The guidelines contain testable requirements at levels A, AA and AAA. Level AA includes the applicable A requirements as well as AA requirements. WCAG 2.2 AA is a useful target to agree with your web person, but these checks cover only some of its requirements. Full conformance concerns whole pages and complete processes, not just the homepage.

Ask what standard the work will use, which pages and journeys it will cover, and how someone will check it. A claim that a plugin has made the site compliant is not evidence that a customer can complete a booking.

On a computer, put the mouse aside. Use Tab to move forwards through links and controls, and Shift plus Tab to move backwards. Enter normally follows a link; Enter or Space activates many buttons. You should always be able to see which control has focus, meaning it is ready to receive your next keyboard action.

WCAG 2.2 AA requires visible keyboard focus and says the focused control must not be entirely hidden by content the website creates. Cookie banners and fixed headers can cause problems here. Check the page after opening them, not just before they appear.

• Reach the menu, service links, contact button and form fields without a mouse.
• Open and close menus or pop-up panels. Check that you can move out of them rather than becoming trapped.
• Follow the visible focus indicator. Record where it disappears or becomes hidden behind a banner.
• Check that the order makes sense and that a way to skip repeated navigation reaches the main content.

Increase your browser zoom to 200% and check that you can still read the text and operate the page. Then try a narrow window or higher zoom to look for text cut off at the edges. WCAG's AA reflow requirement normally expects content to work at a width of 320 CSS pixels without scrolling sideways as well as down. Some content, such as a map or a data table, has exceptions because it needs a two-dimensional layout.

Contrast is the difference between text and its background. WCAG AA normally requires at least 4.5:1 for ordinary text and 3:1 for qualifying large text. Ask your web person to measure it, including text over photos and pale text in forms. Whether text qualifies as large depends on its size and weight, not whether it looks like a heading.

Use real headings to organise the page, rather than making ordinary text big and bold. A screen reader can use correctly marked headings to help someone move between sections. Keep important information as text, not just as words embedded in a photo, poster or scanned menu.

Alt text is a short text alternative for an image. It should convey the useful information the image adds in that particular page. A picture used as a button needs a description of its action or destination. An image that is only decorative should have an empty alternative so a screen reader can skip it, rather than reading a filename.

Add accurate captions to prerecorded videos with speech or meaningful sound. Check automatic captions before publishing them, especially names, prices and technical terms. If essential information appears only on screen, it needs an accessible alternative too. At AA, prerecorded video can require audio description of important visuals. Ask for a media review rather than assuming captions solve every barrier.

If an image of a menu or price list is the only place that information appears, add a readable text version on the page. It helps people who enlarge text as well as those using screen readers.

For a project photo, useful alt text might describe a level-access entrance with a handrail. The image's role matters more than listing every object in the background.

Every field needs a clear label. Text inside an empty field, called a placeholder, disappears when someone types and should not be its only label. Explain required fields and any unusual format before the person submits the form.

If a form detects an error, it must identify the problem in text. A red border alone is not enough. An error message should name the field and explain what needs correcting. Check that someone using a keyboard or screen reader can find that message and return to the field.

• Reach and complete each field with the keyboard, including date selectors and drop-down lists.
• In an agreed test, leave a required field empty and check that the page explains what is missing.
• Check that correcting one field does not unnecessarily erase the other information already entered.
• Review the booking, payment and confirmation steps as well as the first form. Arrange tests so they do not create real purchases or unwanted messages.

On a phone, try the menu control, close buttons and nearby links. People with limited hand movement need controls they can select without hitting the wrong thing. WCAG 2.2 AA includes a minimum pointer target size of 24 by 24 CSS pixels, with exceptions including adequate spacing and links within text. CSS pixels are the page's sizing units, not the physical dots on a phone screen. Ask your web person to check the actual requirement rather than counting screenshot pixels.

A generous tap area can be more usable than a tiny control that just meets a minimum. Check that a floating chat button or cookie panel does not cover the enquiry button, especially after enlarging the page.

Your website's accessibility work also needs to consider embedded booking tools, maps and payment panels. Ask the supplier about accessibility and test the actual integration. Provide a working contact route for anyone who encounters a barrier while you investigate it. A phone number alone is not a replacement for fixing the website, and it may not help someone who cannot use a voice call.

Record each issue with its page address, the action that failed and the device or browser used. Prioritise barriers that prevent someone reading essential information or completing a customer task. Agree fixes with your web person and repeat the same checks afterwards.

Automated accessibility tools can find useful clues, but they cannot determine accessibility on their own. Human judgement is needed to check whether alt text makes sense, keyboard use works and the whole journey is understandable. For a fuller review, combine technical checks with manual testing and feedback from disabled users.

Repeat checks when adding a form, changing colours or switching booking tools. Make it easy to report an accessibility problem, and respond with a practical way to help while you address the cause. Keep that route available rather than relying on a one-off certificate or score.