QR Code Accessibility: Making Them Work for Everyone
QR codes can be hostile to users with low vision, motor impairments, or older phones. Here's how to design them inclusively.
QR codes work great when you have a recent smartphone, full vision, steady hands, and good lighting. They can be hostile to users who don't. This isn't an argument against QR codes — it's an argument for designing the entire scan-to-content experience with accessibility in mind, the same way you'd design a website.
Here's how to make QR-based experiences usable for everyone, from the print design through to the destination page.
Who QR codes can fail
Several user groups encounter friction with QR codes that full-vision, recent-smartphone users do not:
- Low-vision users. Locating a QR code visually, framing it in the camera, and reading the destination page all assume baseline vision.
- Users with motor impairments. Holding the phone steady at the right angle and distance can be hard.
- Users with older phones. Some Android budget phones still have weak cameras that fail in low light.
- Users without smartphones.About 15% of Americans over 65 don't have one. The rate is higher internationally.
- Users in low-bandwidth conditions.Scan succeeded; site doesn't load.
Always offer a non-QR fallback
The single most important rule: never make QR the only path to content. Print the destination URL in plain text near the code. Use a short, memorable URL (e.g. yourbiz.com/menu) so a user without a smartphone can type it on a different device, or a server can read it back to a screen reader.
For especially-critical information (medical instructions, emergency procedures, legal disclosures), provide a printed full-text version. QR codes can supplement; they shouldn't gate.
Make the QR code easier to find and aim at
- Print large. The 1/10th rule (QR width = 1/10 scanning distance) gets stricter for low-vision users. Add 25–50% on top of normal sizes.
- Add high-contrast framing. A simple rectangular border around the QR (with adequate quiet zone inside) makes the code easier to spot at a glance.
- Caption the code in plain English."Scan for menu" or "Scan to log in" — close to the code, in a body-text font size, so users know what they'll get.
- Don't rely on color aloneto indicate the QR's meaning. Pair color cues with text or icons.
Position codes within reach
QR codes mounted at standing-eye height work well for ambulatory adults but exclude wheelchair users, children, and anyone who can't comfortably tilt their phone upward. The Americans with Disabilities Act recommends important interactive elements be reachable within an envelope of roughly 38–122 cm above the floor for forward reach. The same logic applies to QR codes on counters, ATMs, and registration kiosks.
Design the destination page accessibly
A scan that lands on an inaccessible page hasn't solved anything. Treat the destination as a regular accessibility target:
- Use semantic HTML. A real
<h1>,<nav>, and<main>beat divs for screen-reader users. - Hit at least WCAG AA contrast for body text, interactive elements, and form fields.
- Make tap targets at least 44×44 px.Phones are held one-handed; sloppy taps are common.
- Don't auto-zoom or auto-rotate.Let the user's OS handle these.
- Support font scaling. Use
rem-based sizing so iOS and Android Dynamic Text settings actually do something. - Respect reduced motion. Heavy animations on the landing page are dizzying for many users; check
prefers-reduced-motion. - Keep the page small.Under 250 KB ideally — large pages fail more often on weak networks.
Provide voice and screen-reader-friendly alternatives
For users who can't aim a camera, alternatives include:
- A short, spoken URL."Visit example dot com slash menu" — printable next to the QR.
- An NFC tag in the same physical location. Holding a phone close to a surface is easier than aiming a camera at it.
- A phone number to call for the same information by voice — useful for restaurants, civic services, and emergency contexts.
Don't overload one QR with too much data
It's technically possible to encode an entire WiFi configuration, a vCard, a payment URL, or a long block of text into a single QR. Don't. The denser the code, the harder it is to scan with cameras that struggle with focus or low light. For accessibility, smaller, simpler codes win every time.
Test with assistive tech
Before committing to a QR-based experience, walk through it with:
- VoiceOver (iOS) or TalkBack (Android)
- Dynamic Text scaled up to maximum
- A phone with a low-end camera
- Throttled network (3G or slower in DevTools)
- Color filters or grayscale modes turned on
You don't need to nail all of these on day one — just don't skip them. Most QR-experience accessibility wins come from catching the obvious issues (the destination page is unreadable on a 320-pixel screen; the URL alongside the code is in 6 pt type) before they go to print.
Quick checklist
- QR is dark on light, with high contrast.
- Plain-text URL is printed alongside, in body-text size.
- Caption tells the user what they'll get.
- Code is positioned within reach of seated users.
- Destination page is small, semantic, and meets WCAG AA contrast.
- Critical information has a non-QR alternative (printed, spoken, callable).
- Tested with VoiceOver/TalkBack and large text settings.
QR codes can be a wonderfully low-friction shortcut for users who can use them — and a wall for users who can't. Designing with both in mind takes very little extra effort and matters a lot. QR This! is the easy part; the other 90% is the page on the other side.