Website Accessibility in Plain English
Website accessibility means building your site so that people with disabilities can perceive, understand, navigate, and interact with it effectively. If your site cannot be used by someone who is blind, has limited motor function, is deaf, or has a cognitive impairment, it is inaccessible. And if you think this only affects a small fraction of your audience, the numbers will surprise you: roughly one in five people in the UK lives with some form of disability, and that proportion grows significantly when you include temporary and situational impairments like a broken wrist, bright sunlight on a phone screen, or age-related vision decline.
For mid-market B2B companies, accessibility often falls into the “we’ll get to it eventually” category. That is a costly mistake. An inaccessible website excludes potential customers, exposes you to legal risk, harms your search rankings, and signals to the market that you have not thought carefully about your digital presence. The good news is that most accessibility improvements are straightforward engineering and design decisions, and the earlier you make them, the cheaper they are to implement.
What Accessibility Actually Involves
When people hear “accessibility,” they often picture screen readers and nothing else. The reality is much broader. The Web Content Accessibility Guidelines (WCAG), maintained by the W3C, define accessibility across four principles, sometimes remembered by the acronym POUR:
- Perceivable: Users must be able to perceive the content. This means providing text alternatives for images, captions for videos, sufficient colour contrast, and content that can be presented in different ways without losing meaning.
- Operable: Users must be able to operate the interface. Every interactive element must be reachable by keyboard alone. Navigation must be consistent. Users must have enough time to read and interact with content.
- Understandable: Content and interface behaviour must be predictable and readable. Forms should have clear labels and helpful error messages. Language should be identified in the code so assistive technologies can pronounce it correctly.
- Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means writing valid, semantic HTML and following established coding standards.
WCAG is organised into three conformance levels: A (the bare minimum), AA (the widely accepted standard for most organisations), and AAA (the aspirational gold standard that is rarely required in full). When businesses talk about “meeting accessibility standards,” they almost always mean WCAG 2.1 Level AA, and increasingly WCAG 2.2 as it gains adoption.
The Types of Disabilities You Are Designing For
It helps to understand the specific groups your accessible website will serve, because each requires different technical accommodations:
Visual impairments range from total blindness to low vision, colour blindness, and light sensitivity. Blind users rely on screen readers like JAWS, NVDA, or VoiceOver that read content aloud and navigate via heading structure and ARIA landmarks. Low-vision users may zoom the page to 200% or more, which means your layout must reflow gracefully. Colour-blind users need information conveyed through more than colour alone; a red-outlined form field needs a text error message too.
Motor impairments include conditions like cerebral palsy, Parkinson’s disease, repetitive strain injuries, or simply a broken arm. These users may navigate entirely by keyboard, by voice command, by eye-tracking hardware, or by a switch device. If your dropdown menu only works with a precise mouse hover, these users cannot reach its contents.
Hearing impairments affect users who consume video and audio content. Captions, transcripts, and visual alternatives to audio cues are essential. If your product demo relies on a voiceover with no captions, you have excluded this group entirely.
Cognitive and neurological impairments cover dyslexia, ADHD, autism spectrum conditions, and acquired brain injuries. These users benefit from clear language, consistent navigation, reduced animation, and predictable page behaviour. Flashing content can trigger seizures in users with photosensitive epilepsy, which is why WCAG has specific thresholds for flash rates.
The Legal Landscape You Cannot Ignore
Accessibility is not merely a nice thing to do. It is increasingly a legal requirement, and enforcement is accelerating.
In the UK, the Equality Act 2010 requires organisations to make “reasonable adjustments” so that disabled people are not placed at a substantial disadvantage when accessing services. Courts have interpreted this to include websites. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 explicitly require public sector websites to meet WCAG 2.1 AA, and private sector organisations face scrutiny under the broader Equality Act provisions.
In the EU, the European Accessibility Act comes into force in June 2025 and extends digital accessibility obligations to private sector companies offering products and services to EU consumers. If your B2B company sells into Europe, this applies to you.
In the United States, ADA (Americans with Disabilities Act) lawsuits against website operators have exploded. Over 4,000 digital accessibility lawsuits were filed in US federal courts in 2023 alone, and the targets are not only large enterprises. Mid-market companies, e-commerce sites, and even small businesses have been sued. The US Department of Justice issued a final rule in 2024 requiring state and local government websites to meet WCAG 2.1 AA, and the direction of travel for private sector regulation is unmistakable.
The practical risk for a mid-market B2B company is straightforward: if a user with a disability cannot complete a key task on your website, you face potential legal action, regulatory complaint, and reputational damage. The cost of defending an accessibility lawsuit typically dwarfs the cost of building the site accessibly in the first place.
The Business Case Beyond Compliance
Legal compliance is a floor, not a ceiling. The real business case for accessibility goes well beyond avoiding lawsuits.
You Are Losing Revenue From Excluded Users
The Purple Pound (the spending power of disabled consumers and their households in the UK) is estimated at over £270 billion per year. Research from the Click-Away Pound survey found that 71% of disabled users leave a website that they find difficult to use, and the vast majority never contact the company to complain. They simply leave and buy from a competitor. You never see this in your analytics because there is no “couldn’t use the site” metric. These are silent losses.
For B2B companies, the audience is smaller but the deal values are higher. If a procurement officer with low vision cannot navigate your product pages or fill in your contact form, you have lost a lead that might have been worth tens of thousands of pounds. And you will never know it happened.
Accessibility and SEO Overlap Significantly
Many of the technical practices that make a site accessible also make it easier for search engines to crawl and understand. Proper heading hierarchy, descriptive alt text, semantic HTML, readable URLs, and well-structured content all serve both audiences. Google cannot “see” your images any better than a screen reader can; it relies on the same text alternatives. A site with clean, semantic markup and a logical content hierarchy will typically outperform a poorly structured competitor in search, all else being equal.
In our projects, we treat accessibility and performance as two sides of the same coin. Both are architectural decisions that become exponentially more expensive to retrofit. When we set performance budgets before design starts, as described in our performance architecture guide, we also establish accessibility requirements at the same stage. Bolting on either one after launch is painful and costly.
It Improves the Experience for Everyone
Accessible design benefits far more people than just those with permanent disabilities. Curb cuts, the ramps built into pavements for wheelchair users, are used constantly by people pushing prams, pulling suitcases, or riding bicycles. The same principle applies to digital accessibility.
Captions on videos help users in noisy environments or in open-plan offices. High colour contrast helps everyone read content on mobile screens in bright sunlight. Keyboard navigation helps power users who prefer not to reach for a mouse. Clear error messages help every person who makes a typo in a form. When you design for the edges, the middle benefits enormously.
Common Accessibility Failures on Mid-Market Websites
After auditing dozens of mid-market B2B websites, certain problems appear with frustrating regularity. These are not obscure edge cases; they are fundamental mistakes that affect large numbers of users.
Missing or meaningless alt text on images. Either images have no alt attribute at all (so screen readers announce the file name, which is often something like “IMG_3847.jpg”), or every image has alt text like “image” or “photo.” Decorative images should have empty alt attributes (alt=””) so screen readers skip them, while meaningful images need concise descriptions that convey the same information a sighted user gets.
Insufficient colour contrast. Light grey text on white backgrounds is a perennial offender. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Tools like WebAIM’s contrast checker make testing this trivially easy, yet many brand guidelines specify colour combinations that fail these ratios. If your brand palette does not meet contrast requirements, the palette needs to adapt for digital use, not the other way around.
Inaccessible forms. Form inputs without associated labels, placeholder text used as the only label (which disappears when you start typing), error messages that are not programmatically associated with the field they describe, and form submissions that provide no feedback to screen reader users. Forms are where conversions happen. If your contact form is inaccessible, you are literally blocking leads at the point of conversion.
Keyboard traps and unreachable elements. Modal dialogs that cannot be closed with the Escape key. Dropdown menus that only open on mouse hover. Carousels that cannot be paused or navigated by keyboard. Custom interactive components built with div and span elements instead of native HTML buttons and links. Each of these creates a dead end for keyboard-only users.
No skip navigation link. Screen reader and keyboard users who land on your homepage must tab through your entire header navigation on every single page if you do not provide a “skip to main content” link. This is a two-minute fix that dramatically improves the experience for these users.
Auto-playing video and audio. Content that plays automatically with sound violates WCAG success criteria and is deeply frustrating for screen reader users, whose audio output is suddenly competing with your promotional video. Auto-play is bad practice generally, but it is an accessibility barrier specifically.
How to Approach Accessibility Practically
You do not need to make your entire website perfectly accessible overnight. What you need is a structured, prioritised approach that addresses the highest-impact issues first and builds accessibility into your ongoing workflow.
Start With an Audit
You need to understand where you stand before you can plan improvements. A proper accessibility audit combines automated scanning with manual testing. Automated tools like axe, WAVE, or Lighthouse can catch roughly 30-40% of WCAG issues: missing alt text, contrast failures, missing form labels, and similar machine-detectable problems. But the majority of accessibility issues require human judgement.
Manual testing should include navigating the site entirely by keyboard, testing with at least one screen reader (VoiceOver on Mac, NVDA on Windows), checking that all interactive elements have visible focus indicators, and verifying that the page makes sense when read in a linear order. If your team does not have this expertise in-house, bring in specialists. A thorough audit of a mid-market website typically takes two to five days depending on the size and complexity of the site.
Prioritise by User Impact and Legal Risk
Not all accessibility issues carry equal weight. Prioritise fixes that block users from completing core tasks. An inaccessible contact form is more urgent than missing alt text on a decorative image in a blog post. A keyboard trap in your main navigation is more urgent than a minor contrast issue in your footer.
Our team typically groups findings into three tiers: critical (blocks task completion or causes legal exposure), significant (degrades the experience substantially but has workarounds), and minor (does not meet the standard but has limited practical impact). This helps development teams plan their sprints sensibly rather than treating every issue with equal urgency.
Build It Into Your Process, Not Onto Your Backlog
The most expensive way to handle accessibility is to build a site, then audit it, then file dozens of remediation tickets. The cheapest way is to bake accessibility into design and development from the start. This means designers check colour contrast as they select palettes. Developers use semantic HTML by default and test keyboard navigation as they build each component. Content editors are trained to write proper alt text and use heading levels correctly.
This is the same philosophy we apply to performance. Architectural decisions made early, choosing the right heading structure, using native HTML elements, setting content authoring standards, cost almost nothing. Retrofitting those same decisions after hundreds of pages exist costs orders of magnitude more.
Test With Real Users
Automated tools and manual expert testing will catch the vast majority of issues, but nothing replaces testing with actual disabled users. People who use assistive technology daily will find problems and friction points that even experienced auditors miss. If budget allows, include disabled users in your usability testing. Organisations like AbilityNet in the UK can help connect you with testers.
Accessibility and Performance: Two Architectural Decisions That Compound
There is a strong relationship between accessibility and site performance that most businesses overlook. A slow website is an inaccessible website. Screen readers have to wait for the DOM to load and stabilise before they can parse the page. Layout shifts (poor CLS scores) are disorienting for sighted users but can be completely bewildering for screen magnifier users who lose their place on the page. Heavy JavaScript frameworks that rewrite the DOM can break the connection between ARIA attributes and the elements they describe, leaving assistive technology users with stale or incorrect information.
Conversely, many performance best practices improve accessibility. Serving properly sized, well-compressed images with descriptive alt text is good for speed and good for screen readers. Using semantic HTML instead of JavaScript-heavy custom components is faster to parse and more accessible by default. Reducing third-party scripts improves load time and reduces the chance of injected content that screen readers cannot interpret.
What we see on most mid-market sites is that accessibility and performance problems cluster together. A site built with bloated page builders, excessive plugins, and no architectural planning tends to fail on both fronts simultaneously. The fix is the same in both cases: make better decisions at the architecture stage.
Common Objections and Why They Do Not Hold Up
“Our audience doesn’t include disabled people.” You do not know this because your analytics cannot tell you, and disabled people who cannot use your site have already left. One in five people has a disability. Your audience includes them whether you realise it or not.
“It’s too expensive.” Accessibility built into a new site project adds roughly 5-10% to development cost. Retrofitting accessibility onto an existing site costs significantly more, and defending an accessibility lawsuit costs more still. The cheapest time to address it is now.
“We’ll add an overlay widget.” Accessibility overlay tools do not make websites accessible. Products that promise one-line-of-code accessibility compliance are, at best, ineffective cosmetic patches and, at worst, actively harmful. They add JavaScript bloat, can interfere with screen readers that already have their own settings, and provide a false sense of compliance. Multiple accessibility organisations have published statements condemning overlays. Several companies have been sued specifically for using them. Do not use overlays.
“Our CMS handles it.” Your CMS provides the tools; it does not guarantee the outcome. WordPress, for example, has reasonably accessible core markup, but the theme, the plugins, and crucially the content you enter determine whether the final page is accessible. A CMS with a perfectly accessible theme will still produce an inaccessible page if the content editor uploads images without alt text, uses bold text instead of proper headings, or embeds videos without captions.
What To Do This Week
If you have read this far and suspect your website has accessibility gaps, here is a practical starting point. Run your homepage and two or three key pages through an automated tool like WAVE or the axe browser extension. Note the number and severity of issues flagged. Then try navigating those same pages using only your keyboard: Tab to move forward, Shift+Tab to move backward, Enter to activate links and buttons, Escape to close dialogs. If you get stuck, lose track of where the focus is, or cannot reach a key element, your keyboard-only users are experiencing the same thing.
That simple exercise will give you a baseline understanding of where your site stands. From there, decide whether you need a full audit, a remediation plan, or whether accessibility should be a core requirement in your next redesign. The most important thing is to stop treating accessibility as an afterthought and start treating it as what it is: a fundamental quality attribute of a well-built website, on the same level as performance, security, and usability.
