Right, let's talk about web accessibility. It's not just the right thing to do—it's a legal requirement in the UK, and it's good business sense. An accessible website means more people can actually use it, which means more potential customers for your Swindon business.
I've worked with enough businesses to know that accessibility often gets pushed to the bottom of the priority list. But here's the thing: it's not that hard to get right, and it makes your website better for everyone. Plus, if you're a public sector body in the UK, it's legally required. Even if you're not, the Equality Act 2010 means you need to make reasonable adjustments for disabled users.
What Web Accessibility Actually Means
Web accessibility means designing and developing websites that can be used by people with disabilities. That includes visual impairments, hearing impairments, motor disabilities, and cognitive differences. Basically, it means your website works for everyone, not just people who can see perfectly and use a mouse.
The Web Content Accessibility Guidelines (WCAG) provide the framework for this. There are three levels: A, AA, and AAA. In the UK, public sector websites need to meet WCAG 2.2 Level AA. That's the current standard as of 2025, and it's what I aim for when building websites for Swindon businesses.
WCAG 2.2 builds on 2.1 and adds 9 new success criteria, 6 of which are in levels A or AA (so they're mandatory for compliance). If you want to make sure your website meets these requirements, get in touch and we can discuss an accessibility audit.
Semantic HTML: The Foundation
Using semantic HTML is the foundation of accessible web design. It's not complicated—just use the right HTML element for the job. Semantic elements like <header>, <nav>, <main>, <article>, and <footer> provide meaning that screen readers and other assistive technologies can understand.
Here's the thing: if you use a <div> for a button, screen readers don't know it's a button. They just see a div. Use <button>, and everyone knows what it is. Simple, but it makes a huge difference.
Always use the correct HTML element:
- Use
<button>for buttons (not<div>with a click handler—that's just wrong) - Use
<nav>for navigation menus - Use heading elements (
<h1>through<h6>) in proper order (don't skip from h1 to h3, it confuses screen readers) - Use
<label>elements for form inputs (so screen readers know what each field is for)
This stuff is basic, but I see it done wrong all the time. Get the HTML right, and accessibility becomes much easier. If you're not sure whether your HTML is semantic, drop me a line and I can review it.
Alt Text: Describing Images Properly
All images need alt text. It's that simple. Screen readers use it to tell users what's in the image, and it shows up when images fail to load. The alt text should be concise but descriptive—convey the same information the image provides.
Here's where people get confused: decorative images should have empty alt text (alt="") so screen readers skip them. If an image is just for decoration and doesn't convey information, don't describe it. For functional images like icons in buttons, describe what they do, not what they look like.
Bad alt text: "A blue button with an arrow"
Good alt text: "Submit form"
See the difference? One describes appearance, the other describes function. Function is what matters.
Keyboard Navigation: Not Everyone Uses a Mouse
Lots of people navigate websites using only a keyboard. Whether it's because of a motor disability, preference, or they're just faster with keyboard shortcuts, your website needs to work without a mouse.
Test your website by navigating with only the Tab key. Seriously, try it. You'll be surprised how many sites break when you can't click things. Users should be able to:
- Access all interactive elements in a logical order (not jumping around randomly)
- See which element currently has focus (visible focus indicators are essential)
- Activate buttons and links using Enter or Space
- Close modals and dismiss notifications using Escape
If you can't navigate your site with just a keyboard, neither can people who rely on keyboard navigation. It's that simple. I test all websites I build for keyboard accessibility—if you want help making your site keyboard-accessible, get in touch.
ARIA: When HTML Isn't Enough
ARIA (Accessible Rich Internet Applications) attributes provide extra information to assistive technologies when HTML alone doesn't cut it. Use ARIA labels to describe elements that don't have visible text, and use ARIA roles to clarify the purpose of custom components.
But here's the important bit: prefer semantic HTML over ARIA. Only use ARIA when you actually need it. If you can use a proper <button> instead of a <div> with ARIA, do that. ARIA is for when HTML isn't sufficient, not a replacement for proper HTML.
Colour Contrast: Making Text Actually Readable
Colour contrast matters. If people can't read your text, your website isn't accessible. WCAG 2.2 Level AA requires:
- 4.5:1 contrast ratio for normal text
- 3:1 contrast ratio for large text (18pt or 14pt bold)
There are tools to check this—use them. Don't guess. Light grey text on a white background might look trendy, but if people can't read it, what's the point?
Also, don't rely solely on colour to convey information. If you use red to indicate errors, also include an icon or text label. About 8% of men are colour-blind (it's less common in women), so colour alone isn't enough. This is one of the new WCAG 2.2 requirements that's worth paying attention to.
Forms: Where Accessibility Often Breaks
Forms are where accessibility often goes wrong. Every form input needs:
- A properly associated
<label>element (not just placeholder text—that disappears when you start typing) - Clear instructions and error messages (tell people what went wrong and how to fix it)
- Required fields clearly marked (not just with an asterisk—some people won't see that)
- Logical tab order (fields should be in a sensible order)
Use the required attribute for mandatory fields, and provide clear, specific error messages. "Invalid input" is useless. "Please enter a valid email address" is helpful. See the difference?
WCAG 2.2 has new requirements around form accessibility, including things like consistent help and accessible authentication. If you're building forms for your Swindon business, getting this right matters. If you need help making your forms accessible, let's discuss your requirements.
Testing: How to Actually Know If Your Site Is Accessible
You can't just assume your site is accessible—you need to test it. Use a combination of:
- Automated tools: Tools like WAVE, axe DevTools, or Lighthouse can catch many issues (but not all—they're a starting point, not the whole solution)
- Screen readers: Test with screen readers like NVDA (Windows, free) or VoiceOver (Mac/iOS, built-in). You'll be surprised what you find
- Keyboard navigation: Navigate your site using only the keyboard (no mouse, no touchpad)
- Manual review: Check colour contrast, text alternatives, and semantic structure
Automated tools are useful, but they can't catch everything. You need to actually test with assistive technologies. I test all websites I build with screen readers and keyboard navigation—if you want help ensuring your site is accessible, get in touch.
WCAG 2.2: What's New
WCAG 2.2 is the current standard (as of 2025), and it adds 9 new success criteria. Six of these are in levels A or AA, so they're mandatory for compliance. Key additions include:
- Target size minimums: Interactive elements need to be big enough to click (at least 24x24 CSS pixels)
- Focus not obscured: Focus indicators can't be hidden by other content
- Dragging movements: If you require dragging, there must be an alternative
- Accessible authentication: Authentication shouldn't rely on cognitive function tests (like remembering a password pattern)
- Consistent help: Help mechanisms should be in a consistent location
These are all sensible requirements that make websites more usable for everyone. If you're building a new website or updating an existing one, it's worth making sure you meet WCAG 2.2 Level AA from the start.
Why This Matters for Swindon Businesses
Building accessible websites benefits everyone. It improves SEO (Google likes accessible sites), expands your audience (more people can actually use your site), and ensures compliance with UK accessibility laws.
For public sector bodies in the UK, WCAG 2.2 Level AA is legally required. For private businesses, the Equality Act 2010 means you need to make reasonable adjustments for disabled users. Following WCAG 2.2 is good evidence that you're doing that.
But beyond the legal stuff, it's just good practice. An accessible website is a better website. It's easier to use, works on more devices, and serves more people. If you're a Swindon business looking to improve your website's accessibility, let's have a conversation about how I can help ensure your site meets WCAG 2.2 standards.