25 Accessibility Myths Exposed, with Receipts

97% of the top one million websites have detectable accessibility issues. That figure comes from the WebAIM Million 2024 report, and it paints a stark picture.

Think about this. Around 1.3 billion people worldwide live with some form of disability, according to the World Health Organisation. That's 15% of the global population. Together, they represent an estimated £5.9 trillion in annual disposable income.

So why do products remain so inaccessible?

Some of the problem traces back to myths. Misconceptions about who needs accessibility, what it costs, and how to implement it have created entirely avoidable barriers. These myths are regurgitated in planning meetings, retros, and boardroom discussions. They shape budgets, timelines, and priorities.

So let's dismantle them. You'll find 25 of the most common accessibility misconceptions examined, debunked with data, supported by expert insights, and illustrated with real-world examples.

TL;DR

• 15% of the world's population (1.3 billion people) live with disabilities

• Accessibility benefits everyone: ageing users, temporary injuries, situational limitations

• Building accessibility from the start adds approximately 2% to development costs; retrofitting is expensive

• Accessibility is a team effort across design, development, QA, content, and leadership

• Automated tools catch only 30–50% of issues; manual testing is essential

• Overlays and toolbars don't fix code-level problems

• Legal action applies to private businesses, not only government sites

• Accessible products gain better SEO, lower maintenance costs, and wider audience reach

• WCAG compliance is a baseline, not a guarantee of usability

• Accessibility is an ongoing practice, not a one-time fix

Myths About Who Benefits from Accessibility

#1: Accessibility Only Affects a Small Group of Users

The Myth: "Only a tiny percentage of our users need accessibility features."

Your product team is building a new customer portal. Someone in the planning meeting says, "Our analytics show only 2% of users have screen readers installed. Why spend resources on such a small group?" The team agrees to deprioritise accessibility. What they've missed: those analytics can't detect users with motor impairments navigating by keyboard, users with dyslexia who benefit from clear typography, users with colour blindness struggling with the interface, or the thousands who visited once, found the experience unusable, and never returned.

The Reality:

Let that 15% figure sink in. One billion people. This is the world's largest minority group. In the United States alone, 26% of adults, 61 million people, have a disability, according to the CDC's 2023 data. That is more people than the combined populations of New York and California.

And the number is growing. Populations are ageing. Age-related impairments in vision, hearing, motor control, and cognition are becoming more common every year.

But the story doesn't end with permanent disabilities. Consider the broader circle of people who benefit from accessible design:

• Older users who need larger text or captions to follow along

• Non-native speakers who appreciate extra time to read content

• People with temporary disabilities - a broken arm, recovery from eye surgery

• Anyone experiencing situational limitations, bright sunlight washing out a screen, a noisy environment drowning out audio

Accessibility features are not niche. They are universal.

#2: Disabled Users Don't Use My Website

The Myth: "We don't have any users with disabilities—no one has complained."

A product manager reviews support tickets and finds zero accessibility-related complaints. "See?" they tell the team. "Accessibility isn't an issue for our users." Meanwhile, a prospective customer (a project manager with repetitive strain injury who navigates primarily by keyboard) has tried three times to complete the onboarding flow. Each time, they've hit a custom dropdown that can't be accessed without a mouse. They've given up and signed with a competitor. No complaint ticket. No feedback form. They're gone.

The Reality:

Many assistive technologies are invisible to your analytics. Screen readers, switch devices, and eye-tracking systems do not announce themselves in your data dashboards. Users with colour blindness or motor impairments may browse your site the same way anyone else would, and you would never know.

Here's the uncomfortable truth: most users who struggle with your site don't complain. They leave. They find a competitor whose experience works for them. 71% of disabled customers with access needs will leave a website that's difficult to use. They don't file complaints. They click away. Your analytics register a bounce.

For some people, the internet is their only means of communication with the world. It is how they bank, access healthcare, apply for jobs, and stay connected. Saying disabled people don't use your site is like claiming there is no point installing a lift because wheelchair users never visit the top-floor restaurant. They can't get there in the first place.

#3: Accessibility Is Only for Blind Users

The Myth: "Web accessibility means making sites work with screen readers."

Your development team has diligently added alt text to every image and ensured screen reader compatibility. The accessibility box is ticked. Job done. Then, user testing reveals problems. A user with Parkinson's disease can't click your tiny close buttons. A user with ADHD loses track during your multi-step form because there's no progress indicator. A user with colour blindness can't tell your red error states from your green success states.

The Reality:

Screen reader compatibility is one slice of a much larger picture. Accessibility addresses a broad spectrum of human needs:

• Visual disabilities: Blindness, low vision, and colour blindness (which affects 8% of men worldwide)

• Hearing disabilities: Deafness and partial hearing loss

• Motor disabilities: Tremors, muscle slowness, limited fine motor control, paralysis

• Cognitive disabilities: Dyslexia, ADHD, memory difficulties, learning differences

• Speech disabilities: Conditions affecting voice-controlled interfaces

• Seizure disorders: Photosensitive epilepsy triggered by flashing content

• Multiple impairments: Often experienced by elderly users

The CDC reports that mobility and cognitive issues affect a higher percentage of the population than visual impairments.

#4: People with Disabilities Don't Use the Web

The Myth: "Disabled people prefer offline interactions anyway."

A local council decides to invest in improving their physical offices rather than their online services. "People who need help prefer face-to-face interaction," reasons the director. A resident with chronic fatigue syndrome, for whom leaving the house means exhausting their energy for the entire day, needs to report a housing repair. The online form has broken tab navigation and unlabelled fields that confuse their screen reader. They can't complete it. Their only option is to travel to the council office, which costs them two days of recovery time.

The Reality:

This myth gets the situation precisely backwards. For many people with disabilities, digital services are more accessible than physical locations. The web offers independence. It removes the need to navigate inaccessible buildings, rely on transportation, or depend on others for help.

Online banking means no queue to stand in. Telehealth appointments mean no waiting room. Digital forms mean no handwriting. Where non-disabled people can rely on their natural senses and physical capabilities, people with disabilities often rely on technology to bridge the gap.

For many users, an accessible experience is essential infrastructure.

#5: Blind People Don't Watch Movies or Video Content

The Myth: "There's no point making video accessible for blind users."

Your team is producing an onboarding video for a new software tool. The project manager suggests adding audio descriptions. Someone pushes back: "That's a lot of extra work for something blind users won't watch anyway." The video launches without audio descriptions. A blind developer at a client company wants to learn the tool. They can hear the narrator saying "Click here" and "As you can see," but they can't see. They have no idea what's happening on screen. They request accessible documentation instead, which doesn't exist. They recommend that their company switch to a competitor.

The Reality:

Blind users actively consume video content. Audio descriptions (narration that describes visual elements during natural pauses in dialogue) make this possible.

Streaming services include audio descriptions as standard. Netflix, Disney+, and Amazon Prime Video all offer extensive libraries of audio-described content. The demand is real, the technology exists, and the audience is watching.

If your product includes video, audio descriptions open it to a wider audience. Ignoring this is ignoring potential users.

Myths About Cost, Time, and Effort

#6: Making a Website Accessible Is Costly and Time-Consuming

The Myth: "Accessibility will blow our budget and delay our launch."

A startup is racing to launch their MVP. "We'll add accessibility later," the CTO decides. "Right now we need to ship." The team builds quickly, using custom components without keyboard support, divs instead of semantic HTML, and colour combinations that look good but fail contrast guidelines. Eighteen months later, a major enterprise client requests a VPAT before signing. The audit reveals 847 accessibility issues. Fixing them means touching nearly every component in the codebase. The three-month remediation project balloons to nine months and £180,000. If they'd built inclusively from the start, the additional cost would have been approximately £12,000 on their £600,000 initial development budget.

The Reality:

When accessibility is built in from the start, it adds approximately 2% to development costs, according to W3C estimates. Development time doesn't change significantly when teams have proper training and established processes.

"Designing a new site to be accessible should not add significantly to development cost... Some aspects of accessibility, such as use of style sheets, can actually reduce the costs of maintaining or updating sites." - W3C

The expensive part? Retrofitting. Bolting accessibility onto an existing product after the fact can mean significant rework. Code that was written without keyboard navigation in mind may need restructuring. Interfaces that were never tested with assistive technologies may need redesigning.

The cost comparison becomes clear: invest a small amount upfront, or pay a much larger amount later.

#7: We Can Quickly Add Accessibility Before Release

[shift left]

The Myth: "We'll bolt on accessibility at the end of development."

Two weeks before launch, the QA team runs an accessibility scan. They discover that the entire application navigation is built with JavaScript-only click handlers. There's no keyboard support. The custom tabs component traps focus. The modal dialogs don't return focus when closed. The project manager asks how long fixes will take. The senior developer's estimate: six weeks minimum, because the navigation architecture needs fundamental restructuring. The launch is delayed. Stakeholders are frustrated. The team works overtime. And during the fix, they introduce three new bugs that need additional rounds of testing.

The Reality:

Some fixes can be added late. Alternative text for images, labels for form fields, heading structure corrections, these are relatively straightforward.

But complex user experience issues cannot be patched in at the last moment. If your navigation fundamentally breaks for keyboard users, you may face full refactoring. What could have been a single line of code addressed early becomes what accessibility professionals call a "Mothra-sized bug" - a monster that demands major rewrites.

The industry term for the better approach is "Shift Left." Build accessibility in from the beginning. Include it in your design specifications, your development standards, and your testing protocols. Make it part of how you work, not something you scramble to add before launch.

#8: Accessibility means redesigning my entire product

The Myth: "We'd have to start from scratch to make our site accessible."

An AudioEye survey found that 52% of professionals believe this myth. They're wrong.

A marketing director hears that his website has accessibility issues. "We can't afford a complete redesign," they say. "We'll address this in version 2.0, maybe next year." An accessibility consultant reviews the site and provides a different picture. Eighty percent of the issues can be fixed without visual changes: adding labels to buttons, fixing heading hierarchy, ensuring touch targets meet minimum sizes, providing text alternatives for icons. The remaining issues need minor visual tweaks: slightly darker text for contrast, visible focus indicators that match the brand. Total effort: four sprints, not a complete rebuild.

The Reality:

Most accessibility improvements are incremental. Automated tools can detect 30–70% of issues without any design changes. Basic layout and visual design often remain intact.

Yes, some adjustments may be needed. Brand colours that fail contrast checks might need accessible alternatives for functional elements. Interactive components might need keyboard support. But these are targeted fixes, not ground-up rebuilds.

#9: Accessible design is ugly

The Myth: "Accessibility means text-only, ugly, basic designs."

A design lead presents a bold new visual direction for a product redesign: dramatic colour gradients and flashy animations. Someone mentions accessibility. The designer sighs. "I suppose we'll have to tone everything down and make it boring." But that's a false choice. Apple's product pages are accessible and visually stunning. And Stripe's products combine beautiful typography with excellent accessibility.

The Reality:

This misconception is a relic of the early internet, when technical limitations forced trade-offs between aesthetics and accessibility. Those days are long gone.

You can build websites that are beautiful, media-rich, interactive, and fully accessible. The Web Content Accessibility Guidelines (WCAG) don't forbid images, videos, or JavaScript. They ask that you provide alternatives and ensure functionality for all users.

Need proof? Visit these sites and see accessible design in action:

• 24 Ways (24ways.org)

• Indiana University (iu.edu)

• U.S. Web Design System (designsystem.digital.gov)

• University of Washington (washington.edu)

#10: Accessibility is a one-time fix

The Myth: "We fixed our site for accessibility, so we're done."

A company completes an accessibility remediation project. They celebrate. The project closes. Six months later, during a routine check, they discover: the new marketing team has uploaded 47 images without alt text, and a developer rebuilt the date picker component without keyboard support. They're back where they started. Their one-time fix was undone by business-as-usual work.

The Reality:

Every content update introduces the possibility of new issues. Every new feature needs an accessible implementation. Every navigation change needs testing.

When team members leave, their accessibility knowledge must transfer to their successors. When standards evolve, as they have from WCAG 2.0 to 2.1 to 2.2, with 3.0 on the horizon, your approach must adapt. As Ethan Marcotte wrote:

Accessibility is not a feature." - Ethan Marcotte

It's an ongoing commitment woven into how you build and maintain your product. Contrast this with organisations that embed accessibility into their processes: design system components can be accessible by default, content management systems prompt for alt text, QA checklists include accessibility criteria, and new team members receive accessibility onboarding. Accessibility is part of how they work.

Myths About Responsibility and Process

#11: Web Accessibility Is a Developer's Job

The Myth: "The devs will make it accessible."

A developer receives designs for a new dashboard. The designs specify a custom slider control with precise visual styling but no interaction patterns. The colour palette uses light grey text on white backgrounds. There are no focus state designs. The developer builds what's specified. The component looks exactly like the design. It's also inaccessible: the contrast fails WCAG guidelines, there's no visible focus indicator, and keyboard users can't operate the slider. When the accessibility audit flags these issues, the developer is blamed. But they built exactly what was designed.

The Reality:

Accessibility is a team sport. Devs cannot make a product accessible if the designs they receive ignore accessibility from the start. QA can't catch issues if accessibility is not part of the test plan. Product managers can't allocate time for something that's not in the requirements.

Every role has a part to play:

• Designers create accessible user interfaces, considering colour contrast and focus states

• Developers build with semantic HTML, keyboard navigation, and ARIA when necessary

• QA perform accessibility testing as part of their standard process

• Product Managers include accessibility in requirements and timelines

• Content Creators write accessible copy, provide alternative text, and create transcripts

• Legal Teams ensure compliance and manage risk

• Leadership allocates budget and time

• Marketing and Sales understand accessibility's impact on reach and SEO

When accessibility belongs to everyone, it becomes part of the product's DNA.

#12: Only experts can implement accessibility

The Myth: "You need specialised consultants for any accessibility work."

A mid-sized company wants to improve their product's accessibility. They assume they need to hire an expensive consultancy for everything. The budget isn't there, so the initiative stalls. Meanwhile, a junior dev discovers free resources from W3C and WebAIM. They spend an afternoon learning the basics. Within a week, they've fixed 23 issues. Another team member learns keyboard testing. The QA lead adds an accessibility checklist. Three months later, when they do hire a consultant for a formal audit, they're told they've already addressed 60% of common issues.

The Reality:

Anyone with basic web development skills can learn accessibility. The same HTML, CSS, and JavaScript you already know, applied more thoughtfully, produces accessible results.

Easy checks can be performed by non-experts. W3C provides a comprehensive guide to preliminary accessibility evaluation that anyone can follow. Learning accessibility is not a daunting undertaking. Many developers find it genuinely engaging once they start.

Specialists have their place, particularly for complex audits and legal compliance reviews. But day-to-day accessibility work? Your existing team can handle it with the right training, resources, and help.

#13: Accessibility can only be tested by people with disabilities

The Myth: "Only users with disabilities can properly test for accessibility."

A product team wants to test accessibility but doesn't know any disabled users. They assume they can't proceed. The work stops. Another team takes a different approach. Their developers learn to navigate their app using only the keyboard, identifying where focus gets trapped or lost. Their QA team installs NVDA (a free screen reader) and practices using it until they can identify common issues. Their designers test colour combinations against WCAG contrast guidelines.

The Reality:

Users with disabilities are invaluable testers. They use assistive technologies daily and understand their nuances in ways that other testers may not. Including them in your user research provides insights that no automated tool can match.

Anyone can learn to test for accessibility. Keyboard testing. Screen reader testing. Colour contrast checking. These are skills that can be taught and practised.

The best approach combines both. Train your team to catch common issues through standard testing. Then involve users with disabilities in UX testing for real-world validation. Each approach strengthens the other.

#14: A text-only version solves accessibility

The Myth: "We'll create a separate accessible version of the site."

A university decides to create a "simplified accessible version" of their student portal. Now they maintain two codebases. When term dates change, someone updates the main portal but forgets the accessible version. When a new feature launches, it's added to the main portal first; the accessible version gets it three months later, if at all. Students who need the accessible version receive a demonstrably inferior experience. They're missing features their peers have. They're seeing outdated information. They feel like second-class users.

The Reality:

Maintaining two versions of a site costs far more than building one accessible site from the start. Updates must be made twice. Testing must happen twice. Bugs must be fixed twice.

And the experience? A text-only site tells users with disabilities that they deserve a lesser product. It is segregation, not accessibility.

You don't need to strip away tables, JavaScript, images, or multimedia. CSS and modern development techniques allow full design flexibility while maintaining accessibility. One product that works for everyone is better than two products that treat people unequally.

#15: Assistive Technology Does All the Work

The Myth: "Screen readers and other tools will figure it out anyway."

A developer argues against spending time on semantic HTML. "Modern screen readers are smart enough to work it out," they claim. The team ships a page where navigation is built with divs, buttons are styled spans, and the heading structure jumps from H1 to H4 to H2. A screen reader user tries to navigate the page. They press the button shortcut key. Nothing happens (because there are no real buttons). They try to skip to the main content. They can't (because there's no landmark structure). They attempt to navigate by headings. The order makes no sense. The screen reader can only work with what the code provides. And the code provides chaos.

The Reality:

Assistive technology can only work with what you give it. A screen reader can't describe an image without alternative text. It can't navigate a page without proper heading structure. It can't announce the purpose of a button without an accessible name.

Your code provides the raw material. Assistive technology interprets that material. If the foundation is broken, no amount of clever software can compensate.

Proper structure, meaningful labels, and ARIA attributes when needed, these are the building blocks that make assistive technology effective.

Myths About Technical Implementation

#16: Accessibility is only about adding alt text

The Myth: "Add alt tags and you're accessible."

A content manager diligently adds alternative text to every image across the company's platform. Months later, an accessibility audit arrives. It lists 312 issues. The content manager is confused. "But I added alt text to everything!"

The Reality:

Missing alternative text is indeed one of the biggest accessibility issues, consistently appearing at the top of WebAIM's annual analysis. But it is one item on a long list.

Accessibility also includes:

• Heading structure that creates logical document outlines

• Functional controls that work with keyboards

• Colour contrast that meets minimum ratios

• Form labels that connect inputs to their descriptions

• Focus management that guides users through interactions

• Error handling that clearly communicates problems and solutions

A product with perfect alternative text can still be inaccessible in dozens of other ways. Alternative text is necessary. It's not sufficient.

#17: Using automated tools is all you need

The Myth: "Our automated scanner says we're compliant."

A company runs their product through an automated accessibility scanner. It returns a score of 94%. The compliance officer sends an email: "We're nearly there!" But when a blind user tests the product, they can't complete basic tasks. The submit button has an aria-label of "btn-submit-01" (technically present, flagged as passing, but meaningless). The alternative text for a complex diagram says "image" (technically present, completely unhelpful). The custom dropdown technically has keyboard support, but the interaction pattern is so unusual that the user can't figure out how to select an option. All issues the scanner marked as "passed" or couldn't detect at all.

The Reality:

An AudioEye survey found that 57% of professionals believe automation alone is enough. The data tells a different story. Automated testing catches only 30-50% of accessibility issues. Some studies put that figure as low as 25%. A Gov.uk analysis found that even the best tools caught only 41% of errors.

Consider what automation can and can't do. A tool can detect whether an image has alternative text. It typically can't judge whether that text accurately describes the image. A tool can check whether a form field has a label. It cannot determine whether the label makes sense.

Manual testing must complement automation:

• Review heading order and document structure

• Test navigation with keyboard only

• Verify functionality with screen readers

• Check media accessibility

• Conduct testing with real users

Passing an automated scan is a solid starting point.

#18: Accessibility overlays and toolbars solve everything

The Myth: "Add an overlay widget and we're compliant."

A company receives an accessibility complaint. Rather than address the underlying issues, they buy an overlay solution that promises "one line of code" compliance. The overlay adds a toolbar allowing users to adjust contrast and font sizes. The company's legal team relaxes. Three months later, they receive a lawsuit. The plaintiff's attorneys note that: the overlay doesn't fix keyboard navigation (users still can't access the main menu), the overlay's own interface conflicts with the plaintiff's screen reader, the overlay repeatedly announces itself, interrupting the user's workflow, and the underlying code violations remain. The overlay created an appearance of accessibility while the actual barriers persisted.

The Reality:

An AudioEye survey found that 65% of professionals believe this works. Accessibility professionals strongly disagree. Hundreds of accessibility experts have signed an initiative specifically opposing overlays. The reasons are clear.

Toolbars can help with certain visual adjustments, contrast settings, font size changes, cursor modifications. But they cannot fix code-level issues. If your keyboard navigation is broken, no overlay will repair it. If your ARIA implementation is incorrect, no widget will correct it.

Worse, some overlays create new accessibility problems. They may conflict with users' existing assistive technologies. They may announce themselves repeatedly in ways that disrupt screen reader users. They may give organisations false confidence that their site is compliant when fundamental issues remain.

Overlays aren't a substitute for building accessible products from the ground up.

#19: Following WCAG guarantees accessibility

The Myth: "We passed WCAG 2.1 AA. We're done."

A product team completes WCAG 2.1 AA compliance. Every success criterion is met. They're certified. A user with a cognitive disability tries to use the product. Technically, the 44x44 pixel touch targets pass. But there are 47 options on a single screen, and the confusion is overwhelming. Technically, the colour contrast passes. But the dense information architecture makes it impossible to find anything. Every WCAG criterion is met, but the product is still unusable for this person.

The Reality:

WCAG provides principles and guidelines. It establishes a valuable baseline. But compliance does not guarantee usability.

A product can technically meet every WCAG success criterion while still creating a frustrating experience for users with disabilities. The guidelines cannot anticipate every interaction pattern, every technology combination, or every user need. Standards can't update as quickly as technology evolves.

Real accessibility comes from understanding user needs, exercising empathy, and maintaining awareness of how people actually experience your product. Use WCAG as your foundation. Then build upon it with user testing and continuous improvement.

#20: ARIA solves all accessibility problems

The Myth: "Sprinkle ARIA attributes everywhere."

A developer learns about ARIA and decides to be thorough. They add role="button" to actual button elements. They add aria-label to elements that already have visible text labels. They add aria-hidden="false" to elements that should be visible (not realising that "false" doesn't undo what was never set). They add role="navigation" to every nav element (which already has implicit navigation semantics). The result? Screen readers announce elements twice. Some elements that should be hidden are now exposed. The navigation region is announced redundantly. In trying to improve things, they've made it worse.

The Reality:

The W3C has a golden rule about ARIA: "Don't Use ARIA."

That sounds contradictory until you understand the context. Native HTML elements, buttons, links, headings, form controls, have built-in accessibility features that work reliably across assistive technologies. ARIA should only be used when HTML cannot express a relationship or state.

Improper ARIA can create accessibility problems. An incorrect role can confuse screen readers. A missing required property can break expected behaviour. Redundant ARIA can conflict with native semantics.

Reach for semantic HTML first. Use ARIA only when HTML falls short. And when you do use ARIA, ensure you understand its implications fully.

Myths About Legal Needs and Business Value

#21: Accessibility is optional

The Myth: "It's nice to have but not a necessity."

A startup's founder thinks accessibility is "best practice but not mandatory." They deprioritise it. Two years later, they're expanding into the European market. They discover the European Accessibility Act makes accessibility a legal obligation for their product category. They have 18 months to comply or face exclusion from the market. What would have been built-in practice is now an emergency remediation project competing with their European expansion timeline. The "optional" feature has become a business-critical blocker.

The Reality:

Multiple laws may make accessibility mandatory for your product:

• Americans with Disabilities Act (ADA): United States

• Equality Act 2010: United Kingdom

• Accessibility for Ontarians with Disabilities Act (AODA): Ontario, Canada

• European Accessibility Act (EAA): European Union

In the United States, courts have consistently interpreted the ADA to apply to websites as "places of public accommodation." Private businesses have been sued and have lost.

Consider these cases:

• Netflix (2011): The National Association of the Deaf filed a civil rights lawsuit over lack of closed captions

• Domino's Pizza: The case reached the Supreme Court, which denied Domino's petition and let the lower court ruling stand

• Target: Settled for $6 million

• Sydney Olympics (2000): Australia's first website accessibility lawsuit established early precedent

For many organisations, accessibility is a legal obligation, not a suggestion.

#22: Only Government Sites Need to Be Accessible

The Myth: "ADA only applies to public sector organisations."

A restaurant chain's owner dismisses accessibility concerns. "We're not the government. Those rules don't apply to us." A year later, they receive a demand letter citing the Equality Act 2010. The claimant, who uses a screen reader, couldn't access the menu or booking system. The case settles out of court for £15,000 plus remediation costs. The owner discovers that small restaurants have faced similar actions. The assumption of exemption was expensive.

The Reality:

The ADA has been interpreted in plaintiff-favoured rulings to apply to private business websites. Thousands of small and mid-size businesses face legal action each year. The notion that only government sites need to comply is dangerously incorrect.

Small restaurants have lost accessibility lawsuits. Local shops have faced legal action. If you think your business is too small to be noticed, you are mistaken.

The legalities continue to evolve, and enforcement is increasing. Assuming exemption is a risk.

#23: Accessibility is about preventing lawsuits

The Myth: "We're checking a compliance box."

A company's accessibility initiative is framed entirely around legal risk. "Do the minimum to avoid being sued," leadership instructs. The team implements bare-minimum compliance. A year later, a competitor launches with accessibility as a core feature. They market their inclusive design. They win contracts from organisations with accessibility policies. They attract talent who want to work on ethical products. They gain positive press coverage. The company that did "the minimum" watches market share erode. They met compliance, but missed an opportunity.

The Reality:

Legal compliance is one reason to pursue accessibility. It is far from the only one.

Consider the business value:

• User Satisfaction: Accessible design improves the experience for everyone, not only users with disabilities

• Company Reputation: Accessibility positions your organisation as ethical and socially responsible

• Increased Revenue: Access to a market representing $8 trillion in disposable income

• Better SEO: Many accessibility practices overlap with search engine optimisation—clear headings, descriptive link text, alternative text for images

• Reduced Costs: Cleaner code means lower maintenance expenses, fewer support calls, and more efficient updates

• Better Development Practices: Accessibility encourages semantic HTML and thoughtful architecture

Compliance is the floor. Business value is the ceiling.

#24: Accessibility Lawsuits Are Frivolous

The Myth: "These lawsuits have no merit."

A CEO dismisses an accessibility lawsuit threat as "opportunistic lawyers targeting businesses. It won't hold up in court." They refuse to settle. They fight the case. Two years and £200,000 in legal fees later, they lose. The court orders remediation within 18 months, plus damages. The "frivolous" lawsuit cost them more than proactive accessibility work would have cost over a decade. Their competitors, who treated accessibility seriously from the start, spent a fraction of that amount.

The Reality:

An AudioEye survey found that 25% of leaders believe this. Courts have ruled otherwise.

When Domino's Pizza took its case to the Supreme Court, the Court declined to hear the appeal. The lower court ruling—in favour of the plaintiff—stood. This was a significant victory for accessibility advocates and a clear signal that courts take these cases seriously.

The price of inaccessibility can be steep: legal fees, settlement costs, remediation expenses, and reputational damage. Compliance costs far less than litigation.

#25: Making a Website Accessible Has No Additional Benefits

The Myth: "Accessibility is a necessary evil with no upside."

A product manager sees accessibility as pure overhead. "It's a cost centre. We do it because we have to." Then they notice something unexpected. After accessibility improvements: their SEO rankings improve (the semantic HTML and alt text help search engines understand content), their mobile usability scores increase (the larger touch targets and clearer layouts help all mobile users), their support tickets decrease (the clearer error messages and form labels reduce confusion), their page load times improve (the optimised images and cleaner code increase performance), and their design system becomes more maintainable (the component standards reduce inconsistency).

The Reality:

The benefits extend across your entire operation:

• Increased Product Use: More visitors mean more potential conversions, revenue, or engagement

• Cost Savings: Lower maintenance burden, reduced support requests, easier upgrades

• Improved Usability: What helps users with disabilities often helps all users

• Reduced Development Time: Style sheets and coding standards streamline future work

• Improved Interoperability: Accessible sites work across more devices, browsers, and configurations

• Reduced Server Load: External stylesheets and optimised images improve performance

• Better Reputation: Demonstrating commitment to inclusion builds trust

• SEO Improvements: Valid HTML, clear link names, text alternatives, and site maps all contribute to search visibility

Essential for some, useful for all. This is the core principle of accessibility.

Taking Action on Accessibility

The myths are debunked. The facts are clear.

• Accessibility benefits everyone, far beyond the 15% of the population with disabilities

• It is not expensive when built in from the start

• It is a team effort and an ongoing practice, not a one-time developer task

• Automation helps, but can't replace human testing

• Legal obligations are real and enforced

• Business benefits extend well beyond compliance

What happens next is up to you.

Start with an assessment. Many free tools can give you an initial picture of where your product stands. Understand your baseline.

Train your team. Basic accessibility knowledge should be standard across design, development, QA, and content creation. Invest in building that capability.

Build accessibility into your process. Include it in your design specifications. Add it to your acceptance criteria. Make it part of your definition of done.

Remember that small changes compound. You do not need to fix everything at once. Incremental improvements, sustained over time, transform products.

The web was designed to be accessible to all. Every step you take towards fulfilling that promise makes the digital world work better for everyone.

FAQ

What percentage of websites are accessible?

According to the WebAIM Million 2024 report, 97% of the top one million websites have detectable accessibility issues. Full accessibility remains rare.

How much does web accessibility cost?

When built in from the start, accessibility adds approximately 2% to development costs. Retrofitting existing products costs significantly more.

Is web accessibility legally necessary?

In many jurisdictions, yes. Laws, including the ADA (United States), Equality Act (United Kingdom), and European Accessibility Act, create legal obligations for digital accessibility. Courts have ruled that these laws apply to private businesses.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) are internationally recognised standards for web accessibility. They provide principles, guidelines, and testable success criteria organised across three conformance levels: A, AA, and AAA.

Can automated tools make my site accessible?

Automated tools are valuable for identifying issues, but they catch only 30–50% of accessibility problems. Manual testing—including keyboard navigation, screen reader testing, and real user testing—remains essential.

Statistics at a Glance

Legal Needs by Region

Citations

1. World Health Organisation disability statistics: https://www.who.int/news-room/fact-sheets/detail/disability-and-health

2. CDC disability statistics: https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html

3. CDC disability types and prevalence: https://www.cdc.gov/ncbddd/disabilityandhealth/disability.html

4. WebAIM Million report: https://webaim.org/projects/million/

5. WebAIM Screen Reader User Survey: https://webaim.org/projects/screenreadersurvey10/

6. Click-Away Pound Survey: https://www.clickawaypound.com/

7. W3C Web Accessibility Initiative: https://www.w3.org/WAI/fundamentals/accessibility-intro/

8. W3C business case for accessibility: https://www.w3.org/WAI/business-case/

9. W3C accessibility and development costs: https://www.w3.org/WAI/business-case/#costs

10. W3C planning and managing accessibility: https://www.w3.org/WAI/planning-and-managing/

11. W3C easy checks: https://www.w3.org/WAI/test-evaluate/preliminary/

12. W3C involving users in accessibility: https://www.w3.org/WAI/planning/involving-users/

13. W3C WCAG quick reference: https://www.w3.org/WAI/WCAG21/quickref/

14. W3C supplemental guidance: https://www.w3.org/WAI/WCAG2/supplemental/about/

15. W3C Using ARIA: https://www.w3.org/TR/using-aria/

16. W3C ARIA Authoring Practices: https://www.w3.org/WAI/ARIA/apg/

17. W3C accessibility responsibilities: https://www.w3.org/WAI/planning/org-policies/

18. W3C tips for designing: https://www.w3.org/WAI/tips/designing/

19. W3C audio description guidance: https://www.w3.org/WAI/media/av/description/

20. W3C legal and policy factors: https://www.w3.org/WAI/business-case/#legal

21. WCAG version history: https://www.w3.org/WAI/standards-guidelines/wcag/

22. WebAIM semantic structure: https://webaim.org/techniques/semanticstructure/

23. WebAIM quick reference: https://webaim.org/resources/quickref/

24. WebAIM training resources: https://webaim.org/services/training/

25. WebAIM accessible alternatives: https://webaim.org/techniques/alttext/

26. WebAIM accessibility and SEO: https://webaim.org/blog/web-accessibility-and-seo/

27. Deque shift left accessibility: https://www.deque.com/shift-left/

28. Deque team responsibilities: https://www.deque.com/blog/accessibility-is-everyones-responsibility/

29. Deque automated testing limitations: https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/

30. Gov.uk accessibility tools audit: https://alphagov.github.io/accessibility-tool-audit/

31. Overlay Fact Sheet: https://overlayfactsheet.com/

32. Adrian Roselli on overlays: https://adrianroselli.com/2020/06/accessibe-will-get-you-sued.html

33. Ethan Marcotte on accessibility: https://ethanmarcotte.com/wrote/accessibility-is-not-a-feature/

34. Netflix accessibility features: https://help.netflix.com/en/node/25079

35. NVDA screen reader: https://www.nvaccess.org/

36. Scope disability facts and figures: https://www.scope.org.uk/media/disability-facts-figures/

37. Global Economics of Disability: https://www.rod-group.com/insights/return-on-disability-report/

38. European Accessibility Act: https://ec.europa.eu/social/main.jsp?catId=1202

39. UK Equality Act 2010: https://www.legislation.gov.uk/ukpga/2010/15/contents

40. Domino's Supreme Court case: https://www.supremecourt.gov/search.aspx?filename=/docket/docketfiles/html/public/18-1539.html

41. Domino's case summary: https://www.adatitleiii.com/2019/10/dominos-pizza-case-could-have-major-impact-on-ada-web-accessibility-litigation/

42. UsableNet accessibility litigation report: https://usablenet.com/resources/2024-year-end-digital-accessibility-lawsuit-report-key-takeaways

43. 24 Ways: https://24ways.org/

44. U.S. Web Design System: https://designsystem.digital.gov/

45. Digital.gov accessibility: https://digital.gov/topics/accessibility/