Common misconceptions about implementing accessibility

Posted on Thursday, 18 December 2025 by Ela Gorla in Design and development

For many organisations and digital teams, knowing how to start implementing accessibility and how to sustain it over time isn't always straightforward. Teams often wonder who is responsible, which tools to use, and when accessibility should be considered.

Misconceptions about how to implement accessibility are common, whether it’s overreliance on AI tools and overlays, the assumption that accessibility is only a developer’s job, or uncertainty about how to use design systems and component libraries effectively.

Here we discuss some of these misconceptions and provide advice on how to implement true and sustainable accessibility.

Misconception 1: it’s only developers’ responsibility

Some people expect accessibility to happen entirely at the coding stage; developers do their magic, and here you are with your shiny, fully accessible website or app. That's far from reality.

As discussed in our common misconceptions about WCAG, accessibility is much more than just accessible code; it's good visual design, inclusive multimedia, well-crafted editorial, inclusive language and more. Everyone involved in planning, designing, and building a digital product is responsible for its accessibility.

While developers do play an important role in implementing accessibility, they cannot turn inaccessible designs or content into an accessible product. For example, a design containing poorly contrasting colours cannot be made accessible at the development stage. Also, developers shouldn’t be responsible for writing text descriptions for images; the person selecting the images is best placed to do this, as they better understand the context in which the images are used.

Accessibility shouldn’t fall solely on developers; it's a team effort!

Misconception 2: I can rely on AI tools

With so many AI enabled tools available and vibe coding becoming more and more popular, it may be tempting to assume we can rely on them to generate accessible content. However, this is not the case.

While AI can help write code, when it comes to accessibility they present two major drawbacks:

• They are trained on inaccessible code: we know that much of the existing code is inaccessible, and code generated by AI often includes the same mistakes
• They lack a holistic approach: even when AI generates accessible code, that on its own is not enough to build accessible products (as discussed under Misconception 1 above)

We put some AI tools to the test and asked them to write some text descriptions and lines of code. Many of the results we got were incorrect or inaccurate. If you want to learn more about it, head to our can generative AI help write accessible code? and can generative AI write contextual text descriptions? blog posts.

If you use AI to help you write code, always double check it complies with accessibility requirements. And don't solely rely on the accessibility information provided by AI, always verify what AI gives you against reliable sources.

Misconception 3: I can simply use an overlay

Some organisations choose to use "accessibility overlays" as a quick and easy solution to achieve accessibility.

Accessibility overlays are third-party tools that can be added to a website with the aim to enhance its accessibility. In addition to providing a variety of tools and customisation options to the people using the website, they claim they can identify and fix accessibility issues in the website code.

As explained in the Overlay Fact Sheet, this is not technically achievable. Many accessibility issues require manual rectification. For example, colours with insufficient contrast, images with missing or inaccurate text descriptions, text that is not identified as a heading, unclear error messages...the list goes on. This is why between January and June 2025 alone, in the USA 456 ADA lawsuits were filed against websites that use accessibility widgets and overlays.

Also, these tools often end up interfering with the assistive technologies, input devices, and accessibility features used by many people, resulting in a worse, rather than improved, user experience. Here is a quote from a blind person, taken from the Overlay Fact Sheet:

...I know with 100% certainty, any site which has deployed an overlay in the past year and a half has been less useable for both my wife and me - both blind.

Don't be tempted to use a tool that promises to automatically fix all the accessibility issues on your website. True accessibility requires proper planning and implementation at every stage of a product's development process.

Misconception 4: accessibility stops at launch

It's not uncommon to see digital teams doing an amazing work at implementing accessibility while developing a website or app but then stop worrying about accessibility once the product is launched. This often results in accessibility issues starting to appear in just a few months.

Websites and apps are living creatures; they are constantly updated and modified. Any change, small or large, can introduce accessibility issues. This is why accessibility needs to be properly planned and maintained over time.

A few actions you can take include:

• Ensuring that accessibility is an integral part of all the processes and documentation used in your organisation
• Including accessibility requirements in design systems and component libraries used by designers and developers
• Providing everyone working in digital with the training and knowledge they need to implement accessibility

You can find more practical suggestions on how to embed sustainable accessibility into your organisation in our guide to sustainable accessibility.

Misconception 5: I just need to use accessible style guides and components

Nowadays, most organisations have design systems and component libraries which provide designers and developers with style guides and reusable components, thus ensuring consistency across websites and apps. More and more of these have accessibility integrated. This means that when a style or component is used, it already includes key accessibility features. For example, a button may present a large target size area and a good contrasting border, and be coded with the correct HTML elements so it is keyboard and screen reader accessible. This is an important first step into building accessible content but on its own is not enough.

Re-using accessible styles or components alone is not enough. Accessibility also needs to be considered when combining components into web pages or app screens. For example, you need to ensure that:

• Components follow a logical visual and reading order
• Heading levels convey the correct content structure
• When leaving a component, the keyboard focus moves to the most logical location on screen

Ensure that you and your colleagues have the knowledge and skills you need to know how to best use and combine your organisation's style guides and components so you can create accessible content.

Next steps

Learn how our Sustainable Accessibility and Training services can help your organisation implement and maintain accessibility in the long term.