Talks Tech #45: Demystifying Web Accessibility

iTunes – Spotify – Google – Video – More Episodes

Josefine Schaefer, Developer Relations Engineer at Storyblok, shares her talk, “Demystifying Web Accessibility.” She discusses how a page visually presents to its viewer and also to a page reader. She talks about tools and tricks to check accessibility.

I originally studied languages a long time ago. I worked a bit in online marketing. I signed up for a programming boot camp and soon got my first job as a front-end developer. For one of our clients, we had to implement web accessibility because they were in a market where it’s legally required to fulfill specific standards. It was a vast code base with many different stakeholders, and we had a really short time to get things right. It was a new topic not only for me but also for very experienced developers. I felt like this could positively impact a community of people. I got hooked. It was love at first sight. I don’t work at the agency anymore. I work as a developer relations engineer at Storyblok. Storyblok is a headless CMS. It’s a fully remote company. 

Web accessibility means that websites, tools, and technologies are designed and implemented so that people with disabilities can use them and participate equally on the web. It’s also a fundamental human right defined by the United Nations. The World Health Organization found that over 15% of the population experiences some form of disability. Globally, that’s over a billion people. And, of course, it’s tough to measure global data and the experience of disability. I’m hoping that even the people looking at this from a business perspective will be convinced by the number of people and the spending power behind them. This is always a good argument if you must convince your boss to invest in web accessibility.

We have many different user groups that benefit from web accessibility. It benefits people with disabilities or impairments like physical, auditory, cognitive, neurological, speech, or visual disabilities. It also benefits people without disabilities. There are temporary disabilities, such as if you have broken your arm or lost your glasses, that will at least temporarily hinder you. There are also situational limitations. These are things like if you’re out in bright sunlight and can’t really see what’s happening on your screen. Maybe you have a slow internet connection, and the images don’t load properly, or you’re in an environment where you can’t turn up the sound and rely heavily on captions. 

It could mean providing enough color contrast, being open to different input methods, and providing Semantic HTML to give some context to assistive technology. Compatibility with different platforms, transcripts, and explaining unfamiliar terms, not assuming that everybody has the same base knowledge. There are a couple of terms that get thrown around quite regularly. We have the A11Y—the 11 stands for the 11 letters between the A and the Y. I think sometimes. It’s pronounced “Ally” as well. This is just short for accessibility. Then we have the WCAG. That’s Web Content Accessibility Guidelines. This is a shared international standard for the different levels of accessibility. AAA is the most inclusive standard of accessibility. These guidelines have a set of documentation. They provide a lot of background info on how to fulfill these rules so that you can stick to one shared standard. All this was created by the WAI, the Web Accessibility Initiative. 

Semantic HTML means nothing else, but the HTML elements we use are used for their given purpose. Every element has its meaning. So the H1 is the main headline, including the most critical information. An ‘a’ tag shows you that it’s a link. And ‘ul,’ for example, is an unordered list. There are many more. If we use them the way that they were actually intended, we give the page structure rather than just presenting the content in a pretty way. We can do this with CSS or JavaScript to make it look and function as we want. But there are many other good reasons to use semantic HTML. The structure is desperately needed by screen readers that perceive the page slightly differently than people. Some of these elements come with basic default styles and inherent functionality—for example, built-in keyboard accessibility. You have a button element, for example, that is inherently clickable. It has a focus and a standard look that you can identify. These inherent functionalities are something that you would have to build in manually, and it’s going to save you a lot of time and effort, and it’s going to function just out of the box. It could also be things like different cursor styles. 

There’s a fun game called CodePen by Paul. You can check your knowledge of the HTML tag. It could be a fun challenge to see how many you know. Also, you can use the Women Who Code website and open up your DevTool. You could go through any page and check the most critical content, NH1, for example. That’s what’s going to get communicated to the screen reader. How about the buttons? Is the button an actual button or is it a link? What does that tell a screen reader? We wrap these things for styling reasons and div, but what will come across to the screen reader? Turn off CSS and disable all styles, then you can see the rough structure. It doesn’t look as pretty, but you get an idea of the vital information.

Color contrast is super essential when it comes to accessibility. It’s actually one of the number one issues that have been found in many audits. It’s the difference between the perceived luminance or the brightness of the background and the foreground. My text should be perceivable against the background. To do that, I need a sufficient ratio of brightness. High contrast is going to help people with visual impairments. You want to watch out for too flashy colors. This is a bit difficult for people with reading disabilities if it’s too bright. It depends on your audience and what specifications you want to check for. Another excellent tool is to check how different user groups perceive your content. It’s called the Web Disability Simulator. You can select a simulation. I could, for example, go for total color blindness, and then I will see what the website looks like if everything is still perceivable. Other tools will allow you to check from the perspective of other disabilities, such as motor issues or ADHD.

You must be able to reach all the elements you can with a mouse and a keyboard, especially the interactive elements. You want to ensure you have all the functionality by keyboard that you would have otherwise and that the focus is visible. This not only includes getting into a page but also getting out. It can be a perfect challenge to see if you can navigate your favorite page or if you’re working on a website as a product, if you can navigate that with your keyboard. It’s good practice to see how other people experience our products.