Introduction to Web Accessibility: A Guide

As a developer, one aspect of my coding that I admit does not initially come easy is accessibility, however, it should be a cornerstone in everyone’s web development. As I grow and continue to learn as a front-end developer, I have encountered more and more scenarios where my thoughts wander off to “How would a visually impaired person navigate this” or “How would someone with dyspraxia, dyslexia, or colour blindness use this app/site?”…the sad and ugly truth is, they wouldn’t.

Recently, I have been actively focusing on becoming a more inclusive developer and going out of my comfort zone to understand and overcome the barriers to inclusivity.

Along the way, I have found a few exciting tools to assist in recognising where my pitfalls are, where I might not think enough about accessibility and can implement some somewhat easy solutions.

After doing some personal research, I found that according to the World Health Organization (WHO), there is approximately 15% of the world's population lives with some form of disability, we can equate that to over 1 billion people who may benefit from digital accessibility features.

As our population ages, the need for digital accessibility grows. Older adults face challenges like vision and hearing loss, reduced dexterity, and cognitive decline. By 2050, the population aged 60+ will double, exceeding 2 billion.

In addition to the disabilities discussed so far, we also need to take into account situational and temporary disabilities. Scenarios of injuries or illness, loud environment or bright sunlight etc means that we have even more unquantified times where accessibility is important.

A surprising statistic that is important to share is that according to WebAim, it was found that 96.3% of the top 1 million websites in the world had detectable WCAG conformance failures on their homepages alone, this means there were an average of 56.8 accessibility errors per homepage, how crazy is that?!

The most common issues from the above finding (which are very easy to fix) included low contrast text, missing form labels and improperly structured headings.

To put this into a monetary value, if we look at Click-Away Pound Report (2019) it is estimated that UK retailers lost around £17.1 billion due to inaccessible websites. It highlights that 69% of shoppers with disabilities would click away from a site they found difficult to use, and 86% of these shoppers would spend their money on a more accessible competitor site.

How do we make our websites inclusive? 🌍

There are a few different things that we can incorporate into our coding standards that will make our web apps accessible as we build them.

Blindness 🕶️

For our users who are blind, we can make our websites accessible by being screen reader-friendly. A screen reader is a software product which will read out the content of the webpage to the user and it relies on the structure and semantics of HTML to interpret and relay the information to the user. React doesn’t inherently provide semantic HTML, therefore, we as developers can improve this experience by including it in our development process.

Semantic HTML 🏷️

It’s important to prioritize and use the correct HTML elements where possible, such <header>, <footer>, <nav>, and <section>, over the generic and much less descriptive elements like <div> and <span>which do not offer any descriptive insight into their contents. this helps screen readers understand the hierarchy and layout of the page and provides the ability to skip to elements such as <nav>.

Let’s consider the following comparison between non-semantic code and semantic code for a header and a main with two sections as a good example of this:

ARIA (Accessible Rich Internet Applications) 🌟

Aria attributes enhance our HTML with more accessible features. We can add role attributes such as role="navigation" to define the role of a particular part of our page, or if we want to indicate an elements state we could use aria-checked attribute. There is an extensive list over at mdn web docs and I would highly recommend having a read through the many useful attributes we can make use of to ensure we make each element in our website accessible. One particular aria attribute I find really cool is the aria-live attribute which can be used to announce dynamic content changes without a page reload, making live updates more accessible.

Keyboard Navigation ⌨️

Whether used for accessibility purposes, or if you are a keyboard warrior who prefers not to take their hands off the keyboard to navigate then we can ensure our websites support keyboard navigation, and for accessibility it is vital.

Here are some best practices when looking to implement keyboard navigation:

1. Skip Links🔗

‍We can include skip links on our page to allow users to hit the tab button and be presented with an anchor link that will skip the repetitive navigational menus and skip right to the main content on the page. A great example of this in practice is the gov.uk website which populates a yellow bar at the top of the page making it the first in the tabbing order.

‍2. Focus State 🎯  

‍It’s important to make sure that the focus state is always visible and logical as a user uses the keyboard to traverse the page. We can make use of tabindex if necessary, however, we should avoid using positive values to represent the ordering as they can create confusing navigation order. Instead, we should allow for natural document flow which means that they will focus in the order they appear in the HTML

‍3. Interactive Elements 🔄

Lastly, it’s important to ensure that all interactive elements (we’re talking buttons, forms, links) are accessible via the keyboard. Wherever possible, use native HTML elements as they are inherently accessible however for any custom elements, we should ensure that they can receive focus and are operable via the keyboard.

For the most part, you’re likely going to stick to the <button> provided by HTML like this:

However, if we want to create our own custom component (let’s use a button as an example), then it might look a little something like this:

Text-To-Speech 🗣️

Text-to-speech (TTS) is where written text is converted into spoken words which is beneficial to users with reading disabilities or those who have a preference for auditory content.

Implementation Tips💡

1. Readable Content 📚 — This is where as developers (and UX designers) we should be ensuring that the text is easy to read and well-structured so that TTS can interpret it. to do this we ensure that we have clear headings, lists and concise paragraphs, it is helpful to avoid jargon and complex sentences.
2. ARIA Live Regions 🔴 — By using the aria-live attribute on our elements, we can ensure that any dynamic content changes are announced without reloading the page. For instance, if a form submission fails and an error message appears, setting aria-live="assertive" on the error container will ensure that screen readers immediately reads out the error to the user.

Low Vision 👓

Users with low vision or colour blindness would benefit from high-contrast themes and resizable text.

Visual Aids🔍

1. High Contrast ⚫⚪ — There are tools out there like the WebAIM Contrast Checker which can help us verify adequate contrast, we should be aiming for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, that’s to say we would want the text and it’s background to have these standards of contrast to make it easier to read text. This can be checked against the WCAG contrast standards whereby a rating of AA or AAA can be applied based on the ratio identified. I’ve found that using this Accessible Colour Palette can help visualise what sets AAA standards from AA or less.

2. Scalable Text🔠 — Allowing text to be scaled without breaking the layout can be achieved by using units such as em , rem and % for the fonts we apply instead of using fixed units such as px . You don’t want to use font sizing for views you would get on a mobile device, on a 32" monitor for example.

Testing🧪

Okey dokey, let’s get to the final section of this article, I’m sure by now you might be wondering “This is all great, but how do we test it?” and of course, you will want use tools that are direct and easily digestable.

1. Automated Tests 🤖 — Using tools such as Axe, Lighthouse, and Accessibility Insights can help identify and address common accessibility issues in your web applications. By integrating these tools into your Continuous Integration/Continuous Deployment (CI/CD) pipeline, you can continuously monitor and improve the accessibility of your applications throughout the development and deployment process.
2. Manual Tests 🖐️ — Take the time to try your site out with a screen reader such as JAWS or NVDA and use your keyboard to navigate your site to ensure you can get around with ease and in a logical order.
3. User Testing 👥 — Nothing can compare to getting some honest real feedback, and if at all possible, involve users with disabilities in your testing process as it will provide invaluable feedback for identifying and resolving accessibility issues.

One of my favourite accessibility testing tools is the Chrome extension for Accessibility Insight, as a quick insight into the things we can test I’ve captured the tabbing ordering for the BBC news website.

WCAG Compliance ✅

We can go by an acronym (POUR) to ensure we are compliant with WCAG standards.

1. Perceivable 👀 — Provide content that can be easily presented to users in a perceivable way. For example, having text alternatives to non-text content (images)
2. Operable🖱️ — Make all functionality available from a keyboard, help users navigate and find content. Users should be able to operate the interface of your site/app and navigate easily.
3. Understandable 🧠 — Text should be easy to read and understand, ensure pages operate logically and predictably avoiding designing things that might confuse the user.
4. Robust💪 — Maximise the compatibility with current and future user agents, ensure you implement semantic HTML and follow best practices so that your content works well with different technologies

Advice for other Developers/Designers📝

Start having the conversations now because the sooner you recognise and implement an accessible mindset, the sooner it will become second nature to you. One thing I have been reading up on around this topic is that there will be extensions to the current acts we have in place, to ensure that technology is kept up-to-date and accessible.

Over the years we have been presented with the Web Accessibility Directive (2016/2012) which holds the objective of ensuring people with disabilities have equal access to public sector digital services across the EU, it specifically targets the public sector for its websites and mobile applications.

We also have the European Accessibility Act, which has a broader application to encompass a wider range of products and services in both public and private sectors. It aims to harmonize accessibility requirements across the EU to foster an inclusive society. This includes things such as ATMs, ticketing machines, e-readers as well as, but not limited to, various other banking and transport digital services.

Conclusion 👋

The act of making our sites and apps accessible is a forever-evolving process that requires attention to detail and a passion for inclusivity, provided we follow best practices and use tools to highlight shortcomings we can ensure our products are usable by everyone, and after all, it can make a huge difference to someone just trying to go about their everyday.

Accessibility is not just about compliance, for me it is about ensuring that we create a space online that works for everyone regardless of their abilities.

Thank you for taking the time to read through my article, I hope that it has provided some benefit and maybe even sparked your curiosity into how you can implement accessibility into your websites and web apps.

‍