Making email accessibility a team effort: An interview with Mike Paciello

Email accessibility is still far from standard practice, even in mature programs. Many teams ship beautiful campaigns that remain hard or impossible to read for subscribers who rely on assistive technologies.

In this interview, Mike Paciello, chief accessibility officer at AudioEye and one of the early leaders in web accessibility, talks about the most common failures he sees in email, the myths that keep teams stuck, and what it takes to build accessibility into everyday workflows. He also shares practical quick wins, as well as a real case in which accessible templates reduced production time and support load while improving engagement.

Whether you are just getting started with accessibility or trying to scale it across a large team, Mike’s insights show how to move from one-off fixes to a sustainable, shared practice.

Key takeaways

1. Many email teams still do not have the basics. Missing or meaningless alt text, broken reading order, and poor color contrast shut people out and can create real legal and reputational risk.
2. When dark mode, responsive design, brand colors, and accessibility conflict, accessibility should win. Start by fixing the structure and reading order, followed by contrast and responsive behavior, and test with real screen reader and assistive technology users.
3. Strong programs build accessibility into every phase (copy, design, development, QA, and deployment) with clear ownership across roles instead of leaving it to one “accessibility person.”
4. Making emails accessible can have a clear business impact. Teams see support tickets from customers with disabilities drop by around 60%, and overall click-through rates rise by about 8% when they move to accessible templates, clearer structure, and structured QA.

Mike Paciello has been a pioneer and influential figure in digital accessibility for more than four decades. He authored the first book on web accessibility and usability, Web Accessibility for People with Disabilities (CMP Books, 2000), and founded both The Paciello Group (TPG) and WebABLE.com. Mike served as co-chair of the United States Federal Access Board’s Telecommunications and Electronic and Information Technology Advisory Committee (TEITAC), which developed the harmonized technical recommendations that led to the updated Section 508 standards published in 2017. He also co-founded the International Committee for Accessible Document Design (ICADD).

He was recognized by President Bill Clinton for his contributions to the W3C Web Accessibility Initiative (WAI) and received the 2016 Knowbility Lifetime Achievement Award, the 2020 ICT Accessibility Testing Symposium Social Impact Award, and the 2024 CSUN College of Health and Human Development Heroes Award.

As chief accessibility officer at AudioEye, Mike works across teams to inform, advise, and guide efforts that help the company meet the needs of the disability community. A technologist at heart, he is passionate about making sure people with disabilities are not left behind in digital society and believes that finding the right balance between humans and automation is essential to scaling accessibility for both compliance and usability.

Accessibility failures and misconceptions

Stripo: Email accessibility is still treated as a “nice to have” by many brands. From your perspective, what are the most critical accessibility failures you see in modern email campaigns, and which of them pose real legal or reputational risks today?

Mike: The most critical failures I consistently see fall into three categories:

1. Missing or meaningless alt text: I still see campaigns in which images carry essential information, such as pricing, calls to action, and key promotional details, but the alt attributes are empty or say only “image” or “banner.” When most of your value proposition is locked inside images with no text alternative, you exclude millions of screen reader users from the email.
2. Broken semantic structure: Many emails are built as stacks of nested tables, with no heading hierarchy or logical reading order. When a screen reader linearizes the content, the person hears “table, row, cell, table, row, cell” repeated before reaching any real content. It is confusing, tiring, and easy to give up on.
3. Poor color contrast and color-only cues: Trendy light gray text on white backgrounds, pale buttons, and using color alone to indicate links or urgency all create barriers. This affects far more people than teams expect. For example, roughly 8% of men have some form of color vision deficiency.

All of this is not just a design problem. It affects real people trying to read important information, and it creates risk for organizations that keep sending inaccessible emails.

Stripo: From your experience advising standards bodies and companies, what are the most common misconceptions email marketers have about screen readers and email clients, and how do these misunderstandings affect real users?

Mike: There are lots of myths and beliefs that actually harm accessibility. I’ll name only some of them here:

1. Screen reader users are a tiny edge case: This is the most damaging misconception. There are millions of screen reader users, plus many more who use screen readers situationally: in bright sunlight, while multitasking, or due to temporary impairments. 
2. Alt text is just for blind people: This overlooks the fact that it benefits readers on slow connections, image-blocking email clients, and anyone who receives emails with images disabled by default, which many corporate environments enforce.
3. My email looks fine in testing tools: This conflates visual rendering with accessibility. Tools such as Litmus and Email on Acid show how your email appears across clients, yet they don’t tell you what a screen reader announces. I’ve seen emails that render beautifully but read as incomprehensible nonsense to assistive technology.
4. Outlook supports accessible rich internet applications (ARIA): Thinking so is dangerously wrong. Outlook Classic’s Word-based rendering engine strips most ARIA attributes, and Outlook Web has its own limitations. Marketers add role=“presentation” or aria-hidden, expecting them to work, then wonder why accessibility testing fails. You must test in real screen reader plus email client combinations.
5. If it validates, it’s accessible: This confuses technical validity with usability. You can have perfectly valid HTML that’s completely inaccessible. Accessibility requires testing with real assistive technology and real users.

Why teams struggle to maintain accessible emails

Stripo: Dark mode, responsive design, and accessibility often pull in different directions. How should advanced email teams prioritize and test when these requirements conflict, especially across inconsistent email clients? The same goes for brand styles that may clash with web content accessibility guidelines (WCAG).

Mike: When these requirements conflict, accessibility has to come first. Dark mode and responsive design are preferences. For many people, accessibility is the only way they can use email at all.

In practice, most “conflicts” come from deeper design issues that can be fixed. I usually suggest a simple order of priorities:

1. Start with semantic structure. Get the heading hierarchy, reading order, and link text right. If the structure is solid, everything else is easier.
2. Then, make sure the contrast is compliant. Aim for at least 4.5:1 for normal text, and 3:1 for large text and key UI components. Check both light and dark backgrounds.
3. Finally, refine responsive behavior. Ensure touch targets remain at least 44 × 44 px and content reflows without horizontal scrolling.

When brand styles clash with WCAG

Brand styles are a common pain point. My answer is always the same: accessibility is not something you apply after the brand work is done. It must be part of the brand system. If your main brand color fails to contrast against white, you define an accessible alternative for digital use. Some teams create accessibility-compliant “extensions” of their brand palettes that keep the same feel but meet WCAG.

Testing approach

Testing should follow the same logic. First, test base accessibility: structure, contrast, focus order, and link text. After that, test dark mode and responsive behavior, and do it with real assistive technology. Combinations such as VoiceOver with Apple Mail, NVDA with Outlook, JAWS with Outlook, and TalkBack with Gmail on Android cover about 78% of desktop users worldwide. Dark mode testing should take place after base accessibility is solid.

Stripo: Where do teams most often break their accessibility processes in real life, even when they already have good rules in place?

Mike: Common breakpoints:

1. Template drift: People start making “quick fixes” and one-off exceptions. Over time, those small changes add up, and the templates in production no longer behave like the ones that originally passed accessibility testing.
2. Handoff gaps: Designers may clearly mark headings, alt text, and reading order in their files, but this information gets lost between design and development. 
3. Velocity pressure: “We need this out today” becomes a justification for skipping accessibility steps. Once that happens once, it happens repeatedly.
4. Personnel changes: When the person who understands accessibility leaves, institutional knowledge walks out the door. 
5. Success invisibility: Accessibility work is often invisible when done well. In this case, you notice failures, not successes, so it’s easy to deprioritize.

How teams can build and own accessible email

Stripo: Accessibility often breaks down not at the design level but in the production workflow. What does a mature, accessibility-first email workflow look like, from copy and design to QA and deployment?

Mike: I usually describe it in phases:

Copy phase:

• write alt text at the same time as headlines, since it’s part of the content, not a technical afterthought;
• use plain language (WCAG 2.0 Level AAA recommends a lower secondary education reading level);
• front-load key information; don’t bury calls to action within lengthy paragraphs;
• write meaningful link text (“View your statement,” not “Click here”).

Design phase:

• designers must use an accessibility-compliant design system with preapproved color combinations;
• create designs at the mobile scale first. If it works at 320 px with touch targets, it’ll work everywhere;
• include text alternatives in the design file itself, not as a handoff afterthought;
• specify heading levels visually in mockups.

Development phase:

• stick to semantic HTML; use tables for layout only when necessary;
• include the lang attribute on the HTML element;
• build a tested, accessible email template library and reuse it relentlessly;
• never rely on color alone to convey meaning.

QA phase:

• remember that automated testing catches roughly 30% of accessibility issues; the rest require manual testing;
• test with actual screen readers (JAWS, NVDA, VoiceOver), not just accessibility checkers;
• include accessibility in acceptance criteria; 
• maintain a defect log specifically for accessibility issues to identify patterns.

Deployment:

• monitor accessibility regressions in triggered and transactional emails, not just campaigns;
• include accessibility in post-deployment analytics when possible.

Stripo: In a typical email program, who should own accessibility? How do you avoid it becoming just one person’s job?

Mike: It works best when maintaining accessibility is part of the company’s culture, when team members catch accessibility issues without being prompted, and comments like, “We can’t ship this; the contrast fails” come from anyone on the team instead of just designated accessibility people. 

Accessibility is discussed in sprint planning and estimation rather than retrofitted. New hires receive accessibility onboarding as a matter of course. The team can articulate why accessibility matters, not just what the requirements are. Accessible templates are the default starting point, not a special request.

As to how you build accessibility in your work process and who is responsible for what, I can say that different roles own different parts:

1. Strategy: Owns the business case for accessibility and ensures it’s in the brief. Sets the standard that accessible emails are the only acceptable deliverable. Champions accessibility investment.
2. Copy: Owns alt text, link text, reading level, and logical content structure. Alt text is copy, so it should come from writers, not developers guessing at intent.
3. Design: Owns color contrast, visual hierarchy that maps to semantic hierarchy, and ensures designs can be implemented accessibly. Should annotate designs with heading levels and reading order.
4. Development: Owns semantic implementation, testing across assistive technologies, and maintaining accessible template libraries. Should flag when designs cannot be built accessibly.
5. QA: Owns accessibility testing as part of standard QA, not a separate “accessibility QA.” Should use screen readers (JAWS, NVDA, VoiceOver) as part of regular testing rotation.
6. Legal/Compliance: Owns risk assessment and stays current on regulatory requirements (ADA, EAA, Section 508, etc.).

Stripo: If a large team wants to bring accessibility into their QA in a structured way, where should they start?

Mike: I recommend thinking in gates.

Testing structure:

• gate 1: Automated. Every email runs through automated accessibility checking before human review. This catches obvious failures fast;
• gate 2: Peer review. Accessibility checklists are reviewed by someone other than the creator, as fresh eyes catch more;
• gate 3: Testing with assistive technologies (AT). Regular screen reader testing rotation using JAWS, NVDA, and VoiceOver. Not every email needs full AT testing if you’re using established templates, but new templates and significant variations do;
• gate 4: Sampling. Monthly audit of random emails sent by accessibility specialists or external auditors.

Maintaining over time:

• tie to metrics: Track accessibility defect rates and make them visible at the team level;
• automation: Build accessibility checks into CI/CD pipelines so failures block deployment;
• rotation: Rotate “accessibility champion” responsibilities so that knowledge spreads and no one person becomes a bottleneck;
• external audits: Quarterly or bi-annual external accessibility audits prevent internal blind spots from calcifying;
• user testing: Periodically test with actual users of assistive technology. Nothing maintains focus like hearing real feedback.

Stripo: What signals tell you that an email team has truly embedded accessibility into its culture rather than treating it as a compliance checkbox?

Mike: Team members catch accessibility issues without being prompted; it’s automatic, not a checklist item. “We can’t ship this; the contrast fails” comes from anyone on the team instead of just designated accessibility people. 

Accessibility is discussed in sprint planning and estimation rather than retrofitted. Postmortems on accessibility failures happen with the same rigor as other quality issues. New hires receive accessibility onboarding as a matter of course. The team can articulate why accessibility matters rather than just what the requirements are. Accessible templates are the default starting point, not a special request.

Stripo: Can you share a real example in which a team adopted email accessibility and saw changes in production time or subscriber engagement? What actually changed in their workflow?

Mike: I worked with a financial services company that overhauled its email accessibility program. Their triggered emails, statements, alerts, and confirmations were essentially inaccessible. They used images of text, had no alt attributes, and were very hard to navigate with a screen reader.

What changed in their workflow was not one major shift but several connected steps. They built a new template library with semantic HTML, a proper heading structure, and real text instead of images of text. They integrated an accessibility checklist into their existing QA tool. Writers were trained to author alt text alongside other copy, and JAWS and NVDA testing were added to their standard QA rotation.

The results were clear. Production time decreased by about 15 percent once the new templates were in place, because they were more modular and easier to customize than the old designs. Support tickets from customers with disabilities dropped by around 60 percent within three months. Click-through rates increased by about 8 percent overall, not just among users with disabilities. Better semantic structure and clearer link text improved the experience for everyone. The team also saw fewer rendering issues across clients because semantic HTML tends to be more consistent than image-based layouts.

The business case for accessibility in that program was not only about being inclusive, although that matters; it was that accessible emails performed better for everyone and reduced support costs. This pattern repeats often: accessibility improvements tend to benefit the entire audience.

Small changes teams can make today

Stripo: From your experience, what are the smallest workflow or communication changes teams can make that immediately reduce accessibility errors and save time, even before they touch design systems or tools?

Mike: You can get a lot of value from small changes in how you plan and review work. A few examples:

• write alt text at content creation, not in development. This one change makes sure alt text gets the same editorial attention as other copy;
• require contrast ratios in design specs. Designers should document the contrast ratio for every text/background combination. If they can’t, they haven’t checked;
• create a simple accessibility handoff checklist. One page, a few items:
  • alt text: completed;
  • contrast: verified;
  • link text meaningful: check;
  • heading structure: documented;
  • reading order: confirmed;
• adopt “accessibility first” questions in reviews. Before any other feedback, ask, “Can this be perceived by someone who can’t see it?” This one question shifts attention very effectively;
• ban “click here” and “learn more” as standalone links. Make this a style guide rule. It forces writers to think about link context and immediately improves the experience for screen reader users;
• test one email per week with a screen reader yourself. Just one. Use VoiceOver (built into Mac and iOS), NVDA (free for Windows), or JAWS. A few minutes of lived experience change your perspective more than hours of reading guidelines.

These are all small process changes, but they move accessibility into everyday work instead of leaving it as a separate, occasional task.

The future of email accessibility

Stripo: Looking ahead, what emerging technologies or regulatory shifts do you believe will force email marketers to rethink accessibility more radically in the next 2–3 years, and how can forward-looking teams prepare now?

Mike: I usually look at this from two angles, regulation and technology, and what teams can do about both.

On the regulatory side, the European Accessibility Act (EAA) came into force on June 28, 2025. It requires accessibility for digital services, including email communications, for EU customers. Organizations that were not prepared are now dealing with real compliance challenges. In the US, rulemaking under ADA Title II on web and mobile accessibility is expanding, and even though it focuses on the public sector, there is a strong spillover effect in expectations for private companies. In addition, state-level legislation is accelerating. Accessibility requirements are starting to grow beyond just federal standards.

On the technology side, AI-generated content is flooding email programs. Most AI systems, by default, produce content with accessibility issues: missing alt text, weak or meaningless headings, and link text that does not tell you where you are going. Teams need governance frameworks for AI-generated email content that treat accessibility as a requirement, not a “nice-to-have” fixing step afterwards. 

We are also seeing more voice interaction with email through smart assistants and voice-first devices, which makes semantic structure and clear hierarchy even more important. Privacy changes that affect images, such as Apple Mail Privacy Protection, push teams to rely less on tracking pixels and more on the actual quality and clarity of content. This aligns well with accessibility best practices.

For teams that want to be ready, the pattern is simple. Start by auditing your current state across both campaigns and triggered or transactional messages, so you know where you stand. Build accessibility into any AI content process you use so that generated emails go through accessibility reviews before reaching subscribers. 

Invest in solid, accessible templates, because good templates reduce the effort required for every new send and keep things consistent. Focus on broad training so that most people on the team have basic accessibility literacy, instead of relying on a single expert. Most importantly, engage with recipients who rely on assistive technologies, because their feedback will tell you what really works.

Organizations that treat the next two or three years as a transition period and invest steadily in accessibility capabilities will be in a strong position. Those that wait for regulatory deadlines tend to face rushed, expensive remediation. I have seen both scenarios many times, and proactive investment almost always costs less and produces better results.

Wrapping up

Email accessibility is not a side project or checklist item. As Mike Paciello highlights, it starts with a few clear foundations, solid structure, sufficient contrast, and meaningful copy, and grows into shared ownership across strategy, design, development, QA, and legal. With accessible templates, simple workflow changes, and regular testing, teams can not only include more people but also reduce production time, cut support tickets, and see measurable gains in clicks and trust.

We thank Mike Paciello for sharing his insights, experience, thoughtful perspective, and practical steps for implementing accessibility with Stripo blog readers.