Small design flaws, such as low contrast, images without descriptions, or a removed focus indicator, become barriers for some users, making it impossible for them to use the website. In this guide, I go through seven WCAG rules that you should know, along with the number and level of each criterion, show how to check the website using tools and manually, and provide a checklist for level AA.
Imagine opening a website and seeing nothing. Not because of a technical error, but because no one who made it thought about people who use the website with a screen reader, keyboard only, or with magnified text.
According to World Health Organization data, at least 2.2 billion people worldwide have a near or distance vision impairment. This figure refers only to vision and includes milder impairments as well, so this is only a fraction of the people for whom an accessible website makes life easier. This text is a practical guide: seven rules to know, how to check a website, and a checklist before delivery.
As a UX/UI designer, I can say that accessibility usually doesn't suffer because of bad intentions, but because no one thought about it while the website was being designed.
What WCAG requires and which level to target
WCAG (Web Content Accessibility Guidelines) are international guidelines developed by the W3C consortium. The current version is WCAG 2.2, and version 3.0 is under development. Each requirement in the guidelines is called a success criterion, has its own number, and one of three levels:
- Level A: minimal requirements. Without them, the website is unusable for many.
- Level AA: recommended target. It includes all Level A requirements, and accessibility regulations most often rely precisely on it.
- Level AAA: highest level. It is good as a direction, but the W3C itself does not recommend it as a general requirement for the entire website, as some content cannot meet it.
All criteria are grouped into four principles: content must be perceivable, operable, understandable, and robust. What these principles mean and why they are important for business, I explained in the article what the WCAG standard is and why it matters. Here I deal with application, and alongside each rule I list the criterion and level so you know what is an obligation for AA, and what is a recommendation.
Seven WCAG rules every designer should know
1. Color Contrast
Criterion 1.4.3 Contrast (Minimum), Level AA, requires a contrast ratio of at least 4.5:1 for regular text and 3:1 for large text. Criterion 1.4.11 Non-text Contrast, also AA, requires 3:1 for user interface components such as input borders, icons, and button states. Light gray text on a white background is a classic mistake: it looks "elegant", but a person with low vision can barely read it, as can anyone looking at their phone in the sun.
To check contrast, you can use:
- WebAIM Contrast Checker (free)
- Figma "Contrast" plugin
- Adobe Color, accessibility section
Tip: look at the design in grayscale as well. If you can still read everything without effort and distinguish the states of elements, the contrast is probably good. However, measurement gives the final confirmation.
2. Alternative text for images
Screen readers do not "see" images, but read the alt text that you write. This is required by criterion 1.1.1 Non-text Content, Level A. Good alt text says what the image conveys in that context. Decorative images get an empty alt attribute, so the screen reader skips them.
Bad example: alt="image"
Good example: alt="A woman working on a laptop in a cafe, a cup of coffee next to the keyboard"
3. Keyboard navigation and visible focus
Many people do not use a mouse: blind people, people with motor disabilities, but also anyone who works faster using a keyboard. They navigate through the site using Tab, Shift+Tab, Enter, and arrow keys. Criterion 2.1.1 Keyboard, Level A, requires that everything that can be done with a mouse can also be done with a keyboard.
How many times have you heard from a client: "Remove that ugly blue outline around the button"? That line is the focus indicator, and without it, a keyboard user does not know where they are. Criterion 2.4.7 Focus Visible, Level AA, requires that focus always be visible. Therefore, do not remove it, but design it so that it fits the visual identity.
WCAG 2.2 also added 2.4.11 Focus Not Obscured (Minimum), Level AA: an element in focus must not be completely hidden behind a sticky header, cookie banner, or chat window. Criterion 2.4.13 Focus Appearance, which prescribes the size and contrast of the focus indicator, belongs to Level AAA. It is not mandatory for AA, but it is a good measure when designing focus.
4. Semantic HTML
Screen readers rely on the meaning of HTML elements. Criterion 1.3.1 Info and Relationships, Level A, requires that the structure the user sees also exists in the code: buttons as <button>, headings in a proper hierarchy, form fields linked to their <label> elements.
When handing over a design from Figma, add notes about semantics: what is a heading of which level, what is a button, and what is a link, in what order the focus flows. That way, the developer doesn't have to guess, and you don't discover errors only on the finished site.
5. Text size and scaling
Criterion 1.4.4 Resize Text, Level AA, requires that text can be resized up to 200% without loss of content or functionality. A related one is 1.4.10 Reflow, also AA: content should wrap into a single column without horizontal scrolling when the user zooms in significantly on the page.
In practice, this means rem units instead of px for font size and containers that grow with the text. Do not set a fixed height or max-height on text blocks without overflow: auto, because magnified text will then get cut off.
6. Forms and error messages
An error in a form can go completely unnoticed if it is marked only by a red border of the field. Criterion 1.4.1 Use of Color, Level A, requires that color is not the sole carrier of information. 3.3.1 Error Identification, Level A, requires the error to be described in text, and 3.3.3 Error Suggestion, Level AA, that you suggest a correction to the user when it is known.
Bad message: "Error in form". It doesn't say where the problem is or how to solve it.
Good message: "Email address must contain an @ character. Example: name@domain.com". It stands next to the field to which it refers and says what needs to be done.
7. Animations and movement
Animations can cause dizziness and nausea in people with vestibular disorders, and distract everyone else from the content. Two requirements apply to Level A. According to criterion 2.2.2 Pause, Stop, Hide, content that starts automatically, lasts longer than five seconds, and is presented alongside other content must be able to be paused, stopped, or hidden. This applies to carousels, background videos, and auto-scrolling tickers. According to criterion 2.3.1 Three Flashes or Below Threshold, nothing on the page should flash more than three times per second.
The ability for a user to disable animations triggered by interaction, such as parallax scrolling, is described by criterion 2.3.3 Animation from Interactions. This is Level AAA, so it is a recommendation, not an obligation for AA. However, it is worth sticking to because it is cheap to implement: it is enough for the site to respect the system preference prefers-reduced-motion.
How to check website accessibility
Checking has two parts. Tools quickly find what can be measured, and you have to test the rest yourself.
Automated check
- axe DevTools (Chrome extension): finds bugs in code and links them to WCAG criteria.
- Lighthouse in Chrome DevTools: free, provides an accessibility score and a list of issues.
- WAVE (WebAIM): highlights errors directly on the page.
Tools only detect part of the problems. They can determine that an image has alt text, but not whether that text makes sense. A score of 100 in a Lighthouse report therefore does not mean that the site is accessible.
Manual check
- Put the mouse aside and go through key user flows using only the keyboard: menu, form, purchase.
- Turn on VoiceOver (Mac, iOS) or NVDA (Windows, free) and listen to how your site sounds.
- Switch your screen to grayscale and see what is lost.
- Zoom the browser to 200% and check if the layout falls apart.
Common misconceptions about accessibility
"Accessible design must be ugly"
Requirements concern contrast, structure, and behavior, not style. The GOV.UK website is a well-known example of a design built around accessibility, and because of that, it is clear. Constraints here do the same as any good brief: they narrow the choices down to solutions that work.
"That's the developer's job, not the designer's"
A large part of accessibility is decided in design: colors, sizes, content hierarchy, element states, message copy. What is poorly set up in a mockup is hard to "fix" in code.
"Our site has no blind users"
Analytics do not reliably identify screen reader users, so you don't see them in the data. Just because you don't see them doesn't mean they aren't there. It could also mean they gave up at the first barrier.
Practical checklist
Before delivering a design or launching a website, go through these items. They all refer to Level AA, unless indicated otherwise.
Visual
- Text contrast of at least 4.5:1, for large text 3:1 (for Level AAA 7:1)
- Contrast of user interface components of at least 3:1
- Focus indicator visible on every interactive element
- Errors and states marked with text or an icon as well, not just color
Content
- All images have alt text, decorative ones have an empty alt
- Headings follow a logical order (H1, then H2, then H3), without skipping
- Link text describes the destination (not "click here")
Interaction
- The entire interface can be used with a keyboard
- Focus remains trapped inside an open modal window, and the window closes with the Esc key
- There is a "Skip to content" link at the beginning of the page
- The focused element is not hidden behind a sticky header or banner
- Touch and click targets are at least 24 by 24 CSS pixels
- Auto-moving content can be paused, and animations respect
prefers-reduced-motion
Forms
- All fields have visible labels
- Error messages are clear and stand next to the field they refer to
- Personal data fields have
autocompleteattributes
Where to start
You don't have to do everything at once. Install axe DevTools, put your mouse away for an hour, turn on VoiceOver, and open your website. I believe this experience will change the way you look at design, because barriers you wouldn't otherwise notice become obvious after just a few minutes.
What this looks like on a real project is shown by the UX/UI design of the Balkanaukcija platform.
If you are also interested in the business side, including regulations in the EU, read why digital accessibility is important for businesses. And if you want someone from the outside to check the accessibility and user experience of your website, see what a UX audit of a website looks like.
