Accessible QR Codes: What to Add So Everyone Can Reach the Same Content

An accessible QR code is never the only way to reach the content: provide an accessible text link or equivalent route, make the code easy to see, explain what scanning will do, and check that the destination page is accessible too. When the QR image adds unique purpose or function, its alt text should convey that purpose; when a nearby accessible link already provides the same information and action, alt="" may be appropriate. ^{[S1][S3][S16]} This checklist turns those points into items you can apply to a web page, a document or a printed piece, and shows which of them connect to a specific WCAG 2.2 success criterion and which are only good practice.

It is a set of recommendations, not a compliance certificate. Following it does not make a page conform to WCAG, and the checks have not been validated with real assistive-technology users.

What WCAG says, and what it does not

WCAG 2.2 is a standard for web content. Its Understanding pages do not mention QR codes (the 1.4.11 page, which people most often cite for QR contrast, says nothing about them), so every mapping from "QR code" to a criterion is a reading, not a W3C ruling. ^[S6] Third-party guidance makes similar readings and sometimes assigns different criteria to the same advice. For example, the DAISY Consortium's EPUB guidance ties identifying the code, giving instructions and offering an alternative link to 1.1.1, and ties minimum size to 2.5.8. ^[S15] This article uses three labels so you can tell which kind of statement you are reading:

• WCAG means the criterion's own wording covers the item for web content.
• Interpretation means we are applying a criterion to a QR code, and the W3C page does not say so.
• Recommendation means no WCAG success criterion requires it. It comes from the sources cited or from our own judgement.

Printed pieces are outside WCAG's reach as web content, and Section508.gov notes that Section 508 standards do not apply to print, so every print item below is a recommendation. ^[S1]

Who a QR code leaves out

A QR code asks someone to point a camera at a small picture, wait for a scan, and trust a destination they cannot read first. That excludes more people than it first appears:

• People who cannot see the code or aim a camera at it. TetraLogical's 2022 analysis cites a survey in which 60% of the 38 blind or visually impaired respondents found it difficult to use QR codes independently, which is a small sample and so a signal, not a population figure ^[S2].
• People without a suitable smartphone, or who cannot reach the code. BOIA notes that people without smartphones or with older devices should not be left to figure it out ^[S3], and TetraLogical notes that people using wheelchairs or of restricted growth may not be able to reach a code placed high or low ^[S2]. Glare on a glossy surface can also stop a scan; that point is our own and not from these sources.
• People who do not want to open a link they cannot read. The destination is hidden until after the scan, and TetraLogical notes that some people may not use QR codes because of concerns about where they will be redirected. ^[S2]

BOIA's advice is similar and short: offer an alternative, give instructions, and make sure the code leads to accessible content. ^[S3] Everything below is a way of doing those three things concretely.

Rule 1: always offer a route that does not need the camera

Label: Recommendation, with WCAG 2.4.4 for the link text. Put the destination where a person can read it and type it, or click it.

• In print: the full address, or a short address that is easy to type, printed next to the code. Section508.gov says print materials should include the URL ^[S1].
• On screen: a clickable link next to the code, with link text that tells people where it goes. Link text such as "click here" tells people nothing on its own, and WCAG 2.4.4 asks that the purpose of a link can be determined from its text or from its text together with its context, where "link context" means context that software can work out, such as the sentence the link sits in. Write the purpose into the link text itself and you do not have to rely on that. ^[S5]
• For people who cannot browse: a phone number or office hours, when the code is the only way to register or pay.

Keep the address short enough to type. A long tracking address is not a real alternative.

Rule 2: write a useful text alternative

Label: WCAG 1.1.1 (Level A) for web pages; the example wording is our recommendation. For a QR image that conveys an otherwise unavailable destination or function, write alt text that communicates that purpose rather than its appearance. WCAG 1.1.1 asks for a text alternative serving the equivalent purpose. ^[S4] Section508.gov gives an example such as "QR code linking to the product accessibility page". ^[S1] Exception: if an adjacent, accessible text link fully communicates the same destination and action, the QR image may be redundant and alt="" can be appropriate. An empty alt attribute is different from an omitted alt attribute; do not omit the attribute itself. This choice depends on context, not a blanket rule for every QR image. ^[S16] For Word, PDF and slide decks, follow the relevant software's accessible-image guidance.

These are examples we wrote for this article. Adjust them to match the language and context of the page, and keep each one short, because a screen reader reads every word.

Automated checkers cannot judge any of this on their own.

In a local run, 17 small HTML pages went through axe-core 4.11.0: 4 correct ones and 13 that were each broken in one deliberate way, and its default rules flagged 6 of the 13 (a missing language, an invalid language code, a missing alt attribute, an unnamed image link, an unnamed SVG, and low contrast). ^[T1] They did not flag the other 7, which included an image with the alt text "QR code", an alt text that was a filename, an empty alt, a "click here" link, and a page showing a code with no visible address. ^[T1] An empty alt is not always an error; it depends on whether another accessible route already provides the same purpose. ^[S16] The pages were ones we wrote, they are HTML only, and one run in one browser does not describe real sites, but the pattern is the point: a green automated report is not evidence that a QR code is accessible.

Rule 3: contrast, size and placement

Contrast. Label: Interpretation of WCAG 1.4.11 for the squares; WCAG 1.4.3 for nearby text. WCAG 1.4.11 asks for at least 3:1 contrast for graphical objects that are needed to understand content, at level AA. ^[S6] The W3C page does not mention QR codes, so applying it to a code is an interpretation. TetraLogical makes that reading and recommends that the colours used for the squares have a contrast ratio of at least 3:1. ^[S2] Section508.gov points to the WCAG 2.1 ratio of 4.5:1 for normal text and images, but it does not say which part of a QR code that ratio is meant for. ^[S1]

Treat 3:1 as a floor for people seeing the code. It is a visibility threshold for people, not a scanning guarantee: nothing in WCAG says whether a camera will decode a code at that ratio, so test every printed or on-screen variant with real phones. Text next to the code is ordinary text and needs 4.5:1 under WCAG 1.4.3 (3:1 if it is large-scale text). ^[S7]

Size and distance. Label: Recommendation. Standards do not give a single number here, and WCAG 2.5.8 sets a 24 by 24 CSS pixel minimum only for clickable targets on screen, which is a different question from whether a camera can read the code. ^[S11] TetraLogical suggests a minimum of 2 cm by 2 cm and a scanning distance of roughly ten times the code's width, and credits both figures to QR code vendors (QR Code Generator and Sprout QR for the 2 cm minimum, Scanova and Sprout QR for the ratio). ^[S2] Use them as starting points: a 10 cm code is meant to scan from about a metre. Then test on the real surface at the real distance.

Placement. Label: Recommendation. Put codes at a consistent, reachable height and position, and not where glare lands. TetraLogical notes people using wheelchairs or of restricted growth may not reach codes placed high or low. ^[S2]

Rule 4: tell people what will happen

• Label: Recommendation. Put a short instruction beside the code, such as "Point your phone camera at the code to open the sign-up form". Do not assume everyone knows how to scan. ^[S2]
• Label: WCAG 1.3.3 and 1.4.1. Do not rely only on position, shape or colour in the instruction. "Scan the square on the right" or "scan the green code" fails people who cannot see the layout or the colour, so name what the code does. WCAG 1.3.3 asks that instructions not rely solely on sensory characteristics such as shape, colour, size or visual location, and 1.4.1 asks that colour is not the only visual means of conveying information. ^[S8][S9]
• Label: Recommendation, loosely related to 3.2.5 (AAA). Avoid codes that act on their own, such as sending a text or starting a download. Link to a web page with a clear call to action so the person decides whether to continue. ^[S1][S14]
• Label: WCAG 1.4.5 for text in an image. Do not put text inside the code image. Put it in real text. WCAG 1.4.5 prefers real text over images of text, with an exception for essential presentation such as logotypes. ^[S10][S2]

Rule 5: check the destination, not only the code

Label: WCAG applies here, to the page you send people to. A perfect code that opens an inaccessible page is still a barrier. ^[S3] This is the one place where WCAG can actually be assessed, because the destination is web content.

• The destination should work on a phone: readable without zooming sideways, which WCAG 1.4.10 describes as presenting content at 320 CSS pixels wide without two-dimensional scrolling, with labelled form fields and buttons (3.3.2). ^[S12][S13]
• Do not force a file download as the only result. Give a page that explains and offers the file.
• Test the page with a screen reader and magnification. Section508.gov names VoiceOver on iOS and TalkBack on Android for this. ^[S1]
• If the code is on a short or redirecting address, check the final page too, because the code only holds the first address.

When not to use a QR code

Ask these questions before you add one:

Copy-ready checklist

Web page

• If the QR image provides unique purpose or function, its alt text conveys it; if an adjacent accessible text link makes the image fully redundant, alt="" may be appropriate (WCAG 1.1.1). ^[S4][S16]
• A text link to the same destination is next to the code, and its text says where it goes (WCAG 2.4.4). ^[S5]
• The visible web address is printed as text, not only inside the image (recommendation).
• Caption and link text have at least 4.5:1 contrast (WCAG 1.4.3). ^[S7]
• The code's squares have at least 3:1 against their background (interpretation of WCAG 1.4.11). ^{[S6] [S2]}
• Instructions do not depend on colour, shape or position (WCAG 1.4.1, 1.3.3). ^[S8][S9]
• The destination page works with a screen reader and magnification.

Word, PDF or presentation

• Provide a suitable text alternative for a QR image that conveys unique information or function; if the image is fully redundant to an accessible equivalent, consult the software's guidance for marking it decorative. We have not verified menu paths for any specific version.
• The address is visible text in the document and, where the format supports it, a live link.
• Run your authoring tool's own accessibility checker, and then a person's review.

Print (all recommendations)

• The address is printed next to the code, big enough to read. ^[S1]
• The code is at least about 2 cm across for close-up scanning, and bigger when it will be scanned from further away. ^[S2]
• A short instruction sits beside the code.
• You scanned a proof on at least two phones at the real distance and in the real light.
• Someone checked the destination page on a phone.

Example markup

This is an English adaptation of the block that passed axe-core in our fixtures (the original is in Traditional Chinese): a code, a purpose sentence and a typed fallback, all in one block. ^[T2] The adaptation below was not itself run through axe-core.

<figure class="qr-block">
  <img src="spring-fair-signup-qr.svg" width="200" height="200"
       alt="QR code that opens the spring fair sign-up form">
  <figcaption>
    <p>Scan with your phone camera to open the sign-up form.</p>
    <p>Can't scan? Go to
      <a href="https://example.com/spring-fair">Spring fair sign-up: example.com/spring-fair</a>
    </p>
  </figcaption>
</figure>

Making the code itself

If you need a plain code to start from, OwnQR's free QR code generator makes a static code. It uses error-correction level H, which the user cannot change. Its SVG export keeps the code itself as vector, but caption text is written as live text, not outlined shapes, so its font may be substituted on a machine without it, and an uploaded logo stays a raster image, so check how a caption looks after export. Whatever you use, apply the checklist above to the placement and the text around the code.