The idea behind accessibility is providing an alternative way to perform actions we normally take for granted. A simple example is walking. A person without a disability walks on two legs. A person with a mobility impairment performs the same action using a wheelchair. We apply that same concept to the content on our website. For example: when we see large, bold text at the top of a page, we instantly recognize it as a heading. But how would a blind user understand that?
A blind user relies on screen reader software. This software reads aloud everything happening on the screen. It scans lines of code and uses tags and definitions to interpret the meaning of each element. For the software to "know" it is reading a heading rather than a regular sentence, we wrap the heading in an H1 tag — and in doing so, we have created an alternative way to identify a heading.
There are 4 principles that underpin all Web Content Accessibility Guidelines version 2 (WCAG 2), which is today's leading accessibility standard.
Perceivable
Users must be able to identify the nature of elements on a web page using their available senses or with the help of assistive technologies.
With today's technology, any information can be translated into any available sense. Text can be read aloud by screen readers, delivered as an audio file, or even printed in Braille. Audio content can be transcribed as text or presented via sign-language video. Video files can be accompanied by a transcript or an audio description track.
Under this principle, users do not yet need to understand the full meaning of what is presented to them — but they do need to recognize what each element is. For example, they need to distinguish between a button and a link, or between a heading and a paragraph. They do not yet need to know what the button triggers or where the link leads — only to identify it based on the code or visual design.
Operable
The entire interface must support keyboard navigation and assistive technologies. Think about how frustrating it is when you simply cannot click a certain link — or when you have to hit an incredibly precise spot just to make it work — all because a developer made the target area far too small. Now imagine your hand trembles constantly, as it does for someone living with Parkinson's disease.
How would you manage?
The way users interact with your site should be as simple as possible — and most importantly, it must work with a keyboard alone. We also need to ensure that all content is reachable via the keyboard. Take blind users as an example: keyboard-accessible UI is an absolute necessity. Consider a scenario where a button opens an article in a lightbox — but the lightbox itself is not accessible. If users cannot reach the lightbox with the keyboard, then the content inside it is inaccessible as well.
Understandable
Users must be able to understand both the information presented to them and how to use the website — as simply and clearly as possible. A user needs to understand what a link is and where it will take them. If they are using a calculator on your site, they need to know what each button does. Is that button multiply or divide? Is what they are looking at a heading or a paragraph?
Robust
A website and its content must be built in a stable, reliable way that supports a wide range of browsers and assistive technologies.
This means using sound design structure — one where, even after stripping away all styling, the key sections of the page and its content flow remain clear. Another example: linking a text label to a form field using the appropriate HTML tags. In addition, backward compatibility must be provided for any new tags or features you use. It is important to remember that assistive technologies often lag behind the pace of web development, and we need to bridge that gap during the transition period.
It is worth emphasizing that there is no single, fixed way to achieve this. New tags are introduced constantly, programming languages improve, and capabilities expand. Staying current and tracking changes is essential. At the same time, keep in mind that assistive technologies for people with disabilities do not evolve as quickly as the broader web. For instance, you should verify that using new HTML tags unsupported by older browsers or legacy screen readers does not break the functionality of your site.