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
5. How to test accessibility
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:
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.
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 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.
These people require the site to provide a textual alternative to any voice content, such as video captions and the like.
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).
This is the most numerous group of people, which includes people with:
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.
Depending on individual requirements, people use:
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 have been created for making and verifying the accessibility of the website:
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:
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:
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 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.
⚠️ 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.
ℹ 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!
<div role = "button"> Place Order </div>
Other resources I recommend you see:
Want to help us build a meaningful and responsible digital world? We have open positions!
We can choose three approaches to testing:
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.
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):
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.…
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.
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:
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 – tool built on axe-core library. Automatically tests the React application and reports accessibility errors directly to the console.
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.
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.
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.
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:
More information can be found at:
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.