What is accessibility and how to make your web accessible

Contents

1. Motivation
2. Who we make the web accessible for?
3. How people with disabilities use web
4. Specifications and standards 
    a. WCAG - Web Content Accessibility Guidelines 
     b. WAI-ARIA - Web Accessibility Initiative - Accessible Rich Internet 
        Applications
5. How to test accessibility
6. Legislation

‍

Motivation

If you create an accessible website, everyone will benefit from it:
 

• It removes barriers on a web for people with disabilities

• The semantic web helps accessibility and also improves the SEO and searchability of the web.

• Accessibility rules also improve usability (UX).

• The benefits of an accessible website are also used by ordinary users, for example:

• I'm watching a video with captions when I can't turn on the sound.
• I increase size of the content when I forget my glasses.

In addition, public administration websites must be accessible by law, and from 2025 the law will apply to some other types of websites, such as e-shops.

Who we make websites accessible for?

There are many different disabilities that prevent people from using the web to its full potential. According to statistics, 337 147 people with disabilities are officially registered in Slovakia alone (data from 2020). There are more than 60 million in the USA and more than 1 billion in the world.

In this video Peter Halada from the Union of the Blind and Partially Sighted of Slovakia introduces you to the (not only digital) world of the blind (in Slovak)

People with visual impairments

In addition to the blind, this also includes people with impaired vision or color blindness (daltonism). Such people usually use a screen reader or enlarge the content of the page. Demonstration of how blind users use a screen reader on the web. Alternatively, you can see how color-blind users see the site.

People with hearing impairments

These people require the site to provide a textual alternative to any voice content, such as video captions and the like.

People with mobility impairments

Such people cannot make full use of the mouse or touchpad, so it is important for them to be able to access the web using only the keyboard. It can also be people who have suffered an injury, such as a broken arm (or just people who do not use a mouse).

People with cognitive impairments

This is the most numerous group of people, which includes people with:

• Learning disabilities e.g. dyslexia, ADHD…
• Memory problems that are often related to age.
• Mental disorders.
• Temporary perception disorders associated with alcohol or drugs.

These people need the content of the site to be understandable, consistent, and to minimize disruptive content. If we incorporate these requirements, we will also improve the overall UX of our website.

If you're wondering what reading can be like if you have dyslexia, check out the demo.

How people with disabilities use the web

Depending on individual requirements, people use:

• Assistive Technology: it can be software or hardware that helps people interact on the web. For example, a screen reader that reads the content of a web page for blind users.
• Adaptive strategies: these are techniques where users modify the software, e.g. by enlarging the text, turning on subtitles, etc.

You can find more about how people with disabilities use the web on the web: How People with Disabilities Use the Web.

Specifications and standards

Specifications and standards have been created for making and verifying the accessibility of the website:

WCAG 2.1 - Web Content Accessibility Guidelines

The WCAG specification contains a wide range of recommendations and criteria to increase the accessibility of web content. The individual recommendations consist of criteria that need to be met.

📄 Example of WCAG recommendation:

‍Guideline 1.4 – Distinguishable
Make it easier for users to see and hear content including separating foreground from background.
‍
‍1.4.3 Minimum Contrast  (Level AA)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1,
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• Logotypes: Text that is part of a logo or brand name has no contrast requirement.

The individual recommendations (criteria) are divided into three levels:

• Level A – The basic criteria that a site must meet in order for site content to be accessible and usable by people with disabilities.
• Level AA – Criteria that remove most barriers on the web and make the web accessible.
• Level AAA – These criteria are not mandatory, but we should try to implement the WCAG AAA recommendations if possible.

How to start?

The WCAG specification is quite extensive and detailed, which can discourage many developers. Therefore, I recommend starting by studying WebAIM's WCAG 2 Checklist. It is an abbreviated and simplified version of the complete WCAG specification. You will find specific tips in it, which you can immediately use in development. There are other checklists, such as:

• WCAG Checklist - a free and simple guide to WCAG 2.2
• Checklist - The A11Y Project
• Web Accessibility Checklist

However, if you really want to understand this topic in detail, please also read the complete WCAG Web Content Accessibility Guidelines (WCAG) 2.1 specification. However, this version seemed quite confusing to me. I prefer the version: How to Meet WCAG (Quickref Reference), which is clearer and you can filter the individual criteria.

WAI-ARIA – Web Accessibility Initiative – Accessible Rich Internet Applications

WAI-ARIA is a W3C specification that adds additional attributes to HTML to improve the semantics and accessibility of website content. Modern web applications often include more advanced functionality that we cannot describe with standard HTML elements or attributes. Alternatively, they still lack browser support.

We often replace such elements with elements such as div or span, to which we can assign arbitrary functionality using CSS and JavaScript, e.g. datepicker, dialog, etc. Ordinary users who use a mouse do not see any difference, but for blind users who use a screen reader, this element is unusable.

⚠️ Always try to use native HTML elements to create semantic content. Use WAI-ARIA only if there is no suitable HTML alternative. Usually when creating more complex page components such as slider, datepicker, etc.

For example, we can replace the HTML element <dialog>, which is not yet sufficiently supported, with the classic div element, to which we add semantics using ARIA role="dialog", aria-labelledby and aria-describedby.

<div role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDesc">
  <h2 id="dialogTitle">Your personal details were successfully updated</h2>
  <p id="dialogDesc">You can change your details at any time in the user account section.</p>
  <button>Close</button>
</div>

ℹ WAI – ARIA adds additional information about page elements and does not affect the rendering of the DOM of the page.

⚠️ Not using ARIA is better than using ARIA incorrectly! 

E.g. if we set the <div> element of the button role, but we do not ensure its functionality, e.g. via JavaScript, so the screen reader will misinterpret this element to the user. 

‍<div role = "button"> Place Order </div>

‍

Other resources I recommend you see:

• WAI-ARIA basics - Learn web development | MDN - A very clear introduction to WAI-ARIA.
• WebAIM: Introduction to ARIA - Accessible Rich Internet Applications – In addition to the WAI-ARIA explanation, you will also find many useful tips here.
• ARIA Authoring Practices Guide – The guide that describes how to apply WAI-ARIA to common design patterns and widgets.

How to test accessibility

We can choose three approaches to testing:

• Automated testing.
• Manual testing.
• Audit from an external company.

It is ideal to combine all approaches, as automated testing will save you a lot of time and also reveal errors that we may overlook during manual testing. However, automated testing cannot detect all errors.

Automated testing

There are many tools for automated testing - A list of tools for evaluating web accessibility. Therefore, I chose only these most used (+ some for React developers):

Lighthouse

A more comprehensive tool for automatically generating a web accessibility report. You can find Lighthouse directly in Chrome DevTools and in addition to accessibility, you can also test web performance, SEO, etc.…

‍

WAVE Web Accessibility Evaluation Tool

This tool from WebAIM can detect errors according to the WCAG specification. It is available as an add-on in a browser or even an online version on the web.

axe® Tools

A set of accessibility testing tools built on the world's most popular accessibility library: axe-core. More advanced tools and functionality are already paid for, but many useful tools are available for free. The offer of tools and functionalities is wide (projects that use axe-core), for example:

• Linter for VS Code.
• Browser add-on.
• Monitoring.
• Testing of Android mobile applications and iOS.
• CI/CD integration.

According to the information on their website, you can use these tools to detect 80% of errors during website development. They also boast 100% reliability, which means that the tool does not report fake errors.

@axe-core/react

@axe-core/react – tool built on axe-core library. Automatically tests the React application and reports accessibility errors directly to the console.

ESLint plugin

eslint/eslint-plugin-jsx-a11y - statically analyzes the code for common errors in JSX code (especially useful in React projects). Ideal combination with the @ axe-core / react tool, which tests the rendered DOM.

Manual testing

Automated tools can never reliably verify web accessibility. Therefore, it is advisable to verify accessibility manually, ideally by a tester who has good knowledge in this area. Accessibility testing by people with disabilities is even more advanced. In manual testing, we can help e.g. checklist: Checklist - The A11Y Project or Web Accessibility Checklist.

Audit from an external company

Another option is to have an audit carried out by an external institution. In Slovakia, for example, the Union of the Blind and Visually Impaired of Slovakia carries out an audit: An audit of the accessibility of websites and mobile applications.

European Accessibility Act

Parliament has approved a European accessibility act, which also regulates the rules for accessibility on the web. Approval is currently underway in EU member states (including Slovakia), and the law should apply from June 2025. The new law should define the requirements for the accessibility of certain services and obligations for providers of these services. These are mainly electronic communication services, services providing access to media services, transport services, banking services or e-commerce services.

The new rules will apply, for example, to:

• E-shops.
• Cash machines and payment self-service terminals.
• Computers and operating systems.
• Smartphones, tablets, television equipment.
• Access to audiovisual services, e-books.
• etc.…

More information can be found at:

• How to make products and services accessible to people with disabilities |  News | European Parliament‍
• Directive of the European Parliament and of the Council 2019 / 882‍

Where to start? 

You can find a good introduction to the topic on the MDN portal: Accessibility - Learn web development and also on web.dev from Google. There is also a lot of useful material on the WebAIM website. Subsequently, you can start studying the material according to the sources we mentioned in the article. You will also find an interesting overview of resources from books to video courses at The A11Y Project.