Email Accessibility in WordPress: Maria Maldonado  🔗 **Source:** [Email Accessibility in WordPress: Maria Maldonado](https://www.youtube.com/watch?v=kE66IY1QwhM) > [!note]+ Document Notes > --- > tags: [email-accessibility, wcag, screen-readers, transactional-email, woocommerce, assistive-technology-testing] > author: Maria Jose Maldonado (speaker); Amber Hinds (host) > source: WordPress Accessibility Meetup / Equalize Digital > reference: https://www.youtube.com/watch?v=kE66IY1QwhM > date created: 2026-09-19 17:18 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Email Accessibility in WordPress: Maria Maldonado > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Session recording (source)](https://www.youtube.com/watch?v=kE66IY1QwhM) > - [Equalize Digital — Focus State newsletter and recaps](https://equalizedigital.com/focus-state/) > - [Accessibility Craft podcast](https://accessibilitycraft.com) > - [WordPress Accessibility Day 2026](https://wpaccessibility.day/2026) > - [WordPress Accessibility Meetup Facebook group](https://facebook.com/groups/wordpress.accessibility) > - [WCAG 2.2](https://www.w3.org/TR/WCAG22/) > ## 📝 Summary > - Maria Jose Maldonado, an Accessibility Specialist at Equalize Digital holding CPACC, WAS and CPWA certifications, presents a practical framework for auditing emails sent from WordPress sites, covering both transactional and marketing messages. > - The organising argument is that email is a continuation of the website experience: the journey runs website, then transaction, then an email carrying critical information, then the user's next action. An accessible site that sends an inaccessible email breaks the task anyway. > - She gives five reasons email accessibility gets skipped: testing targets the website not its messages, emails are generated by assorted plugins and themes, marketing and transactional systems are owned by different teams, email clients support HTML and CSS inconsistently, and a preview is not the message a user receives. > - The deliverable is a ten-point checklist — meaningful headings, logical reading order, descriptive links, appropriate alt text, no essential information only in images, sufficient contrast, readable typography, appropriate table semantics, assistive-technology testing, and testing across relevant email clients. > - Her single most reusable test is a falsification question for image dependence: if every image disappeared, could the recipient still understand the email? > - The Q&A yields a finding worth more than the slides: screen-reader-only text generally does not work in email, because the off-screen positioning CSS it depends on is unsupported by many clients, so hidden text is not a reliable remediation. > - Stakeholders: WordPress site owners sending WooCommerce, form, membership and newsletter mail; plugin authors generating email templates; and accessibility auditors whose scope usually stops at the website. Risk: the presenters state plainly that Outlook is outside their testing scope, so the client-coverage advice rests on Gmail experience. > - Bottom line: test the email a user actually receives, with images disabled and a screen reader, and fix as close to the source as possible. > ## 📖 Main Content > - The email-as-UX-continuation framing is the talk's foundation and is stronger than the usual compliance framing, because it locates the failure in a broken task rather than in a violated criterion. Maldonado names three barrier classes: screen reader barriers from structure, low-vision barriers from contrast and image-based information, and task barriers where users cannot find or complete the next step. > - Email is treated as a distinct technical environment rather than a webpage variant: CSS support varies sharply across clients, tables remain common for layout, responsive behaviour is unpredictable, and assistive technologies interact with clients differently. The goals stay constant — receive, understand, find the next step, complete the task. > - On tables, the position is precise and avoids the common overcorrection: the goal is not to avoid tables but to use correct semantics. Layout tables should carry presentation semantics; real table headers and relationships belong only to genuine data tables; nesting should be minimised; and what the screen reader announces should be tested. > - The image taxonomy is three-way — informative images need alt text conveying the specific information, decorative images take empty alt, and text-in-image must reproduce the exact text in the alt attribute or adjacent markup. > - Reading order is presented as a DOM-versus-visual mismatch problem, with a worked example where the footer is announced first, then the button, a column, the logo and another column, against an intended sequence of logo, hero, content, call to action, footer. > - The transactional/marketing distinction matters for risk rather than for standard: transactional email supports a task (password reset, order confirmation, membership renewal) while marketing email encourages an action (newsletter, promotion, event invitation). Both must be accessible; failure costs differ. > - The WordPress-specific chain is enumerated — core triggers the notification, plugin or theme code generates logic and content, templates define HTML and CSS, a mail service delivers, the client renders, and the user's assistive technology consumes it. Her conclusion follows directly: a plugin may generate the email, but that does not make the result accessible. > - Remediation guidance is to fix as close to the source as possible, distinguishing WordPress-side causes (plugin settings, theme, template, custom HTML) from email-platform causes (template, campaign builder, automated messages) from client rendering and fallbacks. > - The audit workflow is five steps: identify the email source, send the email, inspect visually and with assistive technology, document issues, retest the fix. Maldonado configures sends to her own inbox specifically to test as a user rather than as a template previewer. > - The live exercise is effective pedagogy — an intentionally inaccessible order confirmation with light red text, a blocked banner carrying all the important information, bold text standing in for a heading, an untagged pseudo-table, status conveyed by green and yellow alone, three adjacent vague links, and a decorative image with the alt text 'Order confirmation banner'. Attendees correctly identified contrast, colour-only meaning, ambiguous links, image-dependent information and missing table structure. > - Contested and honestly flagged: whether email length is an accessibility concern. Maldonado assigns it to usability, then immediately notes that complex vocabulary and dense paragraphs affect people with cognitive and attention differences — which places part of it back inside accessibility. > - The capture is a transcript of a recorded meetup and contains no hyperlinks, so the URLs named aloud (equalizedigital.com/focus-state, accessibilitycraft.com, wpaccessibility.day/2026) appear as spoken text rather than as links. > ### 🗒️ Notes > #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=kE66IY1QwhM&t=0) Meetup housekeeping, sponsor, upcoming events and speaker introduction > - Amber Hinds, CEO of Equalize Digital and lead organiser of WordPress Accessibility Meetup, opens; recordings, transcript and recap promised within days via the Focus State newsletter. > - GoDaddy sponsors live captioning and transcription for the session. > - Upcoming: 1 October, Deneb Pulsipher on 'Ethical A Amber: Welcome to WordPress Accessibility Meetup. This is Email Accessibility in WordPress with Maria Maldonado, who is an Accessibility Specialist at Equalize Digital. If you've not been before, a few things that are good to know. First, we have a Facebook group that you can use to connect between meetups. You can find it if you go to facebook.com/groups/wordpress.accessibility. Everyone always asks, "Is this being recorded?" The answer is yes, it is being recorded. We have updated our processes, and so we should be able to have the full recording, the transcript, and the recap ready in a couple of days, hopefully when our email newsletter goes out this Thursday. So on that note, if you want to get notified of the recap, please join our email list. You can do that if you go to equalizedigital.com/focus-state. If you said yes when you registered, we'll put you on, but if you said no, we will not even send you an email about the recap because we want to respect that no. So if you wanna get notified, you do have to join the email list. You can also find recordings. In a week or two, it'll be up on accessibilitycraft.com, which is our podcast. So if you prefer to listen rather than watch, that is the place to go. If you have any suggestions for the meetup or you need any additional accommodations to make the meetup work for you, you can contact us at [email protected]. Who am I? I've been talking. If you haven't been here before, you might be wondering, "Who is this person introducing the meetup?" I am Amber Hinds. I'm the CEO of Equalize Digital. We are the lead organizer for WordPress Accessibility Meetup. We are a mission-driven organization that is focused on WordPress accessibility. We make WordPress plugins, including the Accessibility Checker plugin that helps you find and fix problems on your website. We also have a couple of micro plugins, ArchiveWP and BoardScribe, to support remediation efforts. We have online courses for NVDA and VoiceOver screen reader testing, as well as selling accessibility, all of which are pre-approved for continuing ed credits if you need those for any accessibility certifications. And we do accessibility audits, remediation, and consulting, not just in WordPress. We do a lot of it for many other content management systems and mobile applications as well. We have one sponsor that I want to thank, and that is GoDaddy. GoDaddy is very generously covering the cost of our live captioning and transcription today. We very much appreciate them. GoDaddy provides a managed WordPress experience that is as easy as it is effective. The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, and malware removal so pros can spend less time on monotonous maintenance and more time building their businesses. You can learn more about GoDaddy if you go to godaddy.com. We always ask if you are willing, on whatever social media platform you are on, to send them a tweet or a message or comment on one of their posts and say, "Thank you for sponsoring captions for WordPress Accessibility Meetup." It helps to tell them that the sponsorship matters, that captions matter, and that will encourage them to want to continue sponsoring in the future. A couple of upcoming events to be aware of. On Thursday, October 1st at 10:00 AM Central Time, Deneb Pulsipher will be presenting Ethical AI and quote, "Benevolent Friction": Rethinking Alternative Text in WordPress. Then on October 7th through 8th, I can't believe we are already only a couple weeks away WordPress Accessibility Day is happening. That is a 24-hour live stream of events, 24 amazing presentations all about accessibility. It is free. It starts at 10:00 AM Central in the US, but since it's 24 hours, no matter where you are in the world, there are going to be talks that are during your business hours. You can register free for this and learn more about it, see the schedule if you go to wpaccessibility.day/2026. And then our second presentation in October for Meetup will be about using Accessibility Checker Pro and Claude AI to remediate a large WordPress website, and Courtney Robertson will be presenting on that. I am very excited to introduce our speaker today. Today's speaker is Maria Maldonado, who is a seasoned web accessibility professional. She works on our team here at Equalize Digital. She has a strong foundation in education. Since transitioning to the accessibility field in 2018, she has been dedicated to advancing accessibility testing and fostering digital inclusivity. She has a CPACC, WAS, and CPWA certifications from the International Association of Accessibility Professionals, and she possesses a comprehensive understanding of web content accessibility guideline standards and legal requirements. I am gonna stop sharing. I'm gonna let Maria take over sharing and go away, but we will come back. If you have any questions, please post those in the Q&A, and I will pass them along to her at the end. Maria: Perfect. Okay. Let's start. Hi, everyone, and thank you for joining today's session, Email Accessibility in WordPress. My name's Maria Jose Maldonado, and as Amber said, I'm an Accessibility Specialist at Equalize Digital. Today, we are going to talk about email accessibility in a very practical and approachable way. My goal is to show you how accessibility applies to emails sent from WordPress websites, including both automated transactional and marketing emails. The session will look at practical examples, including table-based email layouts, links, headings, images, color contrast, readable content structure, and testing workflows. What we'll cover. Here's what we'll cover today. First, we'll define why email accessibility matters for WordPress websites. Then we'll look at some of the most common accessibility issues in transactional newsletter emails. And after that, we'll focus on how to test emails sent from a website. Emails are part of the user experience. The website experience doesn't end when someone submits a form, makes a purchase, or joins a membership. We have the website at the beginning with the initial interaction and entry point. Then we have a transaction, form submission or purchase. We have the email that contains critical information, and it's a critical continuation of the UX. And then we have an action, which is the next user step or confirmation that we call through the email, right? If someone cannot read, navigate, or understand an email, the experience breaks, even if the website itself is accessible. Sometimes accessibility gets reduced to a checklist or compliance requirement, but at the center of all of these are real people. Let's ask what happens when email isn't accessible. So we have screen reader barriers, like structure, headings, and links made difficult to understand. Low vision barriers, like poor contrast, small text, and image-based information. And we have task barriers. Users may not be able to find or add on the next step. Think about missed orders, confusing instructions, or promotions people cannot use. These are real barriers, not just technical issues. Why is email often forgotten? Accessibility testing focuses on the website, not the message that it sends. Emails may be generated by different plugins, themes, or platforms. Marketing tools and transactional system may be owned by different teams. Email clients have inconsistent HTML and CSS support. And a preview is not the same as the email a user usually receives. So email is often forgotten because teams focus on the website, but WordPress can send a lot of important messages automatically. Keep in mind that if your website sends it, it is part of the user experience. Email accessibility is different. The HTML email is different from the webpage. So we have CSS that's overpriced significantly across clients. Tables are still commonly used for layout. Responsive behavior can be highly unpredictable, and email clients and assistant technologies interact differently. But the goal is the same. Recipients should be able to receive the information, understand the message, find the next step, and complete the task. So email has its own limitations. We need to think about HTML support, email clients, images being blocked, and assistive technologies. This is the checklist that we are going to use. Content, structure, reading order, tables, images, links, color, typography, and testing. Review all 10 key areas to deliver fully accessible email experiences. Now, we are going to go to the interesting part. Content comes first. Before talking about HTML, ask yourself: Is the purpose clear? Can someone quickly find key information? Are instructions explicit? Is language concise and understandable? Can the recipient tell what to do next? I have an actionable text example here. We have first a "Click here" link, which is vague because click here what? It doesn't really say anything or where it's going to direct the user. And then we have another example, which is "View your order". Descriptive link text clarifies the purpose for screen reader users and also for schemers. So start with the message. Clear content and a logical order help everyone, especially people using a screen reader or a magnification. Let's talk about headings and content structure. A common mistake is using bold text to make something look like a heading instead of using actual heading tags. Another issue is skipping heading levels randomly. Think of headings like an outline, right? H1 is a main title, H2s are major sections, and H3s are subsections. Clear structure improves readability for everyone. On the screen, I have two examples. I'm going to describe it for you. The first one is hard to navigate because we have the order confirmation text. First, we have all the text without any heading markup. Order confirmation is in bold and a little bit bigger than the rest of the text. Then we have thank you for your purchase, and then we have your items, shipping details, payment details. Those three sentences have the same size and the same style. The screen readers are going to treat this, all of this information, as flat text without clear section stops. And then on the other side, I have an easier to navigate example. I have order confirmation marked up as an H1, and then your items, shipping details, and payment details are marked up as H2. So we have a clear title for the email, and then we have three subsections that help the user navigate between the content that they have. So semantic HTML tags allow users to jump straight to the relevant sections using screen reader shortcuts. Use real headings when content is divided into sections. Avoid making text look like a heading only with bold or larger font. Let's talk about email reading order. Here I have two different examples as well. I have one that is a visual order or the sequence of an email. So let me describe it for you. First, I have the logo, then I have the hero image, then we have the main content of the email, then we have a button which it may be a call to action, and then the footer with all the enterprise information, company privacy policy, et cetera. This is the expected sequence, but what happens if this is not set as it is in the actual code sequence? We have the other side that is a screen reader order. In this example, the footer is at the beginning. Then we have the button, then we have a column, then we have the logo, and then we have another column. So if this information is not matched, it doesn't match the order, the screen reader is going to read it out of sequence, and it's not going to match. So the order in the code should match the order that people need to read because the visual placement alone is not enough. And this is a very important slide that I have, and it's why are tables everywhere? Email clients have, is historical offered limited CSS support. Tables provide predictable layout across many clients, and tables are common in both simple and complex email templates. But layout tables are not data tables. So use presentation semantics for layout. Only tables where appropriate. Avoid unnecessary table semantics and nested complexity. Use real table headers, and relationships for actual data tables, and test what the screen reader announces. Tables are common in email because they help with layout. The problem is using them in a way that exposes layout details as content. Let me be clear with something. The goal is not to avoid tables. It is to use the right semantics, right? Now, let's see something about images in emails. There are three types, at least this is how I classify them. Informative, decorative, and text in an image. For informative images, it basically conveys key content. It describes the specific information or intent that the image adds to the page. They might have decorative images, which is visual enhancement only. For this, use an empty attribute, sorry which is alt empty when the image adds no information. And then, for text in an image, which are embedded graphics, provide the exact same information as real text within the alt attribute or surrounded markup. Images need meaningful alternative texts when they communicate information. And decorative images should generally have empty alt texts. But what if images are blocked? This is something that happens all the time, at least it happens to me because my email blocks images from almost all senders. I don't know if you have the same situation. But I have a key question for you in this case. If every image disappeared, could the recipient still understand the email? And this is very important because if there is a high accessibility risk when you put all the information in the image. If it is image dependent, for example, something that I have on the slide, your package is arriving today, that exists only inside a banner image. If this is blocked, the user is not going to be able to have this information. So what is the best practice? The delivery date and next step are available as real text. Now let's talk about links and buttons. Link text should describe the destination or the action. I think this is a topic that we are always talking about. So avoid vague labels like "Click here", "Read more", "Learn more", and make the link text more descriptive, "View your order", "Reset your password", "Read the January newsletter". So make the links and buttons understandable out of context. There are some users that like to navigate the page using only the links or the buttons, or by components. So having something like "Click here", it doesn't add context to the user, and it's very confusing without the surrounding information. So the idea is to have link text that is descriptive in a way that the user can know what is the destination or what is the action that is going to be deployed after they activate that component. Now, color and contrast. This is something that I think we have been talking about in the last time as well, but I didn't want to leave it outside the presentation. Please use sufficient contrast for text and meaningful controls. Do not communicate meaning through color alone. Check text placed over images or colored backgrounds, and make links distinguishable from surrounding text. Do not use color as the only way to communicate meaning. Also, check contrast for text, links, and important controls. Another aspect to keep in mind is typography and readability. Ask yourself, "can someone scan this email quickly and understand what they need to do?" So use readable text sizes and line spacing, keep paragraph short and scannable, avoid dense walls of text, use headings, lists, and spacing to support comprehension. Check mobile readability, not just desktop appearance, and keep text readable. Use clear language, enough spacing, and avoid making people zoom or work too hard to understand the message. In WordPress, emails can come from plugins WooCommerce, forms, membership tools, newsletters, or custom code. On the screen, we have WordPress, which is the core system functionality triggering default system notifications. We have also plugin, theme or core, source code generating the message logic and content. We have also email templates, which are HTML or CSS layout defining visual structure and presentation. We can also have mail service. Email client is dependable as well. We have Gmail, Outlook, Apple Mail rendering the final HTML output. And we also have these variants, the user and assistive technology, so screen readers and end users consuming the delivered email. I want to talk about transactional emails and marketing emails because there is a difference between these two. Transactional emails support a task. For example, a password reset, a order confirmation, account notification, a membership renewal contact front response. But marketing emails encourage an action. It can be a newsletter, a promotion, product announcement, event invitation, campaign email. Both need to be accessible, but the risk can be different. The idea is to have accessibility in consideration for both type of emails. And you may ask yourself, where should we fix the problem? Fix the problem as close to the source as possible. Sometimes it is WordPress. It means it is related to the plugin settings, a theme, or a template, or you need to use custom HTML, or you use custom HTML which is not accessible. Sometimes it is related to the email platform, so the template, the campaign builder, automated messages. Sometimes this may deliver rendering, client behavior on fallbacks. So a plugin may generate the email but doesn't mean that the result is accessible. We still need to review the final message. This is my basic workflow for testing email. First, I identify the email source, send the email, inspect it visually and with assisted technology. I document the issues, and I retest the fix. The key principle here is to test the email that the users actually receive, not only the template preview. What I usually do is that I configure the email to be sent to my inbox, so I test it in my inbox itself as if was a user, not the preview in the template or in WordPress itself. Now, I have an intentionally inaccessible email. This is a scenario that I have for you. The goal is to show you how quickly small issues can add up, and we have an example here, and I need to… I would like your interaction in this. You can write in the chat if you want. I'm going to describe it for you. It's an order confirmation. The order confirmation is red, light red text. Then we have a banner image that is blocked, and the banner image is supposed to contain all important information, but remember, it's blocked. Then, I have bold text that is big. It's larger text that says, "Hi, Maria. Your order is confirmed." Then I have what it looks like an intent of a layout table because it says, "Your items" in a column, and then the "Price and status" in another column. I have the items below the first column. And in the second column, I have two status, "Shipped" and "Pending". And something important here is that Shipped is green and Pending is yellow. And then I have some links, click here, read more learn more. And at the end I have a banner that is a decorative image which which is also blocked and has an alt that says, "Order confirmation banner." So can you please tell me what are the issues that you can identify here? I'm going to check the chat. Ehm Okay. Color contrast, yeah. The red, yellow as well may not happen. The link text, yeah, because we have click here, read more, learn more. That doesn't say really anything. Then we have the banner image. Alice says the banner image has all the… Oh, sorry, all the information in an image. Yes, and it's blocked. So basically, the user is not able to access that information. Then we have what else? Sorry. Spacing and separation. Yeah. All the content in the main content of the or the main section is like, it doesn't have really a good layout, right? It's difficult to read. Color is the only way to convey information. Yeah. Because shipped is green, so I don't know. We can say that's good, and then pending is yellow. It shouldn't be like that. Click here, read more, learn more, plus the spacing. Yeah, it's everything there. We have three links that look like one. And then there is alt text for a decorative image. And also about this, it says, "Order confirmation banner." Do you think that's enough for an alt text? I would like to know that. Ah someone already wrote that. Order confirmation image is set as a order confirmation banner. Color contrast is difficult to read. Variants are not apparent. Missing table structure for the products table. Yeah. It doesn't have headers. It doesn't seem to have markup or been coded as a programmatic table. Set as an decorative image. Yeah. Yeah, I think that we cover most of the issues that this email has, right? All right. So now I have I see another message. Okay. The questions we are leaving to the end, but I'm going to pass to the next one. I have here an example of an inaccessible email on the left, and then on the right, that's the same email made accessible. So I'm going to go with you and explore a little bit about this. The first one, it has the logo. The logo is My Store, and it's missing alt text. The logo and the image don't have meaningful alternative text. Then below that, I have a text, an image of text that says, "Your order is on its way." It means that important information is only in an image. Then I have some text, it says, "Hi there. Your order has been processed and is on its way." And that is a light gray text on a white background, so it's very hard to read. And then I have an ambiguous link, it says, "Click here", that's the link text and that's the link, "to view your order details". And then, that doesn't really communicate the destination because if I'm tabbing around, it's going to announce that's click here, and that's it. Then I have order details. It seems like a heading, but it is not clear. And then I have a table, a layout table that is used to show the product, the quantity, and the price. And these are visual layout tables, which is used as a data table and can confuse the screen reader users because the thing with the tables is that they convey visual information on relationships between the cells and the columns. And at the end, I have another image of text with a very poor contrast. It says, "Thanks for shopping with us", and I have the footer. And there are missing headings. This email lacks a clear heading structure. If we skim this as a sighted user, we don't really have an idea of the structure of this email on which are the sections, which is the title, and this is going to be very difficult for our screen reader users to navigate as well. The key accessibility issues that we found in here are missing alt text, images with text, low contrast, ambiguous links, layout tables, and no headings. Now, let's move to the happy part. It means when the, this email is accessible. First, My Store has meaningful alt text. This logo and images have descriptive alt text. Then we have a clear heading structure. You can observe that your order has been shipped. We have order details. We have a total. We have everything it's more structured, right? We have descriptive links. Instead of view or click here, we have a sentence that says, "You can track your order in any time for your account." So your account means that you are going to be directed to your account. And then I have a view your order button, which clearly explains the destination of that item. Then we have also good contrast. Text and buttons meet contrast standards. Also, we are not using just images because the important information is available as text. Even if the images are blocked, we have that information available. And then we have a logical reader order. There's a clean structure, no unnecessary tables or markup. Next I have some more examples for you that what may be wrong with emails in general. Because I cannot cover all of the errors in an example, but I'm going to try to go with the generic ones. Important information is contained only in an image. This is very common, and you can share in the comments if you want, if this is something that happens to you very often. Then the image has redundant or inaccurate alt text. Tables structure may be announced unnecessary. Links are ambiguous when encountered independently. Heading structure is missing or is unclear. Contrast and reading order need to be checked. The email should be tested with images disabled and a screen reader. And again, the key principle is test the actual email experience, not just visual previews. And now you may ask yourself, what do we do to pass from a finding, because we have been discussing finding, now to recommendations. Let's study one example that I have here, and is an ambiguous link text. The email contains links with ambiguous text such as "Read More", which doesn't adequately communicate the destination when links are encountered independently. My recommended fix is use descriptive links. Use descriptive link text that communicates the purpose or the destination, such as "Read the January accessibility newsletter". And also, you don't always need to have all of this visually presented for the users. You can use screen reader tags, you can use ARIA labels, and leave the "Read More" if you don't want to change the visual appearance of your email. But make sure that the "Read More" is also connected to the context. In this case, I'm putting an example here about a newsletter. A good recommendation explains the problem, why it matters, and what the developer or content author should change. The mindset is simple. Email is part of the product, so test experience people actually receive, not just a template or the editor. Ask yourself the following questions. Can I perceive it? It means can I access the information? Can I understand it? Is the structure and the content clear? And lastly, can I act on it? Can I find and activate the next step? Meaning is the screen reader able to access this information, this is keyboard operable, can I activate a component using Enter, Spacebar, or is it color-depending, or this is drag, dragging or movement, there is a dragging or movement required that is going to affect some users? Here is a short checklist that I would keep in beside me during an audit or a QA pass. First, meaningful headings. I'm sorry if I'm too emphatic on this, but when I do audits, I always find that headings are not meaningful. Second, a logical reading order. Make sure that the DOM matches the visual structure. Three, descriptive links. Four, appropriate alt text. Five, no essential information only in images, this is very important. Six, sufficient contrast. Seven, readable typography. Eight, appropriate table semantics. Nine, assistive technology testing. And ten, testing across relevant email clients. Last, I want to bring you some key takeaways. Emails are part of the user experience. Accessible websites can still send inaccessible emails. Automated testing isn't enough, so you need manual testing. And test the email that the users actually receive. The main takeaway is the accessible email starts with clear content, simple structure, and testing the final email in realistic conditions. With that, I got to the end. Thank you so much for being here today. I hope this session helped make accessible emails feel more approachable and actionable. And remember that even small changes can make a meaningful difference for users. Now, I'd love to answer any questions that you have. I'm going to stop sharing my screen, and we can go to the questions. Amber: Yep. Maria: Or comments. Amber: There are a few questions in the Q&A, so I will walk through those. Alice had asked, "If a website isn't offering a transaction, can informational emails about things be sent to a group, like a Google Group email?" Do you have any opinion on group sending? And have you ever tested the accessibility of the Google Groups platform? I don't know if I have. Maria: No, I haven't, honestly. Amber: Yeah. Maria: But that's an interesting question. Yeah. Let me read it again because I lost it. Amber: Yeah. Also I know we use Google Groups that then forward to our company, like Gmail accounts, and that's where we access them all. I think probably any sort of group emails, as long as you know where users will be opening it would be fine. But I've never tested the accessibility of Google Groups, so if you're gonna expect people to log in there to get information, you'd probably need to test it. Yeah. Maria: Let's go to another one. Amber: Yeah, let's see. So Naomi had said, for a newsletter, is it better to keep all text left aligned and not use columns to avoid potentially having content missed by screen magnifiers? Maria: I would say that, avoid the use of tables if you don't really need it, because a table combines information or a relationship between what is in the cells or in the columns with the headers. Really if you are showing a newsletter and you only have paragraph text, I would say do not use columns because it's unnecessary. And also, it's more work, because if you build the table, you also have to add the role of presentation, so it is not rendered to the screen readers. So I would just say use regular text. And test the alignment. Because we were talking about this before the meeting started, and sometimes it depends on the device. Try to test it with different zoom, 200, 400, or test it in a cellphone. If you have the opportunity to test it in different platforms as well Google, Gmail, Outlook, also, that's going to be different, and that's something that is not going, that is, is not possible for you to predict. But you can test it to see if something is missed, something is cut, overlap, or misaligned. So you can identify it and remediate it before it is actually sent to the clients. Amber: Yeah. I think the question about columns is really interesting, and I tried briefly when I saw this question come in to find an email that WordPress Accessibility sent recently, and I couldn't find it in my email. But I will be honest, I don't know if I've ever opened those emails, which we have occasionally. We frequently just have a single column, but occasionally with WordPress Accessibility Day, we have put things in two columns. And I know that at least those emails aren't coming out of WordPress. They're generated with MailChimp, and they do stack. So I don't know if MailChimp is using the table structure or if they've just handled the CSS for it to stack and not require a sideways scroll on mobile or zoom. But I think you're right. Ultimately, it probably, as long as you test it in enough platforms or you're aware of what it's going to do. I think it's weird 'cause I've seen different implementations for how people handle columns. And a lot of times it is underlying a table, and then you have to put role presentation like you were saying. Do you have any thoughts about centered text versus left align? 'Cause that was the other part of this question. Maria: Yeah, I think that I prefer that because it's the… If people use justified, it can creates like gaps in the text that are difficult to read for some people. So I always prefer the left aligned. But as I said … again, you need to test it not only in the preview, because it can be cut or misaligned sometimes. Amber: Yeah. I think a rule that we followed on both our website and our email is that if it's going to be more than two rows of text, then it should be left aligned and not centered. Because it gets a lot harder to read when to wrap your eyes to the next row when where the next row starts is always different. So I would say from a readability standpoint, it's probably better not to center your emails. But I know a lot of people are like, "All headings should be centered." But you have to think about if it, if the font size doesn't get small enough on mobile, then you could end up with a giant block of centered… like many rows of text. Maria: And also take care with the sticky information because that can block the rest of the information. If you use something that is sticky, like a footer or a header banner, it can just cover the main information as well. That's something that is very common when we're testing responsiveness. Amber: Yeah, Jules' question was a carry-on to what you had started to say about "Do we test different email platforms to see if the sent email differs? For example, would you test Outlook versus Gmail, and what about desktop clients versus online?" Do you wanna talk a little bit more about this conversation that we just had internally? Maria: Yeah. We honestly don't have Outlook, so it's not under our testing scope, that's the truth, because we don't. We use Gmail. But we do test different layouts with the simulator in the desktop, in the browser, sorry. So we use the screen size for phones, tablets, sorry, and also different zooming. But we were talking that maybe it's necessary to add Outlook to our scope as well, because it's something that we are missing. We don't really know what is the difference, but as we as a company use Google and Gmail, that's what we use when we test. But it could be interesting to launch a poll to see how many people use Outlook so we can see if it is necessary to test it across Outlook as well. Amber: Yeah, we actually got an email yesterday from someone where they sent a screenshot. And I don't know what email app they're in but they sent a screenshot of one of our emails on mobile, and there was no margin or padding on the left and right, so it went all the way to the edge of their screen. And I was like "This is interesting, because it doesn't look like that for me in Gmail." And I do know that Steve uses his iPhone mail on his phone. So we have gotten it tested there, and it doesn't look like that there. And I was like, "I wonder if this is the mobile Outlook app." And so I think… my advice that I would say is figure out what your customers are most likely to have, and then try to test. I know a lot of the CRMs have emulators, and they can show you in different platforms. It's just more difficult in WordPress. But our solution was is we're like, "You know what? It doesn't hurt us to go add five pixels of padding on the left and right of every container in all of our email templates, and then that will solve it for that one person in whatever app they happen to be using that we don't see the problem." But, you just have to be responsive, I think, if somebody reports an issue. Patrick said, "When you create an email, how do you check the header information and other information? What tool do you use?" Do you wanna answer that one? Maria: Yeah. You have different ways to test this. You have in the extension. In the browser, you can use browser extensions as HeadingMaps or Landmarks, but you can also inspect the elements manually. And also you can use a screen reader and navigate so you can find out if that's correctly or programmatically set up. I would say that the quickest is just using the extension, because it's going to show you and highlight all of the headers or the headings in the page. It's something like one minute or less. But you can also inspect what we think what you think it may be a heading and just see if it is properly tagged in an H tag. I hope that this answer your question, Patrick. Amber: Yeah, I think I could actually… Hold on, let me share my screen for just a second, 'cause I know we've also had conversations, like we use the WP Mail Logging plugin sometimes so you can see emails in WordPress. But then we're like, "No, you actually have to send them and look at them somewhere else," because the way it looks in the browser in the WP Mail Logging plugin might not be the same way that it looks in an email platform. But I'm just gonna… I'm gonna share my email. This is like an IAAP email that I got. And if I use the HeadingsMap, like that will give me some information, but you have to obviously note, like search, this is actually the Gmail search. So the email actually only starts here with the sub- that's the subject. And then the title is, that's who the sender is. Then this H1, this is the heading that they put into the email. So I would say, and if you really want to investigate like the literal HTML headers, I don't know if that's what you're asking about, like viewing it in a browser and exporting it is probably gonna give you more information. But I think this would allow you to see some tools, and sometimes if you're like, "It's confusing 'cause I see all these other headings," if you open a print preview, then you get only the email and not all of the other noise, so you can get just the headings that are actually controlled in the body of the heading, or of the email. I think like this view is sometimes more helpful if you wanna use like WAVE. We'll see if it'll work. Nope. WAVE doesn't wanna test this. But if you wanna try and… Probably 'cause it can't go out and come back. I think this view is maybe more useful if you're trying to test, oh, Alice added extra context, an automated-- About her question before, she said an automated informational email is better subscribed to from the website. She says people get information now by subscribing to the group, and then emails are sent to the group. I guess what I would… just a follow-up on that, I would just-- If you're going to have people join a group and then the email goes to the Google Group and the Google Group distributes it, you just need to make sure you test whatever the final email is that the Google Group is sending because you want to make sure whatever you set up isn't getting stripped out for some reason. If the Google Group is sending it, are the headings still present? That kind of thing. But hopefully that helps. Michael asked "Since their support of HTML and CSS is limited, do email clients typically support ARIA labels and screen reader-only text?" Maria: It depends. We don't have a- Amber: I think the screen reader only text answer is usually no. Maria: No, but we can hard code some of the plugins or templates sometimes. Yeah, I don't have a- Amber: I think you can't- … Maria: answer to that. Amber: I think screen reader only text can't be screen reader only text, not that it will be hidden from the screen readers, but that it will not be hidden from sighted people, is my understanding. Because normally when you do that, you position it off screen, and I think that CSS is not supported by a lot of email clients. So it's just text. It's not screen reader only text, is my understanding. Maria: But I… Yeah, but I would say something that I always say, I'm sorry if I'm too repetitive, but if you have something that is helpful for screen reader users, it may be useful for all of your users. So you can find a way to have that information available for everyone, and that's a better approach than just hidden text. That's what I always recommend to the clients. I know that sometimes you have to preserve the design or the visual layout or the client refuses to change something, so you have to add it as a hidden text. But I always say that if it is helpful for a group, it's helpful for everyone, so just put it there. Amber: Yeah, I think the biggest thing to pay attention to on marketing emails is probably those ambiguous links. If you're doing a roundup of your recent blog posts, don't add a link style button that just says read more. I would err on the side of not even having that and just linking the title of the post so that you make sure that it is unique every time, because it… You won't really be able to add, I don't think, an aria label. Maybe an aria label might work, but you also might not have the support to that in however you're building your emails, unless you have the ability to fully edit the code in the email platform. Someone asked, "Do we have an opinion on whether the email is too long? Newsletters cover so many topics that emails can feel like webpages. Does that impact accessibility, the email length?" Maria: I don't know if this is in under our scope. I think this is more related to usability than accessibility. The important thing is the level of the reading that you are using. If you use a lot of complex words or very stacked or paragraph that are too dense, that is going to affect some people that may be hard to read or that have cognitive or the attention deficit as well. And I would say that all users as well. So I would say that this question applies more to usability or UX in general than, rather than accessibility. My personal opinion, yeah, you don't need an email that is too long. If you want, you can just lead your clients or your or people to a webpage through your email so you have a call to action in the email instead of having all of the information in there. Remember also that people review their emails often in their phones or in the tablets, so it's going to be… You have a reduced space to fill all of the information, so try to keep it concise. That's my personal advice. I don't know if you want to add something, Amber, on this. Amber: Yeah. I would just say it's also worth noting that some email platforms will truncate long emails, and they literally cut it off. And so it's almost like you have a fold, and then somebody has to hit view the whole thing. This happens with my HOA their weekly events email has so much stuff in it, and it'll never show me all of it. So it would be difficult any headings that were below that are not there, people would not have as much of an idea. I know we intentionally, with our Focus Date newsletter, decided that we were not gonna have a featured image for every article, and there's very few images in that email period. Because we're like, "What does actually matter?" It's let's give people the text information quickly. Obviously, if it's an e-commerce website and you wanna show a new product, then an image really matters. But I think you wanna think about who are… if you're a service-based business sending out updates, or you have something that's not just an e-commerce product, then the image might not matter at all, especially if it's a stock photo. If it's a stock photo, then you probably don't wanna waste time by putting that in the email. It's probably not gonna help improve your clicks. Noe had an interesting question. "Do you have any recommendations for emails that need to be bilingual, Maria? And do you recommend that?" I'm guessing school districts, for example, here in Texas, a lot of times the email's English at the top and then Spanish at the bottom. Do you have any tips for that? Maria: And I've seen this mostly in LinkedIn posts that that need to have, and they always put the language English first. I don't know if I have a strong recommendation for this, but I would say that you can just put the content in both languages in there, and just make sure that it's going to, it's properly marked so a screen reader can make the switch of the language when they are announcing it. Because otherwise it's going to be really confusing for users. Amber: Yeah. Maria: So… Amber: Having a lang attribute and the proper text direction. So if you're doing a right to left text, you need to make sure that you have the HTML attribute that specifies that, otherwise the screen reader'll have a, a lot of difficulty reading the right to left text. Yeah. We are about time. Alice, maybe you can post more about the Google Group in the Facebook group and see if people there have additional… 'Cause you could include like screenshots or share more of what is being sent. I'll say another thing that is worth noting, as Maria mentioned, just in a recap and thinking about how to make this actionable, is there's a lot of different emails that can come from a lot of different places in WordPress, and some of them are easy to edit because they give you all of the controls. Like I was thinking about an example of Easy Digital Downloads, which we use for our plugin sales. We can literally write everything about the email. But like WooCommerce by contrast, they have templates that you could, if you're a developer, pull it into your theme and write the code for it, but they don't have a WYSIWYG builder for it. And I know that there's also like MailPoet and some other fancy plugins that replace the CRMs, and I would always just say just be careful when you're creating emails in those, and make sure that you're really watching the structure, and as Maria said, do lots of testing. But do you have any final thoughts, Maria, before we wrap up? Maria: No. I would say that, as I always say, accessibility is a mindset, so you need to change your, the way that you set things in, and just test it. Just ask the right questions. I think you have the slides. I purposely put there a lot of questions that you can ask yourself to figure out if your content is accessible or not, or if your user is missing information. I think that's the most important thing. And also, don't feel like you need to know all of the WCAG requirements to be able to make accessible content. I think you can do a little bit each day just changing the color contrast, paying attention to the link text making a structure, using the templates properly. That could make a huge impact on the users, give independence to the users that before couldn't use your content. So that's very important. That's it. Thank you. Thank you very much for joining. Thank you. And I hope that this is helpful for all of you. Amber: Thank you so much, Maria, and thanks everybody for coming, and we'll see you back here soon for another meetup. Maria: Bye everyone., Email Accessibility in WordPress: Maria Maldonado, Maria Jose Maldonado, 01m2tyzwn1av3qr4c61604ndcy.