Hi everyone!
Today I am going to discuss about a topic very close to me:
Accessibility (or a11y for short).
I have worked a little over one year in the Accessibility team, experience that helped me grow, both personally and professionally.
I have recently moved to another team, so before I will partly override what I learned with new information, I though to flush out the main memory on the disk and write down the main pointers for later reference.
Hopefully with this post I am going to to kill two birds with one stone, both document and share couple of lessons learned.
Quick introduction before we start, what is Web Accessibility?
From wikipedia:
Accessibility refers to the design of products, devices, services, or environments for people who experience disabilities.
Specifically web accessibility, refers to the design of web experiences available to ALL the users.
I think there is something strange with the previous definition.
Can you guess what I mean? Little clue, the word has been emphasized.
The weird part is that the definition specifies that a web application is Accessible if can be used by all our users.
Let's think about it for a moment. We are about to build a new awesome web app, how a requirement for it would look like?
Customers must be able to sign in the web app using an email and a password...
We say Customers, but we really mean all the customers willing to use our app. All is implicit.
Clearly we do not want to restrict our app to part of the customers? Do we?
Unfortunately, this is exactly what happens when we start our project neglecting Accessibility. We close our app to lots and lots of customers.
Before we start, let me define some of the terms I am going to use throughout the article.
- assistive technology (AT for short): an umbrella term that includes products, equipment, and systems that enhance learning, working, and daily living for persons with disabilities. In the context of the web, this means tools like screen readers, magnifier, head pointers, etc.
- screen reader: Software used by blind or visually impaired people to read the content of the computer screen. Examples include JAWS for Windows, NVDA, or Voiceover for Mac.
- magnifier: Allow users to control the size of text and or graphics on the screen. Unlike using a zoom feature, these applications allow the user to have the ability to see the enlarged text in relation to the rest of the screen. This is done by emulating a handheld magnifier over the screen.
- Head pointers: A stick or object mounted directly on the user’s head that can be used to push keys on the keyboard. This device is used by individuals who have no use of their hands.
With that being said, let's start!
1 - Design your application with Accessibility in mind from DAY 1.
This means couple of things:
Favor simple design over complex UI.
This does not mean you can't add dropdown,
carousel, etc. This means that the user must be able to navigate the page without loosing context of where he/she is.
People with cognitive impairments might have issues following long chain of widgets or popups (by the way, try to avoid pop ups, more on that later).
Same for screen reader users. Overall a simple design does not just help AT customers but also non AT customers, which are going to find the experience much more fluid.Mind the contrast ratio. According to colourblindawareness color blindness affects approximately 1 in 12 men (8%) and 1 in 200 women in the world . It's a lot of people, lots of customers.
There are lots of tools out there which can help with that (Google has a dev tool that among other things check for contrast ratio).
It's really a low hanging fruit.
2 - Try to use HTML native elements
Screen readers describe the context to the user, using metadata associated with the element.
This means that if you use an anchor or a div to create a custom button, the screen reader has no way to detect that's a button, which implies that the user does not know how to interact with the element.
If you really have to use a div for your button, be sure to use the role attribute which adds context to element.
This is not enough though, you also need to take care of keyboard navigation and focus.
For native HTML
buttonelements, the button's onclick event will fire both for mouse clicks and when pressing Space or Enter, while the button has focus. But if another tag is used to create a custom button, the onclick event will only fire when clicked by the mouse cursor, even if role="button" is used. Because of this, we have to add a separate key event handler to the element so that the button can be triggered when the Space or Enter key is pressed.
<span role="button"
tabindex="0"
onclick="handleBtnClick()"
onKeyPress="handleBtnKeyPress()">
Save
</span>
The takeaway here, is that it might be a lot work to transform a custom element in one that behaves like a native one. So use a native element whenever you can. If you don't like the look && feel of the element, style it.
On this subject, the mozilla developer guide is invaluable.
It might look like a lot to read...well, it is. But bear with me a little longer.
See, I really think that reading all the Mozilla docs or the W3C accessibility guidelines is not required to make a web app accessible.
Instead, a more sensible and scalable approach is to look up in the guidelines the suggested approach for what you are about to build.
3 - Test the page with different magnification factors
How does the page look like when a different magnification factor is used?
Does the text scale accordingly? What about the page structure?
Many users need to use a zoom factor or a magnifier to be able to read the page.
The only way to actually verify how the UI behaves is to test it out.
4 - Use headings
Communicate the organization of the content on the page using headings from the highest rank h1 to lowest h6.
Assistive technologies like screen readers, allow to navigate between them, providing an effective way to skip entire sections of the page.
If something is an heading, use one instead of styling normal text to look like an heading.
5 - Use new html5 elements
Similarly to headings, the new elements header, nav, main, and footer provide the ability to designate sections of the page.
The elements provide additional information to screen readers, which also support the ability to navigate/jump through them.
6 - Announce page changes
Modern web apps are built to react to internal or external events. Some examples:
- Add to cart button changes the status of the cart showing the number of elements in the cart
- A new email received causes an update to the notification bar to show the number of mails to read
- New message in a chat application
All those examples have something in common: the web app react to an event by dynamically changing parts of a page without requiring the entire page to reload.
While these changes are usually visually apparent to users who can see the page, they are not to screen reader users.
How can we fill this gap for our users?
Enters ARIA.
ARIA defines markup extensions (mostly as attributes on HTML5 elements), which can be used by the web app developer to provide additional information about the semantics of the various elements to assistive technologies.
In this case, an Aria live region can be used.
var result1 = 0;
function update1() {
result1 = result1 + 1;
document.getElementById("result1").innerHTML=result1;
}
</script>
</head>
<body>
...
<div id="result1" role="status" aria-live="polite"></div>
<div>
<button onclick="update1();">Update result 1</button>
</div>
...
</body>
There are tons of examples on the web, pasting here a link for quick reference:
example.
7 - Get to know ARIA
In the previous section I mentioned that ARIA helps us to provide additional information to assistive technologies.
It's an W3C Recommendation, which means that there might be variation in the implementations among browsers and assistive technologies.
My experience on ARIA is of a project pretty mature and well received by the industry.
For many people in this field way more prepared than me, ARIA is going to become a standard pretty soon.
Again, you do not need to read all the ARIA guidelines before starting building you web app, instead use it as a reference.
There is one important rule to remember while using ARIA:
The first rule of ARIA is...do not use ARIA
This is the exact some concept mentioned earlier about using native over custom elements.
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
8 - Avoid the pop up trap
ME: I have added a pop up to the app for the login, it looks so cool!
Couple of hours later:
Issue 1: The pop us is not announced by the screen reader so the customer has no idea how he ended up in the login page
Issue 2: Pop up announced but the focus is still on the background page. Customer can not insert his credentials
Issues 3: Focus is in the pop up, but the Customer is not able to exit. He is trapped in the popup until he refreshes the page
I don't know about you, but I was ready to give up on pop ups after the second issue.
Joke aside, if you really need it, check if the library you use to style the app already provides accessible pop ups.
Otherwise stay away from them unless you are willing to spend a significant amount of time on making an accessible pop up.
9 - Provide an alternative text
Do not forget to add an appropriate description of the image in the alt attribute.
On the other hand, when an image is used only for decorative purposes (think about a line separator, background images, etc.), add an empty alt attribute alt="" or remove the image from the page content and add it as a background image using CSS.
When dealing with a complex image, such as a chart or map that cannot be described in a couple of lines, then the alternative should be provided elsewhere through longdesc.
10 - Test the Web app with a screen reader
It might look like I am stating the obvious, but I think it's important to point out that like any other piece of code we write, if it's not tested, it does not work.
Download the cheat sheet for Voice Over (JAWS if you are a windows users), put your headset on, start the screen reader and close your eyes.
Experience what it is like to navigate the website using the keyboard without looking at the screen.
Check that you can reach any part of the page, you can skip sections, there are no focus traps, etc.
Conclusions
Thanks for reading this far. I might have forgotten something, in which case I'll write a follow up post.
Please comment and share your experience to make this check list even more A11Y awesome.
Thank you!
Top comments (2)
Thanks for sharing, I started to learned and implementing a11y around 6 month ago. I feel really close to this subject. Any advice on how to make understand all stakeholders about the benefits of A11Y (UX UI teams, clients… etc.)?
Hi! Thank you!
One of the most effective way is to organize an Empathy lab.
Get an eye mask and an headset.
Ask the users to wear them, start the screen reader and then guide them through the experience of navigating the web app.
For many people, the experience is illuminating. Before that, they had no clue about what it really means for blind customers to navigate the website.
They are gonna feel all the discomfort of a website which did not take into account
ALLthe users.Such experiment is designed to underline the difficulties of visually impaired customers, but similar experiments can be done also for physical impairments (i.e. ask people to use a pointer stick held in their mouth instead of typing directly on the keyboard).
Even though A11y is just the right thing to do, you know that everything in business is a trade off, so you still need to support your claims with data. How many people suffer some sort of visual impairment (color blind, partly blind or completely blind) ?
Same goes for other type of impairments.
The numbers unfortunately are really big and so it is the loss of income for the company that is neglecting A11y.
-Nicola