--- title: "Dev Discussions: A Primer on Accessibility with Inclusive Design Expert Ben Myers of SomeAntics | CoderPad" description: "Ben Myers discusses the central tenants of accessibility, and how you can make your own website more inclusive." canonical: "https://coderpad.io/blog/development/accessibility-with-ben-myers/" last_modified: "2023-06-05 14:34:45" --- [Back to blog](https://coderpad.io/blog/) # Dev Discussions: A Primer on Accessibility with Inclusive Design Expert Ben Myers of SomeAntics April 18, 2022 7 Minute Read By Ken Swearengen [Development](https://coderpad.io/blog/development/) 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](https://www.twitch.tv/SomeAnticsDev) Twitch stream or discussing inclusive design on [Twitter](https://twitter.com/BenDMyers). 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](https://www.twitch.tv/videos/1436442023) 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. ## Learn how to run front-end developer interviews that don’t suck [Read our guide](https://coderpad.io/blog/interviewing/5-tips-for-interviewing-frontend/) ## 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](https://www.independentliving.org/docs3/brown99a.html) and [paraplegic university students](https://manifold.umn.edu/read/building-access/section/3648dfee-4278-4849-8e47-b5eb56fad60e). 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](https://wearepurple.org.uk/the-purple-pound-infographic/) 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: ![An image Chrome dev tools screen with the accessibility tree juxtaposed with the regular domain object model in the middle and the website itself on the far left.](https://coderpad.io/wp-content/uploads/2022/04/img_625d58dd62967.png) Accessibility tree in Dev Tools [Semantic markup](https://html.com/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 (`

`,`

`, 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`