AccessibilityBroadly, creating an experience that is available to anyone and everyone
ARIAAccessible Rich Internet Applications
RoleThe function an element serves on the page
StateThe state of an element on a page (e.g., expanded, disabled)
PropertyAdditional information about an element or other elements its related to
VoiceOverA screen reader that is built into apple computers
By the end of this lesson, you will know/be able to:
- Speak to why website accessibility is important
- Implement Semantic HTML to make websites more accessible
- Implement ARIA to make websites more accessible
- Learn basic VoiceOver screen reader commands to test accessibility
Accessibility in Web development means enabling as many people as possible to use Web sites, even when those people’s abilities are limited in some way. The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.
Good News! A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times.
Most production websites are not very accessible. This is a great way to set yourself apart from other candidates in the job hunt and add value to teams early.
Let’s watch the first ten minutes of this video to see how far accessible technologies in web development have come.
Ways to Make Your Websites More Accessible
This lesson is largely focused on writing code in a way that is accessible for people with visual disabilities.
In terms of statistics, the World Health Organization estimates that “285 million people are estimated to be visually impaired worldwide: 39 million are blind and 246 have low vision.”
There are two different elements that are semantically neutral: Those are
div elements. Avoid using them except in instances that are purely for styling.
Semantic html is very important for 3 reasons:
- developer empathy - It makes code much easier to read and debug
- accessibility - It allows screen readers to move through the web page seamlessly
- seo - it will make your webpage more discoverable
Side Note: Documentation is your friend when developing a website. Here are some super useful docs for better knowing what element to use for a given scenario.
I will often search google to find documentation for an html element that fulfills a purpose.
Example google search:
html element for navigation mdn formula for a search
[what you want to search for] [documentation source]
Testing for Accessibility
Using your screen reader (basic commands)
When people with visual disabilities are using your website they will be using some sort of screen reader. Luckily for us, we have one that comes with our computer! It’s called VoiceOver and here are some basic commands we can use to test the accessibility of our webpages.
- Starting/Stopping VoiceOver -
command + F5
- Moving your VoiceOver cursor -
control + option + arrow keyie.
control + option + right arrow
- Moving your VoiceOver cursor into your web page’s content -
control + option + shift + down arrow
- Moving your VoiceOver cursor out of your web page’s content -
control + option + shift + up arrow
DO NOT REMOVE THE FOCUS RING that appears on interactive elements without providing alternative styling or accounting for users who depend on the keyboard as their primary way of navigation.
This blog post on writing accessible css has a section that digs into why you shouldn’t remove it (as well as some alternatives to take).This website offers a list of alternative styling options. And this article also has some alternatives to use to get rid of the focus ring while still keeping things accessible.
- Open this code pen
- Plug in your headphones and turn on VoiceOver
- Use the key combination above to move your VoiceOver cursor into the web content of the code pen.
- Close your eyes, and interact with the site using the VoiceOver key combos to move the cursor.
- When you are finished, do the same thing with this code pen
With a partner, answer the following questions:
- What was your experience like?
- What differences did you notice between the two code pens?
WAI-ARIA is a shorthand for (Web Accessibility Initiative – Accessible Rich Internet Applications). WAI-ARIA is a specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking. ARIA breaks down into 3 categories:
- An element can only have one role at a time, but can have as many properties and states as necessary
An important point about WAI-ARIA attributes is that they don’t affect the appearance or functionality of a web page, except for the information exposed by the browser’s accessibility APIs (where screenreaders get their information from). WAI-ARIA doesn’t affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.
Rules of ARIA Use
The core rules to keep in mind when using ARIA are:
If you can use native HTML elements and attributes to communicate the proper semantics (like
<button> etc.) and behavior then do so. Adding ARIA support where it’s not needed is redundant code that isn’t doing anything. For the most part it won’t lead to problems, but it is a waste of time.
Aria Roles, States, and Properties
Roles define what an element is - what function it serves on the page. They give screen readers more information about how to interact with the element (
What am I?)
These can be either implicit or explicit.
Implicit roles are those that are pre-defined by default in HTML. Ie:
<ul></ul>. The semantic meanings of these elements are already clear by the element themselves and assistive technologies have this information too.
If you are writing good semantic HTML, the role will likely be implicit. Remember you can always check the role here
Implicit Role Example:
<h1>Hello World</h1> <!-- The above markup has an implicit role of "heading level 1" --> <nav></nav> <!-- The above markup has an implicit role of "navigation" -->
Explicit Role Example:
<form role='search'></form> A form element has a role of 'form' by default. We can override that role using the `role` attribute and providing it another value. Like in the case above where we are using the role of search.
- Use the table of elements and look up the following elements and their implicit roles
- Turn to your neighbor and take turns explaining what a role is.
- What is the difference between implicit and explicit roles?
States describe how you are interacting with an element (What am I doing right now?)
For example, think about websites that have a sidebar menu that can be toggled open or closed. You might see something like this:
<button> Toggle Menu </button>
Here we have a button with text that says “Toggle Menu”, probably indicating that when you click on said button it will toggle the menu open or closed.
What this doesn’t tell you is if the menu is already open or closed, which is fine if you have fully functional eyesight, but probably not great if you use assistive technology.
Luckily ARIA provides state information that we can add to our markup.
<button aria-expanded="true" > Toggle Menu </button>
This also allows you to target these elements using the
States can also be implicit, imagine a checkbox element in html. If you toggle the checked property that state will change as well.
Here is a good menu example that you can use with voiceover to see how screen readers interact with aria-expanded.
- Turn to your neighbor and take turns explaining what states are.
- What would be another example of state that your app might need?
Properties give an element special characteristics that you can relate to other documents or elements.
For example, take the button we mentioned when discussing states. That button specifically controlled the sidebar-menu, but what if there are multiple menus that have similar buttons? ARIA lets us add additional properties that link elements together.
<button aria-expanded="true" aria-controls="sidebar-menu" > Toggle Menu </button> <nav id="sidebar-menu"> <!-- ...nav code here... --> </nav>
aria-controls property has a value of the ID of the element it is attached to. So in this case, we would assume that there is another element with an id of
sidebar-menu that is contolled by this button.
Open this CodePen to play around with it.
You can also use something called an
aria-label property. Think of this like an
alt tag for accessibility - this property allows you to enter additional text that provides more information to the user. This information won’t show up on the page but will be read by the screen reader.
<button aria-expanded="true" aria-controls="sidebar-menu" aria-label="Close sidebar navigation menu" > Toggle Menu </button>
aria-expanded="false", you’d set your
"Open sidebar navigation menu".
Open this CodePen to play around with it.
aria-label with caution. The screen reader will now REPLACE whatever exists as the default button text and instead read the
aria-label- Described above. Provides additional information about an element.
aria-required- Tells a user if they need to provide input on an element before a form is submitted.
aria-controls- Seen above. References an element that is controlled by the current element.
aria-labelledby- Sister to
aria-label, references the ID of another element, which is a short title for the element.
aria-describedby- is just like aria-labelledby – but is meant for longer descriptions instead of short titles. This is read after the field-type is stated
- Turn to your neighbor and explain what a property is
- Come up with a good analogy for property
- How are properties different from state?
Accessibility in Practice Moving forward
- Most of the above mentioned aria attributes should be used sparingly.
- The time to use them is if the answer to the following question is yes:
- Will sighted users see content that people with visual disabilities cannot?
Below are some low hanging fruit that you should always incorporate in lessons
Alt Attributes for Yo Images!
- Hugely important
- Low hanging fruit, easy to use on images.
- Be verbose.
- Just do it.
bad <img src="mountain.jpg" alt="mountain"> good <img src="mountain.jpg" alt="The cascade mountains at sunset in January">
Below you will find a REAL example of how alt text helps to paint a picture of what a missing image depicts:
Title Attributes for Yo Links that have no text!
- Low hanging fruit on anchor tags.
- Not necessary for all links, but make sure to use them for your icon anchors – you know, things like your facebook, twitter, etc icons:
<a class="facebook-icon" title="Facebook"><a/>
Lang attribute on Yo HTML!
- Low hanging fruit for HTML
- As far as non-english speaking screen readers are concerned, when they land on an english-speaking web page without lang attribute, it will be spoken with the screen reader language - making it impossible to understand - unless the screen reader user disables language switching in the screen reader.
- Just do it
<html lang="en"> </html>
ARIA Landmark Roles
One of the easiest ARIA features to implement, and one that provides significant immediate benefits to screen reader users, is landmark roles. To add them, simply add a relevant role attribute to an appropriate container within your HTML. This allows the screen reader to quickly jump to that section of the page. Below, you will find an example of how you might utilize the different landmark roles for your layout:
- The banner, main, and contentinfo roles are meant to be used only one time per page
- Take care in using
role="application"- When assistive technologies encounter content that’s marked up with
role=”application”they stop listening for users’ keystrokes and hand off all functionality to the application. This is due to an expectation that the application has its own model for navigating and operating all controls by keyboard. It generally should not be used.
Below you will find a code example of defining three landmark roles:
<!-- explicitly using the role attribute --> <!-- bad --> <div role="banner"></div> <div role="main"></div> <div role="contentinfo"></div> <!-- implicitly using the correct semantic tag --> <!-- good --> <header></header> <main></main> <footer></footer>
Label Input Elements that do not have a label element associated with them
aria-label: property that defines a short title for an element
<input type="text" aria-label="First name" placeholder="Grace">
Take the following HTML snippet and make it accessible using explicit semantic HTML, ARIA roles, and attributes.
<div> <p>Main Title</p> <form action="/" method="get"> <input type="search"> <input type="submit"> </form> </div> <ul> <li><a href="/">Home</a></li> <li><a href="/products">About</a></li> <li><a href="/about">Contact</a></li> </ul> <div> <div> <p>Content Title Subject One</p> <p>This is the content of this important section</p> </div> <div> <p>Content Title Subject Two</p> <p>This is the content of the section important section</p> </div> <div> <img src="mountain.jpg"> </div> </div> <div> <span>Copyright &copy; Aurelio De Rosa 2014</span> </div>
Perfect is the enemy of good
For many people, the fear of not getting EVERYTHING right when it comes to accessibility causes them to not do accessibility at all. Don’t be that person.
Helping one group of people is a good place to start. There's a temptation with accessibility to think it has to be perfect. This is technology. This is people. We don't do perfect. It never happens. So, really, please don't go out there and think that if you're going to do accessibility that you have to get everything right. Perfect is, very much, the enemy of good. - Leonie Watson, Accessibility Engineer
- MDN Documnentation
- Aria Documentation
- Aria Examples & Design Patterns
- Web Accessibility in Mind
- 9 Tools for Website Accessibility Testing