In the 35th episode of the AAArdvark Accessibility Podcast, co-hosts Natalie Garza and Natalie MacLees discuss the critical importance of incorporating digital accessibility into web agency offerings.

Natalie MacLees, an expert with over 20 years of experience, explains the increasing legal requirements for accessible websites, the risks of non-compliance, and the benefits of accessibility, including improved SEO and expanded market reach. 

Join co-hosts Natalie Garza and digital accessibility expert Natalie MacLees for episode 34 of the AAArdvark Accessibility Podcast. This episode delves into the overlap between accessibility and SEO, highlighting how both can benefit from keyword targeting, content readability, page titles, link purposes, headings, and adaptable content.

The hosts discuss various Web Content Accessibility Guidelines (WCAG) criteria that also enhance SEO and provide practical tips for making your website more accessible and search-engine-friendly. 

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 34. I’m one of the co-hosts, Natalie Garza, and with me today is,

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: And she is a digital accessibility expert here to walk us through today’s topic, which is the overlap, the handshake between accessibility and SEO. 

So let’s give the viewers a little refresher. What does SEO even stand for to begin with?

Natalie MacLees: Search engine optimization. And it’s just some things that you can do on your website to make sure that search engines are more likely to find it, especially when they’re searching for particular keywords.

Natalie Garza: Yeah, and we’re not gonna get into all SEO basics. We just wanna show you guys how much overlap there is between accessibility topics and fixes for your website and SEO improvements. 

So, starting off with the concept of keyword targeting. Basically, creating content based on what people search for. So what is the first WCAG success criterion that we’re gonna talk about that overlaps with this?

Natalie MacLees: Yeah, so 1.1.1, which is called Non-text Content, but this is basically the WCAG rule that says our images need alt text. It says some other things as well, but that’s the main thing that most people take away from that one. 

So you do wanna make sure that if you have non-decorative images, images that are conveying information of some kind, that they have alternative text.

So for somebody who can’t see the image, for whatever reason, they can still get information about what is contained in that image. Search engines can’t see your images, so they also benefit from having alt text. 

Where you wanna be careful is that your alt text is for people first. So don’t just use your alt text for keyword stuffing for SEO. Make sure it works for people first.

Natalie Garza: Exactly. Yeah. Would you be embarrassed if this gets shown to a person, or will this be actually helpful? So alt text is a great way to incorporate keywords. 

What’s the next way to incorporate keyword targeting that also overlaps with accessibility?

Natalie MacLees: Yeah, so your content itself, so we have 3.1.5 Reading Level, we wanna keep things to about an eighth grade reading level. So if you’re not in the US that’s around like junior high, like where you are when you’re 12 or 13 years old. Very friendly, straightforward language, that is going to be helpful for the search engines to ingest that and figure out what your page is about.

But it’s also helpful for the people who come to the site. They’re busy, they’re distracted, they don’t have time to read a dissertation, right? They just want the information in plain language as quickly as they can get it. 

Natalie Garza: What’s the next success criterion?

Natalie MacLees: Your page titles! So this is, it doesn’t actually appear anywhere on your page, but it appears on the tab in the browser, and it’s the title of each of your pages. It does also show up in search engines, and this is WCAG 2.4.2 called Page Titled. So every page of your website should have a unique and descriptive name, so every page of your website can’t just say “best services ever”.

Because nobody will know what the individual pages are about. So it has to say, “home – best services ever”, “about us – best services ever”, et cetera. And you need to make sure each page is unique so you can tell them apart. 

And each page is descriptive so that when someone lands there and they hear that title read out to them, they understand what the page is all about.

Doing that also helps search engines understand what your page is all about and what the difference between all of your pages are. So there’s a lot of overlap here between SEO and accessibility.

Natalie Garza: Yeah, because when you’re looking through the search results. Google wants to show people actually relevant pages, and if your page is titled accordingly, they’re more likely to show it.

Natalie MacLees: Exactly.

Natalie Garza: All right, what about 2.4.4 Link Purpose?

Natalie MacLees: Yeah, so you don’t wanna use link text like “read more” or “click here” because that’s generic. What am I learning more about? What am I clicking? Where am I going? 

The actual text that’s linked should give a hint about where it’s going. That helps to reinforce keywords for that page. So if I have my about page and I link “about – super services”, then search engines are going to have that keyword now for the about page, they’re gonna understand this is the about page for super services. 

So we wanna make sure that there’s extra context in there. “Read more about this topic”, “learn more about this topic”, and then instead of “click here”, you would want the name of where you’re going, right? “Download this document”, or “visit our contact us page”, or whatever it happens to be.

Natalie Garza: Yeah, because on a website with a hundred pages, click here could go anywhere.Or even outside the website, taking a whole millions of millions of websites. 

All right, so next on the list, 2.4.6 Headings and Labels. So similar.

Natalie MacLees: Yeah, so another similar one, but this is if we have a long page of content. We wanna break that up into section, and each section should start with a header that is actually marked up in the HTML as a header. 

So that’s really helpful for accessibility because it helps to pull an outline of our content out for assistive technology users and helps them navigate around the document and find the relevant sections they wanna read.

But it also helps us to tell search engines what kind of content is on this page and how is it arranged, and how is it organized so that when it’s indexing it for returning search results for keywords, it can tell more easily if your content is relevant. 

Natalie Garza: And last one, 1.2 Time-based Media, which I think ties back to the images.

Natalie MacLees: Yeah, so that’s a guideline instead of a success criterion, but there’s a whole bunch of success criteria under here that deal with audio and video files. 

So essentially, a search engine can’t access your audio file or your video file to figure out what’s going on in it. So the way that you would address that is to provide a text alternative, which could be captions, transcripts, et cetera.

Those also happen to be really helpful for people with disabilities. So people who can’t hear the video, people who can’t see the video, we have different ways that we wanna provide that information to them. Or also just people who are trying to watch a video on a train, right? And they can’t have the volume on.

Because if you have a podcast, you have, you know, every episode is this rich content that’s talking about a certain topic, and you definitely want that indexed in search engines so that if people are looking for a topic you’ve discussed on a podcast, they can find it.

And the only way that’s gonna happen is if you have that text transcript of your podcast and/or captions on a video that there’s text in some way that that search engine can grab onto to figure out what that video or audio file is all about.

Natalie Garza: Could you say that search engines are maybe equivalent level as people who are blind? 

Natalie MacLees: So I think I would compare a search engine or a search engine crawler more to assistive technology, where in both cases we have just a simple machine that is trying to ingest and understand content, and they both have very similar capabilities, so they’re not able to you know, see or interact with anything on the page. 

They’re not able to get information presented as videos or images, and they’re not able to get text that’s presented in images. So all of the same kind of limitations apply to both a search engine and assistive technology. 

The whole process of making something search engine optimized is about making it readable and ingestible by a search engine, and the whole process of making something accessible is about making it readable and searchable by assistive technology so that the assistive technology can then present that to a user.

So the end goal is different. Because when I’m doing search engine optimization, my goal is to make sure search engines know what my page is about so they can send more traffic to me. When I’m making my page accessible, that’s about ensuring that anybody who comes to my page can get my content. So the means by which I accomplish those two goals are very similar.

Natalie Garza: Yeah, exactly. And so that’s why we wanted to make this episode, ’cause it’s just undeniable, there’s so much overlap!

All right. So this next part, a lot of search engine optimization relies on site health. So you wanna go into the first one, 2.4.5 Multiple Ways.

Natalie MacLees: Yeah, so this just means that you have to have multiple ways of getting to the different bits of your content. So you might have a main navigation, you might have breadcrumbs, you might have a site map, you might have a bunch of links down in your footer. 

So, just all different ways that people can get to your content, and that is helpful for accessibility because it gives people multiple ways of getting to the same thing.

They don’t have to try to memorize this one perfect path to getting to something that they want. 

And it’s helpful for search engines because it helps them understand the structure of your website and how your content relates to each other, like how one page relates to the other pages on your site and how those are arranged.

Natalie Garza: Yeah, like when we say crawl, like the search engine is literally crawling every single link and going through every single page on your website.

All right, next, 2.4.8 Location.

Natalie MacLees: Yeah, so this is when, I’m sure we’ve all seen it at the top of a webpage, there will be little breadcrumbs that let you know you were on the “homepage” and then you went to “services”, and now you’re on “web design services”. 

So it’s really easy to see at a glance, like, “oh, this page is part of services, which is a section of this website”.

So that it’s really helpful for people with cognitive disabilities and memory issues and helpful for a lot of different cases for accessibility. But again, it’s another mechanism to help a search engine understand how your content is structured and what the hierarchy is, and what the relation between pages are.

Natalie Garza: Next, we have another whole entire guideline, 1.3 Adaptable, which is all about semantic HTML, you’re favorite.

Natalie MacLees: All about semantic HTML, one of my favorite topics, so HTML, those, all those little tags, all those little

tags and

That helps search engines to understand what the different bits of content on the page are, and it helps assistive technology understand the same thing so that a user can understand, “oh, that piece of content is more important because it’s an H1.”

So that tells me that’s a top level heading for that page compared to a paragraph tag that’s maybe just a piece of content and maybe there’s 50 of them on the page.

Natalie Garza: Exactly. So that’s a whole guideline. We recommend going to check each one out individually.

Natalie MacLees: Yeah.

Natalie Garza: And then the last one on the list we have is 1.4.10 Reflow.

Natalie MacLees: Yeah. Search engines love mobile design. We are seeing, of course, there’s been a trend, especially since smart devices have come onto the market, that more and more web traffic comes from mobile devices. 

So, we’re over 50% of web traffic is coming from mobile devices. So when search engines are looking at sites, they are looking at sites that work well on mobile devices.

So having a page that is responsive works really well on a phone. Everybody can get to all of the content. That’s gonna be a priority for search engine optimization, but it’s also a priority for accessibility, number one, because people will be using all different types of devices to access your site, and you wanna make sure it works on all of them.

But then number two, because people with different disabilities might use zooming and panning and screen magnifiers. And different ways of getting to content that maybe they would otherwise have a hard time seeing or perceiving. 

Natalie Garza: Yeah, because generally if your website works well on mobile it means somebody on desktop zooming in 200% is probably gonna have a good time getting to all the content.

Natalie MacLees: Yeah, it should work really well for them. Of course, you wanna test it to make sure, but that’s a really good way of doing it.

Natalie Garza: Mm-hmm. All right. And then the last SEO concept we wanted to talk about is earning links and mentions, which generally is not too big of an accessibility topic. 

However, if you have well-structured, easy-to-read content and you follow many accessibility guidelines when building your website, it is more shareable and more likely to get mentioned.

Natalie MacLees: Yeah, people will wanna interact with it more, so you’ll get benefits from that, and more people will be able to interact with it, and more people will be able to share it online and tell their friends about it. So it definitely helps.

Natalie Garza: Yes. So with that, where can people go to improve their accessibility and SEO?

Natalie MacLees: Yeah, so we don’t have any SEO specific tools, but we’ve already talked about improving your accessibility is gonna improve the SEO of your site. So come on over to AAArdvarkAccessibility.com. You can test your homepage for free. We’ll show you all of the automatic issues that we found on there and tell you how you can fix them.

Natalie Garza: Yes. So with that, thank you guys for watching. That was episode 34 of the AAArdvark Accessibility Podcast. We will talk to y’all next time. 

Join Natalie Garza and Natalie MacLees on the AAArdvark Accessibility Podcast as they discuss the importance of keyboard accessibility in web design. The episode highlights why some users rely on keyboards instead of mice or touchscreens and provides key insights and practical tips for ensuring websites are fully navigable via keyboard. Topics covered include the importance of using semantic HTML, testing custom components thoroughly, and understanding native keyboard interactions.

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. I’m Natalie Garza, I’m one of the co-hosts, and with me today is,

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: and she is a digital accessibility expert here to answer our questions on today’s topic, which is keyboard accessibility 101, the basics you can’t ignore. 

So we’re gonna talk about why keyboard accessibility is important and some key notes on when you’re testing for keyboard navigation on your website.

So why doesn’t everyone just use a mouse or tap on their phones to navigate a website? Why keyboards?

Natalie MacLees: Well, not everybody can do that. Not everybody has hands. Not everybody has hands that they can move. So we have lots of different cases where people aren’t able to use a mouse or a touchscreen reliably. 

So sometimes it’s limited mobility. Sometimes it can be cognitive disorders or fine motor control issues. Like you can move your hand, but you don’t have a lot of control over exactly where it goes. 

If you have no vision or limited vision, you can’t see where a mouse cursor is on a screen and you can’t tell where to tap on a touch screen so you don’t have any other option other than to use a keyboard to navigate around the screen, and also sometimes just power users don’t wanna move their hand off the keyboard.

They’re going too fast. They’re setting their keyboard on fire, just going through too fast. No time to move your hand over to the mouse.

Natalie Garza: Yeah. Even everyday users like you use Control-C, Control-V to copy/paste. I’m sure a lot of people do. That’s a form of keyboard navigation too.

Natalie MacLees: Yeah, which, you know, you could do that with your mouse. You could right-click with your mouse and say copy and paste, but you could also do it with your keyboard. So anything you can do with a mouse, you can do with a keyboard.

Natalie Garza: And a lot of assistive devices, although they don’t look like keyboards, they fall under the same category as keyboards.

Natalie MacLees: They get treated as a keyboard by the computer. Yeah. As far as the computer is concerned, it’s a keyboard that’s attached. The computer can’t tell the difference.

Natalie Garza: Exactly. Alright, so that’s why keyboard and navigation are so important. 

So how do we translate that into our website? How can we make sure that people using only keyboards can access everything on a site?

Natalie MacLees: Yeah, we have to make sure that we’re not building anything that only works with a mouse. And where that usually happens is when we’re building custom components and not using semantic HTML. So the easiest fix is to just always use semantic HTML. 

Whenever you can, you wanna try to do that, and HTML has gotten to be a lot more robust, a lot more powerful than it used to be. So we have a lot more options. Like you can build now native date pickers and time pickers, for example. You do not have to code that all up in JavaScript. 

And there’s lots of other options. There’s range sliders and different things like that that are built in to HTML and do not have to be built custom. 

You may still run into cases where you have a complex interaction or something that needs to be really custom to what you’re doing, you might find a case where you do have to build a completely custom component. In that case, you do wanna make sure that you are testing extensively with the keyboard and ensuring that you are adding in all of the interactions that the native HTML element would support. 

It’s really easy to forget one, and then it just ruins it for everybody. So you wanna be really careful that you’re thorough about your testing and that you’re covering all of that functionality. And that people can close things and open things, and toggle things on or off, and switch between different selections, and I think where a lot of developers run into trouble is they don’t even actually know what all of the native keyboard functionality is of a native HTML control. 

And then if you don’t know what all of the native keyboard functionality is, you can’t rebuild it. So do some research and make sure that you’re aware of all the keyboard interactions that users are gonna expect to be able to do, and make sure that you’re handling all of those with your custom JavaScript and CSS.

Natalie Garza: Does that mean like going back, going forward, selecting? Is that what you mean?

Natalie MacLees: Yeah, all of the different things that users can do. Like a lot of people don’t realize that when you open a select dropdown, for example, you can hit the Escape key to close it out and just move on to the next thing. And so that gets forgotten a lot of the time. 

That Escape key gets forgotten a lot. And the Escape key is supported on several different native things. So you wanna just make sure that you’re aware of what all those interactions are, and when users would use the Tab key, when they would use the arrow keys, when they would use a Space Bar, and when they would use an Enter key. 

So those are the main keys that you would generally use to interact with a component, and you need to understand how all of those work with the different components and how users are going to expect them to work.

Natalie Garza: Okay. So that was a very developer-y technical answer. Do you have a simplified, high-level answer for maybe the website owner or maybe a designer?

Natalie MacLees: Yeah, I think anybody could test something for keyboard. It’s just the same thing, like you just have to become aware of how would I do this? 

(WCAG 2.1.1 Keyboard: All functionality must be operable using a keyboard alone, with some exceptions)

Because if you are able to use a mouse, you might not even realize that you could fill out a form on a website without touching your mouse. You may not even know that that’s a possibility. 

So I think just to learn how you would do that, which it’s pretty straightforward, right? It’s Tab to move forward. Shift-Tab to move back, usually arrow keys to move between choices. So for example, a set of radio buttons you would use, the arrow keys you can use either left and right or up and down to move between choices. 

Usually, you use the Space Bar to activate or push a button, and usually you use the Enter key to submit a form and sometimes also to activate a link or to activate a button.

So once you kind of know all those things, and then if there’s anything that opens, like a dropdown, you should be able to hit the Escape key to close it. If a modal, a dropdown, or something like that opens, you should be able to hit Escape to get out and close that up so that you don’t have to look at it anymore. 

And if you know those basic interactions, you should be able to test and go through and make sure all of that is working on whatever you’re working on.

Natalie Garza: Hmm. So, this is a summary, and correct me if I missed any: 

Natalie MacLees: Yes, you should be able to see where the focus is. That’s a good thing that I didn’t mention. As you’re tabbing through a page, you should be able to tell where you are.

Natalie Garza: Okay, so we have keyboard navigation and input, and we have a few little details that you need to keep in mind whenever you’re testing with a keyboard. So what are some things that we should keep in mind? 

Natalie MacLees: Sure. So, like we already touched on, you should be able to get to everything with the keyboard. So there shouldn’t be anything on the page that you can’t Tab to, to interact with. 

You should make sure that your focus never gets trapped anywhere. Sometimes that happens with things like media players, where once you kind of Tab into it, you cannot get back out. Just make sure that you don’t have anything like that happening as you Tab through the page. 

The Tabs should move you through the page in a predictable way, so you shouldn’t be suddenly surprised, right? You shouldn’t go from the header down to the footer and then back up, and then over to the sidebar, and then back to the main. It should be very predictable, right? Like if you’re in a left-to-right language, it should start at the top and roughly move left to right, left to right, left to right down the page in a way that makes sense. 

It can be really helpful to have skip links to skip over things that might be tedious. So if you have a huge navigation with a hundred links in it, have a link before that to skip over it so that if I don’t actually wanna use the navigation, I don’t have to hit Tab a hundred times to get past it. 

And then we also wanna be thoughtful that I can get to all of the functionality. So anything that a mouse user can do, there’s a way for me to do it with a keyboard and ideally in the ways that I would expect that interaction to happen. So like we said, with the Space Bar, the arrow keys, the Tab keys, the Enter key, Escape key should all work the way that I expect them to.

Natalie Garza: Yeah, so that’s the main details when navigating the keyboard. But then, whenever you use a keyboard alone, there’s also the visual feedback that you have to have. Otherwise, you don’t know where you are on the page. 

Natalie MacLees: Yes, and designers love to put CSS that says “outline: none” because they don’t like it to look, they don’t like to have a dotted outline around a button or a link. After they click it with their mouse, you can adjust the CSS so that you don’t get the mouse dotted line, but you still get the dotted line when you’re using the Tab with keyboard.

So make sure that it is there. You need to be able to see as you’re tabbing down the page, where are you? So that if I hit Enter, if I hit the Space Bar, I know what control I’m activating.

Natalie Garza: Yeah, and they, I think it looks pretty nice if you can make it match your design, like there’s CSS for helping you match, like the brand colors for if you wanna do like a dotted line or a little fine line, at least just showing where you are. That’s the most important part.

Natalie MacLees: Yeah, you can get pretty creative with your focus styles. You don’t wanna get too creative so that people don’t understand what it is. 

But there’s all different kinds of things you can do, like by default browsers use an outline, but you can also use shadows and glow, and style that outline as dots or dashes or rounded corners, or not rounded corners like any color you want.

Like there’s lots of stuff you can do make sure that your focused style is on brand with the rest of your design.

Natalie Garza: Yeah, just like you can go crazy with the hover styles for a mouse. You can go crazy with the keyboard focus styles and actually make them look pretty nice and cool.

Natalie MacLees: Yeah. Yeah. And they can fit right in and not be something that you’re trying to hide.

Natalie Garza: Exactly. So that is keyboard accessibility 101. You guys make sure you can navigate to everything and use everything the same way you would with a mouse or your touchscreen, with a keyboard alone. So. Where can people learn more about keyboard accessibility, specifically the criterion around them?

Natalie MacLees: Yeah, so on the AAArdvark website we have a resource called WCAG in Plain English or W-C-A-G in Plain English, depending on how you like to pronounce that. That’s the Web Content Accessibility Guidelines spelled out in plain English. 

So if you’re a beginner and you’ve taken a look at the official documentation and found it to be kind of confusing, a little dense, a little hard to understand, WCAG in Plain English is a nice place to get started to kind of get those basics under your belt, in a nice user-friendly way with lots of examples. 

So you can come on over and try that out at AAArdvarkAccessibility.com. 

Natalie Garza: Yeah, and you can also sort by the theme of keyboards, which gives you 16 criteria that all affect keyboard navigation and how they look and so on. So go check out WCAG in Plain English. And where can people check their websites for keyboard navigation accessibility?

Natalie MacLees: Yeah, if you wanna also come to AAArdvarkAccessibility.com, you can sign up for an account and for free you can test your homepage. You can find all of the issues that we can find automatically on your homepage. Learn how to get those fixed, and you can also conduct your manual testing and find any issues that we can’t find automatically.

Natalie Garza: Exactly. ’cause anybody can really test keyboard accessibility. It’s pretty straightforward.

Natalie MacLees: It’s pretty straightforward. Yeah. You just have to learn the few little keys that you gotta keep track of.

Natalie Garza: Mm-hmm. All right, so go check out AAArdvark. And with that we’re gonna wrap up episode 33 of the AAArdvark Accessibility Podcast. Thank you guys for joining us, and we will talk to y’all next time. 

Join Natalie MacLees and Natalie Garza in the 32nd episode of the AAArdvark Accessibility Podcast as they discuss how to make social media posts accessible. They cover using emojis, shortened links, adding alt text to images, creating easy-to-read text, avoiding fancy decorative fonts, and ensuring videos have captions and audio descriptions. Learn practical accessibility tips to enhance the inclusivity of your social media content!

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. My name’s Natalie Garza. I’m one of the co-hosts, and with me today is.

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: And she is a digital accessibility expert here to answer our questions on today’s topic. So in this episode, we’re gonna cover accessibility and social media posts. Even the content you post on social media platforms should aim to be accessible. 

So, starting with emoji, what about emoji do we have to keep in mind with social media posts?

Natalie MacLees: Don’t do posts that are all emojis. Those are terrible. We did our episode last time on The Good, The Bad, and The Ugly of Emojis. So if you want more information about how emojis work, you can check that out. 

But generally, a social media post, wanna try to limit yourself to one emoji per message. And don’t put it at the beginning. It’s better if it’s at the end of the message, so that way it’s not blocking somebody from getting to the rest of the message. 

(WCAG 1.1.1 Non-text Content – Emojis are non-text elements that need a text alternative or must be used in ways that don’t block meaning.)

But very quickly, the emoji gets read out to a screen reader. It does not announce that it’s an emoji. It just reads the name of the emoji. So we’ll just say like “slightly smiling face” with no context. No hint that it’s an emoji. So it can be a very odd experience if there’s lots of emojis in a message.

Natalie Garza: And also I’ve seen a lot of social media posts using emoji lists to replace the bullet points.

Natalie MacLees: Yeah, that’s, that’s, that one is pretty rough for screen reader users, so try not to do that. 

If you need to do a bulleted list, you can actually use the Unicode bullet character, which just gets read out as “bullet”, and everybody can understand what that means. So if you really need bullets, try to use that one instead.

Natalie Garza: Oh, I see. So if you’re gonna use the emoji, let it be the little bullet emoji. Is that what you’re saying?

Natalie MacLees: Yeah, I think it’s not even technically an emoji. It’s just one of the characters that’s in a font.

Natalie Garza: Oh, I see. This is just a copy-paste.

Natalie MacLees: Yeah.

Natalie Garza: All right. Next on the list, we have links versus shortened links.

Natalie MacLees: So most social media platforms don’t let you do what you would do on a website, where you can take a word or a phrase, link that, and have the words that are visible be different from the link, right? 

It’s like on your website, you could be like, “Check out our pricing,” and that whole phrase could be a link to the pricing page. You can’t usually do that on social media platforms, which means that you have to put the text of the link directly in your social media post, which is then going to be read out, character by character to a screen reader user, which is not a pleasant thing to listen to. 

Nobody wants to hear, “H T T P colon slash slash,” nobody wants to hear that. So if you are going to be sharing a link in a social media post, it’s better if you use a shortened link. 

(WCAG 2.4.4 Link Purpose (In Context) – Links must make sense and be understandable from their surrounding context.)

So at least then somebody only has to listen to, you know, 10 or 12 characters and not the whole thing from beginning to end.

Natalie Garza: Does it give you the option to skip a link that’s really long like that, or you just have to bear with it?

Natalie MacLees: You can skip characters. I don’t know if it would technically count as a word in a screen reader, but you can skip through characters, so you could skip ahead a little bit, but it’s kind of a hassle. 

And, also, you can’t really figure out, “Is that a link I wanna click on? Like, where’s this taking me?”. Like, it’s really hard to listen to it like that and figure that out. So make sure you’re giving context in the post about what you’re linking to.

Natalie Garza: Would it be helpful to do like parentheses, like (This links to my website) and then the link?

Natalie MacLees: If you have enough characters in your post, but some social media platforms force you into a pretty short post.

Natalie Garza: So there are a few link-shortening places that you can go to. There’s like TinyURL, some social media posting platforms like Sendible. They do it automatically. Zapier can help do it. That’s how we do some of ours.

Natalie MacLees: LinkedIn replaces it sometimes with a shortened link and sometimes it doesn’t. I don’t know what the rules are around when it decides to do that or not.

Natalie Garza: All right, so then we also go into the topic of images, which are all over social media.

Natalie MacLees: Yeah, if the platform makes it possible to add alt text to images that you share, please do that. Some of them that is very easy. It’s right in front of your face when you are adding an image. There will be an alt button right there or an alt field, and you can just fill it in. 

Other platforms really make you work for it, and it’s buried three options deep in menus. But you could look, you know, look up online or ask an AI like how to do it on whatever platform you happen to be using. So if that’s at all possible, make sure to do that. 

For the platforms where you can’t add alt text to images, make sure to put the alt text in the body of your post. So, it’s mostly on platforms that let you have long posts that this is a problem, that they don’t have an easy alt attribute. So adding it to the body isn’t a problem. Right? 

Like the really short platforms like Twitter and stuff, they let you add alt text, so you don’t have to worry about it on those platforms. But on platforms where you can’t add it, go ahead and put it in the body of the post. 

And if you are sharing on a platform that lets you add alt text and kind of gives you unlimited length on post, put it in both places. It’s just the most friendly way to do it so that people can get that information whichever way they prefer, as like the last thing in the body of your post or as alt text on the image. So have both of them available.

(WCAG 1.1.1 Non-text Content – Images must have a text alternative that serves the equivalent purpose.)

Natalie Garza: Would you put it like after the hashtags?

Natalie MacLees: Yeah. 

Natalie Garza: And you can always just say like, “alt text for the image in this post.”

Natalie MacLees: Yeah. And when it’s the very last thing, it’s easy for somebody to skip if they don’t wanna listen to it.

Natalie Garza: Alright. And then the other part about images, too. Try to avoid text inside the images, and if you do, make sure to spell out what’s included

(WCAG 1.4.5 Images of Text – Text should be real text, not embedded in images, unless essential.)

Natalie MacLees: Yeah, if you’re sharing an image with tons of text in it, that text has to be in the alt text

Natalie Garza: or included in the post.

Natalie MacLees: or included in the post. Sure.

Natalie Garza: It does get kind of crazy with like a infographic though. What would you say would be the best option when it’s a big infographic?

Natalie MacLees: Then you would probably, if you have room in the post, put the whole long description of what’s happening in the infographic, and if you don’t, you’ll have to put it up online somewhere and link to it.

Natalie Garza: Hmm, that’s true. You could always link to the transcript somewhere else, or the extended description.

Natalie MacLees: Sure.

Natalie Garza: All right, so we did emojis, short links, and images. What about the text itself? 

Natalie MacLees: Yeah. So the first thing that you wanna do is make it really easy to read. So everybody’s distracted. Everybody’s doing 50 million things. So this is helpful for everybody. But you know, aim for about an eighth-grade reading level as you do with most of your content that’s online for accessibility purposes. 

(WCAG 3.1.5 Reading Level – Content should be written to be easily understood or have supplemental content available.)

If you’re gonna use hashtags, make sure to camel case them, which is where you capitalize the first letter of each word instead of letting it be all lowercase characters all run together. That makes it easier to visually pick out the words and read them more easily, and then it also ensures that screen readers can pronounce them correctly and the screen reader can pick up which word is which. So that’s really helpful. 

(CamelCase for hashtags is a best practice; check out the VideoToVoice blog post for a fun deep dive into ‘Why Camel Case Is So Important for Hashtags‘)

Also, don’t go crazy with the hashtags either. Like, try to keep those down to just one or a couple on each post. Don’t put like 50 hashtags on a post ’cause remember, they’re all linked as well. So a screen reader user is going to hear, “link,” before everyone. So it’s even more tiresome to listen to. 

So try to limit the use of hashtags, and then don’t do anything in all caps. Some screen readers, depending on the settings, can read that in a more assertive, louder, more aggressive-sounding voice. Others are gonna mostly ignore it, except that they might be programmed to see all caps words as acronyms or abbreviations, and then pronounce them weirdly. So you have to be careful with all capitalized letters. 

And then they’re also really difficult to read, like they’re harder to read for everybody. But for somebody who has a reading or a learning disability, they can be next to impossible to read all caps letters because there’s a lot less variation in the letter shapes, which makes it harder to recognize individual letters.

Natalie Garza: That’s a good point. They do kind of all blend in as like a little block. It kind of block shapes.

Natalie MacLees: There’s no ascenders or descenders, like there’s a lot of hints that we get from the shapes of letters. They’re gone when you use all caps.

Natalie Garza: Speaking of the shape of letters, what about those fancy little decorative fonts that look kind of crazy?

Natalie MacLees: Oh, the bane of my existence. The websites that let you say, “Oh, write your Twitter posts in cursive,” and you can go and type in and it gives you this, it looks like text, it gives you back that you can paste into social media platforms, but it is not actual it’s not actual characters and screen readers won’t be able to read it at all. 

So, you wanna avoid using those that let you do bold and italic and different, they’ll say different fonts, right? Like cursive fonts and things like that. They’re not actually different fonts. 

They’re using Unicode ranges for like scientific notation and things like that. They’re not actual letters, so even though they look like letters, they’re not, and they don’t get read out to screen readers.

Natalie Garza: They kind of fall into the category of ASCII art, almost. They’re just made up of characters.

Natalie MacLees: Yeah, that’s a good way to think about it.

(Screen readers cannot read these Unicode symbols from other character sets, so for accessibility, they count as non-text content. Under WCAG 1.1.1 Non-text Content, anything that’s not real text needs a text alternative that works the same way.)

Natalie Garza: So yeah, decorative fonts. Keep the camel case on the hashtags and try to make them friendly to read. I mean, you’re on a social platform, and you’re not writing your college thesis! Keep it simple.

All right. And then last, which maybe not too many people post videos and like audio. But they’re, when you do, they’re pretty important. So do you wanna go over captions, transcripts, and audio descriptions?

Natalie MacLees: Yeah, so a video that you upload, it should always have captions. Some platforms will require you to upload a separate caption file. I know LinkedIn does that. Like you have to upload your caption file separately. 

So make sure that your videos have captions, that’s for closed captions, which are the ones that are kind of coded. If you’re gonna do open captions where they’re edited directly into the video, be really mindful and make sure that they’re very visible and easy to read. 

You can also do a transcript, so just like a printed out, you know, like reading a play of who’s talking and what they’re saying, as just like one big document.

So have that available. You could link out to it, maybe you could put it directly in your post, depending on the platform and how long it is. 

Then also one thing that’s really popular on social media is those videos where the only soundtrack is a song and all the words are just on the screen, and people are dancing and pointing at them or whatever. Like those videos are great, but if you are blind, all you get is a little snippet of a song. 

You can’t tell what’s happening in the video, so you wanna make sure that there’s audio description. That any information that’s being conveyed visually is also being conveyed in an audio format so that somebody who can’t see the video can still get that content so to just be mindful of that and, you know, that could be a transcript, but you could also just speak the words instead of just having them appear on the screen. 

(WCAG 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative (Prerecorded) – Multimedia needs captions, transcripts, and audio description where applicable.)

Natalie Garza: We talked about using emoji-shortened links, images, texts, video, and audio for your social media posts. But your website is another big part of your online presence. Where can you go to check if your website is accessible?

Natalie MacLees: Hey, come on over to AAArdvarkAccessibility.com. You can scan your homepage for free, see what all the issues are, and get information on how those issues can be fixed.

Natalie Garza: Yeah, go check out AAArdvarkAccessibility.com to scan your homepage for free. And with that we’re gonna wrap up episode 32 of the AAArdvark Accessibility Podcast. Thank you guys for joining us. We’ll talk to y’all next time. 

Join Natalie Garza and digital accessibility expert Natalie MacLees in episode 31 of the AAArdvark Accessibility Podcast. This episode talks about the implications of accessible emojis, exploring the good, the bad, and the ugly sides. Learn about specific WCAG success criteria, the role of emojis in aiding comprehension, and the challenges they pose for screen readers.

Natalie Garza: Hello, and welcome to the AAArdvark Accessibility Podcast. This is Natalie Garza. I’m one of the co-hosts, and with me today is,

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: And she is a digital accessibility expert here to answer our questions. And this episode’s very cinematic topic is called ” The Good, The Bad, And The Ugly: Emojis and Accessibility”. 

So we’re gonna go over some WCAG success criterion that goes over emojis and why they can sometimes be good, bad, and ugly. So what is the first WCAG success criterion that we’re gonna talk about today that emphasizes the good in emojis?

Natalie MacLees: Yeah, so I think we could talk about 3.1.5 for Reading Level, which is AAA, success criteria. But it’s one of the ones that I think is good to try to implement whenever you can. There are a few things in AAA that I think, even if you’re going for AA level compliance, they’re so helpful that I think it’s a good idea to try to implement them on any site where you possibly can, and Reading Level is one of them. 

And to meet that criteria, you would just make sure that you don’t have any content on your site that’s over about an eighth-grade reading level. So if you’re not in the United States, that would be about a middle school reading level, or like where you are in your early teens, so around the ages of 12 or 13. So around that reading level, is what you wanna go for to make sure that the most number of people are gonna be able to read and engage with your content. 

And where emojis can come into that is that they can help with comprehension, they can help with understanding some more complex information by presenting it in an alternative way. By highlighting certain things or kind of communicating, you know, “Hey, this is something you have to really pay attention to. This is a really important point,” right? Little emojis being sprinkled in there can communicate that kind of information and help with understanding.

Natalie Garza: Yeah. The one caveat with 3.1.5, though, is that the emojis still have to be accessible.

Natalie MacLees: They do have to be accessible, and I think one of the challenges with emojis, well, we’ll get into that I guess when we go into the bad.

Natalie Garza: Yeah, but in summary, emojis can be good. They can help break up content, they can help express content at a glance, right? 

But let’s go into the bad side of emojis, starting with 1.1.1 Non-Text Content Level A. 

Natalie MacLees: Yeah, emojis are in this kind of weird spot where they’re technically a font, but they’re not actually text content. So they’re non-text content, and they do get alternate text by default, but it behaves in kind of a weird way. 

So when you come across an emoji with a screen reader, the screen reader does not announce, “this is an emoji.” It doesn’t give the screen reader user any kind of notification that this is an emoji. It just reads the meaning of the emoji as though those words were typed out in the sentence. 

So I have a good example because my car has a feature that, while I’m driving, it will read text messages to me. So it’s essentially a screen reader. And one time I was meeting my friend at the park, and she texted me and she said, “There’s a puppy training class. Tears of joy.” Because she put the little tears of joy, which is the little laughing emoji with tears coming out of his eyes (), she had put that in there, so it was very funny. 

But again, like it just gets read like that. It doesn’t say, “emoji, tears of joy.” It just says whatever the meaning of the emoji was. Which makes it kind of weird, and especially if there’s several of them in a row, it’s hard to tell, “Was that an emoji or did they type that text? What’s happening here?” It could be really a really kind of odd experience.

Natalie Garza: Yeah. It can get confusing fast. Or, a lot of times, people like to do emoji lists.

Natalie MacLees: You mean for bullets?

Natalie Garza: Yeah. And like replacing bullet points.

Natalie MacLees: Yeah. And that’s confusing for the same reason, like if you use a regular bullet point list. A screen reader user will hear, “Oh, there’s a list with five items. Here’s the first item, second item, third item,” and let them know that there is a list there; if you just use emojis, they don’t get that context. 

And then they also are just hearing the emoji being read out at the beginning of each point. Like I said, it’s not always clear that it’s an emoji or if it was text that was typed because it sounds the same either way. And then the other big challenge is emojis aren’t always literal, right? They can have meaning other than what the emoji is, and sometimes that can get completely lost when you’re just listening to what the name of the emoji is. 

That kind of social or cultural meaning that we’ve layered onto several different types of emojis gets completely lost.

Natalie Garza: Yeah, their names are not very helpful, like “smiling imp” like he’s a little sneaky. He’s a little mischievous, but “smiling imp” does not convey that at all. ()

Natalie MacLees: No.

Natalie Garza: So all in all, emojis can be bad, but they can still be made accessible and there’s a few different ways to do that.

Natalie MacLees: Yeah, if you’re thoughtful about how you use them. They can definitely still be helpful. I would be careful about using too many. So that would be the first thing: don’t use several of them in a row. 

And don’t do a message that’s just emojis instead of text. Don’t do that. You can give them aria-labels or alt text, basically, if you really think somebody’s gonna be confused about why that’s there or what it’s doing. You can do that. It is an option. 

Or you could include something in the text next to it that explains what it, what it is. Like why is that there? To let people know like, “Hey, that was an emoji, by the way. I didn’t type out full moon face. I just used that emoji. Here’s what I meant by it.” So to help people understand a little bit, ’cause they can, they can be helpful for people who at like having the extra visual input, right?

For very visual learners, they can be very helpful. And you know, this is a constant tension that we see in accessibility, where sometimes something that works really well for one group actually creates a barrier for another group. 

And so there’s this constant kind of push and pull over like who. Who are we accommodating and how, what can we do to help one group that doesn’t harm another? And a lot of it is gonna come down to knowing about who your audience is for your particular use case, and then being really thoughtful that even when you do do something that’s going to accommodate one group, that it’s not causing harm or barriers for another group.

Natalie Garza: Yeah, because again, they can be good, but they can also be bad. I think I will also tack on, avoid starting sentences or starting text with emojis, ’cause then it’s really disorienting going like “full moon face. Today’s moon forecast is.” ()

Natalie MacLees: Yeah, yeah. If you use them at all, and I think social media is the place where people tend to get really carried away with them, like put one at the end of your message and call it a day. Like that’s it. 

Don’t put multiple emojis and don’t put them at the beginning. And also that weird thing that people do with the hands clapping emoji between every word. Stop and think for a second about what that sounds like to a screen reader user.

So someone’s gonna hear like, “Don’t. Clapping hands. Use. Clapping hands. Too. Clapping hands. Many. Clapping hands. Emojis. Clapping Hands.” () You’re not emphasizing your message. In that case, you’re making it really hard to understand what it is.

Natalie Garza: No. If anything, that just makes me a little dizzy to hear is like, “Don’t. Clapping hands. Use. Clapping hands.”

Oh my goodness. So yeah, emojis good and bad, but now let’s go even further. How can they be ugly?

Natalie MacLees: Yeah, well we’re, we’re throwing it back to the, early days of the web here, and ugly is the emoticons and ASCII art that maybe if you’re old like me, you remember when these were really popular and used all over the web. But Natalie tells me that this is having a resurgence with Gen Z.

Natalie Garza: Yes, I see this becoming a resurgence. The Frutiger Aero aesthetic is in full swing right now.

People are trying to bring back vintage little things, and I think ASCII art is one of ’em. And in the early days of texting, which I do remember, we used a lot of emoticons.

Natalie MacLees: Yeah, so I think Natalie, you’ll have to put an example on the screen just to make sure everybody understands what we mean when we say emoticons and ASCII art. But ASCII art is basically just a way to type characters, to make a picture. 

So, you know, you can type parentheses and pipe characters. Usually not letters. It’s usually different kinds of punctuation that you would type to make kitty faces and cows and all kinds of different shapes, over multiple lines of text, usually. 

But of course, like you can imagine. a screen reader isn’t gonna see that and read “cow”, right? It’s gonna read “forward angle bracket, back angle bracket, pipe character, underscore” like it’s not gonna make any sense at all. So if you’re going to make the choice to use those things, you do wanna be really thoughtful about it provide a nice way for people to access that content.

And I think probably the most recommended approach is to take a screenshot and then add alt text to it. So rather than have that be live text on your page, it would just be an image because. Realistically, that is an image, right? Functionally, that’s performing as a graphical element on your page or in your post or whatever you happen to be doing. 

So if you can, take a screenshot and add alt text. If you can’t do that, what you could do is put a description before your ASCII art. So if you have this beautiful ASCII art of a butterfly that goes on for a hundred lines, before that starts, you could put a little description like, “Oh, here’s ASCII art of a butterfly,” and some description of what it is for the people who can’t see it, and then a skip link that’s gonna let people skip past it if they’re using a screen reader or if they’re navigating with their keyboard so that they don’t have to listen to that or interact with it in any way. So that would be another approach that you could use. 

Natalie Garza: In my head, when you said take a screenshot. I almost thought about like an artist paints on his canvas and then makes prints of it, and then sells the prints. The text editor is your canvas, and then you take a print of it, publish it, and share it with everybody.

Natalie MacLees: Yeah. I think also one place that ASCII art gets used a lot is in comments, in code, where it’ll get used to add, like what looks like basically a big header in code. So be thoughtful about that. If you know, probably someday somebody with some kind of disability is gonna have to interact with your code. 

And if they don’t understand what that is, you know, if instead of hearing a word read out, they hear a bunch of characters, a bunch of random parentheses and pipe characters read out, it’s not gonna be, it’s not gonna be very helpful. So be thoughtful about that when you’re putting that into your code as well.

Natalie Garza: Yeah, that is a good point, ’cause trim and borders also technically count as ASCII art. So instead of putting like ” Em dash, em dash, em dash, em dash, em dash, em dash” to make a separator between content, you can just put the HTML element for Line Separator, what is that one called?

Natalie MacLees: Oh, a
tag 

Natalie Garza: A
tag!

(Post-editing notes: we meant tag here!)

Natalie MacLees: Yeah.

Natalie Garza: So to wrap up, that was the good, the bad, and the ugly when it comes to emojis and accessibility. So where can people go to to see if their site’s accessible?

Natalie MacLees: They can come on over to AAArdvarkAccessibility.com. You can test your homepage for free. Find out what the accessibility issues are and learn how to fix them.

Natalie Garza: Yes. So go check out AAArdvarkAccessibility.com. And with that, we’re gonna wrap up. This is episode 31 of the AAArdvark Accessibility Podcast. Thank you guys for watching. We’ll talk to y’all next time.

Join Natalie Garza and Natalie MacLees for the 30th episode of the AAArdvark Accessibility Podcast to explore statistics and dive into state-level compliance with accessibility laws and the prevalence of ADA lawsuits. The hosts discuss specific state requirements in Texas, Illinois, and Minnesota, and elaborate on the differences between Section 508 and WCAG guidelines. They also analyze the statistics of ADA lawsuits targeting WordPress, Shopify, and custom-coded websites, and provide crucial compliance deadlines for the European Accessibility Act (EAA) and ADA Title II.

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. I’m Natalie Garza, and with me today is,

Natalie MacLees: Natalie MacLees.

Natalie Garza: And in this episode, we’re gonna go over some more statistics and dive into them. So first statistic, I’m going to read out:

“The key areas of focus for businesses in 2025 include state-level compliance, proactive accessibility measures, and preparation for the EAA, which will begin enforcement in June 2025.” 

And I looked into the United States. That’s where we live. I actually found, in addition to the ADA, that each state may or may not have its own accessibility requirements. So I wanted to talk about state level accessibility.

So, Natalie, I know you talked about California last time and also New York. Do you wanna go over some of the other states? 

Natalie MacLees: Yeah, Sure. We can go over some of the other states. So we have Texas, which has Administrative Code Section 206 that generally is aligned with Section 508, Section 504, saying that websites are required to meet specific standards. 

(Texas Administrative Code Chapter 206 is only applicable to state agencies and higher education websites as of 08/2025)

Do you know Natalie, if that is just government websites or does it apply to private business websites as well?

Natalie Garza: I am gonna have to look into that. But you mentioned that there is a difference, and most states, and most laws apply to government sites, don’t they?

Natalie MacLees: In the United States, that’s generally true. Most of our accessibility laws that apply to websites apply only to government websites. 

There are a few states and, like local governments, that have requirements for private websites, but most of the laws are focused on government websites or websites that are associated with the government in some way, like public universities, public libraries and things like that.

So you know, our borders, our political borders that we use as humans, kind of become meaningless on the web, and it gets a little bit sticky about who can apply, which laws where and how.

So we could talk about Illinois, which has a law that applies to the state agencies, so any of their state agencies must have accessible websites. So following similar rules to Section 508.

(Illinois Information Technology Accessibility Act applies to state agencies and universities; however, it does not apply to local governments, school districts, community colleges, or private organizations.)

And, Minnesota has a similar law, and that also applies to all of their state websites, and they were one of the earliest states to have a law, an accessibility law that applied to their government websites.

(Minnesota Statutes 16E.03, 363A.42, and 363.43 apply to state agencies, continuing education, or professional development courses administered by the state)

Natalie Garza: Could you go over what the differences are between the requirements being closer to 508 versus WCAG?

Natalie MacLees: Yeah. Section 508 is based on WCAG 2.0 AA. I think still at this point, I don’t think it’s been updated yet to 2.1. But it’s kind of a specialized set of WCAG where they have, you know, if you look at the WCAG success criteria, each one has those recommended techniques, sufficient techniques, advisory techniques.

And Section 508 basically takes a special set of those things and says, “You have to meet this standard and here are the ways you can meet it.” And it overlaps with WCAG but it’s not a hundred percent the same. So there’s some differences in which techniques are are acceptable. 

Some of them are a little more strict and some of them are a little less strict, interestingly. I mean, in the same way that EN 301 549, which is the like analogous law in the EU. It’s similar to WCAG, but it’s not exactly the same. Like it’s its own thing, but it’s based on WCAG.

So there are a lot of similarities, but it is slightly different.

Natalie Garza: Okay, so whenever a state says you have to adhere more to 508 than WCAG 2.1, that’s what they mean. They have the modified set of criteria.

Natalie MacLees: Yeah, the slightly modified set of criteria and Section 508 gives you this like, I don’t know, 200 page PDF that goes through because it’s the government and they love a PDF. 

What each success criteria is walks you through exactly how to test it, and then tells you like which techniques are acceptable and which aren’t.

 So it’s similar, but like I said, slightly different.

Natalie Garza: Okay. So, yeah, we’re going from the national to the state level and getting a little bit more detailed. 

Natalie MacLees: There is a lot of overlap between all of these laws because Section 504 would apply to all the government websites anyway. So to now say, “Well, now there’s Title II of the ADA that also applies to all of these.” It’s a little bit redundant, but luckily, they don’t really contradict each other too much.

So they’re basically just two laws saying to do the same thing: make your website accessible.

Natalie Garza: Gotcha. Next statistic, 

“In 2023, the most common platforms targeted by ADA lawsuits were Shopify at 35.7 %, and WordPress at 18.1% and other custom coded websites at 31.3%.” (EcomBack, 2023 ADA Website Accessibility Lawsuit Report)

What does that have to say about WordPress and Shopify?

Natalie MacLees: Yeah, so it’s interesting, and I was trying to grab some statistics on this, but they’re surprisingly difficult to find. So for WordPress, it’s easy. So you hear that 18% of all of the ADA lawsuits brought against websites are brought against WordPress sites. And you might wanna say, “Whoa, WordPress must be really bad”, but WordPress sites make up 40% of the internet.

So if. Everything was fair and level, right? You’d expect about 40% of the lawsuits to be against WordPress sites. So it actually seems like WordPress is fairing pretty well in there. And I don’t think that that means that WordPress sites are particularly accessible. Although that would be very nice if that were the case.

I think it’s more that a lot of WordPress sites are little independent blogs, that maybe don’t have a business behind them but are personal, and wouldn’t be very likely to be targeted by lawsuits. So there’s some good news and some bad news, I think, for WordPress there. 

The Shopify lawsuits, at almost 36% I think, are really surprising because I couldn’t find any statistics on what percent of the internet is built on Shopify, but I, it’s nowhere near 36% like that I can say for sure. 

So they have more of the share of lawsuits than I think we would expect. And I think like that’s not all bad news for Shopify. We do know that there is an emphasis on e-commerce in these lawsuits very often. So that makes sense. If people are specifically targeting e-commerce sites, Shopify would end up being overrepresented in the sample. 

And then other custom-coded websites, it’s kind of hard to say because that could cover just about anything. I don’t know if there’s a specific set of CMSs that were used in that, or if that’s, you know, just a big lump of everything that’s not WordPress, Shopify, so it’s a little bit hard to say.

Natalie Garza: Yeah, I think it was a big lump of like Wix, Webflow, Weebly, Squarespace.

Natalie MacLees: Squarespace, Square, weirdly. Now we have Square and Squarespace websites.

Natalie Garza: Yeah. I think that’s what the other website category is, but I think the fact that you have a purpose in a Shopify website. 

It’s built so people will interact with it. If a keyboard can’t tab through, if a screen reader user can’t hear everything on the page, and they can’t check out, then they’re more likely to file a lawsuit.

Natalie MacLees: Yeah, it’s really frustrating when you’re trying to shop and you can’t check out. You’re like, “but I just wanna buy this thing. I just wanna give you my money and you can’t do it”. 

So, and then I think also an e-commerce site is very clearly a business that is making money, whereas like somebody’s recipe blog

may or may not be making money, may or may not be a business. It may be just a little personal project, or it could be somebody’s full-time job or anywhere in between. So it’s not always super clear that it’s a business that would have money to even defend itself in a lawsuit.

Natalie Garza: Yeah, that’s a good point. And I also think it’s interesting that WordPress and Shopify are very customizable-friendly. Like anyone can make a theme. Anyone can customize those themes, which then leads to issues with accessibility.

Natalie MacLees: Yeah, especially if the platform hasn’t followed ATAG, right? To help people, which is the Authoring Tool Accessibility Guidelines can help guide people through making an accessible site, ’cause you can’t expect just any business owner who comes along and says, “Oh, I think I’ll set up my own Shopify store.”

You can’t expect them to know anything about accessibility. That’s not a realistic expectation. So the platform is really gonna have to lead them. And if they try to put, you know, pale yellow text on a white background, the platform itself is going to have to say like, “Ooh, are you sure about those color choices? You might wanna rethink that.” 

I don’t think it’s really doing that to a great extent. So it is really easy if you’re not aware to make a website that’s not accessible at all.

Natalie Garza: Yeah, I also feel that Shopify websites— just because they’re people who just wanna sell their products online—they come in not knowing much. They’re also really prone to using a lot of images of text. Like I’ve come across a lot of websites lately, they’re like little e-commerce stores, like Shopify stores, and like their main homepage is just a picture and nothing about it is

Natalie MacLees: Yeah, that’s rough, that’s not good for many, many reasons, but accessibility is obviously one of them. But on one hand I kind of get it, because if you’re not accustomed to wrestling with HTML and CSS, and you just want something to look the way you wanna make it, it’s easy to open up something like Canva, make it look the way you want, and then just take that whole image and plop it on a web page.

Natalie Garza: Exactly. So I think with that said, if you’re on Shopify, if you’re on WordPress, make sure to double check your themes, make sure to check all the content that you personally add on there, and maybe check with the developer who’s familiar with accessibility to help guide you through using those platforms, which let you basically do whatever you want. Just be careful. 

And with that, I think we’re gonna have to wrap up this episode. We’re a little over time, but if you’re a small business or a government website to go check out a special tool.

Natalie MacLees: Sure. You can check out AAArdvarkAccessibility.com. You can run a free scan on your homepage. Find out what your accessibility issues are and get instructions on how to fix them.

Natalie Garza: Wanna talk about the dates?

Natalie MacLees: So we have some important compliance deadlines to just touch on very quickly. So EAA, which is the European Accessibility Act, which applies to anyone who actually does business in the EU, not even if you’re not based there. So if you have an e-commerce site that sells to customers in the EU, it applies to you.

That went into effect in June of 2025. It does require that you have an accessible website. We have another episode where we talked about that. We also have in the United States, ADA Title II, which has some guidelines that go into effect. If you have a total population of 50,000 or more, you have until April of 2026 to make sure that all of your websites and digital services for your constituents are accessible.

If your total population that you’re serving is less than 50,000, you have until April of 2027. So if you are working with a government and you need to make sure that those sites are accessible by either 2026 or 2027, depending on how large the audience you serve is.

Natalie Garza: Yeah, so important dates coming up. Go check out AAArdvark. That is the end of this AAArdvark Accessibility Podcast. Talk to y’all next time!

Join Natalie MacLees and Natalie Garza for the 29th episode of the AAArdvark Accessibility Podcast. They delve into the significant rise in ADA lawsuits related to digital properties, examining how these lawsuits affect small business websites and government entities. The discussion covers key statistics, including the increase in state-level lawsuits, repeat lawsuits, and the impact of accessibility widgets. They also emphasize the importance of education and proactive efforts in making websites accessible.

Natalie Garza: Hello everybody and welcome to the AAArdvark Accessibility Podcast. My name’s Natalie Garza. I’m one of the co-hosts, and with me today is,

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: and she is a digital accessibility expert here to answer our questions. Talk to us about today’s topic, which is how accessibility lawsuits have affected small business websites and also government websites. 

So we’re gonna go through some statistics and then dive in. So to get started, first one, we found that “Over 4,000 ADA lawsuits related to digital properties were filed in 2024. With a decline in federal cases and an increase in state level lawsuits, particularly in New York and California.” (UsableNet 2024 Report)

Natalie MacLees: I think generally the decline in the federal cases is probably due to the change of the administration at the federal level and the administration demonstrating a different set of priorities around accessibility right now. So we see those cases kind of shifting to the state level. 

California has a Civil Rights Act, the Unruh Civil Rights Act, that was passed in 1959. Which does let plaintiffs claim $4,000 per violation, per person, per visit, so that does create an incentive structure for frivolous lawsuits, unfortunately. Not all accessibility lawsuits are frivolous. But there is a problem I think, in the industry with abuse of using the judicial systemfor personal gain.

And there are definitely legitimate cases, and I don’t wanna take that away from anybody, but there are also cases where it seems like nobody actually did go try to use the website, and then they file these lawsuits. 

So unfortunately, there’s that incentive for that to happen, and it’s meant to be an incentive for small businesses and government websites and things like that, it’s meant to be an incentive for them to avoid those fines and fees and make their, you know, the, it’s not just their websites, right? That law applies to physical locations, like having a wheelchair ramp for your restaurant and accessible restrooms, like it applies to all different all different situations, but it does include websites.

So it’s meant to be an incentive for businesses and governments to make things accessible. And I think it has accomplished that to a certain degree, but I think it also has this kind of other unfortunate side effect, that we see. 

And then in New York, there’s not a specific law in New York that’s causing the extra lawsuits there.

I think it’s just a friendly court district that happens to be in New York, and I know that there are a lot of family-owned wineries in upstate New York that have been for some reason targeted by these lawsuits. Which is also unfortunate that what’s getting targeted are they small family run businesses.

I agree that they should all have accessible websites and accessible premises I think they should be doing everything that they can to make their websites and their shops accessible. But I, I don’t think that filing many, many lawsuits, and having serial plaintiffs for lawsuits is necessarily moving accessibility forward or encouraging the world to be a more accessible place.

Natalie Garza: Yeah, whenever you told me about this, I was very shocked to learn that it’s not a requirement to reach out to the businesses first before filing the lawsuit either. Like you can just find like missing alt texts and that’s enough for you to be like, “okay, well I’m gonna file a lawsuit against you.”

Natalie MacLees: Yeah, it is unfortunate, and we have seen some judges start to push back a little bit, and they wanna see proof that somebody did actually try to use the website and wasn’t able to. Because what does happen in a lot of the cases is a lawyer or, you know, probably a legal clerk or somebody who works for a lawyer will just go on a website, run an automated checker, and if they find issues, they put it on a list.

And that, that these are the people that they’re gonna find a plaintiff for and file a lawsuit against. So it is really, it is really unfortunate that it gets treated that way because, you know, these are laws that were meant to help people, and they were laws that were meant to make the world more accessible for everybody.

So it’s, it’s a little bit sad and frustrating to see it getting abused that way because I don’t think that that’s moving things forward.

Natalie Garza: No. I mean, in my opinion, I think it’d be more helpful and move it forward more if you just reach out to the website owner and say, “Hey, I can’t submit your form. I’m a screen reader user. Or like, I use my keyboard only.” Then if they don’t reply, then yeah, I mean.

Natalie MacLees: I would rather focus on let’s get it fixed, and let’s make everything better. But yeah, I mean, a lot of, you know, a lot of these small businesses, they have either built their website themselves or they’ve hired, you know, just a little freelancer to do it for a couple thousand dollars and nobody in that situation has any idea that this is something that they should be, looking at.

Right? They have no idea that they should need to be thinking about the accessibility of their website. I think it’s unfortunate that the way that they sometimes find out is getting a lawsuit pressed against ’em when I think it’d be more useful if it were somebody getting in touch and saying like, “Hey, did you know that I, I can’t use your website, because it’s not accessible.”

And to have them learn about it that way, and then be able to take steps to fix it. I think it would be the preferred way. And I know, I, I’m aware that not every business is going to suddenly go, “oh no, let’s fix it right away.” 

That’s, that’s not what’s gonna happen. And, and I think it’s okay to, to move forward in those cases and try to, force the issue, I guess, and try to push a business into making their website more accessible.

But I do think there’s some amount of education and outreach that should happen first.

Natalie Garza: Yeah, especially if it’s a customer who truly was trying to purchase something or get in contact or learn something from their website. If you reach out and honestly just say, like “I was trying to buy this product and I couldn’t check out with your form” or something, they would be very inclined to fix that ’cause they want your business, they want your traffic, they want you to interact with their website.

Natalie MacLees: Yeah, and, and I can understand from the other side too that people with disabilities, they get worn out trying to do that kind of thing, right? 

Most websites have some kind of barrier on them. And can you imagine like if your day was just reaching out to every website you try to use to tell them it wasn’t accessible, like it’s gonna take up half your day, you got other stuff to do.

Like, so I can understand it from that point of view too. It’s a frustrating and unfortunate situation I think all around and I hope the answer is to educate people and to make them understand why it’s really important and that would hopefully provoke them to take action on it and make the situation better for everybody.

Natalie Garza: I almost feel, though, like the website owners, like the business owners, like this should have gone back to the developers. Go check out our other episode on accessibility and website development [education].

Natalie MacLees: Yeah. Yeah. And then it gets hard to even put it on the web developers because it’s not getting included in curricula when they’re taking courses and learning how to do web development. It’s not being included, which kind of communicates that, “hey, that’s not something that’s that important. If you’re interested, you’ll go learn it on your own.”

And so, it’s just a big cycle of, I think a lack of education and a lack of awareness that this is something that needs to be done. That hopefully we can break that cycle and start getting more web developers educated about it, more business owners educated about it, and then that just becomes the way you build websites.

Like it’s not even a question, should we make an accessible website or not? It’s of course it’s going to be accessible, just like it’s going to be responsive and it’s gonna be search engine optimized. 

Like you wouldn’t ask a customer, right? “Well, do you want search engines to find your site?” Well, of course they do!

Why else do they have a site? So I think it would be just like that. Like it’s not even a question, it’s just an assumption that this is how we’re gonna do it. I think that would be the ideal situation to get to.

Natalie Garza: Exactly. But, alas, we have the laws of the land that we have right now.

Natalie MacLees: And the imperfect world that we live in. 

Natalie Garza: Next statistic that I found. “Repeat lawsuits are common, with one in four lawsuits filed in 2024 involving companies that had already been sued in the past.”(UsableNet 2024 Report)

Natalie MacLees: Yeah, I think sometimes companies are very quick to settle these cases, right? Just settle out of court and pay a certain amount of money to the person, who brought the suit against them. 

And I think that unfortunately sets up another incentive structure, right, to just say like, “oh, well we can sue those people and they’ll just give us money and won’t even make us go to court.”

So we are unfortunately, I think setting something up like that, and I don’t know how often. Those businesses are actually taking action. The businesses that are getting sued, again, like, I would hope that that was because they had refused to do anything about their website, but I don’t know if that’s actually the case or if it’s something where they’ve started working on it and they’ve started making improvements.

But, you know, it’s not like you can overnight make a website, go from inaccessible to accessible. And so I do wonder if sometimes it’s like, unfortunately they’re already trying and they’re already working on it, and they’re not really getting the room to do that in time. So it’s another tough situation, I think. 

Natalie Garza: And not only are there repeat cases for the same companies, there’s repeat filers.

Natalie MacLees: Yeah. So the same person coming back again.

Natalie Garza: And that leads into the next statistic, “24.5% of ADA lawsuits in 2023. So a year before were against websites with accessibility widgets.” (EcomBack 2023 Report) So if a company gets sued, they’ll settle it. And they could either go two ways: actually try to fix it, or maybe try accessibility widgets, which are not a good idea.

Natalie MacLees: Yeah, because they’ll probably see some marketing that says, “oh, make your website accessible in five minutes”, which is very misleading. And then they do that, and then they get sued anyway, because that doesn’t actually work. That’s unfortunate. 

And I do think we’re starting to see a little bit of evidence that maybe those widgets actually make a website a target for a potential lawsuit because they are like, you wouldn’t have put that on your site if you didn’t have accessibility issues.

And we know that that widget isn’t fixing a hundred percent of your accessibility issues. 

Natalie Garza: Yeah, and they’re easy to scan for. 

Natalie MacLees: They’re, they’re very obvious when they’re installed on a site. It’s not a secret.

Natalie Garza: All right, so those are just a few of the statistics. We didn’t get to go over all of them. will make a part two to go through the rest. So with that said, we wanted to introduce a little accessibility testing tool called AAArdvark. 

Natalie MacLees: Yeah, so if you are responsible for a website for a small business or a government entity, and you wanna know what’s the state of the accessibility on that site, come on over to AAArdvarkAccessibility.com. You can scan the homepage for free, find all the issues that are on there, and get instructions on how to fix them.

Natalie Garza: Yes, and with that, we will talk to y’all next time. 

Join hosts Natalie Garza and Natalie MacLees in episode 28 of the AAArdvark Accessibility Podcast as they continue discussing web design for digital accessibility. Topics include the proper use of headings for creating meaningful hierarchy, text spacing and typography principles, consistent navigation design, considerations for limiting motion and animations, and the impact of videos in design. Learn about best practices and resources like WCAG in Plain English and the new AAArdvark Circle community.

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 28. I’m Natalie Garza, one of the co-hosts, and with me today is.

Natalie MacLees: Natalie MacLees, the other co-host.

Natalie Garza: And she is an accessibility expert here to answer all of our questions today. So this episode is the second part of the one we did last week on web design for digital accessibility. We’re gonna pick up where we left off. So starting with the next topic, which is headings.

Natalie MacLees: Headings. Yeah. So you wanna make sure that you’re including headings in your design. And before you hand that design off to a developer, you would wanna put some annotations in the design. To let them know which heading levels should be used for each thing, and that way, you can make sure that there is a meaningful hierarchy to those headings.

So I think we’ve talked about this before, but just a quick refresher. There should be one H1 on the page, and that H1 should be the main idea of that page. So the main reason that that page exists, it’s probably going to match or be very close to the title of the page. So that’s a good hint on which heading should be the H1 on the page. 

Then each section of the page should be headed up by an H2, and if you have subsections under those sections, those would be H3 and so on and so forth. You can go all the way down to an H6, although it’s pretty rare to need much past an H3 or an H4.

Natalie Garza: Yeah. And remember, headings are not stylistic choices like they’re there for a reason.

Natalie MacLees: Yes, they do make text large and bold, but they also say this is a heading for the section of content that follows. So if you just need big, bold texts because you’re putting text over an image for a big banner or something like that, you have to think about whether that makes sense for that to be a heading or not.

Like, is it actually heading up a section of content? ’cause if it’s not, it should probably just be a paragraph that’s styled to be big. 

Natalie Garza: All right, so those are headings next on the list. Text spacing kind of goes hand in hand.

Natalie MacLees: Yeah, and I would even maybe call this typography. So there are only a few official WCAG rules that deal with text and typography. Shockingly few, if you ask me, actually, because there’s no rule around minimum font size, for example, which is kind of surprising. And there are no rules around which typefaces you choose. And obviously, a typeface can be pretty difficult to read, for anybody like, let alone somebody who may have a learning disability or a reading disability. 

But we do have a few rules around line heights. You wanna make sure that your lines aren’t too squinched up all together. You wanna make sure that words aren’t pushed too far together, that there’s a nice space, a nice separation between words. You don’t want letters touching each other. And those are all things that you can do, like in a design program, and with CSS, you can scrunch text steps. 

So if it’s really small, so the lines are touching each other, and the letters are touching each other. That’s a bad idea. You wanna make sure that it’s really easy to distinguish one character from another, but then also you don’t want them too spread out because that makes it also hard to read. 

So, just some really basic rules around good typography can go a long way. And there are some official WCAG rules that line heights should be at least a certain amount, that paragraph spacing should be at least a certain amount, etc. So you definitely wanna check on those and make sure you’re following those rules. 

But then aside from the official rules, I think you do wanna be really thoughtful about what typefaces you choose, what sizes of those typefaces you use, what colors you use for text, because all of those things are going to impact the readability and can impact people with different disabilities. So just being really thoughtful and making sure that things are very easy on the eyes, but very easy to read.

Natalie Garza: Is there any best practices for typefaces or choosing typefaces?

Natalie MacLees: Oh, there are so many. There’s people who are complete typography geeks who will talk your ear off about the difference between Arial and Helvetica, for example. 

There’s a lot of nuances in typeface, right? Typefaces, like there’s a lot of different considerations that go into selecting a typeface because there’s different amounts of legibility, and then legibility is different for things that are printed versus things that are on the screen. So there’s considerations there. 

And then, of course, we all know that typefaces are also very evocative. They have a mood to them, right? They are one of the best ways to establish a distinctive brand is to have some really nice choices of typefaces that you’re using in a design. So there’s a lot of considerations that go into typography and I would say. That most of those considerations actually have an impact on accessibility, even though officially there are only a few rules around typography in the WCAG guidelines. 

Natalie Garza: Okay, so there’s not any like “use Serif and not San-Serif” best practice or something? No.

Natalie MacLees: Isn’t that surprising?

Natalie Garza: Yeah, that is kind of surprising. I bet there are guides out there. They’re like, “Oh, most accessible fonts” or something. 

Natalie MacLees: Yeah. Yeah. And I know, there’s somebody that I follow on social media, Piccia Neri has a course on accessible typography, if that’s something you really wanna dig into, you could check out her course.

Natalie Garza: Okay, cool. I’ll find it and link it in the notes.

Natalie MacLees: Okay. 

Natalie Garza: Alright, next on the list, navigation for the site.

Natalie MacLees: Yeah, so you can’t just do whatever you want with navigation. You have to be thoughtful about it.

One of the most important rules for accessibility is that it is consistent from page to page. I can predict what navigation is going to look like on different parts of the page to help me find my way around. So that is an accessibility consideration. 

It’s helpful for people who are using screen readers, who can’t see the screen and have to rely on just their memory for what was where. And that can get very confusing if it’s switching around from page to page. It’s also helpful for people with memory issues or with cognitive disabilities who may have trouble. 

Just kind of any help that they can get in understanding where they are on a page. It is really helpful, but that’s really helpful for everybody. Like anybody who’s trying to make their way around a site appreciates when there’s consistent navigation. And navigation is not just limited to like that line of five links in your header, right?

Navigation means a lot of different things. It’s your pagination, it’s using your, skip links. To skip over parts of content to get directly to the main content, for example. And then it’s also using things like breadcrumbs to say like, “Hey, here’s where you are. You know, you’re in this section, this subsection, and then this page is nested in that subsection” so that you can kind of understand how the content on the site is structured.

So all of those different things are navigation or part of navigation and have a lot of considerations for improved accessibility.

Natalie Garza: Yeah. Even goes beyond if like you’re making a blog layout design, like there could be a table of contents. How can people navigate between the blog posts? There are different types of navigation depending on what you’re working on, too. 

Natalie MacLees: Yeah, it depends on what you’re working on. So any way that people are getting around from one place on your site to another place on your site, that’s navigation. No matter what it happens to look like. 

Natalie Garza: Yes. And even site maps. 

Natalie MacLees: Yes. Site maps can be very helpful on a large site where you’re trying to figure out how is this all organized? Yeah. Site maps can be super helpful.

Natalie Garza: Yeah. I feel like a lot of people don’t realize those exist. 

Natalie MacLees: You think so?  I tend to look for that in the footer if I’m just lost on a site.

Natalie Garza: Those were new to me when I started working here. I was like, “I didn’t know there was a page with every single link on it.”

Natalie MacLees: They’re so helpful.

Natalie Garza: All right, next topic. Blinking, flashing, and animations. 

Natalie MacLees: Yeah, so for a variety of different reasons, we wanna make sure that we are limiting the amount of motion that’s happening on a page, if not avoiding it altogether. 

There are some very specific considerations, like one is if you have blinking or flashing, which can impact people who have vestibular disorders or seizure disorders.

And if you’re not thoughtful and careful about how you handle that, you could cause somebody to have a seizure or lose consciousness and become injured, right? If they fall down, they could become injured pretty seriously. So you wanna be really thoughtful about those things. 

And then animations in general. You wanna be really thoughtful about them because people with different kinds of learning disabilities and cognitive disabilities, and honestly, just anybody, can be really annoyed if they’re trying to read an article and there’s just a constant animation running over on the sidebar. It’s so hard to focus on the article and read what you’re supposed to be reading. And some people actually find that literally impossible to do. They just cannot read or focus. 

So you don’t wanna have an animation that the user can’t control, that they can’t pause it, they can’t stop it, they can’t hide it, and it, they just have to deal with it if they wanna work on the screen.

And maybe they’re trying to fill out a form, maybe they’re trying to read an article, maybe they’re trying to watch a video, and this other thing is running and it’s very disruptive and it can make people feel sick. 

It can give them headaches, it can give them dizziness, it can give them nausea. So you wanna be really thoughtful about that and respect if they have set their setting in their browser to say, “I prefer reduced motion.”

That you respect that, I have that setting turned on on my computer, and I’ll tell you almost no site respects it. So please respect that. And then if you do have to include some kind of animation, make it opt in so people turn it on if it’s something they wanna see. But if that’s not possible, you need to at least make it opt out, make it so that they can pause it, stop it, hide it, and they don’t have to deal with it.

Natalie Garza: Yeah. Super popular in modern sites to make their pages look dynamic, but some people will get sick.

Natalie MacLees: Yes. Some people definitely get sick, or just get distracted or annoyed or frustrated, but also can sometimes get very sick. So be thoughtful about that. 

Natalie Garza: And then I think I wanna add in one last note, but really, designers don’t have too much say in, but they can sometimes choose to put videos into their designs, and that’s a whole other accessibility topic too. 

Natalie MacLees: Yeah, especially a couple of years ago, you saw this on every site, a background video. So like, you know, your big hero section of your homepage, for example, wouldn’t just be an image as a background, which is problematic enough for a lot of people, but an actual video that you couldn’t pause. Or stop, and it was just running all the time. Yeah. So I’m glad that that fad has kind of faded, because that was awful. 

Natalie Garza: Yeah, it got replaced by animation, so, so.

Natalie MacLees: Yeah, that’s true.

Natalie Garza: Yeah, so I guess the designer doesn’t have too much say in like, “oh, there’s like captions and there’s like a transcript.” But I guess annotations and just keeping those things into consideration, like adding a ton of videos, there’s gonna be a lot of captions and a lot of work on making sure that those are accessible too. 

Natalie MacLees: Yes, there is for sure.

Natalie Garza: So that wraps up the second part of web design for digital accessibility. Where can we learn more about this? WCAG in Plain English. We have a design category specifically to call out all the success criteria that have to do with design specifically. All right, so like contrast, text spacing, which we went over, headings, et cetera, et cetera.

So go check it out. I’m gonna put a link on the screen and in the notes. And Natalie, do you have something important to share with us? 

Natalie MacLees: So we are launching AAArdvark Circle, which is a community for freelancers, agency owners, web developers, designers, anybody who works building websites, a community to learn how to do that accessibly. 

To learn all the technical side and then also learn how to get clients to come along on the ride with you, get them on board. How to price things, plan things out, and all of that, so that you can make all of your work accessible. So if that’s interesting to you, you can join the AAArdvark Circle 

Natalie Garza: Yes, and we’ve talked about a special hand gesture whenever we do this Circle.

So go check out WCAG in Plain English, design category, and the AAArdvark Circle. We have summer bonus special, and with that we’re gonna wrap up episode 28 of the AAArdvark Accessibility Podcast. Thank you guys for joining us. We will talk to y’all next time. 

Join hosts Natalie Garza and digital accessibility expert Natalie MacLees in the 27th episode of the AAArdvark Accessibility Podcast, as they discuss important considerations for designers in creating accessible websites. They cover topics including color contrast, touch targets, responsive design, hover and focus states, and forms. Also, learn about resources like WCAG in Plain English and the AAArdvark Circle community.

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 27. I’m Natalie Garza, and with me today is,

Natalie MacLees: Natalie MacLees.

Natalie Garza: And she is an accessibility expert here to walk us through today’s topic, which is web design for digital accessibility. So a lot of people think that digital accessibility falls only on developers’ plates who are building the websites, but that’s completely untrue. 

Natalie MacLees: I mean, it does fall on their plates, but it’s not only on their plates. It falls on the plates of everybody who’s involved in making a website. So starting from planning, project management, design, user experience, content, copywriting, marketing, photography, and images. 

Every part that goes into making the website, everybody has some responsibility for accessibility, but we’re not gonna talk about everybody today.

We’re just gonna talk about the designers.

Natalie Garza: Yeah, because the designers, a lot of the time, will set the tone for the website project.

Natalie MacLees: Yes, the designers tend to come in pretty early in the process, so they have a lot to do with the direction that things go and making sure that things like color schemes and forms and all of those are designed to be accessible from the very beginning.

Natalie Garza: ’cause you can’t always expect the developer to know how to implement a lot of stuff. Like the designer, they’re the one there to tell them how you should execute the website, whether it’s like a hover state that you don’t often think about or like the form errors that often get missed, like the designer’s there to say, this is how it’s supposed to look.

Natalie MacLees: And to a certain extent, this is how it’s supposed to work. Also, there should be some accessibility annotations in most designs that explain a little bit about how something is expected to function to make sure that it’s accessible.

Natalie Garza: Exactly. So in this episode, we’re gonna walk through all the different concepts or things that designers have to keep in mind when designing accessible websites. Starting with contrast. 

Natalie MacLees: Yes. Probably the most common accessibility failure across the internet is insufficient color contrast between text and whatever background it happens to be on, whether that’s a solid background color, a gradient, a background image, something that changes, something that’s absolutely positioned over some other part of the site. 

There are so many different ways that color contrast can fail. And there are also some trends in web design that are very inaccessible, like using very light pastel colors as a background with white text. 

You know, it has a very fresh, fun feel to it, but it is not sufficient contrast, and it is very difficult to read that text. And sometimes people really get carried away with it on very, very light colors with white text, and it’s just too difficult to see. 

So you wanna make sure to avoid things like that, and that there is, for normal size text at least a 4.5:1 ratio, for bigger text it can be a 3:1 ratio, but making sure that you’re at least there with a color contrast to make sure everybody’s gonna be able to read the text. 

Natalie Garza: Yeah, and often missed, too, is the contrast within the images.

Natalie MacLees: Do you mean like cases where there’s text in the image?

Natalie Garza: Yeah.

Natalie MacLees: Yeah, you generally you wanna try to avoid using images of text, but it’s not always avoidable. And when you do have to use an image of text, you wanna make sure that it also has sufficient color contrast and that you’re including that text as alt text. 

So somebody who can’t see the image can still get that content. That’s starting to get into the development side of things though, but it is something that you would want to annotate on a design to say, “make sure that this text gets included as alt text”.

Natalie Garza: Yes. Next on the list is touch targets.

Natalie MacLees: Oh yes. People love making little teeny tiny x’s for us to try to click with our big human meat fingers, just doesn’t work. So for AA, WCAG AA things should be at least 24 by 24 pixels, which should be roughly the size of the your fingertip. So that you can tap that pretty reliably with your finger. 

If you wanna go for AAA compliance, which I actually recommend that anywhere possible you do, it would be at least 48 by 48 touch target. So that’s really easy to tap with your finger. It’s easy to click with your mouse. 

There’s a really basic user experience rule that the bigger something is, the more likely people are to click on it. And why are you putting it on the page if you don’t want people to click on it? So just to keep that in mind and have plenty of space around things. 

You know, people have different kind of mobility issues and fine motor control issues that make it really difficult to click on something that’s very small and very fine, or that’s right next to other things, right? It’s hard to get just the thing that you want if you don’t have a lot of fine motor control over where your fingers are going. So that’s really helpful. 

It’s also just helpful if you’re like looking at, I don’t know, something on your phone while you’re walking and holding a coffee, right? wanna be able to reach that button and close it pretty easily with your big fat thumb. So handy for lots of different cases.

Natalie Garza: Yeah. Speaking of mobile design, do you wanna talk about responsiveness?

Natalie MacLees: Yeah, we could jump over to that. You wanna make sure that, because lots of people are gonna be using all different screen sizes, so you wanna make sure that your design works on all of those different size screens, that it adjusts, and that nothing starts overlapping, nothing starts going off the screen, right?

We don’t have to scroll horizontally to try to get to anything. And, also, that mobile view is probably gonna be triggered by people who zoom in on your page. So people who need to use a screen magnifier or who just need to zoom in on a page to be able to see it better. 

You know, whether because they have a vision, disability, or because they just forgot their reading glasses that day, you know, we’re all, we’re all getting, you know, one day older every single day. And eyesight, especially close-up eyesight, is one of the first, you know, the first signs that happen, as you get older, as you lose your close-up eyesight, and it becomes harder to read small texts that you would read up close. 

So making sure that you can zoom in and everything looks good. Nothing overlaps, nothing goes off the screen. All the functionality is there. I can still understand how to get to everything. 

So responsive design, that’s really helpful because now anybody using, you know, if they’re using their phone or their tablet or whatever, they can get to it. But now we’ve also accommodated people who are using screen magnifiers and making the screen bigger and using whatever kind of assistive technology they might need to.

Natalie Garza: Yeah, I feel like the touch targets and responsiveness kind of go hand in hand. Like you have to be able to click all those buttons on the screen.

Natalie MacLees: You have to, yeah. If you are trying to open the menu to try to get around a site and like, but a little hamburger menu is teeny, teeny tiny, and you gotta try three or four times just to click it. It’s, yeah, it’s terrible. Nobody wants to use a site like that.

Natalie Garza: Yeah, I especially appreciate larger touch targets like on Google Maps when I’m trying to drive. And it’s like, I’m not trying to press that button. Ugh. Shaking everywhere.

Natalie MacLees: You shouldn’t be using your phone while you’re driving!

Natalie Garza: Okay. Well, well, well

Natalie MacLees: Sometimes you do have to mess around with the navigation a little bit. 

Natalie Garza: Yeah. You have to change the song. You have to turn off the announcer.

Natalie MacLees: They just passed a law in California. They took away our ability to use navigation while driving. So there was an exception previously that you could interact with your navigation while you were driving on your phone, but you couldn’t do anything else. 

And now they just passed a law, they took that away. If you need to mess with your maps or whatever, you need to pull over.

Natalie Garza: Maybe in other places it doesn’t make too much sense, but when you’re trying to merge into a seven-lane road, like in Los Angeles, it does kind of makes a little sense.

Natalie MacLees: Yeah, you don’t, you don’t wanna be looking at your phone while you’re doing that.

Natalie Garza: Anyway, digital accessibility. As you can see, it helps everybody, whether you’re driving, whether you have larger fingertips. 

All right, next topic, hover and focus states, which often do get forgotten, and it’s up to developers to figure out what they’re going to look like.

Natalie MacLees: Yeah, this is probably, I would say the top thing that designers tend to leave out of their designs is, you know, what’s supposed to happen when I hover over this link or this button or this form field and what’s supposed to happen when it has focus? And those are really important things for accessibility. 

We want to make sure the, hover states less so, but the focus states are very important for users who are navigating by keyboard alone, they need to be able to see where the focus is. 

And the browser default focus is okay, but it, it can be enhanced a lot of the time. And what you also don’t wanna do as a designer is instruct the developers to disable the focus styles, which sometimes happens. Because they don’t like to see a dotted line around a link after it gets clicked, for example. 

But there are CSS adjustments that you can make to prevent that from happening, and it is really important that those states get styled. If you don’t do it as a designer, you’re leaving a developer to do design and that never works out well for anyone. 

Natalie Garza: Mm. No. Speaking of states, I think that’s a good segue into forms that also get overlooked. Like, how is a form supposed to act whenever somebody clicks submit, or when somebody clicks onto this field, what is it gonna look like? 

Natalie MacLees: Yeah. What are the active states for the forms gonna look like? When a form field has focus, how are the labels going to appear on the screen? Because you cannot use just placeholders. You do have to figure out a way to have an always-visible label for every single form filled out there. You need to figure out how an error message is gonna be shown.

So if somebody skips a field and tries to submit, how are you gonna show that error message to them? You have to figure out how you’re gonna mark the required fields so that users can see what those fields are. 

And those are all things that get left out a lot of times from design, but they’re all really important. They’re important from an accessibility point of view, but they’re also really important from a usability point of view, really important parts of design that we have to remember.

Natalie Garza: So a lot of stuff to cover, but we are halfway through and so we are going to continue in another episode, cliffhanger!

Natalie MacLees: Yay, part two.

Natalie Garza: So keep an eye out for that next episode, we’re gonna cover a few more things that designers need to keep in mind for digital accessibility. 

We have a fancy, cool, awesome resource that you can go check out called WCAG in Plain English, and you can go to WCAGinPlainEnglish.com to go read all the articles and you can filter by success criteria that applies specifically to designers, and you can flip through and read in plain language what each of those means.

Natalie MacLees: And understand all those different design requirements. 

Natalie Garza: Yeah, all the ones that we went through, plus more that we’re gonna include in part two.

Natalie, do you wanna talk about the circle?

Natalie MacLees: Yeah. And then we’ve also launched AAArdvark Circle, which is a community for anybody working in web design, web development, who’s building websites and needs to learn how to do that accessibly, how to incorporate accessibility into their workflow, how to understand what all the different requirements are. 

And how to figure out how to talk to clients about that and get clients on board, how to plan for it, how to price it out, all of those different things we’re gonna cover in the AAArdvark Circle. 

So if you go to AAArdvarkAccessibility.com, you’ll see a banner, right across the top of the page. If you wanna click on that and get more information about the circle, we’d love to have you join us.

Natalie Garza: Yes. So with that, we’re going to end this episode of the AAArdvark Accessibility Podcast. Go check out the AAArdvark Circle and WCAG in Plain English, and we will talk to y’all next time.