Accessible digital certificates: a practical checklist

Why accessibility applies to certificates

A certificate reaches three audiences: the graduate who receives it, the employer or admissions office that checks it, and the staff who issue it. Any of them may be blind, have low vision, or use a keyboard instead of a mouse. A certificate that only works as a picture excludes them, and in many places the law now expects institutions to do better.

The standards

• WCAG 2.2, the W3C's Web Content Accessibility Guidelines, was first published as a W3C Recommendation on 5 October 2023. The US rules below each name a version of WCAG.
• PDF/UA (ISO 14289) specifies what an accessible PDF must contain. Part 1 dates from 2012 and was revised in 2014; part 2, for PDF 2.0, was published in 2024.

The rules that may apply to you

• European Union: the European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025 to a defined list of products and services. Whether it covers a given certificate service depends on that list and on national law, so check with your adviser.
• United States, public institutions: the Department of Justice's 2024 rule under Title II of the Americans with Disabilities Act requires state and local governments, including public schools, community colleges and public universities, to make web content and mobile apps conform to WCAG 2.1 level AA. An interim final rule in 2026 extended the compliance dates to 26 April 2027 for larger entities and 26 April 2028 for smaller ones and special districts.
• United States, federal agencies: the revised Section 508 standards require electronic content to conform to WCAG 2.0 level A and AA.

Checklist: the certificate itself

1. Contrast. WCAG asks for at least 4.5:1 between text and background, or 3:1 for large text (at least 18 point, or 14 point bold). Pale gold on cream often fails.
2. Legible type. Keep decorative scripts for one or two words at most. The recipient's name must be readable at a glance.
3. Real text, not a picture of text. A PDF whose words are a flattened image cannot be read aloud, searched or copied.
4. Tagged PDF with a sensible reading order: title, recipient, achievement, date, issuer, verification details.
5. Text alternatives. The W3C's guidance is that images must have text alternatives that describe the information or function they represent. A crest can be described by the institution's name; a purely decorative border should be marked as an artifact so a screen reader skips it.
6. The QR code is never the only route. Print the verification address next to it, for anyone who cannot scan.
7. Document language set, so a screen reader pronounces the name and the words correctly.

Checklist: the verification page

• The page states the result in text ("valid", "withdrawn"), not by colour alone.
• It has one clear heading, works with a keyboard, and keeps its layout when zoomed.
• The form that accepts a code has a visible label and says in words what went wrong when a code is not found.
• It does not require an account or a CAPTCHA to read a public result.

Checklist: the people who issue

The issuing panel is also web content. Staff should be able to design a template, grant a certificate and correct one using a keyboard and a screen reader. Ask your provider which WCAG level its panel targets.

How Emitcert approaches it

Emitcert's verification page states each result in words, is built from real headings and labelled forms, and never asks the reader to sign in. Certificates are drawn from real text with fonts embedded, so the PDF's words are not a flattened picture, and every ready-made design prints the verification address and code as text, not only as a QR code. Its guides, including this one, follow the same rules. For the design side, see our certificate design checklist.