Myths and Misconceptions About Accessibility

In this article, I will address common myths about and objections to accessibility by presenting evidence and examples that debunk them and support reasons for accessibility.

1. Accessibility benefits only a small minority
2. Accessibility is a short-term project
3. Accessibility should be the last step
4. Accessibility is hard and expensive
5. Accessibility is ugly
6. Talk about Myths & Misconceptions

---

1. Accessibility benefits only a small minority<a name=“chapter-1”></a>

Accessibility benefits a wide variety of people.

About 20% of all people have some kind of disability. However, this doesn’t necessarily impact a person’s ability to use the internet and spend their money on your product. Without accessibility, the lives of people with disabilities could be impacted in a dramatically negative way because they can’t use websites.

Fully accessible websites are easier for search engines to index and catalog, making the website easier for everyone to find.

They’re also better for people who are getting older (they may be losing their eyesight, their hearing, their mobility, their cognitive abilities) - and guess what, we’re all getting there (hopefully). And besides the fact that we’re all getting older, we can all get a disability at any time (e.g., from an accident).

So let’s code now for our future selves.

2. Accessibility is a short-term project<a name=“chapter-2”></a>

Accessibility is an ongoing design requirement.

Accessibility will never disappear (just like (web) security, for example). As long as there are people on this planet, there will always be a need for accessible design.

Accessibility must be part of the entire process from the beginning: Business, design and quality assurance requirements, training new employees, and more.

It would be best if the company culture were fully committed to accessibility, through visionary leadership that provides resources and full-time positions for accessibility, as well as job opportunities for people with disabilities. It would be enormously helpful to have people with different abilities and disabilities working together on a daily basis.

3. Accessibility is the last step<a name=“chapter-3”></a>

Taking accessibility into account already in the design process makes it a lot easier and results in a better design than retrofitting as a last step.

If you only introduce accessibility as a final step, it can be very difficult to implement, often leading to poor design or even not implementing it at all. It could also make the process longer and more expensive.

4. Accessibility is hard and expensive<a name=“chapter-4”></a>

Developing accessibility from the beginning is reasonable compared to the cost of alternatives, such as implementing accessibility as a final step, negative publicity, or lawsuits.

5. Accessibility is ugly<a name=“chapter-5”></a>

If the component is ugly, you should look for another designer.

Most accessibility features are invisible anyway and usually only accessible to screen readers (e.g. descriptive text). Writing your code with semantic HTML not only makes the code more readable, but also ensures better search engine optimization.

And let’s face it, in what world is that fully accessible button on the right ugly?!

https://codepen.io/YuriDevAT/pen/eYMzpgw

6. Talk about this topic at Front-End Foxes Day 2022<a name=“chapter-6”></a>

Check out a full length talk about Myths & Misconception at the Front-End Foxes Day 2022, where I get into more details about each myth.

https://dev.to/yuridevat/this-was-front-end-foxes-day-2022-1472

---

Thanks for your reading and time. I really appreciate it!