What Is Accessibility?
Accessibility is the practice of making your websites usable by as many people as possible. - Mozilla Developer Network (MDN)
Why Should I Care?
Obvious Reasons You Should Care About Accessibility
- Enable users with disabilities to access our websites
- Legal Compliance (ex: Accessibility for Ontarians with Disabilities Act (AODA) for us in Toronto )
Non-Obvious Reasons You Should Care About Accessibility
- Helps users on Mobile devices and users with Slow Connections
- Superior and cleaner UX. Accessible design is often simpler and intuitive, removing friction and distractions.
- SEO. Semantic HTML, which improves accessibility, also improves SEO, making your site more findable.
What are Accessibility Guidelines?
Accessibility Guidelines are a set of technology-agnostic standards and recommendations for making websites and web applications accessible. The Web Content Accessibility Guidelines(WCAG) formulated by the World Wide Web Consortium (W3C) are the international standard for accessibility guidelines. While the WCAG are not legally binding, they are the basis for a lot of accessibility legislations around the world including the AODA.
Accessibility Guidelines in a nutshell:
- WCAG 2.1: Web Content Accessibility Guidelines, formulated by the World Wide Web Consortium (W3C)
- 3 levels of compliance: A, AA, and AAA
- For Canadians in Ontario, we have Accessibility for Ontarians with Disabilities Act. It mandates AA level compliance by January 1, 2021 for all internet websites and web content
What is WCAG 2.1?
WCAG 2.1 is a Set of 12 Guidelines divided into 4 Principles.
4 Principles of WCAG 2.1:
- Perceivable Information and UI can’t be invisible to all senses
- Operable Users must be able to operate UI & navigation
- Understandable Info & operation of UI must be understandable
- Robust Content must be interpreted reliably by all user agents
Perceivable
- Provide text alternatives for non-text content.
alttags for instance. - Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
Takeaway:
- Screen-reader and voiceover support should be considered in design.
- Don’t hide content from assistive technologies.
- Do hide decorative elements from them.
Operable
- Make all functionality available from a keyboard.
- Give users enough time to read and use content.
- Help users navigate and find content.
Takeaway:
Don’t expect everyone to use a mouse or pointer. Must incorporate keyboard and other input devices.
Understandable
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
Takeaway:
- Use high contrast color schemes and legible font-sizes.
- Resilient error-handling and helpful error-messages.
- Stick to standard UI patterns. A button should work like a button…
Robust
Maximize compatibility with current and future user tools.
Takeaway:
Your website should work on most devices and browsers, including assistive technologies. This is why backwards-compatibility and polyfilling is important. Many people maybe using IE 11, or be on the “wrong” version of iOS for instance.
Accessibility APIs
Web browsers make use of special accessibility APIs (provided by the underlying operating system) that expose information useful for assistive technologies (ATs) — ATs mostly tend to make use of semantic markup (HTML). This information is structured in a tree of information called the accessibility tree.
Different operating systems have different accessibility APIs available :
- Windows: MSAA/IAccessible, UIAExpress, IAccessible2
- Mac OS X: NSAccessibility
- Linux: AT-SPI
- Android: Accessibility framework
- iOS: UIAccessibility
Semantic Markup
- Semantic markup is the bedrock of web accessibility
- HTML is built to be accessible, if used correctly
- Screen-readers and other assistive technologies rely on semantic markup for their output
Bad Markup Example 1
Here is some bad markup:
<font size="7">My heading</font>
<br><br>
This is the first section of my document.
<br><br>
I'll add another paragraph here too.
<br><br>
1. Here is
<br><br>
2. a list for
<br><br>
3. you to read
<br><br>
<font size="5">My subheading</font>
<br><br>
This is the first subsection of my document. I'd love people to be able to find this content!
<br><br>
<font size="5">My 2nd subheading</font>
<br><br>
This is the second subsection of my content. I think is more interesting than the last one.
What makes it bad markup?
The screenreader hasn't got anything to use as signposts, so you can't retrieve a useful table of contents, and the whole page is seen as a single giant block, so it is just read out in one go, all at once.
Semantic Markup Example 1
Here is the semanitc markup version of example 1:
<h1>My heading</h1>
<p>This is the first section of my document.</p>
<p>I'll add another paragraph here too.</p>
<ol>
<li>Here is</li>
<li>a list for</li>
<li>you to read</li>
</ol>
<h2>My subheading</h2>
<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
<h2>My 2nd subheading</h2>
<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
What makes it semantic markup?
- The screenreader reads each header out as you progress through the content, notifying you what is a heading, what is a paragraph, etc.
- It stops after each element, letting you go at whatever pace is comfortable for you.
- You can jump to next/previous heading in many screenreaders.
- You can also bring up a list of all headings in many screenreaders, allowing you to use them like a handy table of contents to find specific content.
Bad Markup Example 2
Here is some bad markup:
<div width="1200">
<!-- main heading row -->
<div id="heading">
<div>
<h1 align="center">Header</h1>
</div>
</div>
<!-- nav menu row -->
<div id="nav" bgcolor="#ffffff">
<div width="200">
<a href="#" align="center">Home</a>
</div>
<div width="200">
<a href="#" align="center">Our team</a>
</div>
<div width="200">
<a href="#" align="center">Projects</a>
</div>
<div width="200">
<a href="#" align="center">Contact</a>
</div>
</div>
<!-- main content and aside row -->
<div id="main">
<div id="content" bgcolor="#ffffff">
<!-- main content goes here -->
</div>
<div id="aside" bgcolor="#ff80ff" valign="top">
<h2>Related</h2>
<!-- aside content goes here -->
</div>
</div>
</div>
<!-- footer row -->
<div id="footer" bgcolor="#ffffff">
<div colspan="6">
<p>© 2020 acheema. All rights reserved.</p>
</div>
</div>
</div>
What makes it bad markup?
- Divs inside of divs inside of divs…
- Divs don’t have any semantic meaning, besides being a division of content
- Screen readers may not read how you want them to
Semantic Markup Example 2
Here is the semanitc markup version of example 2:
<header>
<h1>Header</h1>
</header>
<nav>
<!-- main navigation goes here -->
</nav>
<!-- main content -->
<main>
<!-- article -->
<article>
<h2>Article heading</h2>
<!-- article content goes here -->
</article>
<aside>
<h2>Related</h2>
<!-- aside content goes here -->
</aside>
</main>
<footer>
<!-- footer content goes here -->
</footer>
What makes it semantic markup?
- It is structured correctly and will be easily understood by Screen Readers
- It is in logical order and easier to maintain for developers
- Great for SEO
Recommended Tools for Testing Accessibility
These are my go-to tools for checking the accessibility of my websites and applications as a frontend developer:
- WAVE Evaluation Tool by WebAIM
- axe - Web Accessibility Testing by Deque.
- react-axe for testing React application with the axe-core accessibility testing library. Also by Deque.
- iOS and macOS VoiceOver. These are built into iPhones/iPads and Macs, respectively. Best way of testing screen-reading support on your apple devices.
- JAWS by Freedom Scientific is the main screen reader used on Windows devices.