Accessibility Quick Start Guide
Resources to Provide a Gentle Introduction to Accessibility
Oftentimes, accessibility is an afterthought. I was very fortunate to have had a manager that enforced best practices and helped me build my lens for accessibility. My goal is to pay it forward and pass on the lessons I learned so that we can flip the script and make accessibility a forethought when developing user interfaces.
My first step towards this initiative is to create a blog post as a gentle introduction on the topic of accessibility. This is by no means an exhaustive list of resources, but my hope is that it helps point you in the right direction so that you can dive deeper into the topic. I made a similar document for my employer's engineering team and figured this would be a great resource to share with the larger developer community.
📍 WAI-ARIA Authoring Practices - If you do nothing else, reference this document which is the standard for implementing accessible web components.
ℹ️ Writing accessible code (easy wins)?
Tips from the Syntax podcast accessibility episode
Use the alt attribute on images
Proper input types - number, text, etc
Use links and buttons properly
Colors and proper contrast
CSS order property on Flexbox and Grid
HTML5 (article, section, header, footer)
Use ARIA roles to define elements when semantic HTML falls flat (popups, non-standard controls, etc.)
Useful articles, courses, etc, found around the interwebs.
- This is a free course that is provided by Udacity. It covers a lot of solid accessibility fundamentals.
- This is a text-based version of part of the content covered in the course mentioned above.
- For situations where you want to modify the tab order, you can leverage the tabindex attribute.
🛠️ Developer Tools
A list of tools that can be helpful in testing and inspecting accessibility pieces within an application.
Axe Tools (Free browser extension and other tools)
Accessibility Insights (Alternative free browser extension)
VoiceOver (Default screen reader on Mac)
Shortcut ⇒ CMD + F5
Inspect accessibility properties in browsers:
Pa11y (accessibility automation tools)
📺 Video Tutorials
A11ycasts Playlist by Google Chrome Developers
ARIA ⇒ Accessible Rich Internet Applications
WAI-ARIA ⇒ Web Accessibility Initiative – Accessible Rich Internet Applications
The term “a11y” is a shorthand for “accessibility”
ARIA consists of three main components:
Accessibility Tree = the modified DOM tree that the browser presents to the screen reader minus the extra visual style fluff. You can think of it as an API describing the page's structure.
It's similar to the DOM tree but typically has less information and fewer nodes since it doesn't need all the visual presentation stuff.
ARIA works by allowing you to specify attributes on elements that modify the way that element is translated into the accessibility tree.
📖 Semantics and Assistive Technology
Because not all people are able to visually access a webpage and therefore not able to pick up on all the affordances in the same way, we have to ensure that information is expressed in such a way that it can be accessed programmatically by assistive technology. This is referred to as the semantics of an element.
- In return, the assistive technology is able to create an alternative interface that can suit its user's needs.
All images should have an
altattribute. Images that are important for the page should have descriptive
alttext while purely decorative or cosmetic images should have
📖 Semantics in Native HTML
The DOM comes pre-packaged with implicit semantic meaning.
Implicit semantic meaning ⇒ Using native HTML elements that are automatically and reliably recognized by a wide range of browsers. A major gain of using native HTML elements is that accessibility for these elements is handled by default.
ℹ️ This is why it's always recommended to use native elements whenever possible. Trying to "build your own" is always more work because you have to ensure that the accessibility meets the WAI-ARIA standards.
For scenarios where you need something more custom, leverage accessibility-focused libraries that are solid and battle-tested.
🏷️ Labels and Inputs
Each input should have a corresponding label. The
forattribute on the label should correspond with the
idof the input it is labeling.
- Inputs should always have labels as well, especially for accessibility reasons.
Labels are important because they create a connection between an element and its description.
If you can't use a label but want to make it clear that something is the label of something else - use
Typically, you only want to add focus to interactive elements like buttons, tabs, selects, or anything that users might have to provide input into.
If you want to hide a label, for use cases like icon buttons, for example, check out my blog post on an Accessible Friendly Way of Hiding a Label.
👋🏽 El Fin
I hope this article provided a gentle introduction to the topic of accessibility. I plan to write more targeted topics within accessibility in the future so stay tuned for more!
If you enjoy what you read, feel free to like this article or subscribe to my newsletter, where I write about programming and productivity tips.
As always, thank you for reading, and happy coding!