Why Do We Need to Care About Accessibility?

Accessibility is a sensitive topic when it comes to the web. A lot of times people think it’s not worth the effort and time to make a website accessible, but failing to do so, can really hurt user experience and can even cut down your userbase.

Get access to 300+ webtips 💌

Level up your skills and master the art of frontend development with bite-sized tutorials.

We don't spam. Unsubscribe anytime.

Get Access to Webtips

---

Do you really need to care about accessibility?#

If you’re thinking about right now whether you need to care about accessibility or not, I could say you do because you already thought about it, but the answer depends on your current situation. If you’re developing an internal tool for a company that will be used by 20 other developers, then it’s easy to see that accessibility won’t be your top priority and that’s fine, but if you’re selling products to a large userbase all across the globe or serving content to people all over the internet, then it’s definitely worth to think about it.

According to the World Health Organization (WHO), 15% of the world’s population lives with some kind of disability, that’s over 1 billion people who can potentially have issues accessing and using your site. Making your website easier to navigate and more understandable to users not only means that you are helping the disabled but it also caters to the elderly. Not to mention that by increasing your accessibility ranking, you also enable search engines to find your site easier which helps with your SEO ranking as well, helping your business along the way. Overall it has positive effects on several aspects.

Looking to improve your skills? Check out our interactive course to master JavaScript from start to finish.

Remove ads

---

What Accessibility Is Actually?#

To make our website accessible, we first need to understand what accessibility is. Simply put, web accessibility is the practice of ensuring that there are no barriers that prevent interaction with or access to websites and their content by people with disabilities. These disabilities can be things like:

• Visual impairments (including blindness)
• Motor, mobility (difficulty or inability to use the hands, eg.: Parkinson’s disease)
• Auditory (deafness or hearing impairments)
• Seizures (photo epileptic seizures caused by visual strobes or flashing effects)
• Cognitive disabilities

Now that we know what we mean by web accessibility, we want to know what to look after to actually make our sites more accessible. Luckily, we have a really handy document that explains it in great detail. It is called the Web Content Accessibility Guidelines or WCAG for short. WCAG builds up from four different categories and these categories are broken down into further subsections. They are in order:

Perceivable
Information and user interface must be presentable to users in ways they can perceive.

• Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language
• Time-based Media: Provide alternatives for time-based media (eg.: caption video, sign language provided, audio provided)
• Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure
• Distinguishable: Make it easier for users to see and hear content including separating foreground from background

Operable
User interface components and navigation must be operable.

• Keyboard Accessible: Make all functionality available from a keyboard
• Enough Time: Provide users enough time to read and use content
• Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions
• Navigable: Provide ways to help users navigate, find content, and determine where they are

Understandable
Information and the operation of user interface must be understandable.

• Readable: Make text content readable and understandable
• Predictable: Make Web pages appear and operate in predictable ways
• Input Assistance: Help users avoid and correct mistakes

Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

• Compatible: Maximize compatibility with current and future user agents, including assistive technologies

This list is not extensive by any means. If you are interested in further breakdown, you can refer to the official documentation from which this list is taken from.

These are the outlines that we need to think of when designing a site or an app with accessibility in mind, but what are the steps we can take in our code?

Get access to 300+ webtips 💌

Level up your skills and master the art of frontend development with bite-sized tutorials.

We don't spam. Unsubscribe anytime.

Get Access to Webtips

---

How to Improve Accessibility?#

We saw with WCAG what are the outlines for web accessibility. The only question left to ask is how can we practice it in code? This is where WAI-ARIA, the Accessible Rich Internet Applications Suite comes into place. It defines a way to make the web more accessible to people with disabilities by introducing a new set of HTML attributes that can be applied to elements to provide additional semantics and to improve accessibility wherever it is lacking. There are three main features defined in the spec:

Roles
These define what an element is or does. Many of these roles largely duplicate the semantic of an element. Take the following for example:

<nav role="navigation"></nav>

We have a navigation element. In itself, it already describes what it is, so adding the role attribute only duplicates the semantic.

Properties
Properties can be used to give extra meaning or semantics to elements. Take the aria-labelledby attribute as an example:

<span id="contact-info">Contact info</span>

<span id="email">Email:</span> <input type="email" aria-labelledby="contact-info email">
<span id="name">Name:</span> <input type="text" aria-labelledby="contact-info name">

Unlike with the <label> tag, you can specify multiple ids for the aria-labelledby attribute and use it in place of a <label>, when using that is not appropriate.

States
These are special properties that define states on elements. Take aria-disabled="true" as an example this time. It tells a screenreader that an input is currently disabled. The difference between properties and states is that states can change throughout the lifetime of your application, whereas properties stay the same.

It’s important to mention that aria attributes will not affect your page’s structure in any way. It will only provide additional information about your site to assistive technologies, the browser and to search engines that crawl your page.

Where can you use WAI-ARIA?
Nowadays most sites are flooded by interactivity. We have sliders, carousels, tabs, and many other ways content can be presented. These are usually achieved through JavaScript with lots of divs and spans. Navigating through these with a keyboard can be challenging if measures have not been taken from accessibility side. Luckily, ARIA provides a means to allow elements to receive focus with the tabindex attribute. This can help enhance interactivity and navigation through content for screen readers and keyboards.

Accessibility can also suffer for non-semantic controls, for example when building complex user interfaces. Using additional aria properties and states can fill these places where accessibility is lacking.

It’s important to mention that you should only use WAI-ARIA when you need to. Instead, you should always use native semantic HTML elements by default to provide the semantics required by assistive technologies. (When we are talking about semantic elements, we mean “elements with a meaning”.)

Semantics is the study of the meanings of words and phrases in a language

I would like to close this article with a number of great tools that will help you achieve a higher level of accessibility and will take your site to the next level.

Lighthouse
Lighthouse is built inside Chrome’s DevTools, you can access it through the “Audits” tab. Apart from measuring accessibility and giving you hints on what to improve, it also tests your site for performance, SEO, PWA, and best practices. You can test your site for not just desktop but mobile devices and it also enables us to simulate slow network connections, which can give you a more accurate look on how an average user gets your site served. You can also download audits and import them later which is great for doing comparisons once improvements have been done.

Webhint.io
Webhint.io is another great site for checking for accessibility issues on your site. Just like Lighthouse, it also does tests for other categories apart from accessibility and also gives you hints on what is the reason for the failed test and how you can fix it. You can either use their online scanner or use their CLI to run tests right from your command line.

Axe, the accessibility engine
If you rather want to run audits right inside your site, but you want to complement Lighthouse with another tool, then Axe is for you. Just like the other two, it comes with a detailed explanation of what caused the issue and how to resolve it, with an “impact” category, so you know what are the criticalities that should be top priority. Another great feature of it is that you can highlight the related element on your site or inspect it in the dom tree.

Combining these three tools and using them on your site will help you elevate your accessibility game to the next level and make your business accessible to anyone. 📈