E-Mail-Signatur-Barrierefreiheit: Kontrast, Alternativtext, Fokusringe
Your email signature is a functional component of your daily communication, yet most tools generate markup that fails colour contrast ratios, omits alt text on logos, and removes focus indicators. When a recipient uses a screen reader, keyboard navigation, or a high-contrast theme, that broken signature becomes a barrier rather than a brand asset. Accessibility is not a nice-to-have for signatures — it is a compliance requirement and a signal of engineering discipline.
Why default signature tools fail accessibility
Every major email client and signature generator ships with markup that violates WCAG 2.1 AA at minimum. Gmail’s built-in signature editor inserts inline styles with colours that often fall below a 4.5:1 contrast ratio against white backgrounds. Outlook on Windows uses Word’s rendering engine, which strips ARIA attributes and relies on absolute positioning that ignores focus order. Apple Mail allows users to paste rich HTML from any source, but the resulting table-based layouts rarely include role attributes or visible focus rings.
The problem is structural. Signature generators treat the output as a static image rather than interactive content. They hardcode font colours like #999999 for legal disclaimers, assume a white background, and embed logos as <img> tags with empty alt attributes. When a screen reader encounters <img alt="">, it skips the image entirely — the recipient never knows the company logo or social icon exists. Focus rings disappear because developers set outline: none in inline styles to avoid visual clutter, forgetting that the outline is the only visible cue for keyboard users.
Colour contrast: the minimum bar
WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Most email signatures use 10px to 12px text for phone numbers, job titles, and disclaimers — all of which fall under normal text. A colour like #767676 on white yields a ratio of approximately 3.8:1, failing AA. Even #595959 on white, which looks dark, lands at 5.2:1 — barely passing.
The fix is to choose a colour palette that passes at the smallest font size in your signature. If your disclaimer is 10px, test that colour against the background. Tools like the WebAIM Contrast Checker or the contrast function in modern CSS preprocessors can validate ratios before you export. For links, the underline or a bold weight can supplement colour alone, but the text colour must still meet the ratio. Do not rely on colour alone to convey information — a phone number in red without an underline or icon is invisible to colour-blind users.
How to test contrast in email clients
Email clients do not support CSS prefers-color-scheme or forced-colors media queries consistently. The safest approach is to assume a white background and design for that. If you support dark mode, add a [data-ogsc] or [data-ogsb] override for Outlook, but never let the dark mode fallback reduce contrast below 4.5:1. Test by pasting the rendered signature into a plain text editor, taking a screenshot, and running it through a contrast checker. Gmail’s web interface and Outlook’s reading pane both apply their own background colours — verify against both.
Alt text: every image needs a purpose
Every <img> in a signature must have a non-empty alt attribute unless the image is purely decorative. A company logo is not decorative — it conveys brand identity. Social media icons are not decorative — they communicate a call to action. Use descriptive alt text that matches the link destination: alt="Company logo" is acceptable, but alt="Acme Corp logo: home page" is better. For social icons, use alt="Follow us on LinkedIn" rather than alt="LinkedIn icon".
Do not use alt="" for images that are links. Screen reader users navigating by links will hear only the link text, and if the image is the only content inside the <a> tag, they hear nothing. Wrap the image in an <a> with an aria-label that describes the action, or use alt text that includes the destination. For example:
<a href="https://linkedin.com/company/acme" aria-label="Visit our LinkedIn page">
<img src="linkedin-icon.png" alt="" width="24" height="24">
</a>
The aria-label on the link provides the accessible name, and the empty alt tells the screen reader to skip the image. This pattern avoids redundant announcements like “LinkedIn icon: Visit our LinkedIn page”.
Focus rings: never remove them
The single most common accessibility bug in email signatures is outline: none applied to links or buttons. Developers add this to prevent the default dotted outline in older browsers, but they forget to provide a replacement. The result is that keyboard users pressing Tab through a signature see no visual indicator of focus — they cannot tell which element is active.
The correct approach is to define a custom focus ring that works across email clients. Use outline with a high-contrast colour and a width of at least 2px. Because email clients strip :focus-visible and :focus-within, you must apply the outline directly to the element using inline styles or a <style> block in the head. For example:
<a href="https://example.com" style="outline: 2px solid #005fcc; outline-offset: 2px;">
Visit our website
</a>
If you use a <style> block, wrap it in <!--[if mso]> for Outlook and use a standard <style> for other clients. Test by tabbing through the signature in Gmail (Chrome), Outlook Desktop, and Apple Mail. If any client hides the outline, add !important to the style rule — email clients often override user-agent stylesheets.
Semantic structure and reading order
Signatures are typically laid out in tables for compatibility, but tables do not convey hierarchy to screen readers. Use role="presentation" on the outer table to prevent the screen reader from announcing table semantics. Inside cells, use <p> tags for text blocks and <span> for inline elements. Avoid <br> tags for spacing — they create logical breaks that screen readers interpret as new paragraphs, which can confuse the reading flow.
The reading order should match the visual order left-to-right, top-to-bottom. If your signature has a logo on the left and contact details on the right, the HTML source must place the logo cell before the details cell. Do not use CSS float or position: absolute to reorder elements — email clients render them unpredictably, and screen readers follow DOM order.
For links, ensure the link text is descriptive. “Click here” or “Learn more” are meaningless out of context. Use the full company name or the action: “Acme Corp website” or “Schedule a demo”. If you must use a generic phrase, wrap it in an aria-label on the <a> tag.
How newmail.click handles this
newmail.click generates signatures that pass WCAG AA contrast by default. The free builder enforces a minimum 4.5:1 ratio on all text colours and flags violations during preview. Every image field requires alt text before export — empty alt attributes are not permitted. Focus rings are preserved on all interactive elements; we do not set outline: none anywhere in the output. The Pro tier adds click and open tracking via transparent pixels and redirect links, both of which include role="presentation" and aria-hidden="true" to avoid screen reader disruption. Slack and email alerts for new opens and clicks include the same accessible markup. UTM parameters default to utm_source=email&utm_medium=signature, but you can override them per link. The signature HTML is validated against a subset of WCAG 2.1 AA rules before delivery.
Accessible signatures are not harder to build — they just require a tool that treats accessibility as a default, not an afterthought. When every image has alt text, every colour passes contrast, and every link shows a focus ring, your brand communicates competence to every recipient, regardless of how they read email.