Imagine the perfect setting for reading a book. In my case - snowing outside and laying on the couch close to the fireplace with a hot cup of tea next to me. You open the long-anticipated new novel by your favorite author and… the pages are blank. What? The frustration builds up as you really wanted to dive deep into the adventures of the protagonist, but you can’t.
Now you know how it feels when a person with a disability tries to use your non-WCAG-compliant website.
This is an example of a visually impaired person who uses assistive technology to browse the internet. Web accessibility covers a wide spectrum of disabilities that should be taken into consideration - blindness, color blindness, deafness, low vision, cognitive disabilities, seizure disorders, and others. And, as you can imagine, each and every type requires a different solution. Usually, in order to figure out the impact, people often rely on statistics.
Unfortunately, there isn’t a reliable and unified approach to gathering such data worldwide, so I can’t really give you a number - but that’s not what is important. Something a lot of people miss out on is that there are also temporary disabilities that everyone can experience, like having surgery. And what happens when you push your baby in a stroller? You can’t really climb stairs, can you? What about looking at your phone in direct sunlight - wouldn’t a better color contrast help?
Now you know that making sure people with disabilities can access your website and fully use it helps healthy people in different conditions. But the benefits don’t end here. Accessibility greatly improves your search engine optimization, therefore increasing your reach and customer base. And last but not least - you’ll save money from lawsuits. Depending on the country and sector you operate your platform, you should comply with different laws and standards. You can find more information on the W3C website under Web Accessibility Laws & Policies.
If you’ve read up until here, that means that you are willing to make your website more accessible; good for you! Now, let’s talk about how to spot issues and fix them. The industry standards (WCAG) are created based on four principles: Perceivable, Operable, Understandable, and Robust (or POUR).
Perceivable - this stands for all biological ways we can gather information - sight, sound, smell, taste, and touch. For the scope of web accessibility, we will look only into sight, sound, and touch. For easier understanding - imagine you lack one of those senses. Note that this is not the full picture, as we can’t cover all of the cases, but the goal is to help you understand how to approach accessibility web development.
If you can’t see the website you should be able to hear it via assistive technology. That means that the site should be structured in a way that the reader can go through it in the proper order and be provided with all of the visual information - like images, videos, etc.
If you can’t hear - then you should get all of the data only through your sight. That means that we should use captions when there is audio content.
If, unfortunately, you can’t either see or hear - then your web experience will go through the fingers. The same text that would have been narrated is now converted into braille characters - three-dimensional figures that can be easily distinguished by touch.
So, to sum it up - you should be able to deliver all of your content in at least two ways.
Operable - this means that the platform you are building is interactive through all sorts of input sources - pointer (mouse, mouth stick, head pointer), keyboard (onscreen and physical), touchscreen, voice recognition, etc. I know it is impossible to cover all of the input mediators, so what should we look for?
Focus - you should be able to traverse the whole website via the ‘TAB’ button and the focus styling should be in place. When there is a popup, - the focus should automatically switch to it. And when you finish, - it should switch back to where you were.
Timing - as you can imagine, the different input devices require a different amount of time to do the same operation. Therefore, if there is anything related to time to complete (some animation/rotation, etc.), - you should consider slowing things down or making it possible to pause.
Understandable - as a non-native English speaker I can fully understand the pain of listening to an English text-to-speech bot butchering words of my language. That’s simply because the bot doesn’t understand that the language it tries to read isn’t English. And this is as simple as <html lang="bg">. If your site lacks this line, - it becomes unusable for everyone whose assistive technology fallback language isn’t the same.
To make the platform more understandable, there are good practices that should be followed when you try to point out what the user is expected to do - whether it is a guide or a required field validation error message. Just imagine you’ve never seen a website before, you haven’t filled in a form, etc. Do you think that the user can quickly find what they are looking for and go through the whole flow?
Robust - every person has their browser of choice. Whether you use Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, or any other modern browser - you’ll get similar results. The key word here is ‘similar’. The same goes for assistive technologies such as readers. Since we want the same experience across the board, we need to make sure our platform is ‘robust.’.
We can do that by:
- Using semantically correct HTML tags. Running an HTML/CSS validator to make sure everything is fine is always a good idea. This point, as simple as it looks, is extremely important! Almost every tag has some specifics, and here are some examples:
- Having a meaningful <title>
- Create landmarks using <header>, <footer>, <main>, etc..
- Headings should be used as such - not just for the styling. And please - use only one <h1> per page. If for some reason you shouldn’t use <h1> you can achieve the same results for screen readers by having: role="heading" aria-level="1"
- Even text formatting should be done with <em> and <strong> and not only CSS.
- Using Accessible Rich Internet Applications (WAI-ARIA). The WAI-ARIA properties provide the client with further information on what the field role is (i.e. navigation), what properties it has (i.e. required), and what is its state (i.e. disabled). Since the page changes when we interact with it, - so should the WAI-ARIA properties. This can be achieved with JS so the values reflect what is actually on the screen.
