Web Accessibility & UI Patterns
After visiting a few local conferences, in which I would always find at least one interesting speech about accessibility and why it’s very important, I finally decided to spend a few hours on a short investigation about that. At Codeart, we always try to fill in our a-few-day gaps between projects for some interesting research, that can later be turned into a knowledge sharing session for the whole team.
It turned out that this is a very challenging and fun topic, there are a LOT of resources online and you can learn a lot in just a few days. Thanks to my amazing colleagues ❤ for the feedback, I decided to turn a shorter version of my research in a few minutes read, that might bring you some new ideas and would definitely start to make you think about it.
TL;DR Lets start with some term descriptions.
What is accessibility?
“Accessibility defines users’ ability to use a certain product/service.”
From developer’s point of view, making an accessible site means making it for ‘almost’ everyone. The languages that we use to create rich and dynamic web sites, e.g., HTML, CSS and JavaScript do not natively include all the features required to make sites usable by people who use assistive technologies (AT) or who rely on keyboard navigation.
The good news is that it’s very easy to make an acceptably accessible site.
There are several types of accessibility struggles: permanent, temporary, occasional.
To be more precise, we can find a few categories of accessibility: visual (e.g. non-sighted, myopia, color blindness, etc.), auditory, motor cognitive, temporarily disabled users (e. g. one-handed phone users).
Accessibility is often viewed as making your site work on screen readers, as they are very commonly used since a lot of people rely on them and having some type of blindness is very common. In reality, web accessibility is a subset of User Experience (UX) focused on making your websites usable by the widest range of people possible, including those who have disabilities.
The W3C Web Accessibility Initiative’s (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts. The WAI-ARIA Overview provides additional background on WAI-ARIA, summarizes those efforts, and lists the other documents included in the WAI-ARIA suite.
How can we know what to do?
Step 1 — Locate your bad practices with the help of some tools 🔨 🔧
- Use tools like Siteimprove, which is a Google Chrome Extension tool that can scan any website and point you the potential accessibility issues (along with fixes and tips 😉).
- Chrome has an experimental accessibility inspector in dev tools. Go to setting -> experiments in Chrome Developers Tools to enable it. This tool helps by letting you know the computed accessibility properties and can point out potential issues.
- Use can test or try to experience your application using ChromeVox which is a free text to speech and voice command Chrome extension.
- Read posts and books or watch some online courses that can help you understand how other developers are dealing with these struggles.
The most popular browsers for blind users (according to WebAIM) is Internet Explorer 8 (30.4%) and 9 (28.5) and Firefox (20%).
Step 2 — Let’s try to locate potential issues we might be making right now🔍
Keyboard accessible
TAB + SHIFT TAB CONTROL
Focus-ring is the outline that gets displayed around the control when it receives focus. At times, especially with buttons, these focus rings are not very aesthetically pleasant so developers tend to disable it in CSS (`outline:none`). Mouse users wouldn’t face any issues because of this but keyboard users find it problematic because can’t figure out whether the control has focus or not. Ideally focus ring should be visible to keyboard users even if it is invisible for mouse users. This is an awesome library that helps you achieve that.
The default focus ring might look bad on some layouts (for example a blue background), and because every browser might render it differently, a better practice would be to use a ‘box-shadow’ property instead of changing the color of the outline.
This article might help.
DOM TREE & TAB ORDER 🌳
As we focus on the interactive elements, navigating with a keyboard, for example, they are being focused following some order. That order is actually the order in which we created them in our HTML file (the DOM Tree order). Always pay attention to the logical order of the elements in and try to avoid bad user experiences (like the example below), in which first you will get the focus on an element that would be rendered on the right side, and then it would immediately go back on the left side.
Bad practise
<a href="#" style="float:right;">Right aligned link</a>
<a href="#">Link 1</a>
<a href="#">Link 2</a>Better practise
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#" style="float:right;">Right aligned link</a>TABINDEX
Sometimes you might want to make a non-interactive element with some custom interaction and you might want to avoid restyling the native HTML elements in order to save some CSS lines. To make a non-interactive element focusable you can give it a `tabindex = 0` attribute. Example:
<div id=”my-div” tabindex=”0”>Dummy text</div>This not only makes the element tab-accessible but also makes it programmatically focusable. That means you can call .focus() on that element.
A negative as a value to this attribute for example `tabindex = -1` will take out any interactive element from tab-order. That means you can not access it through the keyboard.
<input type=”email” tabindex=”-1” />This is particularly useful when you want to make a few links/buttons inaccessible when they are behind an overlay or transitioned out of display (e.g. hamburger menus).
Positive `tabindex` value makes the element tab accessible and also puts the element ahead in tab-order based on the value of the attribute.
<input type=”text” tabindex=”2” />
<input type=”email” tabindex=”1” />But positive `tabindex` values are considered anti-pattern because it may get very confusing more than one element have positive `tabindex` values.
So, don’t use positive `tabindex`. The best practice would be to follow the DOM Tree order and set the `tabindex` to 0.
USE NATIVE ELEMENTS
As far as possible please use native elements for any specific purpose. That means, for example, if you need a button, then just use a button tag rather than making a button using divs or spans. Native interactive elements like buttons, select boxes, etc. have many built-in accessibility features which you might miss if you are creating your own.
SCREEN READERS & BRAILLE DISPLAY
Many users with visual impairment rely on assistive tools like screen readers and braille display (which can read the text and convert it to the braille alphabet) to get information on the page and to interact with the page. There are a few suggestions I would like to mention that might help those users a LOT.
Always use `alt` attribute for images. Screen readers would read out the alt text for its users who have difficulty in seeing the image.
Pay attention to the description, not always the first description that seems to be logical would be the best practice.
Example:
<a href="index.html">
<img alt="Logo" src="logo.png" />
</a>For the users who don’t have a visual impairment, this would probably mean that if they click on the logo, the link would take them to the homepage. As a very common practice nowadays we can see that designers don’t even put the homepage link in the menu since users are very used to this practice and they immediately know what to do. If a user with a screen reader turned on navigates to this link, the screen reader would read it as a “Logo”, since that is the only content inside that anchor tag, and that might be a very confusing experience.
Better practise:
<a href="index.html">
<img alt="Homepage" src="logo.png" />
</a>If you don’t set the `alt` attribute, the screen reader will read the image file name along with the whole source where the image is located on your server.
Some images (for example the search icon next to the search input) need to be escaped in order to avoid the scenario where the screen reader reads the alt of the image and the label of the input. In those cases, include the `alt` attribute, but leave it empty.
Always put a full stop at the end of the alt description so that screen readers can make a stop, which would lead to a better experience.
Use proper heading tags `<h1>, <h2>, <h3>` etc for headings, because screen readers allow users to navigate within the content of the page using headings.
Make efficient use of semantic tags like `<header>, <footer>, <section>, <nav>` etc because screen readers allow users to navigate within the content of the page using these tags.
Screen readers need to identify the interactive elements correctly so it can ask users to interact with them. For example, if you have created a button using `<button>` tag then a screen reader will call it out as button. But if your button is something like this
<div class=”fancy-button”>Submit</div>then screen reader will call it a “group” because the div is a grouping element, and the users would not understand that they are supposed to interact with that element.
LINKS
Links are one of the most tricky elements from an accessibility point of view. Sad to break this to you, but the `title` attribute, that was most commonly used for describing links, is not the solution.
You can read more about this following this link.
The best way to make a link accessible would be to make the anchor text relevant and descriptive.
Avoid using “weak text” like “read more” and “click here”.
The reason this is bad is that screenreader users often use hotkeys to navigate the page, skipping to the next heading or link. If they skip to a link that says “read more”, it’s unclear what page they’ll be taken when clicked.
But sometimes for the sighted users, a “read more” link is completely appropriate. We can’t write an incredibly long and unique description in the anchor text of every one of our links.
What should we do?
The W3C recommends writing all the text in the anchor, but if you need to provide additional information for screen readers, wrap that in a span which you would later hide with CSS. This means the unique text is there for everyone, but if you really just need the words “read more”, you can show that, and hide everything else.
They also suggest in their recommendation how to hide the text. Using display:none will make the text hidden for the screen readers, so we have to force the text out of the displayed area.
That would look something like this:
a span {
height: 1px;
width: 1px;
position: absolute;
overflow: hidden;
top: -10px;
}You can read the full specifications about this solution following this link.
Please check the Assistive Technologies and HTML Support before using the HTML elements following this link in order to learn how assistive technologies interpret them and improve the experience for our users.
If we start to research accessibility we will notice that there are tons of documented issues we might be making and trying to fix all of them after the project is done might be scary and a bit extra time-consuming.
The idea is to locate the potential issues we might be making which can be implemented from the very beginning of the project.
It’s a lot easier to spread the blueberries at the beginning of making a muffin, than after the baking ;)
