Accessibility: Step-by-step Guide. Part 2
This article is the second and the last part of my walk-through the web accessibility. You can find the first part here.
If you read the first part, you know that accessibility is for everyone. I also covered the importance of the keyboard interactions there.
Here are a few more steps to master the A11y.
Step 3. Semantics and Content
To render a page, a browser parses HTML, creates DOM, CSS and A11y trees. The A11y tree is a simplified model of a web page used by tools like screen readers:
While creating those trees, browsers ignore errors and fill the missing attributes with the default values. Browsers are OK to do the dirty job and display a page, even if the markup isn’t 100% valid. It works fine with the graphic representation of a page, but it’s not an option for screen readers.
For example, look at the code below.
When we see the page, we understand that horizontal box with text First Name on the left side is an input. And we type the first name there. But this is a nightmare for screen readers users.
I tried it with ChromeVox and what I heard was:
- “Fill the form so we can get back to you”
- “Edit text”
- “Submit button”
Not much, huh? And here is why it’s the worst-case scenario for screen readers users:
- The
nameattribute of the input is not informative(name="f_n"); - There is no
placeholderattribute; - First Name text on the left side of input is a
<span>that is not related to the input (it’s not a<label>).
With this markup user with visual impairments has low chances of submitting the form.
And here’s where specifications, standards, and validity matter. The invalid markup leads to the wrong representation of the page to users of assistive technologies. You shouldn’t aim for 100% validity, but fixing basic errors improves both usability and accessibility. The valid HTML means your page has basic accessibility features.
What you should focus on instead of 100% validity score is the comfort of a customer. The content should be easy to consume. For everyone.
W3C compliance is not a ranking factor, so instead of achieving 100% validity, it’s better to focus on a11y aspect. Here are a few things worth considering about validation errors and a11y best practices:
- Add explanatory
alttext to an image. Users with visual impairments would like to get the context of images provided. Be creative: if an image is ironic — put the ironic phrase there; if an image is illustrative — describe it inalt. It makes a site look better if an image is gone:
- Structure the content with headers. There are 6 levels of the H tags that allow you to build complex pages. Assistive technologies like screen readers allow navigating using headings. Like we do when reading a book. It’s a major anti-pattern to use H tags just for styling. Here is the rule — H tags are for structure, CSS is for styling.
- Work on the links. Assistive software like VoiceOver for Mac generates a list of links on a webpage to make it easier to navigate on a website (see the image below). And that’s what links were designed for. Any link should have the
hrefattribute and a descriptive, self-explanatory text. A generic link text like “Read more” doesn’t work from A11y perspective. It will be presented out of context for screen readers users. Add more context, for example, “Read more about accessibility”.
- A link is not a button. If you need an element to trigger some logic (show a popup or to play a video/sound) — let it be a button. Links with
href="#"orhref="javascript:void(0);"will be added to the list of links by VoiceOver. It might confuse a user. You can use CSS to style a button like a link if it’s required. - HTML semantic elements and landmarks. If you were wondering why we need all those
<nav>,<main>,<footer>,<article>HTML5 elements — here is one of the reasons to use them. It’s so uncomfortable to tab through all elements starting from the top of the page to get to the main content. And to save user’s time, screen reader software like VoiceOver allows a user to navigate directly to the specific part of the page (a landmark) like main or footer. We need to add those semantic tags to make it possible. If you can’t use these elements, add landmark roles to divs (see the mapping). Here’s how it looks:
These bits of advice and proper usage of elements with attention to its semantics will help to score higher on HTML validity, accessibility and SEO perspectives.
Step 4. ARIA
With HTML5 we got a lot of new semantic elements and APIs, but so far HTML is limited. For example — there is no “modal” or “tooltip” element in HTML. Although these elements are widely used and are one of the bricks of modern web design. So how can we explain to screen reader user that it’s a modal displayed on a page?
Welcome ARIA.
WAI-ARIA, Web Accessibility Initiative — Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.(w3.org definition).
WAI-ARIA allows to modify the accessibility tree and change the way screen readers or other assistive technologies interpret the markup. So you can transform your generic elements like divs into more specific UI patterns like alerts or trees to make a website accessibility-friendly. In that case, screen readers can explain to a user what we try to construct with all these divs.
ARIA Roles
The key concept of ARIA is role attribute. Role attribute specifies the UI pattern the element implements. For example, if you use icon font and an icon is important in the given context, it’s a good idea to set role="img", so it’s properly represented by assistive technologies:
You can find the list of existing roles in WAI-ARIA specs.
A role may have property or state attributes that describe the element. Here is the table with all roles and possible attributes for each role — Allowed ARIA roles, states and properties.
ARIA is a wide topic which may take a few articles to be properly described. This article is more about the high-level overview. Here is my way to make the decision about using ARIA:
- Use native elements. Native elements have the best support from the a11y perspective. For example form elements. Styling
<select>is tricky. On the other hand, implementing it from scratch takes much more time. Keyboard support, tab order, mobile views and other things that a native one already has out of the box can be a real headache. - Use HTML5 semantic elements. If you need to support old browsers (IE 6–9), use html5shiv to polyfill those elements and add the
roleattribute to it. You will get the markup like the one below. It’s too verbose, but you get good browsers support with a11y features.
3. Look for ARIA patterns. If you need to add a UI element which doesn’t exist in HTML, go to ARIA Design Patterns and see if it’s there. Go through the role definition to see what behavior you should implement.
4. ARIA Live. If your app has dynamic parts that get updates without page reload, utilize ARIA Live Regions. It’s the way an assistive technology can give the response to a user based on the action.
Step 6. Styles
CSS can contribute to accessibility a lot. But we usually ignore this part and use CSS only to make a page look stylish. Sometimes we remove the outline and forget about focus styles.
Keeping in mind how easy and useful it is to style with regard to a11y may help you to improve the styling. It will make a page more usable for users with impairments and keyboard users. Here are a few things to consider:
- Outline and focus styling. As I mentioned in part 1 removing the outline completely is a major anti-pattern. Same thing with focus styles.
:focuspseudo class selects the element which is in focus now. You can style it and provide feedback to keyboard interaction. For example:
2. Use aria attributes for styling. ARIA attributes and states like aria-busy or aria-checked can be used in CSS. It helps to avoid adding more and more classes to an element:
3. Create responsive styles. Responsive styles allow to provide a better user experience for different devices like phones or tablets. It also useful to provide another layout for users with visual impairments who need to zoom in. So first of all — don’t disable the zoom:
And secondly — use bigger font-size value for small screens. Relative units like rem are super handy for this:
4. Pay attention to the contrast. Per WCAG 2.0 Text and images of text have a contrast ratio of at least 4.5:1. Tools like Accessibility Audit in Google Chrome are handy to check it:
5. Don’t rely only on color. It’s easy to mark an invalid field with just the red border. But color-blind people might not see the difference. Use color, text and icon that explain what happened, so everyone can see it and react to it:
Summary
In these two articles I’ve tried to give you the overview of what is Web Accessibility and describe some of the best practices. My main intention was to prove that a11y isn’t hard or tricky. It’s the set of the 6 steps (first 3 steps are in part 1 of this article) that you have to follow.
I also encourage you to go and try things out. Try to close your eyes and use your favorite website with a screen reader (VoiceOver or Chrome Vox). Try to play with markup to find best usability patterns.
And never stop learning. Here are a few links to read if you would like to know more about accessibility:
- https://a11yproject.com/ — the website with different how-tos and articles that explain a11y
- https://classroom.udacity.com/courses/ud891 — Udacity Web Accessibility course
- https://webaim.org/intro/ — intro to web accessibility from Web Accessibility in Mind (webAIM) — non-profit organization that empowers to work on a11y
Have a nice journey in the accessibility world!
