Accessibility in Email Signatures: WCAG 2.2 for the Overlooked 100 Bytes
How to make a signature that works for screen readers, low vision, colour-blind users, and everyone else.
By Editorial Team, Editors, SignatureCraft · Updated 2026-06-15 · 10 min
Signatures are the last part of an email most designers accessibility-audit. This guide covers the WCAG 2.2 rules that actually apply to signature blocks and the practical fixes for the most common failures.
Why signatures are a real accessibility surface
Email signatures rarely appear on anyone's accessibility checklist. This is partly because they are short — often under 100 bytes of actual text — and partly because they live inside a communication tool rather than a public product surface. Both reasons are wrong. The signature is read by everyone who reads any email you send, is often the piece of the email with the highest information density per pixel, and is the single most likely place inside a message for accessibility failures to cluster.
A screen-reader user who receives a signature made entirely of images with no alt text hears silence where your name should be. A user with low vision who receives a signature in 9-point pale grey text sees a decorative smudge. A user with red-green colour blindness who receives a signature whose only visual differentiation between name and title is colour sees an unbroken block. Each of these failures is trivially fixable, and each is present in the majority of signatures we audit.
The European Accessibility Act came into force in June 2025 and treats business communications from covered entities as in-scope. WCAG 2.2 — the current version of the Web Content Accessibility Guidelines — is the practical standard courts and regulators reach for. Its rules apply to HTML email including signatures, and they are not difficult to follow.
Rule one: text is text, not an image of text
The single most common signature accessibility failure is the signature-as-image pattern. Someone in the marketing team designs a signature in Photoshop, exports it as a single PNG, and instructs the company to paste that image into their email client. It looks pixel-perfect. It is also unreadable to every screen reader, unsearchable in the recipient's inbox, and blocked-by-default in Outlook for users with images disabled.
WCAG 2.2 Success Criterion 1.4.5 (Images of Text) is explicit: text that conveys information must be provided as actual text unless a particular presentation is essential. A signature block never meets the 'essential' bar. Use HTML text for all textual content, and reserve images for things that are actually images — the company logo, a photo of the person, a small icon.
For the images you do include, provide meaningful alt attributes. 'Jane Doe, Product Manager at Acme' is a useful alt for a headshot. Empty alt is correct for a purely decorative separator. 'logo.png' is wrong. The alt attribute is the only text a screen reader has to work with for that image; treat it as the accessible substitute for the visual.
Rule two: colour contrast that survives dark mode
WCAG 2.2 requires a contrast ratio of at least 4.5:1 for body text and 3:1 for larger text (18pt or 14pt bold). Signatures routinely fail this because designers pick a subtle grey to differentiate the signature from the email body, without checking the contrast ratio against a white background.
#999 on white is a 2.85:1 ratio — a WCAG failure. #767676 is the darkest 'light grey' that passes at 4.54:1. If your signature uses grey for anything that carries information (not just visual separation), pick a grey darker than #767676 or push the ratio further to be safe.
Dark mode is the second half of this problem and the more commonly-missed one. Gmail, Outlook and Apple Mail all now render emails against a dark background for a large share of recipients. A signature designed only against white becomes low-contrast or unreadable when auto-inverted. The reliable fix is to test both modes explicitly and to avoid hard-coded background colours in the signature markup — let the client's background show through.
Rule three: link text that means something
A signature typically contains several links: the company URL, a LinkedIn profile, a phone number, sometimes an unsubscribe link and a calendar-booking link. Screen readers can navigate a document by pulling out just the links, and users who do this hear the link text in isolation.
'Click here' and 'Learn more' are meaningless in that context. 'Book a call with Jane' is meaningful. 'acme.com' is acceptable but 'Acme homepage' is better. For social icons, the accessible name should be the platform and the account owner — 'Jane's LinkedIn' rather than just 'LinkedIn'.
WCAG 2.2 Success Criterion 2.4.4 (Link Purpose) is the relevant rule, and it is satisfied when the link's purpose is clear from the link text alone or from the surrounding context that the assistive technology exposes. For signatures — where the link often stands alone with a small icon — you almost always need the link text itself to carry the meaning.
Rule four: reading order that survives table layout
Reliable HTML email is built on tables because the alternatives break in Outlook. This is unavoidable and not, by itself, an accessibility problem — but it requires attention to reading order. A screen reader reads a table row by row, left to right, top to bottom. If your signature places the photo in a left column and the name in a right column, that works. If it places the photo in the right column and the name in the left, reading order still works. But if it places the name in a spanning row above the photo, and the phone number in a spanning row below, the reader can lose the semantic connection.
The reliable pattern is a single-column stack for the textual identity (name, title, company, contact details) with the photo and logo either to the left or to the right of that stack as a whole. This gives a linear reading experience that survives auto-linearisation on mobile.
Add role='presentation' to layout tables. This tells screen readers to skip the table semantics (headers, cells) and just read the content in order. Without it, some readers announce every cell boundary — turning a signature into a maze of 'cell, cell, cell, John Doe, cell, cell, Product Manager'.
Rule five: touch targets and text size on mobile
Around 65% of business email is now read first on a phone. On mobile, tap targets that are too small — the icon-only social links being the classic offender — cause frustration for users with motor impairments and are simply harder for everyone. WCAG 2.2 introduced a new criterion (2.5.8, Target Size Minimum) requiring interactive elements to be at least 24×24 CSS pixels, with 44×44 being the widely-recommended comfortable minimum.
For social icons in a signature, that usually means 24–32 pixel icons with adequate padding around each so the target extends to the recommended size. Cramming five icons into a 100-pixel row breaks this immediately.
Text size on mobile is the other half. The signature is often the smallest text in the email because designers set it in 11px expecting a desktop viewport. On a phone, that becomes physically hard to read. 14px is a reasonable minimum for signature body text; 12px is the smallest that stays comfortably legible for most users.
A ten-minute accessibility audit for your current signature
Copy your current signature into a document. Turn off image loading in your email client and forward the signature to yourself. Read it. If you cannot identify who sent it, your signature depends too heavily on images. Turn images back on, put on dark mode, and forward it again. If anything becomes unreadable, your colour choices are not dark-mode-safe. Then open the raw HTML source and search for images without alt attributes, links whose visible text is only an icon, and inline styles that hard-code light backgrounds. Fixing what you find will bring the signature substantially into WCAG 2.2 compliance and — much more importantly — make it usable for the recipients who currently cannot read it.
Put these tips into practice
The SignatureCraft editorial team writes about email tooling, deliverability and the small design details that quietly shape how professional we look online.