It’s human to make assumptions based on our own knowledge, right? We all do it - after all, this is how evolution shaped our brains: sometimes we needed to make quick decisions based on the information that we had: Can I eat this? Will this kill me? Should I better run away really quickly? It’s in our nature, and that’s not necessarily a bad thing. That being said, making assumptions unconsciously and without reflecting on them can also exclude different perspectives and users.
Impact on Technology
Let’s have a closer look at who is building our code. Bare in mind that global data is really difficult to collect and that there is no holistic, reliable worldwide survey - however, looking at different data, there are a few things I would like to point out:
- According to a report by Statista, in the US, around 20% of workers in Software & Web Development jobs are women.
- 43% of Professional Developers are 25-34 years old (Stackoverflow, 2022)
- 68.8% of the State of JS respondents are white
- Majority is able bodied / did not report any (temporary) disability
Disability Status in State of JS
In the State of JS developer survey, there is a question regarding disability status, which was answered by 18% of the total survey respondents. According to these results, around 3.9% of respondents have visual impairments, 0.9% hearing impairments, 0.7% mobility impairments, and 1.9% cognitive impairments. While of course there could be many reasons for people deciding not to report their disability, this gives us a rough overview of the demographic.
The majority of people who write our code, at least according to these surveys, are relatively young, white, able-bodied males. And this has consequences.
The Empathy Gap
This lack of diversity when it comes to different perspectives and abilities leaves the web currently a pretty inaccessible place. Only 3% of the web is accessible.
Most Common Accessibility Failures
The WebAim One Million report evaluates the most common WCAG failures on the one million most popular homepages. They have found pretty astounding numbers when it comes to accessibility issues, most common are:
- Low Color Contrast
- Missing Alternative TExt
- Empty Links
- Missing Form Input Labels
- Empty Buttons
- Missing Document Language
Let’s have a closer look.
Low Color Contrast Ratio
With 83% of home pages having this issue, it’s by far the most common failure. This means the contrast between the background and the foreground is not sufficient to be able to comfortably read and be accessible also to people with visual impairments. WCAG set a minimum contrast ratio of 4.5:1. There are several tools to test this and adjust colors accordingly. Fixing color contrast issues on your website will likely eliminate a bunch of issues already.
Missing Alternative Text
We need alternative text on images to describe the contents to folks who can’t see it otherwise. It’s also helpful if an image can’t be loaded, for example, due to a slow internet connection. It’s as simple as filling an alt=”” tag with a description of the image that you are using. If the image is purely decoration, you can leave the alt text empty.
Empty Links
Over half of the websites that were analyzed in the WebAIM one million report had empty links. Usually, when creating a link, we would wrap an <a> tag around the Link that we are describing, right? Well, in many cases, icons or images are used as links, not mere words. When no text, title or aria-label is added, this leaves screen reader users guessing as to where the link will take them.
Missing Form Input Labels
When you have a form that requires user input, you need to let your users know, not guess, what kind of input is required from them. This is why you should have a <label> associated with each <input> field.
Empty Buttons
This is very similar to the empty links: You need to let your screen reader users know where they are going and what they can expect. Make sure your buttons aren’t empty, also and especially when you are using icons or images as a button.
Missing Document Language
On 18.6% of the pages in the report, the document language isn’t set. This is a problem because screen readers use this information to make sure they are pronouncing the content correctly.
The True Cost of Implementing Accessibility
When it comes to implementing Web Accessibility, many people argue that it’s too expensive, takes to much time and too many resources. I would like to convince you of the contrary. Not implementing Web Accessibility is actually much more costly. First of all, it’s more time-consuming and expensive to fix accessibility bugs as an afterthought than integrating Web Accessibility into your design & development processes from the start. But there is much more to this equation:
- Access to (digital) information is a Human Right as defined by the United Nations. Take a stand!
- Depending on where you are, failing to comply with Web
- Accessibility standards can result in legal consequences and potential lawsuits. Much more expensive than fixing accessibility bugs.
- You are missing out on business opportunities: According to a report by the World Health Organization, over 15% of the global population are experiencing a form of disability throughout their lifetime. That is a lot of lost revenue if you exclude all of these potential customers.
- Focussing on Web Accessibility will improve your overall user experience and therefore user engagement.
- Not caring about Accessibility will likely hurt your brand image & corporate social responsibility.
Integrating Empathy
First of all, let’s point out that this is a shared responsibility. No one discipline should be entirely in charge of making sure your product, service, or website is accessible. The more perspectives are involved, the better. Regardless of whether you are involved in design, development, content creation, or testing - accessibility matters everywhere.
So what can you do to implement a little more empathy?
- Clearly Define your Accessibility Goals. The clearer the goals, the easier to reach them. Many use the WCAG AA standard as it is the most common and widely recommended (and in some countries required by law)
- Identify the most common user journey. If you can’t test everything at once, have a look at your page analytics and start with the 3 most important actions. This will already have a big impact on your users.
- Run an initial audit: use an automated audit like the axeDevTools one or a Lighthouse report as your initial guideline on where to start. Mind you, automated tests of course don’t eliminate the manual testing process - but they are a good start.
- Identify low-hanging fruit and prioritize. What is something you can fix relatively quickly that will have a big impact on a large number of users? Start there!
- Emphasize high code quality - this will improve your accessibility enormously, as many failures are based on issues with semantic HTML
- Automate where you can - use linters, automated tests, and integrate accessibility in your CI / CD pipelines.
- Diversity your user personas. Use a tool like Cards for Humanity to explore different user personas beyond the binary.
- Invest in testing. Make sure, if you can, to employ people who use assistive tech natively - you will get a lot of valuable feedback for your product.
There are a lot of actionable steps you can take to make your product, service or website a little more accessible, one step at a time. No reason not to get started 🚀
Top comments (0)