How to build inclusive websites using the least effort
Maggie and I started working together months ago when I had this certain project and I had to get her help and collaborate with her to get it done. Maggie is the one who sparked the awfulness of the WEB for people who cannot use the WEB as regular users do. After I get to know her, I realized how painful is to navigate websites to just run my daily chores. I could no longer buy from Amazon within 5 seconds, or watch my favorite show lightning fast. When I add something to my cart, I had to go and navigated my cart to see if it was the correct item. I couldn't just know with a glance of eye anymore.
That was the time I realized we are not building the Web as it supposes to be. Tim Berners-Lee invented the Web to be universal and accessible by everyone, as he says:
You may say, not many people in the world really need these features, why should we spend time thinking about accessibility? We need to deliver projects as fast we can and we don’t have time to put accessibility features on the top of what we need to do.
To be honest, I was thinking the same way, so I started digging the numbers. I find an article in Wikipedia titled “World report on disability”. According to this article, the number of people with disabilities is more than one billion which is about 15% of the world population.
“More than 1 billion persons in the world have some form of disability. This corresponds to about 15% of the world’s population. Between 110–190 million people have very significant difficulties in functioning.”
When we look at 15% as the percentage of people with disabilities, we may think this is not much, my website is going to work for 75% of people and that is great. But when I compared 15% of the world population to tangible and relative numbers, here’ s what 15% of the world’s population is equal to:
15% of the world population at the moment ~ 1.155.000.000 ~ 1.1 billion
= Europe + the USA
= North America + South America + Japan
I was very surprised how large this number is,
Do we want to develop websites when mostly all Europe and the USA cannot use it?
Definitely, not.
I still thought I need to do extra work to my features accessible. But that was not it at all. Here I want to walk you through steps you can take to make your web features seamless for everyone, even for people without a disability, with no extra effort or time.
Before we move further let’s define some terms:
#A11y
When I started learning about accessibility there was one word that I use to hear all the time and had no idea where it comes from, and that was A11y.
A11y is a numerical contraction for the word “accessibility”. There are 11 letters between the a and the y in the word accessibility, hence a11y. This term is generally only used to refer to web accessibility, and we’ll use it in this post because typing out “accessibility” every time is kind of a drag.
#AT
AT stands for Assistive Technology. It is a piece of equipment, software program, or product system that is used to increase, maintain, or improve the functional capabilities of persons with disabilities.
As a Web developer the three main AT that you need to know about:
- Screen Readers
- Screen Magnifiers
- Alternative Input devices
Remember Maggie? She was my screen reader on my laptop.
Where should we start?
Before we start looking at best practices to write seamless, accessible web applications, let’s look at some guides which are already out there to make this possible. These guides include some rules and best practices for a11able websites.
One of these guides is WCAG.
WCAG _ Web Content Accessibility Guidelines
To address the concern for accessible websites, the World Wide Web Consortium(W3C) developed a series of accessibility standards. This document, known as the Web Content Accessibility Guidelines, (WCAG) breaks down accessibility into 4 main principles. To understand these principles, ask yourself a series of questions when developing:
- Perceivable: Can I consume content on my site in different ways? (Having closed captions for a video, for example)
- Operable: Can the site function without confusion and without the use of a mouse or complex interactions?
- Understandable: Can a user understand how the user interface of the site functions and the information on the site?
- Robust: Can different assistive devices (screen readers, for example) understand the website?
Each of these different principles has a success rating of either A, AA, or AAA. An A rating is the minimum requirement for having an accessible site and AAA is the gold standard of accessibility.
Many organizations do not reach Level AA across all aspects. WCAG exists to guide you in making the right decisions about accessibility for your design. It is your responsibility when designing/developing an accessible site to do everything you can to ensure that the design/behavior does not limit users in any way, regardless of their ability.
Again looking at these make us think about the effort needed to achieve these levels of a11y standards. So I put together 3 No Extra Effort_NEF and two Minimal Effort_MEF practices that are core to building accessible experiences and removes the worry of putting extra hours and work to achieve seamless experience across your site.
No Extra Effort A11y Steps
➡️ Use the right Semantics
Regardless of what framework you are using, writing good HTML is important (there’s a reason all those tags exist).
Semantic HTML elements clearly describe it’s meaning in a human and machine-readable way. Elements such as <header>, <footer> and <article> are all considered semantic because they accurately describe the purpose of the element and the type of content that is inside them. You’ll often find that semantic HTML makes for more organized and readable code in the long run.
when it comes to semantics, HTML elements can be divided into two groups:
- Tags with no meaning: <div> and <span>
- Tags with meaning: all other tags
If you are used to using <div> s everywhere or using <span> s for buttons and labels. You need to pick your tags more purposefully. Remember to choose Semantics over presentation.
➡️ Use the right colors
Color contrast is crucial not only for a11y purposes but also for seamless and understandable designs. On the web finding complementary colors is about finding shades that provide enough contrast between content and the background for anyone with low vision impairments and color deficiencies.
In WCAG 2, contrast is a measure of the difference in perceived “luminance” or brightness between two colors (the phrase “color contrast” is never used). This brightness difference is expressed as a ratio ranging from 1:1 which is like white text on a white background to 21:1 which is like black text on a white background. Here are minimum color contrast for each WCAG success rate:
There are some tools out there to help you pick the right contrast when it comes to choosing colors, the first one that I really like is the Chrome Dev Tools contrast checker. This feature is available on the color palette dialog. You can also use the WCAG Color contrast checker Chrome plugin or https://color.a11y.com/ for validating color contrasts.
In addition to contrast, we also want to render the colors as accurately as possible. Nowadays we run so many web applications on many different devices some may not be as stellar as others.
One feature I’m excited about is the color-adjust property, proposed in CSS Color Module Level 4. There are two values for color-adjust: economy and exact. The description for the economy value in the specification reads as
“The user agent should make adjustments to the page’s styling as it deems necessary and prudent for the output device.”
It places trust in the browser’s hands, allowing it to make adjustments to color values as it sees fit. But we need to understand that our design might not be able to be experienced in the real world as intended. Not everyone owns a device that outputs to a Retina display with a luxurious DCI-P3 color space; nor do they always have perfect vision or ideal lighting conditions. In these kinds of circumstances, it’s better to bend, not break.
Color-adjust can actually find its way to the body. Ensure every color on the page is flexibly changes based on the user circumstances. Of course, if you want to pertain certain colors on the page you can leverage the CSS Cascadeness awesomeness and set your specific element to use color-adjust: exact.
➡️ Review your A11y Tree
When Screen Reader navigates your Web page it does not, it does not go to the usual DOM tree. The browser takes the DOM tree and modifies it into a form that is useful to assistive technology. We refer to this modified tree as the A11y Tree.
You might visualize the accessibility tree as looking a bit like an old web page from the ’90s: a few images, lots of links, perhaps a field and a button.
A11y tree is very useful since you can actually see how the SR is reading your elements without running it. Chrome Dev Tools actually has an Accessibility Tree section inside its Accessibility tab, which you can browse the DOM and see the translated A11y Tree. You can also see a section called Computed Properties. These are the properties that can reproduce the DOM node inside you A11y with more detail.
In the image below, I am selecting an image tag, you can see a11y tree just see and `<img src=”…” />` and nothing more. For visual impaired used in this way, there is not any more information about the image.
You can see in the computed properties section, we can set a title or an alt attribute on the <img> tag to make the image self informative for users and screen readers.
Minimal Effort A11y Steps
➡️ Enable no-mouse navigation
Keyboard navigation is one of the most used navigation after the mouse on the Web, and not only people with motor disabilities use it, but also developers love it too. I had a colleague who actually didn’t use the mouse.
Here are some tips that can make keyboard navigation easier:
- Use interactive meaningful elements instead of div’s and span’s
- Manage your website focus state
- Never remove CSS outlines
- Use Skip Navigation links
➡️ Enable Screen reader announcements
Screen readers process contents in a linear way and are always on one single point of a page, so they are not aware of changes to the document that happens somewhere else. Using role="alert" though, you can force a newly added element's content to be announced anyway.
Setting role="alert" to a newly added DOM element (using JavaScript) forces the screen reader to announce its content, regardless of what it is doing right now.
This is specifically useful for certain scenarios such as state changes in JS frameworks, or announcing CRUD operations' success. In short any change that happened immediately as a result of a user action.
Conclusion
Understanding and planning for web accessibility should be included from the beginning and throughout the design and development process. Web accessibility is a continual process with any website or technology updates, changes, and periodic reviews.
Accessibility is not a one-time checkbox it is a developer mindset.
And not only it is about people with disabilities, but also about providing a seamless experience inclusively to everyone with any ability.
There are more techniques than all we covered here, but here is the summary:
If you enjoyed this point don’t forget to 👏and send me your feedback and comments.
