Written by: Everett Zufelt
One thing that makes the web exciting, at least to me, is that it’s open to all. Designers and developers come from diverse backgrounds — it’s not uncommon to find people who are part-time, self-taught, and completely free from formal training in their chosen craft — but nevertheless, they create great experiences and share meaning through the medium of the web.
Where to Begin?
Most designers and developers I’ve worked with are eager and excited to learn about accessibility. Some become interested after coming across an article or inspirational video, but more frequently, it happens because they’re mandated to incorporate it into a project.
Once they dive into accessibility, they inevitably come across the litigation portion of the topic. Probably anyone who has been through this themselves is familiar with the 2008 Target accessibility settlement for $6m. And in the years since the Target suit, many other successful actions have been raised, including a 2017 ruling against Winn-Dixie, where the grocer was ordered to improve the accessibility of its site to make it more accessible to the blind.
The tides are shifting towards a more inclusive web, and whether it’s the good of your heart that brought you to accessibility (including working on a project that includes “doing the right thing”) or, more commonly, a mandate issued because of legislation or a fear of litigation, the desire to dig in and get more knowledge on the topic is the real start.
With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model. (Source)
The DOM and Accessibility
To complicate things further, what lives in the DOM is not what is consumed by assistive technologies. Most browsers map the representation of the user interface from the DOM to a platform specific Accessibility API. This is similar to how native desktop and mobile UI libraries map their components back to an Accessibility API, and provides for more reliable interoperability for assistive technology:
In order to add the missing semantics to all of those meaningless <div> elements, the W3C has created the WAI-ARIA (Accessible Rich Internet Applications) specification.
The WAI-ARIA specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.
“But I just want to create something cool!”
At this point many of you will be thinking that this is all a little bit overwhelming. You want to create something cool, and don’t have the time to read and understand pages of documentation from the W3C in order to understand how to ensure that everyone can enjoy the new (insert comical web-meme based fictional product name here) that you’re planning to launch.
As someone who both requires web applications to be accessible for daily use, and who leads teams of developers under the triple constraint of budget, time, and scope, I empathize with anyone who feels like accessibility isn’t achievable. You’re not alone, and you can start small. Like anything of value, becoming an expert, or even proficient, will take time and effort.
5 easy steps to get started
1. Learn how people with disabilities use the web. Even if your mandate is to avoid litigation, you’re going to be most successful if you build empathy for the people on the other side of the DOM.
2. Join a community of those learning to build more accessible web applications. The WebAIM Web Accessibility E-mail Discussion List is one of the first I joined.
3. Attend an accessibility meetup or an accessibility camp. These events are typically a mix of beginners, experts, and everyone in between. Like many meetups, they often have pizza and beer.
4. Recruit users with disabilities to take part in your next round of testing. Ask them to bring their own device / assistive technology, so that you get the full experience of the barriers they face with your web application.
5. Find some accessible UI components. There are many out there, and I recommend a web search for “[component name] accessibility”.
Do Good, Feel Good
I was on a flight to San Francisco the other day and began speaking with the passenger beside me. He worked for a FinTech company, and shared with me that they put a lot of effort in to accessibility. I didn’t ask him what caused them to start looking at accessibility, but assumed it was regulatory.
He told me that one of the core constituents for their service is veterans with disabilities. He went on to say that they receive feedback from these users that theirs is the only service they could find that they could use. He didn’t use the word, but from the way he told his story, I could tell that he was proud. That’s a feeling we can all replicate using the simple steps above.
Remember, Rome wasn’t built in a day and you don’t have to be an expert out of the gates. Start small: find some users with disabilities, take them to lunch and listen to their stories about how they use the web. Pay them to show you how they interact with your web application and ask them to point you to others that they enjoy.
Perfection isn’t the expectation, but it should be the goal.
Improve incrementally, you don’t need to boil the ocean. Your web application team likely isn’t building all of its user interface components from scratch, you’re likely using a UI framework, or open source components from NPM. Do some research, find out what people are saying about the tools you’re using and look at versions — you may be missing out on new accessibility improvements and new features. Look for other libraries that provide the same component with built-in accessibility, it may not be that difficult to make the switch.
Give back, read a few articles on how to make that complex component more accessible, and file the PRs or bug reports that will improve the component for users around the globe. And be proud, you’re making the web more open to all!
Found some good info in this piece? Be sure to applaud 👏 and share!