1.1.1Non-text Content
Images, icons, charts and other non-text content need a text alternative that serves the same purpose. Purely decorative images are hidden from assistive technology.
WCAG 2.2 has 86 rules, called success criteria. Each rule explains one thing a website must be able to do. Choose a rule to see an example, a practical tip and a read-aloud option.
Looking for meaning rather than a keyword? Use the search by meaning.
No rule matches this filter. Change your selection or reset the filter.
Everyone must be able to take in the content with at least one sense: sight, hearing or touch.
Everything that is not text gets a description in text.
Images, icons, charts and other non-text content need a text alternative that serves the same purpose. Purely decorative images are hidden from assistive technology.
Audio and video need captions, descriptions or transcripts.
An audio-only recording has a transcript. A video without sound has a text description or an audio track that explains what can be seen.
Prerecorded videos with sound have captions. They show spoken words and important sounds, for example “[phone rings]”.
What can only be seen in a video must be available another way: as audio description or as a full text version of the video.
Live videos with sound also have captions that run in real time.
Prerecorded videos have audio description: a voice describes important visuals during pauses in the dialogue.
Prerecorded videos with sound are also available with sign language interpretation. For many deaf people it is their first language.
If the pauses in the dialogue are too short for description, the video pauses briefly so there is enough time to describe.
Every video has a complete text version: everything said and everything shown. This especially helps deafblind people.
Live audio without video, such as live radio or a live podcast, also has a real-time text version.
Structure and meaning live in the code – not only in the looks.
What looks like a heading, list, table or form field must also be marked up that way in code. That is how assistive technology recognises structure.
The order in the code makes sense. A screen reader reads in code order – not the way things are arranged on screen.
Instructions do not rely only on shape, colour, size, position or sound. “Click the round button on the right” does not help someone who cannot see it.
Content works in portrait and landscape. Some people have their device fixed to a wheelchair and cannot rotate it.
Form fields for personal data state in code what they expect. Then the browser can fill them in automatically.
The purpose of regions, buttons and links can be determined from code. Tools can then show familiar symbols or hide what is not essential.
Content is easy to see and hear: contrast, size, spacing.
Colour is never the only way to convey something. About one in twelve men has difficulty telling red from green.
Sound that starts by itself and plays for more than 3 seconds can be paused or turned down. Otherwise it drowns out the screen reader.
Text stands out clearly from its background: at least 4.5:1 for normal text and 3:1 for large text (24 px and up, or 18.66 px bold).
Text can be enlarged to 200% without losing content or functionality.
Text is real text, not a picture of text. Real text can be enlarged, recoloured and read aloud. Logos are exempt.
For especially good readability: at least 7:1 for normal text and 4.5:1 for large text.
Speech recordings have no background sounds or only very quiet ones – at least 20 decibels quieter than the speech.
People can set up blocks of text so they are comfortable to read: their own colours, at most 80 characters per line, not justified, line spacing of at least 1.5, larger paragraph spacing, and 200% enlargement without sideways scrolling.
Images of text are not used at all – except as pure decoration or where essential, such as a logo.
At 320 CSS pixels wide (equal to 1280 pixels at 400% zoom) content can be read without scrolling in two directions. Exempt: content that needs two dimensions, such as data tables, maps and diagrams.
Controls and important graphics need contrast too: at least 3:1 for input borders, icons, focus rings and chart lines.
People can increase spacing without text being cut off or overlapping: line height 1.5 times, paragraph spacing 2 times, letter spacing 0.12 times and word spacing 0.16 times the font size.
Tooltips and pop-up content that appear on hover or focus can be dismissed (Esc), stay when the pointer moves onto them, and do not vanish on their own.
Everything must be usable – by keyboard, mouse, touch, voice or assistive technology, and without time pressure.
Everything also works without a mouse.
Everything can be operated with the keyboard alone. Many people do not use a mouse: because of paralysis, tremor, blindness – or simply because it is faster.
Keyboard focus never gets stuck. Anyone who can tab into an area can also leave it with the keyboard.
Truly everything works by keyboard – without the exceptions in rule 2.1.1, such as freehand drawing.
Shortcuts made of a single letter, digit or symbol can be turned off, changed, or are only active while the component has focus. Otherwise speech input or a slip triggers actions by accident.
People get the time they need.
Time limits can be turned off, adjusted or extended. Some people need much longer to read and type.
Anything that starts moving, blinking or scrolling on its own, lasts more than 5 seconds and is shown alongside other content can be paused, stopped or hidden. The same goes for content that updates itself automatically. Motion is highly distracting.
There are no time limits at all. Exceptions are real-time events and media that simply play.
Interruptions such as pop-ups and notifications can be postponed or turned off. Only emergencies may interrupt.
If a session expires and people have to log in again, they lose no data and can continue where they left off.
People are told in advance how much inactivity leads to data loss – unless data is kept for more than 20 hours.
Nothing flashes or moves in a way that can make people ill.
Nothing flashes more than three times per second – or the flashing is small and dim enough to stay below the thresholds. Strong flashing can trigger epileptic seizures – this can be life-threatening.
Nothing ever flashes more than three times per second – with no exception for small or dim areas.
Motion effects triggered by scrolling or clicking can be turned off. Parallax and zoom effects can cause dizziness and nausea.
People can find their way and always know where they are.
Repeated areas such as navigation can be skipped. Nobody should press Tab 30 times on every page to reach the content.
Every page has a title that describes its topic or purpose. It shows in the browser tab and is the first thing a screen reader announces.
With the Tab key, focus moves in a sensible order – usually top to bottom and left to right.
The link text – together with its surrounding sentence or paragraph – makes clear where the link goes.
There are at least two ways to find a page – for example navigation and search, or navigation and a sitemap. Pages that are a step in a process, such as checkout, are exempt.
Headings and labels clearly say what something is about. Screen reader users jump from heading to heading to skim a page.
You can always see which element has keyboard focus. Without a visible focus, using a keyboard is like using a mouse without a pointer.
People can tell where they are within the website.
The link text makes sense entirely on its own – without the surrounding text. Screen readers can show links as a plain list.
Longer content is organised into sections with headings.
The focused element is not completely hidden – for example by a sticky header, a cookie banner or a chat window.
The focused element is fully visible. No part of it is hidden.
The focus indicator is large and strong enough: at least the size of a 2 pixel border around the element, with 3:1 contrast between focused and unfocused states.
Using touch, pointers and motion is simple and forgiving.
Functions that need multi-finger or swipe gestures also work with a simple tap or click.
An action fires on release, not on press. That way an accidental press can be cancelled by sliding away.
The visible text of a control is also part of its name in code. Otherwise voice control fails: “Click Send” does not find the button.
Functions triggered by shaking or tilting the device are also available as a button – and motion control can be turned off.
Click and tap targets are at least 44 × 44 CSS pixels.
People can switch between input methods at any time: touch, mouse, keyboard, stylus, voice.
Anything done by dragging can also be done with simple clicks. Dragging while holding is nearly impossible with a tremor or a mouth stick.
Click and tap targets are at least 24 × 24 CSS pixels – or have enough spacing that you do not hit the neighbour by accident.
Text and behaviour must be clear and predictable. Mistakes are easy to avoid and to fix.
Language is declared and text is understandable.
The main language of the page is set in code. Only then does a screen reader use the right pronunciation – otherwise English sounds as if read by a German voice.
Passages in a different language are also marked in code.
Jargon, idioms and unusual words are explained.
Abbreviations are expanded or explained.
If text is harder to read than expected after about 9 years of school, there is a simpler version or a summary.
Where the meaning of a word depends on its pronunciation, the pronunciation is given.
Pages behave the way people expect.
Just because an element receives focus, nothing unexpected happens: no page change, no new window, no submit.
Selecting or typing something does not automatically cause anything unexpected – unless people were told beforehand.
Navigation that appears on several pages is in the same order everywhere.
Things with the same function are named and labelled consistently everywhere.
Major changes happen only when someone triggers them – or they can be turned off. No automatic redirects, no unrequested new windows.
If help options such as contact details, chat or FAQs appear on several pages, they are in the same order relative to other content on each page.
Forms help people avoid and correct mistakes.
When input is wrong, text says which field is affected and what is wrong. A red border alone is not enough.
Every input has a visible label. If a specific format is required, it is stated beforehand.
Error messages do not just say something is wrong, they also say how to get it right.
For important actions such as purchases, contracts, test answers or deleting data, people can review, correct or undo their input.
Help for inputs and tasks is available right where it is needed.
For all forms – not just important ones – people can review, correct or undo their input.
What someone has already entered in a process does not have to be typed again. It is pre-filled or offered for selection.
Logging in does not require a memory or thinking test: no typing a password from memory, no puzzle – unless there is an alternative or help. Still allowed at this level: recognising objects or content you provided yourself.
Logging in works with no memory or thinking task at all – not even recognising objects or personal pictures.
Content must work reliably with browsers and assistive technology such as screen readers – today and tomorrow.
Controls expose name, role and state to assistive technology.
This rule was removed in WCAG 2.2. It required a few basics: properly closed and nested elements, no duplicate attributes and unique IDs. Modern browsers and assistive technology cope with such code errors; real problems are covered by other rules.
Every control tells assistive technology what it is called (name), what it is (role) and what state it is in (value) – for example “Menu, button, expanded”.
Messages such as “Saved”, “3 results” or “Added to cart” are announced by the screen reader without moving focus there.