Author: Bill Tranchois

The European Accessibility Act (EAA) is a new EU directive designed to make products and services, including digital communications, accessible to people with disabilities. Approved in 2019, the EAA will enter into force on June 28, 2025. After that date, businesses operating in the EU (or serving EU customers) must ensure that their digital content – websites, apps and emails – meet strict accessibility standards. In practice, this means that every marketing newsletter or transactional message you send to European users needs to be perceivable, operable, understandable and robust, in line with established guidelines.

Complying with the EAA is not just about avoiding fines – it’s about reaching a wider audience. An estimated 135 million people in the EU have disabilities. Accessible emails ensure your message gets to everyone (and isn’t filtered out by assistive technology). Conversely, ignoring email accessibility now puts your business at risk of legal penalties and market exclusion when the 2025 deadline arrives. This blog will explain the EAA’s requirements for emails, the risks of non-compliance, and how to make both marketing and transactional emails fully accessible. We’ll cover practical coding tips (headings, alt text, contrast, etc.), show examples of compliant vs. non-compliant email design, and point you to key standards like WCAG 2.1 AA and EN 301 549. Finally, we’ll give you an email accessibility checklist of best practices to help you get ready well before 2025.

EAA Deadline and Legal Risks for Emails

Under the EAA, June 28, 2025 is the hard deadline. By that date, all new products and services must comply with EU accessibility rules. In practice, that means if your company is sending emails in 2026, those emails will have to meet EAA standards. (Older contracts have a transition grace period until 2030, but don’t count on that for your email campaigns.) Enforcement will be handled by national authorities in each member state, through market surveillance and penalties.

The consequences for failing to comply can be severe. While member states set their own fines, reports suggest penalties range from thousands to hundreds of thousands of euros per violation. For example, some EU regulators impose daily fines for ongoing issues (around €1,000/day in some cases), and repeated or serious breaches can trigger much larger fees. ReciteMe notes that some countries allow fines up to €250,000 for major accessibility failures. In addition to direct penalties, non-compliant businesses risk lawsuits (including consumer complaints) and damage to their reputation. Regulatory scrutiny could even bar you from certain EU markets, especially if you bid for public-sector contracts that increasingly require accessibility.

Bottom line: as of mid-2025, “business as usual” emails in the EU must be accessible. Ignoring this won’t just be a technical oversight – it could trigger fines, lost customers, and legal action. The good news is that you have time to prepare. Start by understanding the guidelines for accessible emails below, and begin auditing and updating your templates now.

Who Must Comply?

The EAA applies to companies that supply digital services to EU markets, which includes email marketing and customer communications. The rules do not apply to micro-enterprises (fewer than 10 employees and under €2 million turnover), but beyond that threshold, nearly all businesses with an EU presence are covered. In practice, if you send email newsletters or transactional emails (order confirmations, password resets, etc.) to EU recipients, you need to meet the EAA’s accessibility requirements. For instance, Mailgun confirms that both marketing emails and essential service emails (like receipts or shipping notices) “fall under the umbrella of digital services” and must comply.

Core Accessibility Standards: WCAG and EN 301 549

The EAA is a law, not a design guide, so it doesn’t spell out exact technical methods. Instead, it incorporates established standards. The key benchmark is WCAG 2.1 AA (Web Content Accessibility Guidelines, level AA), which defines success criteria for digital content. The EAA refers to EN 301 549 – the EU’s harmonized ICT accessibility standard – and EN 301 549 already incorporates WCAG 2.1 AA for web/digital content. In effect, following WCAG 2.1 AA is the way to achieve “EAA compliance” for emails. As one accessibility expert puts it, “to be EAA-compliant, businesses must adhere to WCAG 2.1 Level AA”.

So how do you make an email WCAG 2.1 AA–accessible? At a high level, WCAG covers things like text alternatives, contrast, keyboard operability, semantic structure, and more (the four POUR principles). Much of WCAG for websites can be applied to HTML email: e.g. provide alt text for images, ensure sufficient contrast (ratio 4.5:1 or higher for normal text), use proper headings and labels, make sure interactive elements are keyboard-accessible, and so on. (Note: some interactive features like complex scripts or ARIA roles may be limited by email client support, but you should follow best practices wherever possible.) In this blog we’ll go through the main points.

Technical Best Practices for Accessible Emails

Below are key guidelines and implementation tips for making emails accessible. These apply to both marketing campaigns and transactional emails (order confirmations, notifications, etc.). Whenever possible, use HTML format (rather than plain text or RTF) so you can include semantic markup.

• Use semantic structure (headings, paragraphs, lists). Organize your email like a well-written article: a clear main heading, logical subheadings, and content in logical order. For example, use an <h1> tag for the email’s main title, and use <h2>, <h3>, etc. for subsections. Screen reader users often navigate by jumping between headings, so this structure matters. Never rely on images for text headlines; use real text and heading tags. Also wrap text in <p> (paragraph) tags rather than using manual <br> line breaks, so that assistive technologies know where paragraphs begin and end. Bullet-point lists should use <ul>/<li> or <ol> tags for proper list structure.
• Provide meaningful alternative text for images. Every informative image must include a concise but descriptive alt attribute. The alt text should convey the image’s purpose or content (“red leather handbag with gold hardware” rather than “image of product”). Decorative images (purely visual flourishes) should use alt="" so screen readers skip them. Never use an image of text to convey important information; if you do, include that text in the surrounding HTML as well. (In other words, don’t put sale prices or instructions only in an image – always have the same info as selectable text.) Including alt text is critical: without it, a screen reader will either skip the image or announce an unhelpful filename, and the user misses the content.
• Ensure high color contrast and readability. Text must be easy to read against its background. WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text (3:1 for large text). Concretely, black text on white is ideal; avoid light gray text on white or any low-contrast combination. You can test colors with tools like the WebAIM Contrast Checker. Use sufficiently large font sizes (generally >= 14px) and readable font families (sans-serif fonts like Arial or Verdana). Left-align body text for better readability, and use ample line spacing (1.5×) if possible. Avoid conveying meaning by color alone (e.g. “green means success”); always use text or symbols in addition to color cues.
• Write clear, descriptive link and button text. Every link or button in the email should have context. Avoid vague phrases like “Click here” or “Submit”. Instead, use specific text such as “Download your invoice” or “View Order Details” that tells the user where the link goes or what it does. Screen reader users often navigate by jumping from one link to the next, so each link must make sense out of context. As Section508 guidance puts it: “Avoid generic terms and phrases such as ‘Click here.’ Create link text that’s as specific as possible”.
• Design for keyboard navigation. Some recipients will use the keyboard rather than a mouse. Ensure all interactive elements (links, buttons) are reachable by tabbing. Focus indicators (outline or underline) should be visible so users know which element is active. Most email clients handle basic tabbing by default, but test it. For example, tab through your email using only the keyboard: does the focus move in a logical order (left-to-right, top-to-bottom)? If you’ve added custom CSS, make sure it hasn’t removed the browser’s native focus styles.
• Be mindful of email client quirks. Not all email clients support every feature of HTML/CSS. For instance, older Outlook for Windows uses the Word rendering engine, which can drop many CSS rules. To handle this, many experts recommend using so-called “ghost tables”: invisible table structures that ensure a consistent layout in Outlook while using normal <div>-based layouts in modern clients. Mailjet advises coding with <div>s and fallback tables so that Outlook users get a reliable structure. Similarly, some semantic HTML5 tags (like <header>, <figure>, <aside>, etc.) or ARIA attributes may not be supported everywhere. As a rule, test your accessible email in major clients (Gmail, Apple Mail, Outlook.com, etc.) and adjust. The goal is to use the best markup you can, while ensuring the email doesn’t break in common inboxes.
• Test with actual screen readers or checkers. Automated email accessibility checkers can catch obvious issues, but nothing beats a human test. Use tools: for example, Outlook’s built-in Accessibility Checker, the free WAVE extension, or browser devtools. Better yet, try opening your email with a screen reader (NVDA, VoiceOver, Narrator) to hear what a blind user would hear. And double-check contrast with a tool. Apple Mail, Gmail, and Outlook all have fairly good support for alt text and basic markup, so ensure those functions (like alt text reading) actually work.

Side-by-Side Example: Accessible vs. Non-Accessible Email

By now you know the theory. To illustrate, consider the two email designs below. The first email was built entirely as a single image graphic. The second is an improved version. Notice the differences in structure, text, and alt text:

Figure: Non-compliant email example (inaccessible). Here the entire message is a flyer image with no meaningful alt text. A screen reader would only see something like “Flyer image” (or nothing), so all content is lost to visually impaired users. Users cannot select the text, change contrast, or resize it. Essential info (event name, date, call-to-action) is trapped in the image.

Figure: Accessible email example (compliant). This version has the same content but with real text elements and proper image alt text. The headline and details (“Adventure of a Lifetime… Junior Conference 2022”) are coded as text (using <h1>, <p>, etc.), so screen readers can speak them. The header graphic has an alt="The Adventure of a Lifetime with Georgia 4-H – Junior Conference 2022", matching the visible text. The call-to-action (“Register by Aug 1”) and event details are text, not images. This makes the email navigable and understandable by assistive technologies. In short, all information is also present as actual text, so losing the images (e.g. in a blocked-image view) still leaves a coherent message.

These examples highlight key points: Never rely on images to deliver critical text, and always use alt attributes on images. In the accessible version, the screen reader can read all the same details simply by traversing the text and alt tags. In the non-compliant version, none of the important content is accessible.

Compliance Frameworks: WCAG 2.1 and EN 301 549

As mentioned, WCAG 2.1 Level AA is the de facto guide for email accessibility under the EAA. WCAG is the internationally recognized set of guidelines published by the W3C. Although WCAG itself isn’t a law, the EAA makes its key success criteria legally binding in the EU. EN 301 549 is the European standard that supports this: it explicitly “incorporates the WCAG 2.1 AA standard” for digital services. (A new version of EN 301 549 is being prepared for release in 2025 to align fully with the EAA.)

Practically speaking, you should treat an email like a webpage: apply the same WCAG rules. This includes not just what we’ve covered (alt text, headings, contrast), but also other AA criteria like readable language, error identification, etc., wherever relevant. Fortunately, most marketing emails are relatively simple in form. Key things to ensure: headings for navigation (WCAG 2.4.6), descriptive labels for form fields if you have any, and avoiding purely decorative embellishments that aren’t marked as such (WCAG 1.3.1 and 1.1.1).

Finally, note that some countries have their own complementary laws (e.g. Germany’s BITV, France’s RGAA) that align with WCAG. But for cross-border email campaigns in Europe, sticking to EAA/WCAG is the surest path. In summary, if your emails pass WCAG 2.1 AA success criteria, you’ll be well positioned for EAA compliance.

Email Accessibility Checklist (Best Practices)

To help your team remember the essentials, here’s a checklist of best practices for accessible emails under the EAA. Use this when reviewing your email templates or planning new campaigns:

• Email format: Send HTML emails, not plain-text or RTF. HTML allows semantic markup (headings, lists, etc.).
• Structure: Use <h1> for the main title/headline, then <h2>, <h3> in logical order. Wrap content in <p> tags, and use <ul>/<li> or <ol> for lists. Avoid using <p> tags just for spacing (use CSS padding/margin instead).
• Text content: Keep all important info as text, not images. Make sure fonts are at least 14px (12pt) and readable, and choose a simple sans-serif font.
• Alt text: Every informative image must have a succinct, descriptive alt="...". Decorative images should have alt="" so they are skipped. Do not put meaningful text inside images without also providing it as real text.
• Contrast: Verify text/background contrast is ≥4.5:1 for normal text (≥3:1 for large/bold text). Use a color-contrast checker tool to confirm. Avoid very light text on light backgrounds or vice versa.
• Links/buttons: Use descriptive link labels (e.g. “Download Invoice” vs. “Click here”). Every link text should make sense on its own. Similarly, label buttons with their purpose.
• Keyboard navigation: Ensure tab order is logical. Check that all interactive items (links, buttons, form fields) can be reached with the keyboard and have a visible focus indicator.
• Tables: If you use tables for layout, add table headers (<th>) and avoid empty cells. (Better yet, use CSS layout for simple structures.) If you present actual data in a table, make sure it has row/column headings.
• Language: Specify the email’s language with lang="en" (or whatever) on the <html> tag so screen readers pronounce text correctly.
• Avoid problematic features: Don’t rely on JavaScript or complex ARIA in emails (many clients strip or ignore these). Avoid blinking/scrolling text and other dynamic effects that can cause seizures or readability issues.
• Test thoroughly: Use accessibility checkers (e.g. WAVE, Axe DevTools) and have someone navigate with a screen reader (VoiceOver on Mac/iOS, NVDA on Windows, etc.). Check your emails in major clients (Gmail, Outlook, Apple Mail) and devices to ensure formatting and alt text survive the rendering.

By systematically applying these guidelines, you’ll cover the main WCAG criteria for emails (structure, text alternatives, contrast, navigation, etc.). Keep this checklist handy for all your email projects.

Call to Action: Taking Steps Now

The EAA’s 2025 deadline is approaching quickly. Don’t wait until it’s an emergency to audit your email templates. Here are immediate action steps:

1. Audit your current emails. Use an accessibility testing tool or manual review to identify issues in your most critical emails (newsletters, order receipts, password resets).
2. Fix the high-impact problems first. For example, add alt text to all images and correct any very low-contrast text.
3. Switch to accessible email templates. Update your email generator or marketing platform with templates that follow best practices (proper tags, CSS, etc.). Many email marketing tools have accessible template libraries or modules you can adopt.
4. Train your team. Make sure content writers and developers know these rules. Even non-technical team members should avoid pasting images of text or using ambiguous link phrases.
5. Build ongoing processes. Incorporate email accessibility into your QA/testing checklists. For example, use Outlook’s built-in Accessibility Checker or similar tools before sending major campaigns. Schedule periodic reviews of email content as you would any compliance task.

By preparing now, you turn the EAA from a compliance headache into an opportunity. Accessible emails not only meet EU law but also improve overall user experience and brand reputation. They can increase engagement – after all, if more people can read your message, it’s more effective marketing. Treat this as a worthwhile upgrade rather than a burden.

Call to Action: Audit your email systems today. Use the checklist above to evaluate your top email templates. Plan any necessary redesign or coding work before mid-2025. Remember that email accessibility is part of the broader EU accessibility landscape – so aligning with WCAG 2.1 AA will also serve you under EN 301 549 and other regulations.

In summary, achieving EAA email compliance means building accessible emails Europe across your organization. Follow the guidelines and checklist above to make your marketing and transactional emails inclusive for all users. Taking these steps now will ensure you meet the European Accessibility Act 2025 requirements, avoid fines, and open up your communications to a wider audience.

Sources: Guidelines and data in this post are drawn from EU official releases and recognized accessibility authorities, including industry experts on email compliance. The side-by-side email examples are for illustration of these principles. Use this as a starting point for email accessibility planning under the EAA.