Web Accessibility is a must in every web development project, yet it seems to remain a mystery for many web developers. Like it's something legendary instead of an essential skill needed for the job.

Threre are many misconceptions surrounding Web Accessibility, most of the time fueled by a lack of knowledge (or interest) in the matter. This article is a collection of some of those accessibility misconceptions or myths.

• Accessibility is difficult
• Accessibility is expensive
• Accessible websites are ugly
• Accessibility is for blind people/screen readers
• Accessibility is for people with disabilities
• Automatic tests are enough for accessibility
• Accessibility overlays are enough to ensure Web Accessibility
• HTML is accessible by default
• No ARIA > Bad ARIA
• Prefers reduced motion means no motion

Accessibility is difficult

We often hear this term when a project is at an advanced stage and not accessible. "Accessibility is difficult!" As if it was a justifiable reason because of all the delays they are experiencing.

But there's nothing further from the truth. Accessibility is not difficult. Do you know what's difficult? Running at an Olympic level. Even more, just running is difficult. A baby needs 12 months to start crawling, walking, and finally running. It's a slow process that requires strengthening the muscles, getting coordination, practice, practice, and more practice.

On the other hand, a Web Developer can learn at least the basics of Web Accessibility within hours, practice within days, and have a good grasp within weeks. Of course, they won't be experts. Still, they would be able to fix and prevent many of the issues highlighted in the WebAIM Million report and avoid the main accessibility issues that plague the Internet nowadays.

Obviously, there are more things to Web Accessibility than just the basics. Learning and mastering more advanced approaches takes time, but a good enough level is possible within a reasonable time.

Accessibility is expensive

Is it expensive in time? Expensive in money? Both of them? Either way, it is a dubious claim that can be heard towards the end of projects in which they did not consider Web Accessibility at the early stages... which makes it expensive! Teams will have to work on issues after the fact, rebuilding the solution (almost from scratch in some cases), which will waste time and money. Something that they could have avoided if they had implemented accessibility at the start.

If you have a car and the oil light goes on, you change the oil. It will take you a few minutes, either done by yourself or at the shop, and it will cost you just a few bucks. However, if you don't change the oil, chances are that your engine will seize up and break down after a while. The repair will be in the hundreds (or thousands) of dollars, and it will require a mechanic using special tools and parts. Not to mention that the car will be off-service for days or weeks.

If you apply Web Accessibility at the right time (at the start of a project), it will cost less in the long run and save many headaches and stress to the team. But if you wait to do it until you have to (e.g., after users complain or you get a lawsuit), then it will be expensive and painful. In addition, it will require specialists and be time-consuming.

Taking into consideration that people with disabilities have a purchasing power of 1.3 trillion dollars (over 8 trillion including relatives and friends), maybe it's time to stop talking about Web accessibility as an expensive feature, and start presenting it as a profitable one.

Accessible websites are ugly

Nothing could be further from the truth. Accessibility doesn't determine if a website is ugly or not. There are beautiful, accessible websites and really ugly non-accessible websites. Accessible websites will be as ugly (or as beautiful) as they are designed to be. Like any other website!

This myth has gone a long way. It has existed since Web Accessibility is a thing (which means, basically since the beginning of the Internet) and it is rooted in a misconception. Before, the idea of accessibility was linked to no styles, no animations, no images, no videos... no nothing. A bland, dull, ugly site. But that doesn't have to be the case.

Some of the accessibility requirements will indeed limit the creativity of designers and developers (e.g., sometimes finding an accessible color palette can be a challenge), but there are many tools online that will help with that. Plus, the different standards have evolved to include many accessibility features.

We need to ditch the idea of building a website and then uglifying it to make it accessible. That's an old-school mentality. Accessible websites can be visually striking, animated, fun, interactive sites from the start. And good designers are doing a great job at infusing inclusiveness and accessibility out of the box.

Accessibility is for blind people/screen readers

With the most popular assistive technologies being focused on people with visual disabilities, it is tempting to think that accessibility is mainly for blindness.

But there's more to it:

• Deaf or deaf-blind people,
• People using automatic page-turners, adaptive pencil grips, or assistive pointer devices,
• People with vestibular disorders,
• Keyboard users, braille devices users, sip-and-puff device users, to name a few.

The people who require Web Accessibility are not a homogeneous group. Therefore, we cannot apply a one-size-fits-all type of solution and move forward with it.

Take the online controversy that happened not so long ago as an example: a blind person organized a ClubHouse meeting about Web Accessibility. Soon, he got some backlash from the Deaf community as ClubHouse is a notoriously inaccessible platform, and the gathering excluded people with hearing problems.

Is it really possible to talk about accessibility while focusing only on visual disabilities? Without including all people involved? The answer is no.

Accessibility is for people with disabilities

This myth is a variation of the above. We already made clear that accessibility is not only for blind people, but we must not think it only impacts people with disabilities. It actually affects everyone!

There are invisible and situation disabilities that impair people and limit what they can do temporarily (or even permanently). You may...

• ...break a bone while playing basketball and be unable to use the mouse/keyboard on your computer.
• ...be pregnant or have restless children that don't let you sleep at night, and then have sleep deprivation that doesn't let you focus during the day.
• ...get an ear infection that baffles the sounds and prevents you from hearing your phone.
• ...have common migraines that cause you to have "clouded vision" and short attention spans.

There are surrounded by examples like these. Every day. Everywhere. Pay attention, and you will start noticing them more and more.

Some people may think now:

Those are disabilities! Also, that's great... but that's not me. I have never broken a bone, and I don't plan on having kids, and I have loud ringtones... Oh, and I will stay young forever, too. So Web Accessibility doesn't apply to me.

Great confidence there, but that's wrong. Even if you are a fully healthy individual, you may find yourself in situations where Web Accessibility will help you. For example, using your laptop outside and the reflection doesn't let you read, wouldn't you want more contrast? Camping in the forest and the key images for the "what to do when a snake bites you?" article timeout or don't load correctly, wouldn't you want an alternative text that would help you?

There are many more examples like that: people in remote areas with low connection, people with not state-of-the-art computers and phones, granny asking you for help because the text is too small to read... Don't underestimate the reach of Web Accessibility.

Automatic tests are enough for accessibility

Automated testing for accessibility is possible and highly recommended. But it is not a replacement for manual testing: automatic tests only detect ~30% of the issues.

Even if we can simulate a user's behavior with the keyboard and tab, check for color contrast, or a specific HTML structure, there are still tests that we cannot automate and behaviors that we cannot simulate. Thus, limiting the capacity of what automated tests can do.

This is not to say that we should drop automatic accessibility tests. On the contrary, we should embrace them and use them in all our projects. It is important to remember that they complement and not replace good old manual testing.

Overlays are enough to ensure Web Accessibility

This is more a misconception among executives and people who make decisions about buying these types of solutions. The consensus in the Accessibility community is almost unanimous: overlays don't work. None of them fully work.

An overlay is an automated technology aimed at improving the accessibility of a website. It may come in many flavors: plug-ins, add-on libraries, toolbars, widgets... but their functionality is similar: modify the page's source code on the fly and repair the non-accessible code, replacing it with an accessible version. Something really tempting at an affordable price and with just a single line of JavaScript.

One line of JavaScript does not make a website 100% accessible. In some cases, the results may even be damaging. And all for just a little benefit, as people with disabilities already use tools that fix many of the issues that the overlays claim to fix.

As we mentioned in a previous section, there is no one-size-fits-all solution for Web Accessibility. And that's exactly what overlays try to be.

Things may change. While accessibility overlays may not be enough to ensure Web Accessibility at the moment, with the advances in AI and machine learning, they might become an alternative in the future. But currently, they aren't a solution.

HTML is accessible by default

We've heard many times developers say, "HTML is accessible out of the box," almost as if the definition of HTML in the dictionary was:

HTML
Accessible.

But that is not always the case. There are HTML elements that are not accessible by themselves or may present challenges to the users.

For example, elements like <video> or <audio> have controls that are not fully keyboard-accessible and that differ considerably from browser to browser and cause frustration. Or the <input> element has many types that open pop-ups, which may not be accessible for everyone.

There are many components and structures that are not native HTML elements (e.g., tab panels), and once we start combining HTML, accessibility issues may pop up from the interaction.

The definition of HTML in that imaginary Hitchhiker's Guide to the (Web) Galaxy should be updated to something more appropriate:

HTML
Mostly accessible.

That looks much better, and it is definitely more accurate to reality.

No ARIA > Bad ARIA

Before all accessibility experts start crying foul and cursing my name, let me clarify something: No ARIA is better than bad ARIA. ARIA is not supported by all browsers/screen readers, and it should be a last resort. The way to go should be using semantic HTML when possible.

Unfortunately, using semantic HTML is not always possible and not enough to cover all the cases needed for a good experience. For example, there are widgets and patterns (e.g., tab panels again) that cannot be done using semantic elements and, in those cases, ARIA is a must.

ARIA (an acronym for Accessible Rich Internet Applications) is a set of attributes used within HTML tags to make content more accessible. It supplements the HTML elements and provides assistive technologies with extra information that would not be available otherwise. But, if developers don't use these attributes correctly, the additional information they provide may be confusing and harm the user experience.

The myth/misconception of "No ARIA > Bad ARIA" is that it leaves out an important part of the equation: where does "Good ARIA" go? And the answer is actually quite simple:

We can all agree that bad ARIA is bad. But no ARIA isn't ideal either: the solution to providing a bad experience (bad ARIA) should not be providing a subpar experience (no ARIA). There should be a good experience too!

If a kid is learning to ride a bike and struggles and falls, we don't tell them, "stop! don't ever ride a bike!" Instead, we teach them. We encourage them to keep learning and trying... until they can do it by themselves.

"No ARIA > bad ARIA" perpetuates a false dichotomy. There's good ARIA, too. And we can learn ARIA, practice ARIA, improve ARIA... We won't be good at the beginning, but we will get better and provide a better experience with time and practice than with no ARIA.

Prefers reduced motion means no motion

This is more of developers' good intentions based on a misconception. We (myself included) found an option to reduce motion, and we "brute-force" our way through it, cancelling all transitions and animations like this:

@media (prefers-reduced-motion) {
  *, *::before, *::after {
    animation: none !important;
    transition: none !important;
  }
}

Not everything is black or white. There are many shades of grey, and not all animations and transitions are bad. Some of them are worse than others.

We don't need to cancel every motion on a website. Instead, we need to think through them, check what's appropriate and not, and provide an expanded/animated experience for everybody.

In An Event Apart, Val Head had a great presentation about accessibility and animation. In the video, she explains different animations and transitions and which ones are better when trying to avoid triggering a negative reaction: color changes, opacity fades, small movements...

Also, related to this myth, reduced motion applies to more than just animations and transitions: background videos, animated GIFs, or scroll behavior are examples of things that need changes when the user opted for reduced motion. So let's not forget them.

Thank you Todd Libby, Laurent Denoue, Cristian Diaz, InHuOfficial, and Maciej Pędzich, for all your insights, feedback, and (constructive) criticism when writing the article.

Cover image by Mike Hindle on Unsplash.