According to several reports compiled after 2018 (it is only recently that companies have started to think about the users they lose due to non-accessibility), millions of users worldwide still cannot read the content on websites properly.
Know what that translates to? Millions of users who cannot read the content on websites equate to millions of users who will not, who can not engage with your website, simply because the website does not cater to them.
Whether you’re starting to build your website, or if you’re in the same boat as the people who have built websites without accessibility features, this article will have something for you.
Before moving on, let us first understand what accessibility means in terms of websites.
What Makes A Website “Accessible”?
There are no gray areas here: it’s all black and white. There is a forum known as the Web Content Accessibility Forum, and this publishes the WCAG (The Web Content Accessibility Guidelines).
The Web Content Accessibility Guidelines are updated from time to time and include different versions, such as WCAG (the international standard), WCAG 2.0, WCAG 2.1, WCAG 2.2, and the latest, WCAG 3.0.
The reason that these different versions have been released is that each is specifically tailored to specific disabilities with the international standard being the most general of them all.
When people say the word “WCAG”, they are most usually referring to the international standard, which, for now, is WCAG 2.1.
Here’s a summary of the super-long, jargon-rich WCAG guidelines. For a website to be accessible it needs to meet certain features. These features go by the acronym POUR, which stands for:
- Perceive: A user should be able to perceive all content on your website. To do this, developers need to cater to the senses of sight, hearing, and/ or touch (haptics) if applicable.
If you use non-text content (such as images), use the [alt] attribute to define all non-text content so that it is accessible to people who cannot see the content (sight issues, slow internet, etc).
- Operable: To make a website operable means that all of its functionalities (navigation, interaction, etc) should be possible from the keyboard, to make it easier for people to access the functions of the website.
- Understandable: This is where the “gray area” that I mentioned earlier comes in: your content needs to be accessible, yes, but what it means to make your website understandable is that all elements (across pages) are used consistently. This includes things like calls to action, directional/ navigation cues, buttons, etc.
At a single glance, a user should be able to identify the navigation scheme of a website. If it takes longer than ten seconds, it’s too complicated.
- Robust: And now for the greyest of gray areas: The content of your website needs to be clear enough that it can be perceived (see point one) by the maximum number of users and user agents, which includes accessibility and assistive technologies (such as text to speech readers).
And that’s pretty much it. If you want more data-heavy answers pertaining to the WCAG guidelines, here is a link base for you to do just that:
- WCAG: The Principles Of Accessibility
- WCAG 2.0 Standard (December 2008)
- WCAG 2.1 Standard (June 2018)
- WCAG 2.2 Draft (May 2021)
- WCAG 3.0 Introduction (Working Draft – Recommendations for the future up until ~2027)
Without further ado, let’s get into how you can make your website more accessible with features that are native to the JavaScript framework.
How To Make Websites More Accessible With JavaScript
Use Semantic Elements
Semantics is the study of words and their meanings, thus, semantic elements are those elements that have a meaning.
Semantic elements improve accessibility to a great degree, and here’s how you can use them:
- Make proper use of the <nav>, <article>, <footer>, <header>, etc. tags, because non-semantic tags like <div> and <span> do not tell us anything about what the purpose of the element is.
- Use descriptive attributes (such as the <alt> tag wherever possible, e.g. for images.
- Use the language attribute to define a website’s main language. If there is another website language, remember to specify that with the correct attribute (e.g. <blockquote lang=”fr”>).
Focus On The Design
It’s a smart move to alter, or re-arrange your website’s elements to make them more accessible. Elements to consider redesigning are:
- The Orientation: don’t “lock” the orientation to any particular mode (different people have access to different devices with very different aspect ratios from each other. Your website should look, feel, and most importantly, perform the same on all of them.
- The text: Do not, under any circumstances, use low-contrast text, no matter how good it may look to you. A lot of people have vision impairments or difficulties with color, so high contrast, neutral colored text is the way to go for maximum comprehension on the part of the user.
- Do not space out your labels and input fields as this may create a lot of problems for assistive technologies, the zoom function, and even visually impaired users.
JavaScript makes it super easy to incorporate these changes, even if your website is already up and running. If going through a redesign, it may be worth hiring an accessibility professional, just to get an appraisal of the website.
Use the Aria Tags
ARIA stands for Accessible Rich Internet Applications and is specific to AT (Assistive Technology) users, e.g. screen readers.
<Aria> is one of the few accessibility attributes that was developed specifically for the purpose of making websites more accessible.
Developers should use <aria> to create semantic elements that would not normally be possible with standard HTML. For Example, a developer can make a widget-resembling element by using the code
<button aria-label=”Voice to text only label”></button>
Developers can also use <aria> to do things like auto-check a checkbox with an element like <aria-checked> or use the role tag to specify what it is exactly what an element does.
This makes the job much, much easier for people who use ATs, because using semantics with <aria> makes the ATs that are used quicker and snappier (reduces lag time).
Incorporate Device-Independent Event Handlers
When designing our applications, hire Java developers who may want to play around with trigger specific events such as <dbclick>, <mouseover>, and <mouseout>.
Essentially, these events are the kind that allows the end user to run certain functions when certain criteria (the trigger events) are met. More often than not, these events can pose significant accessibility issues for users.
For instance, what if one particular user cannot perform (for whatever rhyme or reason) the device-dependent task that triggers the function on your website (e.g. expansion of the size of a particular thumbnail image).
You can mitigate the risk of the batch of end users not being able to trigger the function that is device-dependent by either replacing it with a device-independent event handler like <focus> or <blur> or by incorporating both kinds of handlers into the code.
Examples of device-independent event handlers would be <onfocus>, <onblur>, <onselect>, etc.
According to the American Center for Disease Control, one in every four Americans suffer from a major disability that affects the way they live.
That’s a lot of people that need catering when they view your website so that their UX (user experience) is not hampered.
There are other ways to incorporate good UX practices into your website that do not require re-coding but let’s save that for another day.
For now, we hope that this article is enough to get you started on your accessibility journey.