Have you ever been on a website where the text is gray and the background is a slightly darker shade of gray?
Or tried to read an article on your phone where you weren’t able to magnify it?
Hopefully the answer to both of those questions is a loud “No,” and the reason for that is accessibility standards.
For some people those standards – contrast specifications and magnification capabilities – are conveniences, but for many others they are a necessity for web browsing.
And for others still those standards are a cause they advocate for to make the internet a better place for everyone. Ben Myers is one of those.
He started as an engineer implementing accessible frontends with React before moving to a large tech company where he’s responsible for “ensuring that [the] developer documentation is accessible to all, regardless of disability or language.”
When he’s not working on making apps more accessible, he’s showing others how to build great user experiences that focus on accessibility in his SomeAntics Twitch stream or discussing inclusive design on Twitter. He got into content creation for accessibility because he saw a lack of practical application for the content that was out there.
In a recent conversation with CoderPad’s Corbin Crutchley, Ben gives the low-down on what it means for an application to be accessible and what you can do to make it happen.
What is accessibility?
Ben defines accessibility as the subset of usability that focuses on creating equitable experiences that include users with disabilities.
Due to the vast reach of the internet, you have to assume that a significant portion of your users have some disability – and it may not necessarily be in the traditional sense.
Ben points out that there is a whole spectrum of disabilities and how people experience them. It could be that they have vision or hearing issues, a temporary loss of physical capacities like a broken arm or leg, short term memory loss due to a head injury or cancer, a learning disability like dyslexia, a mental health disorder like depression – the list goes on and on.
Each person will experience these disabilities differently, and often people will experience more than one at a time or within their lifetime.
Some disabilities also may only reveal themselves in specific environments. For example, someone may stumble on a website that over-stimulates them, which exacerbates focus issues that impact their short-term memory. Disability and environment interact with each other.
That’s why it can be challenging to pin down the particular access needs of any given person at any given moment. If I’m visually impaired, I may be fine viewing a web page as long as I have my glasses, but if my glasses were to break or get lost, my accessibility needs would change until my glasses are repaired.
When you develop for accessibility, everyone benefits
After discussing what accessibility is, Corbin and Ben go into why people should care about accessibility.
Outside of the fact that it’s just the right thing to do, studies also show that even people without chronic disabilities benefit when you design for accessibility.
To illustrate this, he brings up the curb cut effect.
Curb cut on a residential street
Curb cuts are the ramps you see at sidewalks that lead into the road (usually into crosswalks) that were initially designed to make crossing streets less dangerous and more convenient for people in wheelchairs. They were initially implemented in Kalamazoo, Michigan, and Berkeley, California, in response to efforts from disabled World War 2 veterans and paraplegic university students.
But what researchers found was that it wasn’t just people in wheelchairs who were using the curb cuts. Parents with strollers, travelers with wheeled suitcases, bicyclists, skateboarders – even workers with wheelbarrows – were using the curb cuts.
A more modern example of the curb-cut effect is closed captions. Initially intended for deaf users, closed captioning is also used by people with temporary access needs: non-English speakers may use them to translate what’s being said, bar patrons may use them to comprehend what’s going on in a noisy environment. And lots of us just don’t want to play sound on our devices if we can help it.
Accessibility should not be a separate experience
For accessibility to work, it has to be a fundamental part of the application experience. If you tack it on as an afterthought, lots of users endup with a sub-par experience.
Overlays are a common type of these afterthoughts. They’re a type of automated application that claim to scan – and sometimes fix – your website for accessibility issues. The issue is that they 1) don’t fix the source code generating the HTML, 2) often miss important accessibility criteria, and 3) can hinder your website's performance.
Companies often buy into them because they don’t care or understand accessibility – usually, it’s just lip-service to accessibility to cover themselves from possible legal issues.
Accessibility should be baked into the product from the beginning of the design process – and there is a strong business incentive to do so.
Ben cites the Purple Pound study, which highlights the purchasing power of people with disabilities and their friends and family in the United Kingdom. They estimate that web pages inaccessible to people with disabilities lost around £17.1 million – about $22.3 million per year.
Better browsers with the accessibility tree
Corbin and Ben then dive into the modern marvel of the web browser – and just how much work browser developers have put into making the browsing experience more accessible.
Chrome and other browsers create an “accessibility tree” – it’s a representation of the website compiled primarily from the semantic markup. It’s what assistive technologies use to present an accessible experience to users.
You can access the accessibility tree in Chrome’s Dev Tools:
Accessibility tree in Dev Tools
Semantic markup is an entire discussion in and of itself. Still, Ben briefly describes it as using the tags, elements, and attributes to best reflect the intended purpose and behavior of the content. For example, using the different levels of header tags (<h1>, <h2>, etc.) to create the hierarchy of the content or using anchor tags to take you somewhere when clicked.
An example of semantic markup used in assistive technology is the <nav> tag. This tag registers a shortcut for screen readers so that visually impaired users don’t have to listen to the entirety of the contents being read to get to the section they want to get to.
Every web experience is device mediated – it’ll differ whether you’re using a screen reader, laptop browser, mobile browser, etc. The goal of the accessibility tree is to curate the content of a page to give each device – and hence each user – the best foundation for understanding the page.
Using Web Content Accessibility Guidelines (WCAG)
If you have no idea where to start implementing accessibility, Ben recommends looking at the Web Content Accessibility Guidelines (WCAG).
These are a set of guidelines developed by the World Wide Web Consortium (W3C), which sets the standards for pretty much the entire internet.
WCAG are basic industry standards and are often the legal standard in places where accessibility is mandated.
The guidelines are broken out by the general criteria that an accessible web page should have – perceivable, operable, understandable, and robust.
Under each criterion are more specific pass/fail criteria that must be met to meet the standards for the general criteria. These criteria include actual implementation steps under the “How To Meet” link and explanations about why they are essential for accessibility in the “Understanding” link.
Some of the “Understandable” criteria
Ben points out that there are three levels of accessibility that go from A (the least strict) to AAA (the most stringent). While AAA is the ideal, most companies and compliance organizations aim for AA since it reaches most people and the difficulty of being 100% compliant with the AAA level.
Ben says that he is always learning something new regarding WCAG. For example, one criterion states that a web page should be viewable in every orientation. While this may sound trivial, it helps people who use wheelchairs with mounts for their devices since they often cannot freely rotate their devices due to their disability.
More ways to be more accessible
When Ben advocates for accessibility, he talks a lot about user choice – what can you do to allow the user to tailor the experience to their needs?
Inclusive design allows users to create this optimal experience for themselves. In particular, Ben mentions the user settings of Discord as a great example of this. Discord provides a lot of visual settings that are incredibly beneficial for people with color blindness or other visual impairments.
You need to continuously test your product for accessibility. Test it across browsers, devices, and assistive technologies.
Ben talks about the saying “Nothing about us without us,” which is another way of saying that it’s essential to involve people with access needs in your user testing.
If user testing isn’t available to you for some reason, reach out to disability activists on Twitter or other social media sites. Ask them questions or read the insights they produce in their content.
If you’re interested in watching the whole accessibility discussion between Ben and Corbin, you can find it on the CoderPad Twitch channel here.
Top comments (0)