QR Code Accessibility: Making Your Codes Usable for Everyone

A QR code sits at an unusual intersection: it's a visual pattern that has to be seen clearly, physically aimed at with a camera, and understood as 'something to scan' — three separate points where a person with low vision, limited dexterity, an older or budget phone, or simply no interest in scanning can get stuck. Most of this qr code accessibility guide overlaps directly with what already makes a code scan reliably in the first place — insufficient contrast or a code that's too small fails for a low-vision user and a phone camera in poor lighting for the same underlying reason. Treating accessibility and scan reliability as the same problem, rather than two separate checklists, is the practical way to actually get both right.

A QR scanner (and a human eye) needs a clear, unambiguous boundary between the dark modules and the light background to read the pattern at all. The safest choice is still a dark color on a light background — true black-on-white gives you the largest possible contrast margin, which helps both a phone camera in bad lighting and a person with low vision or color-vision deficiency. If you're using a brand color instead of black, keep it genuinely dark (deep navy, charcoal, forest green) rather than a mid-tone, and avoid pairing two saturated colors with similar brightness — a bright red code on a bright blue background can pass a casual glance but fail for both scanners and people with certain color-vision deficiencies. SMLLR's QR Design Studio lets you set the dots and background to any hex color you want, including gradients, but it doesn't run a contrast check for you — that judgment call is on you when you pick your colors, and it's worth treating as seriously as picking colors for body text on a website.

A QR code that's perfectly designed on-screen can still be unreadable in print if it's too small for how far away someone will be standing when they scan it. A rough, widely-used rule of thumb: the code's printed width should be at least about one-tenth of the intended scan distance. A code meant to be scanned from arm's length (roughly 30cm) can be small, maybe 2-3cm across; a code on a retail poster meant to be scanned from a meter away needs to be closer to 10cm across; a code on a billboard or large banner scanned from several meters away needs to scale up accordingly. Undersizing a code disproportionately hurts people with low vision, older users holding a phone at a further, more comfortable distance, and anyone scanning in a hurry — building in a size margin rather than the bare minimum is the more accessible default.

Some people can't or won't scan a QR code — no smartphone, a phone with a broken camera, low vision that makes aiming a camera difficult, or simply not wanting to pull out their phone in that moment. A QR code should always be one path to your content, never the only one. The simplest fallback is printing the same destination as readable text right next to the code — a short URL or a phone number in a legible font size, not buried in fine print. Because a SMLLR dynamic QR code's destination lives behind an editable, human-readable slug (the same slug you set when creating the code, editable from the QR editor), you already have a short, printable URL available to put underneath the code itself — you're not stuck printing a long, unreadable auto-generated link as the fallback text.

When a QR code image appears on a website — say, a 'scan to get our app' section, or a printable coupon page — it needs alt text like any other meaningful image, and 'QR code' alone isn't good enough. Alt text should describe what scanning the code actually does: 'QR code linking to the SMLLR app download page,' not just 'QR code image.' Better still, don't rely on the image alone — place the same destination as a normal, clickable text link or button next to the QR code image on the page. A screen-reader user browsing that page gets nothing useful from a QR code image no matter how good its alt text is (they can't scan their own screen with their own screen), so the adjacent text link is what actually makes that piece of content usable for them, not the alt text.

Beyond alt text on the image itself, think about how the surrounding page reads to someone using a screen reader. Give the QR code section a proper heading so it can be navigated to directly rather than stumbled into mid-page. State plainly, in text, what scanning leads to and why someone would want to — the same information a sighted user gets by glancing at the code and any caption around it. And critically, since a QR code embedded in a webpage is somewhat pointless for anyone already viewing that page on the device they'd scan with — always provide the same destination as a plain, tappable link on the page itself for a sighted mobile visitor, and definitely for a screen-reader user, rather than asking someone to scan a code displayed on the very screen they're reading from.

QR codes have a built-in error-correction mechanism that lets a scanner successfully read the code even if part of it is damaged, dirty, poorly lit, or partially obscured by a logo. SMLLR's Design Studio exposes four error-correction levels when creating a code — L (~7% recovery, best for clean digital displays), M (~15% recovery, general business use), Q (~25% recovery, SMLLR's default, suited to printed materials and outdoor signage), and H (~30% recovery, meant for codes with a logo overlay or in harsher environments). Choosing a higher level than the bare minimum for your use case is a genuine accessibility-adjacent practice: it builds in tolerance for a slightly worn print, a code viewed at an awkward angle, or a phone camera struggling in low light — exactly the conditions a code needs to keep working under for it to be reliably usable by everyone, not just someone with a steady hand and a new phone in good lighting.

The most common gap in QR accessibility testing is only ever scanning a code on a new flagship phone, in good office lighting, held perfectly steady, at the exact distance the designer had in mind. Before a code goes to print at scale, test-scan it on an older or budget Android device (not just the newest iPhone), in dim lighting, at a slight angle, and from the actual distance a real user would be standing at the real deployment location. This kind of testing catches contrast and size problems that look completely fine on a monitor but fail the moment they meet an imperfect real-world scanning condition — which, for a meaningful share of your actual audience, is the normal condition, not the exception.

Before printing or publishing a QR code at scale, run it against these basics:

SMLLR's QR Design Studio gives you direct control over the contrast-relevant settings — dots color, background color, and error-correction level — plus an editable, human-readable slug you can print as a fallback next to every code. Create your first QR code on SMLLR's Starter plan (₹499/month) and build these accessibility basics in from the start, rather than retrofitting them after a batch is already printed. For more on getting the visual design right generally, see the complete QR design guide.