Web Accessibility 101: Small Things That Make a Big Difference: Maria Maldonado

>> AMBER HINDS: Welcome, everyone, to WordPress Accessibility Meetup, Web Accessibility 101: Small Things That Make a Big Difference with Maria Maldonado, Accessibility Specialist at Equalize Digital. A few announcements. If you have not joined before, we have a Facebook group, which is a great way to connect between meetups if you want to share what you’re working on, get feedback, help other people. You can find that if you go to facebook.com/groups/wordpress.accessibility or just search “WordPress accessibility” on Facebook.

Everyone always asks, “Is this being recorded?” The answer is “yes, it is being recorded.” It takes us about two weeks to get corrected captions and a full transcript and a written summary of the meetup. Then that will be published on our website. You can find upcoming events and past recordings in one place if you go to equalizedigital.com/meetup.

The other way to get notified when the recording is available is if you join our email list. We send out both news once a week on Thursdays and event announcements, both upcoming and then also information in our Focus State email newsletter. You can find that at equalizedigital.com/focus-state.

Then, finally, I’d always encourage everyone to tune into our podcast, which you can find at accessibilitycraft.com. The meetup episodes are put on the podcast as well as conversation episodes where we try craft beverages and talk about accessibility. It’s a little bit of an accessibility happy hour. The episode that came out this week is all about using AI to speed up your remediation.

We had two really great guests from an organization called Connect 211 that builds software for state directories. It was really interesting to hear about their dev workflow to speed up accessibility remediation. Tune into that at accessibilitycraft.com. If you have any suggestions for the meetup or there is anything you would like to learn about, if you are interested in speaking, if you need additional accommodations to make the meetup work for you, please email us at meetup@equalizedigital.com.

I am Amber Hinds. I am one of the organizers of this meetup. I’m the CEO of a company called Equalize Digital. We are the team who runs this meetup. We are a mission-driven organization and a corporate member of the IAAP focused on WordPress accessibility. We have a WordPress plugin called “Accessibility Checker” that helps you find and fix problems on your site. We offer online courses for NVDA and VoiceOver screen reader testing. If you want to learn how to do screen reader testing, we also have a course on how to sell accessibility if you are a agency owner or a freelance developer. We do accessibility audits, remediation, and consulting.

I will put a quick shout-out that our online courses and any new plugin purchases are going to have– we’re going to do a little flash sale at the end of this week. It’s not going to be live on our website, but I’m telling you now, if you’re on our email list, you’ll get, I think, an email about it. I think we’re going to put it in Focus State, but it’s going to be just like two days [chuckles] at the end of this week, so watch for that on our email list. That’s in honor of Global Accessibility Awareness Day.

We do have a sponsor that I want to thank today. That sponsor is GoDaddy. GoDaddy is generously covering the cost of live captioning and post-event transcription for this meetup. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience. 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 GoDaddy 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.

I always ask if you are willing on whatever social media platform you’re on to just give a quick shout-out to our sponsor, tag them, and say, “Thank you for covering the cost of captioning at WordPress Accessibility Meetup.” It helps to let them know that I did what I was supposed to do and also that it is important and that we value having the live captions, which, in turn, helps them want to continue to sponsor. If you’re willing to do that, you can probably find them at GoDaddy, I would imagine, on most social media platforms.

We have a couple of upcoming events. There is going to be another event this Thursday in honor of Global Accessibility Awareness Day, or GAAD. If you have not gone to our GAAD landing page, hopefully, Paola can put a link for that in the chat. We are asking folks to please pledge some time to make the internet better and focus on accessibility on Thursday, May 21st.

If you are not sure what to do at 10:00 AM US Central Time, so the same time, wherever you are in your time zone, on Thursday, I’m going to be running a live webinar that walks people through accessibility testing themes. It is more workshop than webinar because you will actually be doing during this event, and it’s a great way to contribute while also learning accessibility testing.

You can register for that on our landing page at the time that you pledge. There’s just a little box that says, “Invite me to the Zoom webinar.” That will be captioned as well. Please, if you are interested in helping to make the internet better on Thursday, May 21st, later this week, please join us.

The other meetups that are coming up is on Thursday, June 4th. My partner, Chris, will be talking about How Agencies Can Turn Their Accessibility Backlog Into Profit, and then on Tuesday, June 16th, Emilio Dominguez will be talking about Building Your First Accessible Gutenberg Block. This will be a developer-focused presentation. If you’re interested in learning about coding accessible Gutenberg blocks, this would be the presentation for you.

I am so excited to introduce our accessibility specialist, Maria, today. Maria is a seasoned web accessibility professional with a strong foundation in education. Since transitioning to the field in 2018, she has been dedicated to advancing accessibility testing and fostering digital inclusivity. She has a CPACC, WAS, and CPWA certifications. She possesses a comprehensive understanding of web content accessibility guidelines, standards, and legal requirements. She manages all of our auditing here at Equalize Digital, and we’re so excited to have her here to present. Welcome, Maria.

>> MARIA MALDONADO: Hi, everyone. Thank you for joining today’s session, Web Accessibility 101, Small Things That Make a Big Difference. My name is Maria Jose Maldonado, and I’m an accessibility specialist here at Equalize Digital, as Amber mentioned. Today, we’re going to talk about web accessibility in a very practical and approachable way. My goal is to show you that accessibility doesn’t always require a massive redesign or a huge budget. In many cases, small intentional improvements can dramatically improve the experience for your users.

One thing that I learned is that accessibility can feel intimidated at first. There are guidelines, technical terms, legal discussions, and sometimes people feel overwhelmed before they even begin. Accessibility is really about people. It’s about reducing barriers and making websites easier to use. Today, we’ll focus on realistic improvements you can start implementing right away.

Here’s what we will cover today. First, we’ll define what web accessibility actually means in plain language. Then we’ll look at some of the most common accessibility barriers users encounter online. After that, we’ll focus on easy wins, small, high-impact improvements that are often simple to implement but make a huge difference. Finally, we’ll talk about why accessibility benefits everyone and not just people with disabilities.

When we talk about web accessibility, we mean designing and developing websites so people with disabilities can perceive, understand, navigate, and interact with them. Disabilities can affect vision, hearing, mobility, cognition, speech, and more. Accessibility isn’t only about permanent disabilities. Think about temporary or situational limitations. For example, trying to read your phone in bright sunlight or watching a video without headphones, using one hand because your other arm is injured, being tired, or distracted.

Sometimes accessibility gets reduced to a checklist or compliance requirements, but at the center of all of these are real people. For example, someone who relies on a screen reader, someone who cannot use a mouse, someone with low vision who needs larger text, someone with ADHD who benefits from clearer structure, someone watching videos on mute. Accessibility is really an extension of good usability. When we reduce friction and confusion, everyone benefits. We can say that accessibility helps everyone.

One of my favorite things about accessibility is that many accessible practices improve the experience for all users. For example, better contrast improves readability for everyone. Clear navigation helps all users find information faster. Captions help people in noisy environments. Larger touch targets improve mobile usability. Accessibility also often supports self-engagement and user satisfaction. Accessibility isn’t separate from good design. It’s part of good design.

Now, let’s look at some of the most common accessibility barriers found on websites. These include low-color contrast, missing image descriptions, tiny text, poor navigation or confusing navigation, forms without labels, vague linked text like “click here” or “read more,” autoplay media, and keyboard drops. The good news is that many of these are surprisingly common and surprisingly fixable. You don’t need to rebuild your entire website to make meaningful improvements.

One of the most common issues is poor color contrast. This happens when the text doesn’t stand out enough from the background. For example, light gray text on a white background. On the screen, we have a small example of a primary, secondary, and a tertiary palette of [unintelligible 00:13:14]. In the secondary button or the example, the text is white, and the background is gray, and it’s very difficult to distinguish the foreground from the background.

Designers sometimes choose subtle colors because they look modern or elegant. If users can’t read the content comfortable, that creates a major usability problem. The small fit here is increased contrast between the text and the background. That’s a very small design adjustment with a very large input. Again, this helps everyone, not only users with low vision.

Another common issue is missing or poor alternative text for images. A text is what screen readers use to describe images to users who cannot see them. A filename like “image123.jpg” is not helpful, but a description like “woman using screen reader on laptop” communicates meaningful information. A good question to ask is, what information does this image add? If the image is purely decorative, it’s perfectly okay to use empty alt text, so as if the technology is kind of ignored.

Now, let’s see. Let’s talk about keyboard navigation. Not everyone uses a mouse to navigate websites. Some users rely entirely on keyboards, switch devices, or voice controls. Very easy test you can do is to put your mouse aside and try navigating your website using only tap, enter and arrow keys. The questions that you should ask is, can you reach everything? Can you see where the focus is? Can you open menus and submit forms? This simple test often reveals problems very quickly.

Now let’s talk about headings. A common mistake is using bold text to make something look like a heading instead of using actual headings. Heading tags. Another issue is skipping heading levels randomly or using multiple H1s without structure. Think of headings like an outline. An H1 is the main title, and H2s are major sections, and then H3s are sub-sections. Clear structure improves readability for everyone. Headings are incredibly important for accessibility. They help users understand the structure of the page and allow the screen reader users to navigate quickly between sections.

Now let’s talk about links. Genetic phrases like “Click here” or “Read more” can be confusing, especially for screen reader users who often navigate through a list of links independently from surrounding text. Instead, links should describe their destination or ports. For example, a small fix for this issue is write something like “Download the accessibility checklist,” “View pricing details,” and the impact is that screen reader users often navigate by links alone, so descriptive links improve clarity and usability for everyone.

At this point, you may be thinking, “There is a lot to fix.” [chuckles] That’s true. Accessibility is a journey. The important thing is that you don’t need to fix everything immediately. Small improvements can have a huge impact. Start with better headings, improved contrast, descriptive links, alt text, keyword testing, form labels. Progress matters much more than perfection.

Here’s a quick checklist of easy accessibility improvements that you can start with. They are all relatively small tasks that often create immediate benefits. First, I would say, add alt text to meaningful images. Ensure that there is sufficient color and contrast, not only for text and background but also for graphical objects, for example, buttons, icons, or anything that the user needs to distinguish and to be able to interact with the site.

Label forms fields clearly. For example, to make sure that the user knows what information is needed or what is the input that is required for them. Name, email, last name, et cetera. Use real headings. Please avoid using bold or styling to make it look like a heading. Just use a proper structure. Test keyword navigation. Avoid auto-playing media, and allow text resizing. This is very important for users with low vision or script magnifier users, but also this is helpful for mobile and to have a responsive viewport. Even implementing a few of these can noticeable improve the user experience.

Guess what? Accessibility is also good for business. When websites are easier to use, more people can access your content, users are less likely to abandon tasks, customer satisfaction improves, search engines better understand your site. Accessibility can also reduce legal risk and strengthen brand trust. An inclusive experience create a stronger relationships with users.

Something else that I wanted to mention is that there are a lot of misconceptions around accessibility. One myth is that accessibility only benefits blind users. In reality, accessibility supports a huge branch of users and situations. Another myth is that accessibility is always expensive. While large remediation projects can be complex, many improvements are small and inexpensive.

Here, I want to add something. If you think about accessibility and start with accessibility from the beginning, you don’t need to rebuild your site, which is more cost-effective because you are going to use more resources, more time. That’s less effective. In fact, thinking about accessibility from the beginning is not expensive at all. Finally, accessibility doesn’t limit creativity. In fact, constraints often lead to clearer and more thoughtful designs.

Where should you start? My recommendation is run an accessibility scan. We have a scanner in Equalize Digital. Fix obvious contrast issues. Review headings, add missing labels, test with a keyboard, create internal habits around accessibility. The key here is consistency. Accessibility becomes much easier when it’s integrated into everyday workflows rather than treated as a separate task later. I always like to say that accessibility is a mindset.

In fact, something maybe anecdotic or very personal is that when I started working in accessibility, it changed the way that I see the world because I start seeing what could be fit in universal design or buildings and also in apps or web models. It’s like a quick mindset that you can implement. I really encourage you to start doing that with your teams. You don’t need to be like an expert or a developer or work exactly with something like– use directly attached to accessibility to include it in your daily tasks.

I want to leave you with this idea. Accessibility is not about perfection. It’s about progress. So every improvement that you make helps real people access information, complete tasks, and participate more fully online. Accessibility work is ongoing. Technology changes, content changes, and websites evolve. The important thing is to keep moving forward. You don’t need perfection to make progress.

If you like to continue learning, here are a few great resources. You have the W3C Web Accessibility Initiative that provides foundational guidance and educational materials. Also, the WebAIM Contrast Checker is an excellent free tool for testing color contrast. You can also find additional information or resources at equalizeddigital.com.

I have been writing a series explaining the Web Content Accessibility Guidance or test criteria one by one. I still have a large list to write. There are some trainings as well created by Amber that you may find helpful. Well, I think that’s the end. Thank you so much for being here today. I hope this session helped make accessibility to feel more approachable and actionable. Even the small changes can make a meaningful difference for users. Now I love to answer any questions you have or any comments.

>> AMBER: There are a few questions. I’m going to try to go through these that seem specific to the talk. Then there’s some that are broader that we can talk on. Barbara had said, “The slide about missing alt text seemed to say that using a descriptive filename means you can skip alt text. Did she misunderstand?” Do you want to talk a little bit or go back to that?

>> MARIA: To the decorative images?

>> AMBER: Yes. I guess she was saying that she was looking at what was on your alt text slide. I don’t know if it’s alt text.

>> MARIA: Yes, give me one sec. I found it.

>> AMBER: And was a little bit confused about does the filename mean you don’t have to provide alt text? If you had a good filename instead of just “image123”?

>> MARIA: Oh, no. That was just a common example that– Let me go a little bit more in detail with that. Well, I do a lot of testing. Most of the times, what the screen reader does when there is no alt text is to try to figure out the name, and it uses the filename or the source name as the descriptive text. That’s why I used that example, “image123.jpg.”

No. The alt is an attribute that you add in the code. You need to use real text, a real good description. I like to say that, for example, if you were talking on the phone with someone and you are describing what you’re seeing, that’s a good alt text because there is the best way to ensure that what is visually there is being described in text.

Let me see, because I saw that someone will write something. You can leave the attribute empty. That means that you leave the quotation marks without anything inside. That’s what I mean when I said “empty,” because that way, the screen reader is going to interpretate that that image is decorative. It’s going to skip it. You always need the alt attribute on images, even if they are decorative or if they are informative. Is that clear now, or do you have more questions about it?

>> AMBER: Yes, I think that’s clear.

>> MARIA: Yes. Thanks.

>> AMBER: Maybe if she has additional questions– Yes. She said, “Yes.”

>> MARIA: Yes, it is.

>> AMBER: Steph had a question about link navigation. Steph had said, “If a site has a section with three columns and the entire column is linked, but each CTA button says, ‘learn more.'” Steph’s understanding is that the repetitive “learn more” is not going to be picked up by the screen reader. I’m guessing maybe there’s an image and a title and a blurb, like for a blog post, and then it says, “learn more,” but the link goes around the whole container. Steph said, “Keyboard nav doesn’t pick up on the button within the columns. You can’t tab to it because it’s not really a linked button. Do you have any opinion on that sort of design?”

>> MARIA: Yes. Well, this is something that we always find in our reports when auditing. Mostly when you have a post or a card-style design, you have the image, the title, and then a “read more.” That’s something that we call redundant links because it’s going to make the user have like– let’s say in this example that I’m giving, it’s going to give you three stops, right? The image, the title, and then the read more.

>> AMBER: I have an example I could share. [chuckles]

>> MARIA: You have an example? Okay.

>> AMBER: This is a fake website, but this is what you’re talking about.

>> MARIA: Yes. You have an image, then you have a title, then you have a “learn more” or a “read more.”

>> AMBER: Oops. Sorry.

>> MARIA: That’s really three stops for one link. It’s not really we’ve got failure, I have to be honest, but it’s really not a best practice to do it. What we recommend is to have only one link. The screen reader or the keyboard user only gets one tap stop. Something very important with the “read more” is that imagine that you are using a screen reader and you are tabbing through the site, right? You’re going to listen “Read more. Read more. Read more” without context unless you use the arrow keys or trying to figure it out, anything else.

What we always recommend is to attach or use an area label to that “read more” that is invisible for users but is available for screen reader users and give it a context. In this example that Amber is showing, that “read more” would say, “Read more about the secret ingredient top chefs swear by.” The user is not going to obtain only the “read more” several times without context, it’s going to know exactly where the link is leading to.

>> AMBER: If you’re doing card style, like she was talking about, where there’s one link around the whole thing, then I would maybe argue, because at that point, the “read more” is just an element inside the link, and yes, you can’t tab to it, like she was talking about. I would probably be like, “Can we leave the ‘read more’ off the design?” [chuckles] It would be weird to have– Let’s say the link wrapped the whole thing and then it read the title, plus the excerpt, plus the author, plus the date, plus “read more.” That’s a very long link name.

The other option potentially is if you don’t have the “read more” visible, but you use that, that is the link, but it’s an overlay. All of these other elements can be reached, and you could click anywhere, but this title wouldn’t be a link, it would just be a heading. If you’re reading the page, you would just hear the heading, and then you wouldn’t actually hear the link until you got to the bottom with the screen reader, although a sighted person wouldn’t see it and could click anywhere. I don’t know if that totally answers the question about how to handle the cards, but I think that’s kind of what I would say. Maybe don’t even have the read more link.

>> MARIA: Yes. Also, if you don’t want to, use an ARIA label. Another way to handle is to use a hidden text for a screen reader that’s also is invisible, it doesn’t cause any issues with the visual designs, and the text is available there. Something that I always say honestly is that if something is helpful for one user, it’s helpful for all. I try not to give extra information to the screen reader user. I think that the information should be available for everyone there.

>> AMBER: Yes, and I think that sort of answered the question that Mynek asked. I would say broadly, if you’re building– because Mynek had asked specifically about “How do you make that ‘read more’ text more unique?” In WordPress, most commonly, that comes from your theme. That’s probably just a one-time fix in a theme that would then go out to like every post on your archive pages or in your main blog or the sidebar.

I have noticed sometimes with, if you’re building your site with full site editing and you’re using the excerpt block, if you just put “read more,” then that’s all it will say. What you can do is you could, if you have the ability with your theme, to put dynamic text for the title and then hide it with screen reader, with a screen reader wrapper, or a screen reader tag, that would be a way to do it. I would say fixing those “read more” links are most commonly kind of a developer-level fix, less than like a content creator fix. Barbara had a question about what are things that would impede text resizing on a website?

>> MARIA: Well, give me one second. Sometimes, you can use the user scalable set to null or a value that is not allowed. That can restrain the viewport, change it. That’s the most common issue with resizing. I don’t know if that answer the question. Also, well, it’s more complex answer.

>> AMBER: I actually think I might have– Well, let me share again. I might have something that would be useful here on that. What Maria was talking about was the zooming and scaling disabled.

>> MARIA: Yes, it’s that. The meta code.

>> AMBER: Yes. This in your meta code, and this will stop people even on their mobile phones from being able to zoom in on the screen and make it bigger. I was on a website that I tried to do this on over the weekend, and I was so mad. I was like, “I can’t read it, and it won’t let me zoom.” [chuckles] The other thing, this, I feel a little bit bad for this WordPress theme, but I also don’t. This is just like off-the-shelf free WordPress theme, but it’s the perfect example [chuckles] for a lot of these.

Up at the top, it has this grid of featured articles where the photo is the background, and you can see the title and the author and the date over it. If I inspect the containers for these. Let’s see. I got to figure out where one of them is, but somewhere in here, they have fixed defined height set on them with a pixel height. Right now, it just says, “Height 100%,” but what I have noticed on this particular site, if I just zoom in, is I can get to a point where sometimes the content will–

Now I’ve lost the author name. I’ve zoomed enough that the author name doesn’t fit inside the container, or if I go up to 500%, which is more than we normally test you, but there’s certain scenarios, maybe if I’m even down at 400%, but my browser were a little more narrow, now the title even starts to get cut off.

I would say a big issue with text resizing frequently is if you have containers that have fixed width or height expectations that don’t respond to the size of the font. You have to code your grid in a way that it can recognize if the fonts get bigger, and then it can allow other things to get bigger. Let’s see. Jen asks, “Besides screen reader users, are there any benefits to providing alt text?”

>> MARIA: Yes. A simple example that occurs to me. Let’s say that you don’t have a good internet connection and your page doesn’t load. You’re going to have a description there, and it’s not going to be on label. You’re going to have the image. Yes, I would say that that’s something that benefits everyone. Also, it helps the engines recognize the words, the keywords.

>> AMBER: It can help with search engine ranking?

>> MARIA: Yes. It’s good for everyone. There are some questions about screen readers. There are a lot of screen readers that are free. The one that we–There are different combinations as well. The one that we use for testing purposes, just because it’s universal and is one of the most used is NVDA combined with Chrome. That’s free. That’s something that is available. I really like it because– well, the history right behind the NVDA, how it was created. It was created by blind users, and it’s open source.

It’s really, really good. Honestly, you shouldn’t see a lot of difference between different screen readers, but there are some nuances. Let’s say JAWS or VoiceOver sometimes treat the content in different ways. One example is that NVDA reads the titles, try to help the users and read the titles as names. That’s something that doesn’t happen with VoiceOver, for example, but the difference are not so significant. I would recommend you to use NVDA if you need to choose one that is universal. Also, Windows has their own built-in screen reader that is Narrator. Honestly, I don’t know if people really use it. [chuckles] Then you have Mac–

>> AMBER: Yes, I don’t recommend testing with Narrator for that reason.

>> MARIA: Yes, I know. [chuckles]

>> AMBER: I don’t think the blind people [crosstalk] [laughs]

>> MARIA: Use NVDA. Just in case you know you have built-in screen reader, then VoiceOver is for Mac and also for iPhone. You have for Android as well, you have a built-in screen reader. It’s not something that you have to download. It’s something that is already in your devices. You just have to play around and try to use it.

Something that I really, really recommend is learn how to turn it off before you turn it on. [laughs] Otherwise, it may be a little bit overwhelming, but it’s a good exercise. In fact, if you use an iPhone, you can use like the– I remember if it’s called “Black Curtain” or something like that. It really blacks out your screen, so you don’t see anything and you just navigate. That’s a good exercise that I always recommend to do at least once in your life. [chuckles]

>> AMBER: Yes. I will say, not to pitch too hard, but we are having the sale on our courses in a couple of days and they are like– they walk you through all the keyboard shortcuts and all of that, but then I also have 15 different components like tabs, accordions, carousels, and I have good examples and bad examples so you can hear what a good one sounds like, what a bad one sounds like.

I talk about, “Oh, this is what I would flag if I were auditing this.” If you want to learn more about screen reader testing, that’s a good way. I thought Matt had an interesting question related to screen readers, which is “How well do screen readers handle pseudo-element content?” That would be like content that’s added in the CSS.

>> MARIA: Things that are not really coded properly, that’s what I mean.

>> AMBER: I mean, my answer [crosstalk] is very unreliable and frequently screen readers won’t read any content that’s added via CSS instead of in the HTML.

>> MARIA: We had another webinar that I gave related to ARIA, and I explained there how the accessibility app works because there is a way– the accessibility tree works in a way that they just try to distinguish the elements. Something that is not properly code is not going to be interpreted by the screen reader. Let’s say that you have a span or a div and you visually make it look like a button or a link, and it really works with the mouse.

That’s something that is going to be completely invisible for a screen reader because the way that the app will work is that it’s going to find the role, let’s say a button, an image, a link, a tab, wherever the component is, and then the name, if it has a name, otherwise it’s going to say “unlabeled.” That’s why it’s very important to have a name or an ARIA label or something. Then it’s going to behave or interact with the elements the way that that element is supposed to work. Let’s say it was activated with a space bar or enter bar or arrow keys. That’s how the focus is going to be managed.

In summary, if something is just visually appearing like an element where it’s not really coded as it should, that’s going to be useless for a screen reader. Also, mostly for keyboard users, I would say, unless you add that in that. Remember that you have to do a lot of work with JavaScript to make it work. My advice here is that is simpler to use a native tag because that is inherently accessible and it has all the standards there. Instead of making a custom on this, there is no way to do it. Just keep in mind that the screen reader is not going to interpretate it as a real component.

>> AMBER: Yes, I think especially if you’re trying to add words to the page with CSS content, I would just assume that many screen readers will not read those words at all. It’s an important label that you’re putting before something. [chuckles] You should actually have it in the HTML and decide to show it or not with CSS as opposed to just adding the content in the CSS. Fernanda asked, “How can we address animations such as hover animations, drag animations?” Do you want to talk a little bit about animations, Maria?

>> MARIA: Yes. We should always provide a workaround or another way to manage that. It means it should be keyboard operable because there are a lot of users that are not going to be able to interact with that, for example, for a draggable. Do you have an example, Amber, that occurs to you?

>> AMBER: I’m trying to think if I have one just off the top of my head on hover animations. Well, yes, I don’t know if I have one super big as far as animations. I have an example of tooltips, but I could say– This poor website. [chuckles] This is my example of all the bad websites, [chuckles] but it’s got scrolling, which pauses when you hover over it, but there’s no way to– if you weren’t a mouse user, you can’t get this to stop. That’s an animation. There’s a tooltip on this button, which you can’t hover over. I don’t know if that’s sort of worth talking about, but I don’t– there’s actually not a lot of scroll animations on this website.

>> MARIA: Yes. I can talk a little bit how we test the animations and prefers to reduce motion. I’m trying to find the– I’m going to paste the link, but we have some ways to test this. In Windows, there’s a way to– Give me one sec. It seems like I’m not multitasking.

[laughter]

>> AMBER: Yes, I can talk for a minute. Oh, there we go.

>> MARIA: I’m pasting the link there. There you can find how to test reduce animation. The idea is that if you have this set in your computer or in your browser or in your device, there shouldn’t be any animation on there. So the way to fix it is to write all CSS animations in a prefers-reduced-motion media query. Then if the animation is created with JavaScript, you can edit the user’s motion preference, which match media. The idea is that if the user sets these preferences, there shouldn’t be animations in there. I have to be honest [crosstalk]–

>> AMBER: Just significantly less animation, because it’s interesting. It doesn’t always mean zero.

>> MARIA: No.

>> AMBER: You could maybe make your– if your buttons get bigger on hover, you could maybe still do that, but you reduce the speed, so it’s slower or something. I don’t know.

>> MARIA: Yes. Exactly. I hope that answers the question. [chuckles]

>> AMBER: Yes. I would say in general prefers reduce motion, and then, also, if you have anything that’s auto-playing, like that ticker we saw or sliders, videos, sound. Hopefully, [chuckles] nobody does that on websites anymore, but having pause buttons and ways for people to stop it is really helpful.

>> MARIA: Yes, I know.

>> AMBER: Someone said, “I found WCAG very difficult to read as they are almost not useful to me. Are there any tips for learning to read these or easier guidance that you have?” I could maybe pull it up while you’re doing that. Do you want to talk about how did you learn to understand WCAG?

>> MARIA: Well, [chuckles] I agree that WCAG rules are very, very technical and it’s very difficult to understand, but I’m trying to find a simple list that I have. Just give me one second, I’m going to share it. Basically, you need to learn the structure. First, you have the– Amber is showing. You have the guidelines, that is the– yes, in this case, test alternatives. Then you have the success criterion, and you have the level. You have all the information.

You try to understand what does it mean? What is the intention of? Then what I do is to read the techniques, the sufficient techniques, so I know what I need to fulfill in order to be able to satisfy this. I have to be honest. I always have the understanding page open because it has a lot of information, like what is the goal, what do you need to do, and why it is important. Then I have a page that summarizes the rules. I’m trying to find it, but I have that in my markers. When I find it, I’m going to share it. [chuckles]

>> AMBER: I think the understanding docs are probably more helpful than the main success criterions [chuckles] themselves because they have a lot of–

>> MARIA: Yes, I would say that I don’t really– with the main success criteria, I used to understanding that’s the truth.

>> AMBER: Yes. It looks like Rosalinda shared “Aardvark has a resource as far as learning in plain English.” You mentioned earlier, Maria, maybe we can find a link to that. Maria has been writing articles about each success criterion, how to test for them, and ways to meet it in WordPress-specific land with some recommendations for plugins and things like that.

>> MARIA: Yes.

>> AMBER: We don’t have them all yet, but–

>> MARIA: No, because those are a lot.

[laughter]

>> MARIA: I’ve been working on that. I can share. I cannot find the first one, but I can share one, and then you can try to find the rest. For example, this one from January, this is one example.

>> AMBER: Yes, I think Paola shared the latest one, too.

>> MARIA: Oh, okay.

>> AMBER: I think at the top of those, there’s a link to the category, and then you can see all of them.

>> MARIA: Okay. Yes. That makes sense.

>> AMBER: Paul had said, “I’ve been correcting accessibility problems using my page builder and plugins. The fix often involves using JavaScript to change tags or ARIA labels. Is this legitimate?” Do you want to take that question?

>> MARIA: I have to read it again. Sorry. What is it?

>> AMBER: Yes, so using JavaScript to change the tags or the ARIA labels, is that legitimate?

>> MARIA: I don’t know. I think that’s a lot of work. What do you think about it? [chuckles]

>> AMBER: In some cases, you have to use JavaScript. For example, if you’re opening and closing an accordion, you have to change the value of ARIA expanded to true/false, and the only way to do that is with JavaScript. I think JavaScript is part of if you’re doing developer-level fixes for accessibility.

In the reality of WordPress land, when you are frequently building websites using lots of plugins or themes that other people control the code for, and it’s not just a “I built custom from scratch,” everything that is on this website. We do in our remediation work, sometimes, patch things with JavaScript. It’s not always ideal because of the fact that while it may work today, there’s no guarantee.

Let’s say you are targeting an element by a class name, and then if the developer of that plugin decides for some reason, and I’m going to say this, like a jerk, to change their class names. [laughs] That would break a lot of things. It would break your CSS styles. It would break a lot. That said, we’ve literally had that happen to us. Then, now, your JavaScript also doesn’t work. It’s not a permanent fix in some of those cases.

I will say that we have done it. I always try to first go to the developer and report the issue. I’ve had mixed results. Some of them, and honestly, like sometimes it’s the free plugins with a solo dev that responds so fast, and they’re amazing. Then, the ones with giant teams are like, “Okay, we put this in our queue. [chuckles] We’ll work on it.” You have no idea when, and you’re like, “Well, I need this fixed now.”

I would say, yes, we do the JavaScript approach. Sometimes that’s the only way. I actually have a– there’s a video on our YouTube. It’s maybe 15 minutes long, but it’s about how I use ChatGPT to fix our accordions because they were– they didn’t have what they needed for screen readers. They were only basic keyboard functional and it’s a weirdness where the plugin that we had used got worse, and then it got abandoned, and it doesn’t even exist on WordPress.org, but we had so many accordions, and we’re like, “Okay. Well, we can’t get rid of this until we rebuild our website because we have to go replace all these pages.”

I actually use JavaScript to write a snippet that loads in the footer of all the pages that fixes all of those accordions. Now they work really well. It’s not always the best solution, but I think it is frequently the realistic solution in a WordPress situation when you’re not– it’s not your code, so you can’t just go in and edit the plugin or the theme files.

>> MARIA: Yes, I agree. Well, our approach is always going to say use the native just to ensure that it works, but if you need to make it custom, I guess it’s not as sustainable as the native, but it’s a good workaround. As I said before in my presentation, the importance is the progress that you make. It’s a continuous progress. It’s not something that is going to be perfect. I really value that you are trying to fix it, at least. That’s very important. That makes me happy.

>> AMBER: There’s a couple of questions. I think I’m going to try lightning round this. [chuckles]

>> MARIA: Sorry. I shared a quick reference guide that I was talking about. It has a very small summary of each success criterion, something, if you are starting, that’s a way to see it, and not reading the whole understanding, and it’s available in several languages. Maybe you can find it helpful as well.

>> AMBER: Okay. There’s a couple here that I know we don’t have time to answer, but I just want to address them briefly, which is Sakhawat had asked, “How to charge for a fully accessible website built with WordPress?” I’m going to say that’s a really hard question to answer in two minutes. [chuckles] It probably would be really long, but– and maybe Paola can find this.

We have a panel discussion that we did at a previous meetup with a bunch of agency owners where they talked about pricing. Also, if you come– I’m pretty sure also my partner, Chris, has some content on that that’s on our website, and maybe we could dig that up. If you come to his talk in June, I think that would be a better time to address that, but we’ll see if we can find some links to throw for you about pricing.

The same thing about how to make PDFs accessible, [chuckles] but what I do want to tease, I didn’t say this now, but earlier in the year, we had Samantha Merritt, who works at the digital service for the government in the United Kingdom. She is coming back for our Tuesday meetup in July, and she is going to literally show taking an inaccessible PDF and how she fixes it.

Just looking ahead, that will be a time when you can actually see it. We do have some others. If you go to the meetup page and you just search through the history, there’s a lot of talks about PDFs. Real quick, Mynek asked, what tools are your go-to tools, both free and paid? Obviously, we use our Accessibility Checker plugin because we dog-food our own product. What other tools do you use, Maria, that you want to shout out real quick?

>> MARIA: I use some extensions. I use [unintelligible 00:59:32]. It’s an extension that is available on Chrome. I use Headings Map as well, and Apps Developer as well. The free version. [chuckles] Those are like the go-to. Ah, and also, well, I mentioned the color contrast one, right, in the presentation. That’s something that I– That’s my, I don’t know, like my key extensions and tools, and obviously the screen reader.

>> AMBER: I like TPGi has a desktop application that’s free for color contrast checking. I like that one because it’s really helpful, because you can check all kinds of things. [chuckles] It doesn’t even just have to be a browser. It can be an image that’s saved on your desktop, and it will check it for you. I will say too, if you want to see a lot of these in action, if you come on Thursday to the Theme Testing Workshop, which, thank you, Corinda, for throwing the link to that in the chat, you can literally watch me test, and I’ll show a bunch of these tools there, and you can get to try them and learn how to use them there.

I think the same thing about enlarging text. If you can come on Thursday, there will be a recording for that as well. That would be another way to see how enlarging text fits into a testing workflow. The last question that we have, and then I think we’re going to need to hop off, is, I don’t know if you have any broader thoughts about email, Maria. Anything different that you do in email, or is it pretty much the same for testing to make sure emails are accessible?

>> MARIA: Emails, I think you can apply the same. Don’t use color to show information; add alt text, use a structure. Something that really annoys me is when people are responding to a thread, and they say, see my comments below. What I usually do to fix that is to, you can find my comments below in bold and yellow, for example. It doesn’t mean that you cannot use color as well. I know that it’s easier to do it that way, but what I usually do is to put my initials. Screen reader users are able to find my comments below, and don’t use just a way of showing information using color.

For the rest, I think that if you use the styling and the structure, you’re going to be fine. Try to change your mindset and see if that’s printing black and white, and is it going to be understandable anyways, or is there information that is going to be missed? Those kinds of questions really change the way that you build things. I think there is a lot to say about emails, but that’s–

>> AMBER: I know, I feel like we should have a follow-up just about this.

>> MARIA: Just about emails, yes.

>> AMBER: Yes, because you do use a lot of tables in emails, because that is the reality of email, but you want to make sure you’re putting like role presentation on them. Then sometimes it is actually a data table, so you can’t, by default, be like, every table in the email needs a presentation role, because then people miss it. Another mistake I see sometimes, brands their entire email is an image that they design [crosstalk] —

>> MARIA: Yes, that’s something that I used to have, images of that. There was once that I was working in a company and one of my partners was a blind person, and he received a recognition, and the recognition was an image of text. He was unable to see what was the recognition and he had to ask me to read it. You see something very simple, like using real text instead of an image of text, makes a big difference.

>> AMBER: Well, thank you so much, Maria, for presenting and all of the great questions for everybody who hung in with us. I hope to see a bunch of you back here on Thursday. Bye.

>> MARIA: Well, thank you so much.

>> [01:04:36] [END OF AUDIO]

Access “Web Accessibility 101: Small Things That Make a Big Difference” in Google Slides.