Let’s P.O.U.R. it all out in A11y
I recently attended the a11yTO 2020 camp where many well respected people in the accessibility world are there to share their knowledge and vision to all developers new and old. All of the talks were great but there was one specific talk that interested me the most...
Ashleigh Lodge’s Talk about ‘What is Accessibility & Why Does it Matter?’ sparked my interest in how Accessibility works and how Inclusive Design can help achieve that goal. The talk started with all of us asking a question on how many Canadian’s do you think have disabilities? At first, I thought there were not too many, probably about 5% to 7%. Well I was wrong! 1 in 5 Canadians aged 15 and over, had one or more disabilities. It was surprising to me that more than 20%(around 6.2 million) Canadians have some kind disability.
This raised a question on how can we help a PwD go around the web? It directed me to WCAG 2.1 and it’s four guiding principles: Perceivable, Observable, Understandable and Robust. These principles are the guide in understanding digital accessibility.
We are going to go over each of the guidelines to help us understand the things that developers need to keep in mind before creating an application.
“Our goal is to make sure our website, apps, and services don’t disable people.” — James Knight
Perceivable
Let’s start by talking about perceivable. It is the first step and the foundation to the other three principles. How can you operate or understand it if you can’t perceive it?
You want to ask if your application is perceivable by all users, including those with low vision, those who are blind and/or those who are deaf or hard of hearing.
All input to our brains come from one or more senses: smelling, seeing, hearing, and touching. Think of how a person with no vision can access information that a sighted user can see visually, they’d have to use other senses, such as hearing. One of the tools that are always used to help in this case are Screen Readers. It is a device that literally reads out the underlying code so a person with visual impairment could access the site. This brings us to the importance of Semantic HTML.
To achieve web accessibility a site needs to have proper semantic HTML. This can help users that need screen readers to perceive the site properly. To get a proper idea on how important proper semantic HTML is for non sighted users, here are a few examples:
- A screen reader announces specific elements such as buttons and headers along with their level (h1, h2, h6, etc.)
- For images, screen readers attempt to read out a description of the image (alt text) if one is provided. If not, the file name of the image is used instead.
- Most screen readers ignore non-semantic elements, such as divs and spans.
Another big aspect of perceivable is colour contrast. Many people are colour blind or have low vision. In order to have accessible content, a site needs to have great contrast between the background and the text. In WCAG 2.1 level AA the standard colour contrast requires a ratio of 4.5:1. There are plenty of references to help you check the contrast ratio.
Observable
Next up in the 4 guideline principles is Operable. When you are browsing the web, what do you use to move around online? I would probably be right if I said using a mouse or tapping on the screen, and when you need to insert something you use your keyboard.
Operable refers to keyboard accessibility, since most of the assistive devices mimics keyboard functionality. By disconnecting your mouse and navigating around online using your keyboard you can test if a site is operable. Let’s try it out and check if your favourite site is operable:
- Is it always clear where you are on a page (i.e., the focus state)?
- Can you interact with all the controls you normally would — things like menus, buttons, and drop-downs?
- Is it possible to skip irrelevant or repetitive sections easily, such as the header or navigation, via a skip link (“Skip to Menu”)?
- And what about hotkeys?Like using the backspace key instead of the back button.
If you went through a site and it was easy for you it will be well operable for people that have limited mobility.
There are also other cases where operable guidelines are needed. For example, giving users control over timing and time limits. Consider the situation where you’re trying to buy tickets to watch your favourite rapper and there’s a time limit on the process. Now think about the experience of someone with a cognitive disability who has a slower response time. And what if they’re also using an assistive device (screen reader), which could also increase their response time. They might end up not seeing their favourite rapper perform all thanks to the time limits *cough* TicketMaster *cough*.
Understandable
After making the content perceivable and operable to a wide variety of users, now we have to make sure that all users can understand it. A few questions you want to ask:
- Is your language too esoteric
- Is your functionality obscured by the use of non-standard icons?
If your answer is YES, then you might need to change some things in your content to make it understandable.
Basically, you don’t want to use a long word when a short one would work just as well, probably even better. For example, instead of saying additional, say added. Instead of contains, say has, and rather than expiration, just say ends.
Functionality is the other one that needs to be understandable. An example of this is the hamburger menu; at some point, it became the icon that represents the menu. Users became familiar with this icon and it became a standard icon for the menu bar. If you decide to do something unique and change the hamburger icon to a banana icon it might confuse your users, which can create a problem in the understandability of your content.
Robust
Finally, we have robust! There is only one big question to check if a website is robust. Can users choose their own technologies, including devices, browsers, and assistive technology?
The key for being robust is that unless there is a critical compatibility issue, everything should just work. Users need to be able to choose their own technologies in order to meet their own unique needs. This doesn’t mean that you must support every version of every browser out there *cough* IE *cough*, however, you shouldn’t be too restrictive.
Hopefully this shed some light about the guidelines that needs to be followed to create an Accessible Website, Application or Service.
Fun Fact: A11y — 11 in A11y, means the number of letters in between A and Y in the word Accessibility. A ‘ccessibilit’ y
Reference: