Welcome back 👋
Following up on my previous article, A Quick Look at the Four Principles of Web Accessibility, this one covers the first principle: Perceivability.
I’ll walk through implementation guidelines, success criteria, and practical tips I’ve gathered over years of working in this field.
What is Perceivability?
Perceivability means presenting information and interface components in ways users can actually perceive. This includes providing text descriptions for images, audio descriptions for video content (for blind users), captions or sign language for audio (for deaf users), and labels for all interactive controls.
If content is non-textual, you need an alternative the user can perceive. Assistive technologies let people with disabilities consume that alternative in different ways: enlarged text, speech output, or braille display.
There are exceptions to this rule:
Input Controls
If non-text content is tied to an input or control, the alternative should describe its function, not its appearance.
For example: a magnifying glass icon is universally associated with search. But when labeling it for assistive technology, don’t write “magnifying glass.” That tells a blind user nothing about what it does.
Sometimes a visible label isn’t necessary or would hurt the design. In those cases, you can use aria-label in web interfaces to provide a label only assistive technology users will hear.
In Swift, the equivalent is accessibility(label:). In ObjectiveC, it’s AccessibilityLabel.
https://developer.apple.com/documentation/swiftui/list/accessibility(label:)
Time-Based Media
If the non-text content is video or audio, provide a brief text description before the media, then include audio descriptions, sign language, or captions within the media itself.
For example: before a movie trailer, write “Video: movie trailer for [title].” Then include the audio-described version below.
Tests
If describing non-text content would reveal the answer to a test question, describe it enough to convey the context without giving away the answer.
For example: if an image shows the Kingdom Tower in Riyadh and the question asks what it is, describe it as “A tower in Riyadh, 302 meters tall.”
Sensory Experiences
If non-text content is tied to a sensory experience, describe that experience in enough detail to create a mental picture.
For example: if an audience applauds in a film, describe it as “loud applause” for deaf viewers.
Visual CAPTCHA
If the non-text content is a visual verification challenge, label it as “visual CAPTCHA” and provide an alternative that uses a different sense (like an audio challenge). Avoid math-based alternatives, as they can be difficult for users with cognitive disabilities.
Decorative Content
If non-text content is purely decorative and carries no meaning, hide it from assistive technology. In HTML, use an empty alt attribute. In Swift/ObjectiveC, use the Hidden property.
Color is not enough
When building your interface, color should never be the only way to convey information. Always pair it with text.
If red indicates an input error, there must also be a text message explaining what went wrong. Color-blind users and screen reader users won’t see the red.
Source order matters
The order of elements in your code directly affects the experience for assistive technology users. They read elements based on code order, not visual position.
Some developers write elements left-to-right in code to make RTL layouts “work.” This causes screen readers to read everything backwards. Use CSS for visual positioning instead.
Programmatic labels
Link labels to their controls programmatically. Some developers place a label next to a field visually but don’t use <label> elements in HTML, so assistive technology can’t associate the two.
Contrast
Text and interactive elements need a contrast ratio of at least 4.5:1 against the background. Large text and images need at least 3:1. Logos are exempt.
Flutter
For Flutter developers, the Semantics class lets you add all of these properties to your widgets.
This was a quick look at Perceivability, the first WCAG principle. There’s much more I didn’t cover. For the full reference, visit the WCAG Quick Reference from the W3C.
Next up is Operability, the second and most important principle (and the most neglected, unfortunately): Operability in detail.
Happy to answer any questions. 😊