Our first dive into Web Accessibility — What we’ve read, learnt and recommend
Introduction
Since we only had little experience with accessibility in web development we wanted to find out: „What is web accessibility actually?“ and „How can we best apply and utilize accessibility guidelines in web development?“.
To answer those questions our plan was to build a small showcase application which should be made accessible for as many users as possible. Based on our research we tried to follow common accessibility standards and guidelines in the development of our web application.
The goal was to summarize the most important things for us about web accessibility in this blog post — what we’ve read, what we learnt and what we recommend.
What is web accessibility?
When boiled down to the most important part, web accessibility is the possibility for everyone to perceive, understand, navigate and interact with the web.
These basic abilities can be impaired by a number of disabilities, which include but are not limited to:
- Vision
- Touch
- Cognitive
- Neurological
- Hearing
- Physical
(Source: W3C Accessibility Fundamentals)
In our home country, Germany, about 10% of people and in the world around 15% of people have some form of permanent disability. This is already a big portion of our possible users.
It is important however to not only think about permanent medical conditions when talking about accessibility. Here are some examples of everyday situations where we might use accessibility features:
- Working at night with less light in the room? Dark mode.
- Sitting in front of a screen in direct sunlight? Increasing brightness and contrast.
- Reading online articles on a small device? Variable font size.
- Watching a TV series, while someone else is talking in the room next door, so you can’t hear the audio? Subtitles.
- A broken arm so you couldn’t use a mouse? Keyboard controls.
This already shows us that accessibility is something that benefits all users and improves the overall user experience. But increasing the possible user base is only one of many benefits that come from building an accessible web page.
What are the benefits other than increasing your user base?
- A socially responsible company has a higher standing in the eye of the public and therefore generates a more loyal following among customers.
- With a certain amount of accessibility you possibly avoid legal troubles. There are already countries, for example the USA, which have laws in place requiring private companies to achieve a set of accessibility requirements for their websites. The EU has a similar law for websites of public bodies. Therefore check for accessibility requirements from the start to comply with legal requirements when rolling out your product to other countries.
- Accessible websites get ranked higher in search engines. This is because a lot of things like alt tags, heading structure and well defined links are used for both search engine optimization (SEO) and accessibility.
(Source: W3C Accessibility Business Case)
Is there some kind of rule set for web accessibility?
There is a W3C recommendation called the web content accessibility guidelines with the current revision 2.1. There are three levels of conformance (A, AA, AAA). Level A describes pretty basic rules, e.g. every form input has to have a label. The more advanced the level is the more specific the rules get. For some websites the highest level can simply not be achieved, but it should still be a goal to improve your projects according to these guidelines wherever possible.
Approach
To apply our newly gained knowledge from our research of accessibility and various guidelines we decided to build a small showcase application where you can explore different Pokémon and compare them by their stats. The challenge was that this application should be made accessible for as many users as possible by trying to follow the most relevant recommendations and guidelines we’ve discovered.
As most of today’s modern web applications are implemented as a Single-page application (SPA) by the help of known frameworks like React, Angular or Vue, we also used a frontend framework for our showcase application (in our case Vue). The reason for that was that we wanted to find out if there are further issues or challenges of using a framework considering the implementation of accessibility features.
Findings and challenges
During our research and development work we stumbled upon a few challenges and findings which we now want to sum up.
Usage of frontend frameworks and UI libraries
Frontend frameworks in web development support the developer in the implementation of complex and dynamic user interfaces. In combination with UI libraries both the framework and the libraries provide the developer with pre-built components which can be integrated in one’s application.
The problem is that many libraries feature clean and nicely looking UI components, but they often come up with complex and sometimes unnecessary <div> structures. This leads to a decrease in accessibility because no semantics are provided which are essential for screen readers to provide meaningful readouts to the user. Also you could lose native keyboard accessibility if for example a button in the UI is represented by a <div> instead of a <button> element.
(Source: MDN Accessibility UI Controls)
Browsers
Naturally you’re at the mercy of browser vendors, when developing something for the web. If you’re lucky, they all have a similar behavior when it comes to implementing web standards but as we suppose you’ve already experienced, a lot of times this is not true. The same goes for exposing accessibility APIs. You can try this for example by navigating a website with your keyboard. The tab focus will be different in Chrome and Firefox on a Mac. Screen readers, for example, also read focused elements differently depending on the browser.
Another difference between browsers are the built-in audit features in the developer tools. In Firefox you can find this in the accessibility tab, for Chrome this is Lighthouse and in Safari there is an audit tab. All of them check for similar criteria with subtle differences and give you a score for your website. The provided feedback is valuable and we tried to get rid of the warnings each of the audit tools gave us for our demo application.
Assistive technology
The next thing you need to take into account are assistive technologies, like screen readers or alternative input devices. One of the most prominent screen readers is VoiceOver by Apple. For Android there is TalkBack. Each of these screen readers interprets and narrates content on screen differently. While developing our app we tried VoiceOver ourselves and we noticed that the output varies depending on your device (MacBook vs. iPhone).
There are other assistive technologies, e.g. alternative input devices or color filters, which should be in the back of your head during development. For most of them the WCAG standard includes useful guidelines.
Guidelines
When searching for resources on how to make your application more accessible, we were amazed by the huge amount of guidelines. One can quickly get overwhelmed or lost by the tremendous number of available resources. After skimming through some resources we decided to use a rather simple checklist and dive into the WCAG standard when needed.
Dynamic Content
For modern applications it is now common that content is getting dynamically updated with the help of JavaScript. The user interface can for example change due to user interaction or asynchronous requests. Communicating those changes to users who depend on a screen reader can be challenging. ARIA provides us with helpful attributes here which should be used carefully to not disorient the user.
Recommendations
Based on our findings we came up with some recommendations to use for everyday development work which can increase the accessibility in your apps.
#1 Follow common guidelines and checklists
As mentioned you will find dozens of guidelines, rules, tips, etc. on how to make your web page more accessible on the internet and therefore you can quickly get overwhelmed with the amount of resources. We recommend sticking to common guidelines which fit best for your application, because most of them follow a similar goal.
Also we recommend taking accessibility guidelines into account right from the start of a project, since it should not be treated as an added extra but as a necessity. Besides that, it will get more difficult to include accessibility features retroactively in later phases of a project.
Of course you will have different needs for your application, but nevertheless we want to list two resources which were very helpful to us:
#2 Semantic HTML
It can be tempting for developers to use the basic <div> tag for the creation of components on a web page and enrich them with CSS and JavaScript to achieve the desired result. With semantic HTML on the other hand you gain accessibility features out-of-the-box. For example when you are building the layout structure of your application, use elements like <header>, <main>, <footer>, <article> instead of the generic <div> tag.
Not only will you increase accessibility with the usage of semantic HTML, you will also improve your SEO ranking and other developers will thank you for having a more readable and understandable code.
(Source: MDN Semantic HTML)
#3 Use accessible component libraries
Often in web development you are going to use a component library for your project. This is the perfect place for making your most frequently used building blocks accessible and only do it once. When you start with an accessible component library, you’ll avoid having to account for accessibility issues in lots of places later in the project. But you still need to be careful when using the components since the composition of these elements is also important for accessibility. So if you want to pick an open source component library for your next project, make sure to look at its accessibility features.
#4 Testing Accessibility
Not only test the functionality of your application in different browsers, but also keep an eye on accessibility features, since the behaviour can also vary here. Every browser’s developer tool offers helpful warnings for specific accessibility issues which helps the developer to increase accessibility of one’s application across multiple browsers. In addition we’ve found the color blindness simulation tool in the Firefox browser to be really useful and we can only recommend trying it out.
#5 Ask your users
During our development we’ve noticed that we made a lot of assumptions on how a user navigates and interacts with our application. We’ve tried to navigate our application by using a screen reader but naturally we aren’t as skilled as someone who uses it everyday. Through that we started overthinking and made our own decisions on what would be helpful for someone with a screen reader.
It would be better to include people with different abilities in your regular testing workflow to get immediate feedback on what is actually useful and not just good intention.
Final Words
We hope that our first dive into the world of Web Accessibility will be of help for your projects as well. If you are interested in our demo application and a fan of Pokémon, be sure to check it out on GitHub. Thank you for reading! Benno & Fabian.
We hope you enjoyed reading this article. If you have further questions regarding Web Accessibility or Web Development in general, feel free to contact us!
This blog post is published by Comsysto Reply GmbH
