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 verifies it, and the staff who issue it. Any of them may be blind, have low vision, or navigate with a keyboard rather than a mouse. A certificate that functions only as an image excludes them, and in many jurisdictions the law now imposes accessibility requirements on institutions.

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 cited below each refer to 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.

Rules that may apply to your institution

• 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 particular certificate service depends on that list and on national law; the question should be put to the institution's legal 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 entities and special districts.
• United States, federal agencies: the revised Section 508 standards require electronic content to conform to WCAG 2.0 levels A and AA.

Checklist: the certificate

1. Contrast. WCAG requires 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 frequently falls short.
2. Legible type. Restrict decorative scripts to one or two words at most. The recipient's name must be readable immediately.
3. Real text, not an image of text. A PDF whose wording is a flattened image cannot be read aloud, searched or copied.
4. A tagged PDF with a logical reading order: title, recipient, achievement, date, issuer, verification details.
5. Text alternatives. W3C guidance states that images must have text alternatives describing 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 that a screen reader passes over it.
6. The QR code is never the only route. Print the verification address beside it for readers who cannot scan it.
7. Document language declared, so that a screen reader pronounces the name and the text correctly.

Checklist: the verification page

• The page states the result in text ("valid", "withdrawn"), not by colour alone.
• It has a single clear heading, is fully operable by keyboard, and keeps its layout when zoomed.
• The form that accepts a code has a visible label and explains 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 staff 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 the provider which WCAG level its panel is built to meet.

Emitcert's approach

Emitcert's verification page states each result in words, is built from real headings and labelled forms, and never requires the reader to sign in. Certificates are rendered from real text with embedded fonts, so the PDF's wording is not a flattened image, and every predefined 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.