Accessibility, devices and the real world
An app that works on the developer's new phone over office Wi-Fi can still fail for a blind customer, on a cheap phone, in a lift with no signal, or in a cold stock room with gloves on. This lesson gives you the checks that find those failures: the WCAG accessibility checks a tester runs by hand, the two numbers you can measure, a device matrix chosen from data, and a real-world checklist for networks, interruptions and places.
By the end you can
- Explain WCAG 2.2, its four principles and its levels, and why AA is the usual target
- Run a keyboard pass, a screen reader pass and a text-scaling pass on a checkout screen
- Measure colour contrast and target size, and say what automated tools can and cannot find
- Choose a device matrix from usage data, including the cheap and old phones
- Test slow and dropped networks, interruptions, locales and the conditions store scanners live in
The everyday picture
Picture a store manager who inspects her new store at 7 am. The lights are on, the aisles are empty, the floor is dry and she knows where everything is. The store passes. Then the store opens. A customer in a wheelchair meets a step at the door. An older man cannot read the small grey price labels. A mother with a baby on one arm tries to pay with the other hand. At 6 pm it rains, the power flickers and the queue reaches the door.
Testing an app only on a new phone, over fast Wi-Fi, with perfect eyesight and two free hands is the 7 am inspection. This lesson is the rest of the day. You test for people who use the app differently from you, on the phones they really own, in the places they really are.
Accessibility is quality: WCAG 2.2 in one page
About one person in six lives with a significant disability, and many more have a temporary or situational one: a broken wrist, strong sunlight on the screen, a noisy bus, a baby on one arm. They use assistive technology such as a screen reader, large text or a keyboard instead of touch. If your checkout cannot be used that way, those customers cannot buy, and that is a defect like any other. In the quality model of What testing is for, accessibility sits under usability: it is part of quality, and it belongs in the test plan from the start.
The shared yardstick is WCAG, the Web Content Accessibility Guidelines from the W3C. Version 2.2 became a W3C Recommendation in October 2023 (the current edition is dated December 2024). It is written for the web, but teams use the same rules for mobile apps. WCAG groups everything under four principles, known as POUR:
- Perceivable: people can see or hear the content. Text alternatives for images, enough contrast, text that grows.
- Operable: people can use every control. Keyboard access, big enough targets, enough time.
- Understandable: people know what happened and what to do. Clear labels, clear errors.
- Robust: assistive technology can read it. Every control exposes its name, role and state.
Under the principles are numbered success criteria, each at a level. Level A is the minimum; failing it blocks some people completely. Level AA adds the criteria most products need, such as contrast and text resizing. Level AAA is stricter and not expected for whole products. Many laws, public contracts and company policies point to WCAG AA, so that is the usual target, and the one this lesson uses. A product meets AA only when it passes every A and AA criterion. These are the ones a tester checks most often:
| Criterion | Level | What you check |
|---|---|---|
| 1.1.1 Non-text Content | A | Images and icons that carry meaning have a text alternative |
| 1.4.3 Contrast (Minimum) | AA | Text has at least 4.5:1 contrast; large text 3:1 |
| 1.4.11 Non-text Contrast | AA | Borders, icons and focus rings that you need to see have 3:1 |
| 1.4.4 Resize Text | AA | Text can grow to 200% with nothing lost or cut off |
| 2.1.1 Keyboard, 2.1.2 No Keyboard Trap | A | Everything works by keyboard, and focus can always leave a part |
| 2.4.3 Focus Order, 2.4.7 Focus Visible | A, AA | Focus moves in a sensible order and you can always see it |
| 2.5.8 Target Size (Minimum) | AA | Tap targets are at least 24 by 24 CSS pixels, or spaced apart |
| 3.3.1 Error Identification | A | An error names the field and says what is wrong, in text |
| 4.1.2 Name, Role, Value | A | A screen reader can tell what each control is, does and is set to |
| 4.1.3 Status Messages | AA | Messages that appear without moving focus are still announced |
WCAG 2.2 added nine criteria to version 2.1. Three matter to testers every day: 2.5.8 Target Size (Minimum), 2.4.11 Focus Not Obscured (the focused field must not be fully hidden, for example under a sticky "Pay" bar), and 3.3.8 Accessible Authentication (login must not depend on a memory or puzzle test unless there is help, such as allowing paste and password managers). It also removed 4.1.1 Parsing.
Quick check
The delivery-slot hint under the slot picker is 14 px grey text with a contrast of 3.2:1. Does it meet AA?
3:1 is the minimum only for large text (about 24 CSS pixels, or about 18.7 px bold) and for UI parts such as borders and icons. A 14 px hint is normal text, so it needs 4.5:1. Hints are still content that people read.