5 Web Accessibility Myths

Many websites which exist today are not accessible. This causes people with disabilities, especially those who use assistive technologies, to not interact with the web effectively. WebAIM conducted a study across the one million home pages and 50,829,406 distinct accessibility errors were detected—an average of 50.8 errors per page. According to UsableNet, web accessibility lawsuits are increasing in 2022 with almost 100 lawsuits per week. However, fear of litigation should not be the reason you should invest in web accessibility. There are over a billion disabled people on this planet and they should have the human right to access the web. Here are some of the myths which can stop companies and individuals from investing in proper web accessibility efforts:

My Users Don’t Need It

It is a mistake to assume that your users are not disabled and hence you don’t need to make your website accessible. However, it is important to keep in mind that most disabilities are invisible or non-apparent. According to Lime Connect, a disability organization in the US, 90% of disabilities on school campuses are invisible.  A vast majority of the disabled population does not even disclose that they have a disability. In addition to this, disabilities are also temporary and situational. For example, having a temporary hand injury and having to use speech to text. Designing software with accessibility in mind benefits everyone, not just people with disabilities. Think about captions. Initially, captions were invented to help the Deaf/Hard of Hearing population but many of us use captions almost always while watching Netflix!

Automated Testing Will Fix My Website

Many Automated Testing tools such as Deque’s Axe, Google’s Lighthouse, or Microsoft’s Accessibility Insights are great at catching many accessibility errors on your webpage. According to Deque, automated tools right now catch 57 per cent of accessibility issues on your website, as compared to industry believed rate of 20-30%. For example, automated testing will be able to catch missing labels for your forms, or missing alternate descriptions for your images. However, will it be able to determine the accuracy of those labels and descriptions? No. In addition to these, automated testing will also not catch most keyboard navigation, focus trap, form submission etc accessibility issues. Hence, it is extremely crucial to perform manual testing, preferably with people who have disabilities. Many companies have accessibility programs in place where your product goes through manual testing for accessibility. If you are a small company with no accessibility knowledge base, reach out to consultancies such as Knowbility, Equal Entry, Fable, etc who can provide you advice on how to get started and provide feedback on your product’s accessibility. In addition to manual testing, it is also important to shift left in your design and development process. By shift left, it means that accessibility testing must begin as early as possible and should not be left at the end. This can be done by embedding automated testing in your CI development process while simultaneously iterating on your wireframes and user research for accessibility.

I Can Just Use an Overlay

There are various solutions for accessibility offered by some companies these days which claim to fix accessibility on your website with one line of code. These are known as accessibility widgets or overlays. There are various things wrong with these overlays. First, they present a flawed approach towards accessibility. Accessibility is not a bandage or an add-on. One line of code powered by artificial intelligence will not make your website accessible. Accessibility work requires intentional effort and empathy towards people with disabilities. Accessibility is more than just compliance.
Second, they won’t save you from accessibility lawsuits because they don’t really work. According to UsableNet, businesses using accessibility widgets received more than 300 lawsuits. Additionally, many people with disabilities have been open regarding their struggles with such overlays. The overlay fact sheet has many such testimonials on why overlays are a bad idea. One such review says, “There's a perfectly practical tool for making websites accessible. It's called a programmer. The needs that matter in making a website accessible are those of the users. If you can't meet those, then you can't meet the basic costs of doing business.”
In addition, overlays may also cause certain security issues. According to the Overlay Fact Sheet, “Some overlays have been found to persist users' settings across sites which use the same overlay. This is done by setting a cookie on the user's computer. When the user enables a setting for an overlay feature on one side, the overlay will automatically turn on that feature on other sites. While the overlay company might think they're doing good by the end user, the big privacy problem is that the user never opted in to be tracked and there's also no ability to opt out. Due to this lack of an opt-out (other than explicitly turning off that setting), this creates General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) risk for the overlay customer.”

Modern Web Frameworks Are Not Built for Accessibility

It’s not true that you need to build your website to be in pure HTML and JavaScript to be able to embed accessibility. Many modern web dev frameworks such as React JS have accessibility support. For example, React documentation has an entire page dedicated to accessibility which uses standard HTML techniques. All web frameworks are built upon standard HTML so there will always be opportunities to make accessibility improvements. You can also use accessibility code linters which are static code analysis tools to catch accessibility bugs as you code, which will help you to “shift left”, as described in #2. Take the example of React’s Accessibility Code Linter, which can be installed via NPM. Depending on how you set it up, the linter will report [accessibility] issues in your web browser’s console, your editor or in your Continuous Integration Environment.

I Need To Be a Screen Reader Expert

Screen Reader is a text-to-speech tool used by Blind/Low vision individuals to navigate the web. It is not an exaggeration to say that blind individuals struggle the most to use the web due to inaccessibility - hence many efforts for web accessibility are directed towards being screen reader accessible. However, you do not need to be a screen reader expert to start designing and developing with accessibility in mind. It’s certainly a bonus to know how to use a screen reader but creating accessible websites is different from testing them.

Wrapping Up

By implementing good accessibility practices in your code, you are indirectly making them accessible to screen readers. If you are confused about how a UI component can be made accessible - check out the ARIA Authoring Practices Guidelines where they present many design patterns and examples of how an accessible user interface should behave. Also, check out Google Chrome’s Accessibility Tree (this can be found in dev tools) which can help you look at the accessibility structure and properties of your web app. You can also use Paul Adams Bookmarklets which will highlight roles, states and properties of HTML elements on a page. These tools can help you find and fix accessibility bugs. Screen Readers use these roles, states and properties to communicate information to screen reader users, so making sure these appropriate properties are set is extremely important.
This is not to say that screen reader testing is not important. It most certainly is. However, there is a learning curve to using a screen reader and that should not deter you from designing and developing for accessibility. Screen reader testing can be best left to professional testers who are experts in doing so.

Web Accessibility is crucial for the 1 billion disabled people on our planet. Whether you are a designer, engineer, product manager or researcher, each of us play an important role in ensuring equitable access to people with disabilities. The myths outlined above don’t just apply to the web, they apply to desktop, mobile and any product or service interfacing with technology. Gaming, Meta verse, voice assistants, etc are just a few more examples which need to be developed with accessibility in mind. By baking accessibility in your product development phase, you will reach so many more users.