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. 

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. 

Intro: Accessibility Meets SEO

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. 

Intro: Accessibility Meets 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. 

Alt Text and Non-Text Content

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. 

Keep It Simple: Reading Level

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. 

Page Titles Matter

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.

Descriptive Links

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. 

Headings and Labels

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. 

Text Alternatives for Media

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.

Search Engines vs. Assistive Tech

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!

Multiple Ways to Navigate

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.

Breadcrumbs and Location

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.

Semantic HTML

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

tags, they all communicate what type of content is included inside that tag. 

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.

Mobile-Friendly Design and Reflow

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.

Shareable, Accessible Content

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.

Improving Accessibility to Boost SEO

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. 

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.

Why Keyboard Accessibility Matters

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. 

Ensuring Keyboard Accessibility on Your Website

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.

Testing and Best Practices for Keyboard Navigation

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: 

1. You should be able to get to all the important components like buttons, links, and forms. 
2. You can’t get trapped once you go down a certain path on the page, and 
3. you can see where the focus is.

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.

Visual Feedback and Focus Styles

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.

Resources and Tools for Keyboard Accessibility

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. 

Social Media Without Barriers

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. 

Emojis in Social Media Posts

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.

Links vs Shortened Links for Accessibility 

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.

Making Images Accessible

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.

Text Accessibility Tips

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?

Video and Audio Accessibility for Social Media

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.)

Wrap-Up & Your Free Website Accessibility Check

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. 

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!

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. 

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. 

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. 

Natalie Garza: Hello everybody and welcome to the AAArdvark Accessibility Podcast. 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. And in this episode, we’re going to cover the upcoming European Accessibility Act, or EAA.

Natalie MacLees: Yes. 

Natalie Garza: We will start with a disclaimer. We are not lawyers, but we will try our best to explain it and go over why it matters, what it is, who needs to comply, and what does it actually involve. 

So to start off the episode, why does the European Accessibility Act matter right now?

Natalie MacLees: So the day that this podcast comes out, the second part of the act will actually go into effect. So June 28th, 2025. Any new products, websites, or services have to be compliant with the law. If you already have an existing website, product or service, you have until June 28th, 2030 to make it compliant.

But if you’re doing any major updates, redesigns, et cetera, that’s gonna trigger the law and you’re gonna have to make sure that that is accessible.

Natalie Garza: Yeah. As far as June 28th, 2025, any new products hitting the market have to comply.

Natalie MacLees: That date or after have to comply.

Natalie Garza: So super relevant, especially if you’re watching the episode on the day that it comes out and you’re in the European Union.

Natalie MacLees: Or you do business in the European Union, we’ll get to it.

Natalie Garza: Yes. We’ll get to that here in a second. So why does the EAA matter in general? 

Natalie MacLees: You are going to start facing legal penalties for having kiosks, digital devices, websites, web apps, et cetera, that are not accessible. So there will be legal consequences to having those on the market. 

And of course, those are in addition to all the consequences you already have for having something in the market that’s not accessible, which is that you’re damaging your brand trust and your brand.

You’re losing out on some competitive advantages and you’re not respecting everybody’s civil and human rights and not being inclusive.

Natalie Garza: Yes, ’cause everyone has a right to information online.

Natalie MacLees: Yes, they do.

Natalie Garza: So, what is the European Accessibility Act specifically? What is it, what does it cover?

Natalie MacLees: Yeah, so it covers any kind of digital products or services, so mobile phones, gaming consoles, kiosks like where you check in at the airport or at a hotel. Also, any kind of web apps or web services, websites, et cetera. All of those kinds of things are covered, and they all need to be made accessible.

Natalie Garza: And every single European country has their own rules

Natalie MacLees: Yes, yes. The specifics of what that means differs from country to country, so we won’t be digging into that today. But if you are dealing with a specific country, you need to look up and see how the EAA got implemented in that country.

Natalie Garza: Yeah, the EAA is mainly just like a blanket enforcing every country to set something up.

Natalie MacLees: Yes, exactly.

Natalie Garza: Alright. Who needs to comply? So we know about all the digital products that need to comply, but you’re saying everybody who works in the EU or works with the EU.

Natalie MacLees: Yeah, so if your product or your website or your web application, whatever it happens to be, is available in the EU for purchase, you have to comply, whether your company is based in the EU or not. So if you have a SaaS application that has EU customers, if you sell mobile phones and people in the EU buy them.

They’re available for purchase there, gaming consoles, et cetera. Anything that can be purchased in the EU, this law applies to it. Whether or not the company that makes that product is in the EU or not.

Natalie Garza: How are they enforcing it for companies outside of the EU?

Natalie MacLees: So, for companies outside of the EU, they can actually take your product off the market. So if you have, for example, like a mobile phone app that isn’t accessible, it could be removed from the store where that’s available for people to purchase. We don’t anticipate at this time that they’re going to take websites or web applications.

They’re not gonna block them or otherwise make them unavailable in the EU as far as we know. But it is always a possibility. And if it’s a physical device, you may not just be allowed to sell it at all in the EU. 

Natalie Garza: Okay. Gotcha. So it’s pretty, um, how do you say?

Natalie MacLees: Serious.

Natalie Garza: It’s pretty serious.

Natalie MacLees: They’re serious! Yeah. They mean it.

Natalie Garza: All right, so what does compliance actually involve?

Natalie MacLees: Yeah, so the EAA is kind of unique for an accessibility law. Most of the other accessibility laws that we’ve seen passed around the world have specifically referenced a compliance criterion. So that could be Section 508 here in the United States. It could be EN 301 549 in the EU, and it could otherwise be WCAG.

Usually 2.1 or 2.2 AA. Sometimes still 2.0 AA or another similar standard. The EAA actually doesn’t specify a standard, so some individual countries may, but the EAA does not. 

You are free to choose which set of standards you want to follow, but you do have to choose one, and it does have to be reasonably recognized internationally. 

And where EAA gets even more tricky is that following that, you could get, you know what we would call a perfect score on WCAG, but as we have discussed in other episodes, WCAG is just a baseline. It’s not like 100% accessibility. 

You have to go beyond that standar, and you have to show that you are making a good faith effort to address any accessibility issues that are brought to your attention by the consumers who are using your product. You have to do testing with people with disabilities, people who are using assistive technology, et cetera, and you have to document all of your efforts that you are making toward making your website, your web application, your device, whatever it happens to be.

You have to document all of those efforts that you’re making toward improving the accessibility and show that you’re making continuous improvement. And you have to publish an accessibility statement that shows publicly everything that you’re trying, the problems you’re still aware of, that you’re still working on, and what you plan to do about them.

Natalie Garza: Does that include having an accessibility statement on your website?

Natalie MacLees: Yes. Yes. You’re gonna be required to have a public accessibility statement on your website or, if you have a physical device, maybe it would be in the packaging with it or on the website or both.

Natalie Garza: Okay. Can we go back to what you said about there being no official standard?

Natalie MacLees: Yeah. Yeah.

Natalie Garza: Could somebody say, “Okay, well, I’m going to follow WCAG single A as my standard for my site,” and that would be perfectly acceptable?

Natalie MacLees: I would be surprised if most countries would find that adequate because even AA is still falls short for a lot of people. So I would be surprised if somebody thought that A was, an acceptable standard. It would definitely be a good starting point, right? Because meeting A is better than not doing anything.

So that would be an okay starting point maybe for people who are just getting started, but you do still have to be showing that continuous improvement and that you’re doing testing. That you’re continuing to work on this, so you would end up having to go beyond that at some point, even if that’s what you chose as your initial starting point.

Natalie Garza: Okay. I have another question.

Natalie MacLees: Okay.

Natalie Garza: For usability testing, are they going to have any programs in place to help connect people to, people with disabilities?

Natalie MacLees: Yeah, so there’s already some companies that exist that do that. And I know we have an earlier podcast episode on doing user testing with people with disabilities, so you could refer back to that episode if you want some information about those. 

I have also personally spoken to a few more nonprofits that are getting started to do just that, that are going to start connecting people with disabilities with jobs, doing user testing that they’re gonna provide to these companies who need to be doing that testing now.

Natalie Garza: And for companies who have to test, they have to pay out of their pocket, or is it something that the governments are helping pay for?

Natalie MacLees: They’re gonna have to pay for that out of their own pocket as far as I know, there may be some kind of like a tax write off or some sort of like, grant or benefit that maybe you could apply for, but that’s something that you should definitely look into if you need some financial help in meeting this law.

Natalie Garza: Okay. And then for documenting efforts, is it far as just like the accessibility statement, but if somebody from the government comes and says, “Hey, we actually want more details,” then you’ll be legally required to do that.

Natalie MacLees: Yeah. If they think that the accessibility statement you put together doesn’t give enough information, yeah, they could definitely come and demand that you make that more robust and fill it in with more details about exactly what you’re doing and when. 

Natalie Garza: Mm-hmm. So that is the European Accessibility Act. In summary, if you guys need more information. You can go to our website. We’ve put together a very thorough blog post as well as a nice little page that goes over this law in a little bit more detail. 

As far as websites go, though, where can website owners go to make their sites more accessible?

Natalie MacLees: Yeah, we’ll come on over to AAArdvark. AAArdvarkAccessibility.com. You can, for free, run a scan of your homepage, get an idea of what the state of accessibility is on there, and we’ve got tools to help you go through the manual testing as well as the automated testing and tools to help you keep track of that history.

So you’ll have that audit trail available if you need it to show what you’ve been working on, what you fixed, et cetera.

Natalie Garza: Yeah, we have a quite a few neat little features like the issue count over time. The PDF reports that you can export and show the improvements over time on your website.

Natalie MacLees: Yeah.

Natalie Garza: And we also have a few other free resources like WCAG in Plain English if you’ve been to the WCAG website and you don’t understand what’s going on, you should go check out WCAG in Plain English. It’s on our website and it goes over every single success criteria in plain language. And wanna talk about the live streams that you do, Natalie?

Natalie MacLees: Yeah, every other Wednesday afternoon local time here in Los Angeles, I do a live stream on YouTube and LinkedIn that walks you through one or two aspects of doing accessibility testing. So we do all different kinds of topics, and our next one will be on testing using the screen reader, NVDA.

Natalie Garza: Yes, that will be out next week.

Natalie MacLees: Next week!

Natalie Garza: Go check out our YouTube channel and our LinkedIn page for all the live streams and any new updates on next podcast episodes. And so with that, thank you guys for joining us. That was episode 26 of the AAArdvark Accessibility Podcast. We’ll talk to y’all next time.

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

Natalie MacLees: Natalie MacLees.

Natalie Garza: And she is an accessibility expert here to answer all of our questions. And in this episode, we’re gonna talk about quick wins for websites in terms of accessibility. So, what do we mean when we say quick wins?

Natalie MacLees: Yeah, so things that you could fix probably in just a few minutes, or things that you could at least test for very quickly and easily without having to have any kind of special equipment or special software packages or anything like that installed.

Natalie Garza: Yeah. And I would even add that quick wins also include, you don’t have to be a developer. You could do this if you’re pretty new to working with websites or new to accessibility.

Natalie MacLees: Yeah, so our list is based on the WCAG Easy Checks, which are specifically designed for non-developers. Don’t have to be technical. You don’t need any special equipment or any special software. Anybody could check these things and most people could fix most of them.

Natalie Garza: Yes, so to get started, let’s kick off the list with page titles.

Natalie MacLees: All right, so the page title is what shows up on your tab of your browser when you have a page open, and otherwise, you don’t really see it much. But it is the first thing announced to a screen reader user when they land on a page. So it is important that the page title be an accurate description of what the page is about.

So that if somebody lands there, they can immediately understand what this page is all about? And why would, why am I here?

Natalie Garza: Yeah, and they have to be unique, because if they go between pages and they’re the exact same, it’s super confusing.

Natalie MacLees: That’s a very good point. Yes. You want to be able to tell one page from another, just from the page titles.

Natalie Garza: All right, next on the list, image text alternatives.

Natalie MacLees: Yeah, so this is a huge topic. We could probably do a whole episode just on this, but basically, you wanna make sure that you have alternative texts for all of your images. That gives somebody the reason why the image is on the page, and if there’s any information conveyed by that image, to also convey that information.

So your alt text for the exact same image might be different on different pages, just depending on the context that the image gets used in. And generally, you wanna avoid saying things like photo of or image of, because we already know it’s an image or a photo, and you wanna keep your description short and concise. And so cut out all of that filler stuff.

Natalie Garza: And also, don’t worry, not every image needs alt text, especially if it’s purely, purely decorative.

Natalie MacLees: Yeah, if you just have some pretty curly cues or something like that, it should actually not have alt text. It should have an alt attribute that’s just empty, and then that’s the signal to assistive technology that that image is just decorative. It is not conveying any kind of information, and it doesn’t need to be described.

Natalie Garza: Next on the list, headings.

Natalie MacLees: Yeah, so sometimes people think all headings do is make text big and bold, and by default, it does do that. If you use a heading tag, it does make the text large and bold, but it actually gives meaning to that text, and it actually tells assistive technology, it tells search engines, it tells any other kind of robot that might be scanning your page that this is a heading for the content that follows. 

Like this line of text describes the section of content that follows this. And then also the headings are at different levels, right? All the way from H1 to H6, and those should be nested correctly. So, one H1 on the page to describe what the page is about.

The sections of the page should each have an H2. And if you have subsections inside of those sections, those should be in H3 and so on. They should just be used in order.

Natalie Garza: Yeah. They’re meant to structure the page. 

Natalie MacLees: Yeah. If you remember creating an outline for a paper in like sixth grade, how you learn to make an outline, they’re basically the outline of your page.

Natalie Garza: Yeah. So, having useful headings is really important.

Natalie MacLees: Yes, they should be accurate. They should describe the content that they’re heading up. 

Natalie Garza: All right, next on the list, contrast ratio.

Natalie MacLees: Yeah, so this is just making sure that we don’t have pale gray text with a white or pale gray background with white text on it, or vice versa. There should be lots of contrast between the background and foreground. So that it’s really easy to read and understand the content that’s there. We don’t have to squint at it.

If we’re outside on a bright, sunny day, we can still see it. So just making sure that there’s plenty of contrast, right? We have a white background with dark text or a dark background with white text and things like that. 

Lots of contrast between the background and foreground, and be especially careful of that if you’re using images or gradients or something like that in the background. Keeping in mind that on a responsive design, that’s gonna be shifting around on different screen sizes, that that text could be over any part of that image.

So you have to check all different screen sizes to make sure that there’s enough contrast, whether you’re on a little mobile screen or on a big desktop screen, or anywhere in between.

Natalie Garza: Next is resizing text.

Natalie MacLees: Yeah, so there are lots of users who will zoom in on web content for different reasons. Mostly to make it easier to see, make it bigger, if you forgot your reading glasses that day, you can also, of course, pinch a zoom right on most touchscreen mobile devices. And this is just to make sure that you can go up to 200%, so double the size of your text, and it’s still all going to be readable.

You’re not gonna end up with things overlapping. You’re not gonna end up with things running off the side of the screen where we can’t see them, and other kinds of problems like that. So you do wanna make sure that you can zoom into 200% and you can still see all of the content. You can click all the buttons, click all the links, get to all the content that’s on the page.

Natalie Garza: All right. Next up on the list is keyboard access.

Natalie MacLees: Yeah. So we’ve talked about this, I think just in the last episode, right? We talked about how there are all different kinds of assistive technology that people can use if they can’t use a traditional mouse or keyboard for whatever reason, and that, as far as the computer is concerned, those are all keyboards.

And we also have people who have vision disabilities who can’t use a mouse, right? ’cause they can’t see where the cursor is on the screen. So they’re gonna rely on using a keyboard. So there’s a very large population that relies on the keyboard alone to navigate through websites and to accomplish tasks online.

So you always wanna make sure that every button can be clicked, every link can be clicked. That any kind of interactive element, like going through the slides of a slider or opening and closing an accordion can all be done with just the keyboard and without having to use a mouse.

Natalie Garza: Next on the list are forms, labels, and errors.

Natalie MacLees: Yeah, so don’t be using only placeholders on your forms. You wanna make sure that you have a label that is always visible. The problem with the placeholder is as soon as you type one character in that field, the label disappears. 

And if you get interrupted and you have to come back, you forget, “What was the label? What was I filling in?” So we wanna make sure of that, and then of course, make sure that we can fill in those forms with just the keyboard and not have to touch our mouse to fill in a form.

Natalie Garza: Hmm. Yeah, because even the labels are super important for screen readers.

Natalie MacLees: They’re super important for screen readers. They’re super important for people with cognitive disabilities, and they’re super important for anybody who gets distracted in the middle of doing tasks, which I can’t think of anybody who doesn’t happen to. 

Natalie Garza: Yeah, and then having enough instructions, and if there’s a mistake, tell people how to fix them. 

Natalie MacLees: Yes, I’m sure we’ve all had that experience of, “there was an error on this form.” What was it? How do I fix it? How do I keep going? I’m looking at you, IRS. Alright.

Natalie Garza: Next on the list, moving, flashing, or blinking.

Natalie MacLees: Yeah, so if you have animation or a video that plays automatically or something that flashes, you wanna make sure that there is a way to pause or stop that or hide it. Preferably, you just wouldn’t have anything like that happening automatically anyway. Like a user would have to click a play button or opt into that in some kind of way.

But if you have something that does offer some kind of value or explanation that you do feel is necessary, you do still have to provide a way for a user to pause it or stop it.

Natalie Garza: Yeah. This one in particular can be really dangerous. 

Natalie MacLees: It could be. You could actually cause physical injury to somebody by having animations or flashing that can’t be stopped. Yeah.

Natalie Garza: Yeah. Next on the list is multimedia, like videos and audio.

Natalie MacLees: Yeah. So, like we said, you don’t wanna autoplay anything, and if you have to, you have to provide a way to pause it. But then, you should be able to work with that media with a keyboard. So you shouldn’t have to use a mouse to click the play button, the pause button, or adjust the volume. You should be able to do all of those things with the keyboard.

And then of course, you also wanna make sure that you have either captions or transcripts or both. for any kind of multimedia that are on the page for people who can’t either see or can’t hear, what you’re sharing. So you wanna have an alternate way to get that same information.

Natalie Garza: Because not everyone can hear. Not everyone can see. 

Natalie MacLees: Exactly.

Natalie Garza: So that is the end of our quick checklist. Each one of these can be fixed within a either one minute to a few minutes. 

If you wanna go beyond the quick wins, though, where can you get started? 

Natalie MacLees: Yeah, you can come over to AAArdvarkAccessibility.com. Add your homepage for free. Run a scan and find all of the issues that can be found by an automated scanner. You could also learn how to do manual testing and find some more issues on your website, and learn how to fix them.

Natalie Garza: And if you wanna see this quick checklist in action, where can you go check it out?

Natalie MacLees: Yeah. I do a live stream every other Wednesday, and I have gone through the WCAG quick checklist, showing you how to do it a few times on those live streams. You could find those on the AAArdvark page on LinkedIn, or they are on our live tab on our YouTube channel.

Natalie Garza: Yes. Every other Wednesday, Natalie is working away, showing everybody how to do this. It’s really, really awesome. Go check it out. 

And with that, thank you for joining us. We’ll talk to y’all next time. 

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 24. My name is Natalie Garza, and with me today is,

Natalie MacLees: Natalie MacLees 

Natalie Garza: And she is an accessibility expert here to answer all our questions in digital accessibility. In this episode, we’re gonna talk about all the different types of disabilities that can impact your use of the web, and it’s not just blind people. So, to get started, why does everyone just think digital accessibility affects blind people?

Natalie MacLees: I am not really sure exactly where that comes from, but you will have a lot of developers, I think, in particular for some reason, who think that making a website or web application accessible just means making it work with screen readers. So it’s not even just users who are blind, but actually specifically screen reader users.

Right. So I’m not exactly sure where that, where that idea comes from, but you do hear it a lot. And then you hear a lot of accessibility professionals say it’s not just screen readers.

Natalie Garza: All right, so we’re going to break down the different disability types or groups, starting with the first category of disabilities. Do you wanna talk about that one?

Natalie MacLees: A permanent disability. So a disability that once it is acquired, will have for the rest of your life. There are many, many different types of these disabilities. 

Of course, the first up would be some kind of vision impairment. Which could include being completely blind, but could also include being just low vision. So somebody who has some vision, but not, you know, obviously not 2020 vision, which is a lot of, a lot of people. ‘Cause everybody who wears glasses or contact lenses, right? But there’s a spectrum. There’s a spectrum of, maybe you just need to wear glasses to read. Right, would be kind of at one end, and then all the way at the other end would be you have very little vision in your eyes, and maybe can only distinguish general shapes or lightness from darkness. And anywhere in between. 

And then we also have other types of disabilities that affect vision, like color blindness. There are many, many different types of colorblindness. The most common one being just red-green colorblindness. So people who cannot distinguish, red colors from green colors. But there are many other types including complete colorblindness where people, just see the world in black and white and cannot perceive color at all. 

Sometimes, your vision can disappear from the middle outward, and sometimes from outward in, or sometimes you lose your front vision, but still have peripheral vision, or the other way around. There are all kinds of interesting things that can happen to eyes.

Natalie Garza: Yeah. So, what do we have to keep in mind for people with vision impairment?

Natalie MacLees: Sure. There’s a few different things. For colorblindness, you just wanna make sure that all of your colors have sufficient contrast, that they can be distinguished from one another, that you’re not relying on color alone to communicate information. That you would also wanna have text or icons or something like that, that would communicate that. 

For people with low vision, they are going to tend to use a screen magnifier, which is just going to blow up the text on their screen, if it’s 12 pixel or 16 pixel text on a website. They will blow that up until it is the size of, you know, two or 300 pixel typeface to be able to read it and distinguish the letters. Then, they may also use screen readers. Which are just going to read aloud all of the content that’s on the site. So you wanna make sure that everything has accessible names and that everything is labeled correctly. And then also we could have refreshable braille displays in here, but all the same things that make a website work well with a screen reader also help to make it work well with a refreshable braille display.

Natalie Garza: Yeah, so it’s not just blind people, even within the vision impairment group, there’s so much variety.

Natalie MacLees: Yeah. And it turns out that, like when we think of people who are blind, we think of complete blindness, right? Like, no vision at all. And it turns out that’s actually pretty rare. But the group of people who are what we would call legally blind. It’s much bigger. And those people do have some vision, and like I, we already discussed, it’s on a spectrum, but that’s much more common to have at least a little bit of vision. 

Natalie Garza: Do you wanna move on to the next group of disabilities?

Natalie MacLees: Sure, so we covered eyes and now we’ll go to ears. So, being deaf or hard of hearing for a lot of websites that doesn’t have a lot of impact, but if a website includes multimedia or audio, then obviously that is going to impact anyone who isn’t able to hear those things. Or if you have an app that relies on notification sounds or something like that. Obviously, somebody who cannot hear will not be able to hear those things. 

So you wanna make sure that you have captions or transcripts for any audio or video. And whenever possible, if you can provide sign language interpretation as well, that’s always appreciated and very helpful. A lot of people who are deaf learn sign language as their first language, and it has its own vocabulary and grammar, and is very different from spoken language. And so learning to read written language, right? Whatever language, wherever people happen to live, whatever language that is, it’s a very different language. 

And so sometimes there can be a little bit of issues with processing written language, just because somebody’s first language was sign language. And so it’s just like anybody else learning a second language, it’s a lot more challenging and harder to process and harder to pick up on nuances and turns of phrase and things like that. So, wherever you can, provide sign language interpretation for that.

Natalie Garza: And even people who are hard of hearing. They have not lost all of their hearing. They can probably struggle with background sounds on videos and stuff like that.

Natalie MacLees: Yes, yes. It can be a real struggle, if you are hard of hearing to hear voices, if you’re out in a loud restaurant, trying to have a conversation with friends, but watching a video on the web can be really difficult if there’s background music playing or background noise of some kind happening on the video.

Natalie Garza: And there are auditory processing disorders, too, where you can hear everything. You just can’t process it.

Natalie MacLees: Yeah, yeah, that’s true. You can have, you know, some kind of a physical problem with your ear, but then there can also be a problem with just communication between your ear and your brain, so there can be some kind of issue there as well where maybe sign language or being able to read captions or transcripts or things like that could be extra helpful.

Natalie Garza: Mm-hmm. Do you wanna move on to the next group of disabilities?

Natalie MacLees: Sure. Next, we have cognitive disabilities, and this is a huge group, including many, many different types of disabilities. That can be traumatic brain injuries, there can be memory challenges, ADHD, learning disabilities, dyslexia, and more and more and more. It’s a huge, huge category that impacts a lot of different people. 

And generally, you just wanna make sure that your website is really clear and direct and easy to use and understand, that your layouts are clear. It’s not all cluttery. It’s easy to figure out where to go. It’s easy to figure out where you are, so if you think about like those little breadcrumbs along the top of websites, those are really helpful, right?

For figuring out like, “wait, where am I?” And then to figure out, “oh, I’m in this section on this page”. So just things like that are really helpful for that group. And the nice thing about all of those things is they’re really nice for everybody because we’re all busy and distracted and doing 10 other things when we’re using the web.

So all of those things that you would do to help somebody with cognitive disabilities are really gonna make your website a lot more useful for literally everyone.

Natalie Garza: So not just cognitive disabilities can benefit, everybody can benefit.

Natalie MacLees: Yes, everyone can benefit from those things. And then we’ll move along to our next group, which is the physical or motor disabilities. Now obviously, if somebody is a wheelchair user and has mobility issues with their legs, that’s not gonna really impact their use of the web because we mostly use our eyes, our ears, our hands, and our fingers for accessing the web.

But, for somebody who does have some kind of disability that impacts their fine motor control or impacts their ability to move or use their hands, it will definitely impact their use of the web. And there are a million different assistive technology devices that can help in that situation. Basically, if there is some part of your body, even if it is just your eyes, that you can control the movement of, there is an assistive technology that will help you use the web. So if you can move one thumb, if you can move your eyes, you can use eye tracking. If you can move your cheek. If you remember, Stephen Hawking could move his cheek and had a device that attached here (to his glasses) that he could kind of twitch the muscles there to navigate around on a computer. There are so many different things that can be used.

There are foot pedals, and there are sip and puff devices. All the different ways that you can still use the web. The thing that you wanna make sure of when you’re coding a website is to make sure that it works with a keyboard only, and you might say, “You didn’t even mention keyboards just now”, but all of those devices, all of those assistive technology devices that help somebody as far as the computer is concerned, those are all keyboards. 

And so as long as a keyboard can navigate around a site, then all of these other types of devices will be able to get around the site as well. So put your mouse away. Make sure you can use everything on your website with just the keyboard.

Natalie Garza: They’re all basically receiving the same signals, right? Like next, select.

Natalie MacLees: Yeah. So just like hitting a tab key or a shift tab key, or the space bar, or the enter key. Yes, it all works the exact same way as just using a keyboard, so that’s the best thing that you can do to make sure that you’re accommodating people with motor and fine motor control.

Natalie Garza: Yes. And then the last disability group is the seizure disorders.

Natalie MacLees: Yes. So people might have, you know, epilepsy, or they might have different types of vestibular disorders, migraines, or different conditions that get triggered by a lot of light or motion or flashing. And so you wanna be very mindful that you don’t have an animation running right next to the login box where people are trying to type in their username and password, and there’s this motion happening that can’t be stopped or disabled. You wanna be really mindful of that. 

And then anytime that you have animation or motion, it should hopefully respect the prefers reduced motion setting in the browser and not have that motion if somebody has that turned on. It should be able to be paused, ’cause not all users know about that setting, but might prefer that everything can be paused. And you would wanna make sure that you don’t have any flashing kinds of animations that could trigger somebody to have a seizure or to become dizzy or faint or anything like that. You could really cause some physical harm to somebody by not being thoughtful about how you implement those kinds of things.

Natalie Garza: I feel like with the rest of the disabilities, it’s more about inclusion and just like making sure they can access information. But seizure disorders could be dangerous for some people.

Natalie MacLees: Yeah, it could be really dangerous. Yeah. Or you can make somebody sick to their stomach. That’s another thing that can happen.

Natalie Garza: Yeah, not pretty.

Natalie MacLees: Not, not pretty, not nice. Not a good experience.

Natalie Garza: All right. So those are the permanent disabilities, right?

Natalie MacLees: Yeah.

Natalie Garza: We have two other categories that we can review. Would you like to start with the next one? 

Natalie MacLees: So, in addition to those kinds of permanent disabilities, it’s also important to remember that we have temporary disabilities, which are just illness or injury, and we also have situational disability, which is just the situation that you happen to be in at the time.

That can also impact your use of the web. So if you break your arm or if you’re outside on a bright, sunny day, different things like that are temporary or situational. That can also be helped by making sure that your website is accessible. And just making sure that you’re able to access information as expected, even when you have a broken arm or you’re in a noisy room,]

Natalie Garza: Yeah, all in all, we have the permanent disabilities that we covered in depth. We have the temporary disabilities and we have the situational disabilities. It’s not just blind people, you guys, digital accessibility helps everybody. And if you want to make your website accessible, what can you do?

Natalie MacLees: Yeah, come on over to AAArdvarkAccessibility.com. You can scan your homepage for free and find out all of the issues and how to fix them.

Natalie Garza: All right. So with that, thank you guys for joining us. That was episode 24 of the AAArdvark Accessibility Podcast. We will talk to y’all next time.

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility podcast. My name 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 an accessibility expert here to bring awareness on this very special episode. What are we celebrating today, Natalie?

Natalie MacLees: Global Accessibility Awareness Day.

Natalie Garza: Yes, it is a special holiday that the accessibility community brought together, that we do every single year, and this year it happens to fall on May 15th, 2025.

Natalie MacLees: Yes. The third Thursday of May. 

Natalie Garza: Yes. Do you wanna talk about how it was founded, who founded it, and what year it was founded? 

Natalie MacLees: Yeah. Yeah. So, it all started with a blog post from Joe Devon proposing the idea that we needed an accessibility awareness day to help raise awareness for digital accessibility. He tweeted about it, and another accessibility professional named Jennison Asuncion, saw that tweet and said, “Yep, we need this,  I’m on board.” And they co-founded Global Accessibility Awareness Day together.

Natalie Garza: Yeah, a new holiday. I don’t know if it’s fair to say it’s a holiday, but I will say it’s a holiday.

Natalie MacLees: Yeah. Yeah. A celebrated day, an observed day.

Natalie Garza: Observational day! What is the whole point of Global Accessibility Awareness Day, if the title doesn’t already explain?

Natalie MacLees: Yeah, in case it wasn’t already self-explanatory. We wanna get everybody thinking about digital accessibility. So, people who don’t know anything about it, we wanna try to get the word out to them, get everybody talking about it, thinking about it, learning about it, and committing to making anything that they make online a little bit more accessible.

Natalie Garza: Yeah. So spreading awareness to turn into action. Hopefully.

Natalie MacLees: Yes. Most people know. They will hopefully understand the importance of digital accessibility and want to take steps. To make their online presence more accessible.

Natalie Garza: Yeah, because I think the problem is not that people don’t wanna be accessible or that they don’t think it’s important, I think they’re just not aware. It’s just not common knowledge. 

Natalie MacLees: Yeah. You find that a lot. I think, you know, we’ve talked about how accessibility isn’t included in a lot of web development education or web design education. It’s just not included, which kind of silently communicates this idea that it’s not actually that important. And then also for people who are less technical but are in charge of websites, so business owners, marketing teams, et cetera, are in charge of websites, but maybe not super technical, and they may have absolutely no idea that this is something that they even need to be thinking about or planning for, or making changes to how they’re accomplishing things.

Natalie Garza: Mm-hmm. Yeah, so digital accessibility, not everyone is on the same page, so that’s why we have this celebratory observational day.

Natalie MacLees: Yes, we try to get the word out and reach out to people who may not get the word otherwise. And how people usually celebrate Global Accessibility Awareness Day is by hosting a bunch of free events. So if you, well, you could go to the official website and there is just all kinds of workshops and webinars and in-person events and online events, all with the purpose of learning a little bit more about digital accessibility.

And typicall, those are all free, just in observance of the holiday.

Natalie Garza: Yeah. And podcasts. So we’re gonna do our, we’re gonna do our part in spreading awareness. So Natalie, to kick us off, what is digital accessibility?

Natalie MacLees: Yeah, so, digital accessibility is making sure that anything that you have put online, social media posts, your website, et cetera, that that is accessible to everybody so that they’re able to use that regardless of their capacity and regardless of what technology or assistive technology they might be using to access the web.

We do have a kind of discouraging statistic from WebAIM, which is Web Accessibility In Mind. They do an annual study, they automatically scan the top 1 million homepages on the internet, and report back on their findings. And so from the most recent round of WebAIM Million, we know that 98% of those top 1 million homepages have at least one detectable accessibility failure on them.

You know, which is almost all of them, and that number has improved only a tiny bit from when they did the first one a few years ago.

Natalie Garza: And when you say detectable, you mean by automated scanning?

Natalie MacLees: Exactly, yes. They are not manually testing a million pages because that would take a very long time. They’re just running their automated checker on those. Yes. So it’s the types of issues that can be detected by an automated checker.

Natalie Garza: Which means that it’s likely a hundred percent of those homepages have an issue whether manual or automated on them.

Natalie MacLees: It is likely just because it’s very difficult to make something quote unquote “perfectly accessible,” that doesn’t really exist. Um, So there’s always gonna be some kind of barrier. But, that’s not an excuse to not do anything that we can to reduce the number of barriers and to reduce the severity of the barriers that we have.

Natalie Garza: Yeah, cause’ believe it or not, one fourth of the population has some form of a disability.

Natalie MacLees: Yeah, and I think that might even be a little bit low, ’cause one thing that we often, when we say “one in four people has a disability,” in our minds, we think permanent disability. Right, which are the ones that once you’ve acquired that disability, you’re gonna have it for the rest of your life. But we also have temporary disabilities.

Like every single one of us is constantly moving in and out of a state of being temporarily disabled by an illness or by an injury, right? Nobody lives their whole life without ever getting sick or hurt. And depending on how severe that injury is. It could affect your work in different ways. If you work on a computer all the time, a pretty minor injury to your dominant hand, wrist, or arm could be really impactful upon your workday, and you might not be able to use a mouse for a certain period of time.

So that’s another thing to keep in mind. And then we also have situational disabilities where it has nothing to do with your own personal body or mind, but the situation that you happen to be in, which can also impact how you use the web. If you’re trying to watch a video in a really noisy room, or you’re trying to look at the screen of your phone outside on a really bright, sunny day, it’s really difficult to see.

And that would just be a situational disability. So when you take into account all of those things. It’s not one in four people. It’s literally everyone.

Natalie Garza: And it’s not just blind people either. A lot of people just think, “oh, if you can’t see the screen,” but it’s also if you have a mobility impairment, if you can’t hear something. If you have seizures from flashing elements.

Natalie MacLees: I remember that you were surprised to learn how many different disabilities could impact someone’s use of digital products.

Natalie Garza: Yeah, and we’re gonna cover that in an episode soon. So stay tuned.

Natalie MacLees: Okay. That was a sneak peek.

Natalie Garza: Yeah, so digital accessibility. Make sure everybody, no matter their situation, their abilities can access and read web content. So, what can we do to start making the web a better place?

Natalie MacLees: We can start learning some basics about web accessibility and start making changes to what we’re doing. You could learn about how you can make your social media posts more accessible. You could learn how to make your own website more accessible. If you post videos online like we do here, or audio. If you have a podcast, you could learn how you can make that more accessible and then start taking steps to implement those things.

Natalie Garza: Yes, because even if it’s just a small thing like a social media post, it could mean a lot to one person who just wants to learn or see what’s there, or just wants to use social media like everyone else.

Natalie MacLees: Yeah, I, people have a civil right to equal access to information and services, and so we need to be respectful of that and ensure that everybody can access the information and services that are available online.

Natalie Garza: Yes. So with that, Natalie, where can people go to learn about accessibility or get started?

Natalie MacLees: Well, you can come over to AAArdvarkAccessibility.com. It is free to sign up for a workspace and get an automated scan of your homepage, and it will explain to you any of the issues that were found and tell you how you can go about getting those fixed.

Natalie Garza: Yes, and if you wanna start learning about the different guidelines and the different official documentation, but find it a little confusing. We also have a new resource called WCAG in Plain English, which is a collection of all the Web Content Accessibility Guidelines. Is that the acronym? 

Natalie MacLees: Yes, that’s the acronym. Good job.

Natalie Garza: But rewritten in plain language so that everyone can understand.

Natalie MacLees: Yeah, great. For beginners to kind of just get a grasp for what is this accessibility thing all about and what kinds of things do I need to be doing? 

Natalie Garza: Even if you just wanna scroll through it and see what’s there and understand the different aspects of making content accessible, it’s pretty helpful. So go check ’em out. 

And with that, this is episode 23, our Special Global Accessibility Awareness Day podcast. Thank you guys for joining us, and with that, we’ll talk to y’all next time.

Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 22, and my name 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 an accessibility expert here to answer our questions. And in this episode we’re gonna talk about WCAG 3.0.

Natalie MacLees: WCAG 3.0. We did our best.

Natalie Garza: We did our best to research and investigate. So we’re gonna share our notes with you guys and our thoughts. But, to start off, Natalie, do you wanna give us a quick history on WCAG’s versions?

Natalie MacLees: Yeah, sure. So early on, people figured out that we needed guidelines to figure out how to make the web accessible. So WCAG 1.0 was released in 1999 to kind of help address that. It was pretty simple. It was just 14 guidelines, and they had a priority one, two, or three, which kind of roughly became A, AA, and AAA, when 2.0 came out in 2008. 

And that’s where we got the structure we know now, where we have the POUR principles. Perceivable, Operable, Understandable, Robust, with the success criteria and the guidelines underneath those four principles. The web moved along, new technology came out, and people started buying smartphones left and right. They realized there was some things that didn’t get addressed in 2.0.

So we got 2.1, which came out in 2018, which added some more rules around mobile devices and also added some more rules for people with cognitive disabilities and, low vision. Again, the web moved along new technologies and we got WCAG 2.2 pretty recently in October of 2023, which added even more guidelines for people with cognitive disabilities and also with motor impairments.

So just addressing some things that got left out and addressing some new technologies and things as the web moved along.

Natalie Garza: So do you want to give us a quick introduction to WCAG 3.0.

Natalie MacLees: Yeah, so when we WCAG 1.0, it was really focused on HTML, ’cause CSS and JavaScript were so new at the time, like nobody was really thinking about them. And when we had 2.0, that’s when they really started thinking about, “Oh, there’s CSS and JavaScript.” And of course, we see a lot of the techniques and things.

We’ll reference scripting and CSS. But the web has really kind of moved on. We have really robust, rich applications that can take the place of desktop applications, which we take for granted now, and we forget how revolutionary those were. And 2.0 doesn’t really do a super great job at addressing that.

So 3.0 is coming along to help and better address, you know, mobile applications and these rich kind of very interactive applications that we build on the web now.

Natalie Garza: Yeah. And, before we start talking about 3.0, it’s nowhere near finished.

Natalie MacLees: They have the skeleton there and now they just have to fill all the information in. Yeah.

Natalie Garza: Mm-hmm. Yeah. If you try to click through, you’ll find it’s pretty empty. There’s not much to reference.

Natalie MacLees: Yeah, and you definitely couldn’t implement it yet. At this point, there is not enough guidance there to figure out like, how would I meet this rule that’s being added?

Natalie Garza: and it’s not going to replace 2.0, 2.1, or 2.2 anytime soon.

Natalie MacLees: Yeah, so that’s always been the case, like a new WCAG version never replaces what came before. We kind of just move along and adopt the new one when it comes time. I did see a timeline somewhere that said they expect to have the timeline of when they will finish 3.0 in September of this year, so September of 2025.

We can expect them to give us finally a date for when they expect 3.0 to be done.

Natalie Garza: So, do you wanna go over the new structure in 3.0?

Natalie MacLees: Yeah, we can do our best to dive into it. We might get something wrong, but just let us know.

Natalie Garza:  So in WCAG 3.0, they actually changed the structure of all the content, right? So before it was structured in Principle, followed by Guidelines, followed by Success Criteria. Whereas now they’re doing Guidelines as a topmost level, followed by Requirements.

Natalie MacLees: Yes. And then requirements have methods.

Natalie Garza: Yes. And there’s different types of requirements.

Natalie MacLees: There are, which the methods are similar to the techniques we have now. They’re kinda like, how to do this. And we do have different types of techniques now, right? We have the Advisory techniques and the, the other one…

Natalie Garza: Sufficient.

Natalie MacLees: sufficient. Yes. So we have that now. We have Sufficient Techniques and we have Advisory Techniques.

So this is similar ’cause we have Foundational Requirements and we have Supplemental Requirements. And then there are methods under each of those.

Natalie Garza: And in addition, we have Assertions that sit next to the Requirements.

Natalie MacLees: Yes. Yes. We also have Assertions, and I’ll be honest, I don’t quite, I haven’t quite wrapped my head around the Assertions.

Natalie Garza: And they’re supposed to be Informative, so there’s just supposed to be like extra little tidbits.

Natalie MacLees: The Assertions are Normative. But then the how-to documents under the Assertions are Informative.

Natalie Garza: Yeah, there’s, they did a weird thing where they completely threw out all the vocabulary everyone’s already familiar with and has worked with for 20 years, WCAG 2.2, and they’re trying to introduce brand new vocabulary. And names for all these things.

Natalie MacLees: Except confusingly kept Guidelines, but made them mean something different. Slightly different, I guess. Yeah. And they have really focused on breaking out the parts of the spec that are Normative and the parts of the spec that are Informative. So Normative are the things that you would use to test against, to determine is this passing or failing, and Informative are like the techniques that you would use to actually accomplish something.

Natalie Garza: Mm-hmm. Yeah, and I’m trying to think of stuff on those WCAG 2.2 articles that are more informative, like the equivalent of the informative text.

Natalie MacLees: I think the techniques would be the informative part of 2.2, right? Like, how to actually accomplish this. But the Success Criteria in itself is Normative, so that’s what tells you what you’re gonna test against. And then the techniques are the things that are Informative that tell you how to pass that test.

Natalie Garza: Okay. I see what you mean.

Natalie MacLees: Yeah, they’re not as like clearly divided in WCAG 2.0, 2.1, 2.2, but in 3.0, they’re really focused on separating those, Normative and Informative parts of the standard out.

Natalie Garza: Yes. Do you wanna cover or go over the comparison that we have based off what’s already written in 3.0?

Natalie MacLees: Yeah, let’s go ahead and do that.

Natalie Garza: So in 3.0, the one that’s most filled in so far is one called Image Alternatives. And I don’t know if it’s gonna be 2.1.1 or if it’s gonna be 1.1, but the closest success criteria we have right now is 1.1.1 Non-text Content. And I think the theme that we’re seeing in 3.0 is that they’re being a lot more specific on elements, whereas 2.2 can be really broad in a lot of cases.

Especially in 1.1.1, where it says like literally anything that’s not text, we’re gonna check on this one.

Natalie MacLees: Yes. Anything that’s not text falls under 1.1.1. Yeah.

Natalie Garza: And I would say that in the 3.0 documentation, I do like this new approach where they’re kind of trying to guide you through like a conditional statement, it’s: Is this decorative? No. Click here. If yes, continue. 

If this image is available to assistive technology, yes. Click this link here. If not, continue. 

So like, I like that approach. Comparing it to the Success Criteria we have right now, where they give you 30 links, click one of these if you think it applies to you.

Natalie MacLees: Yeah. You do have to do a lot of work in 2.2 to figure out which of the Sufficient and Advisory techniques apply to your situation. And sometimes they spell that out a little bit, but often they don’t. 

So it’s kind of up to you, and it looks like in 3.0 they’re making that a lot more obvious. Like, here’s how you’ll deal with different situations, and there’s some very specific prescriptions for what you need to do if you’re handling those different situations.

Natalie Garza: Yeah, I can see there’s an effort to try to guide people to the right page and the right place, and to the right methods, but this language is still so, so stiff.

It’s still really hard to read.

Natalie MacLees: And very technical at this point still. Yes. So hopefully that, will get adjusted as they go along. And just like with WCAG 2.0, there’s the separate Understanding documents, which are meant to be like a more accessible version of the guideline. And I would imagine that we’ll see the same thing with 3.0, that there will be a separate set of documents meant to be your introduction to this specific guideline or method.

Natalie Garza: Mm-hmm. Yeah. But just as an example, I’d like to read an excerpt from WCAG 3.0 Image Alternatives.

Natalie MacLees: Sure.

Natalie Garza: Under foundational requirements, step two says, 

“Is the image presented in a way that is available to user agents and assistive technology?

Yes, image must meet Image is programmatically determinable AND the accessibility support set incorporates Equivalent text alternative is available for image that conveys content. Stop.”

Natalie MacLees: Very technical.

Natalie Garza: I don’t know what I just read.

Natalie MacLees: Yeah, that, that is definitely language that is meant for a developer who is writing a very technical test, right? So very Normative, like a requirement here that’s explaining exactly how this content is going to meet a test. 

 So I think that more beginner-level information will hopefully come later.

Natalie Garza: Yeah. So to summarize, WCAG 3.0 is still a working draft. Very, very early stages. Changes the structure completely, changes all the vocabulary that we’ve come to know and understand. It’s not supposed to replace 2.0 and maybe around 5% done.

Natalie MacLees: Yeah, that’s probably fair, and we can keep an eye out for later this fall when we find out when they actually expect 3.0 to be ready.

Natalie Garza: Mm-hmm. That’s right. Yes. So, with all that said, where can people start to learn more about accessibility and what guidelines we have now?

Natalie MacLees: Yeah, so I don’t have a place for you to go to learn about 3.0 in an easy way, just yet. But if you wanna learn about 2.0, 2.1 or 2.2 and figure out if your own website is accessible, you can come on over to AAArdvarkAccessibility.com scan your homepage, we’ll show you, where the errors that are automatically detectable are, and guide you through how to fix those.

Natalie Garza: Mm-hmm. Yes. And if you have any confusion as you review the official documentation. Go check out WCAGinPlainEnglish.com where we’ve rewritten every single success criteria in plain language.

Natalie MacLees: Yes, made it easy to understand for beginners.

Natalie Garza: Yes. So with all that said, thank you guys for joining us. This has been episode 22, we will talk to y’all next time.

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

Natalie MacLees: Natalie MacLees, another co-host.

Natalie Garza: and she is actually an accessibility expert here to answer all our burning questions. In this episode, we’re gonna talk about advice and how to start a career in digital accessibility. But before we dive into that, do you wanna make it clear the difference between digital accessibility and physical accessibility jobs?

Natalie MacLees: Yeah, so we’re gonna talk about only digital accessibility today, but of course, there are lots of ways to work in accessibility, and a lot of people will have jobs working in the physical world. So helping to make buildings accessible, museums accessible, art exhibits, all, different kinds of things where people need to go and be in a physical space, you know, concert venues, things like that.

So there is a lot of work to do in the world of accessibility that is not necessarily online and what we’re gonna talk about today, because what, what I specialize in, what I do for a living is digital accessibility and very specifically web accessibility. 

And even within the digital accessibility space, there’s a lot of different things that that can mean because there’s mobile devices and mobile apps and websites and all different kinds of things like that. Accessible documents, et cetera. So we’re gonna mostly focus on web accessibility today.

Natalie Garza: Yeah, and not even to count like the digital accessibility jobs with just like assistive technology devices or tools.

Natalie MacLees: Yeah, I recently met somebody at an event who had had a job at one point, at a university where it was their job to go around and install assistive technology for the students who needed it, whether that was software or hardware. That was that was their job. They just went around and installed refreshable braille displays and screen reader software and those kinds of things, to support the students at the university.

Natalie Garza: Right. Yeah. So all kinds of digital accessibility jobs and just a small subset of the whole accessibility space.

Natalie MacLees: Yeah.

Natalie Garza: What is it like to work in digital accessibility?

Natalie MacLees: It can look like a whole bunch of different things. There’s not, it’s not a single kind of monolithic field where everybody’s job looks the same. 

So that could look like a lot of different things. You could be a developer who’s building websites. You could be a designer who’s designing websites, applications, or user experience. You could be an auditor or a tester who’s testing websites, mobile apps, or any other kind of product for accessibility. You could be a consultant who’s advising people on how to be accessible or how to make their products more accessible. 

So there are lots and lots of different things that a career in digital accessibility could look like. There’s lots of different ways to be working at that.

Natalie Garza: From small jobs as a freelancer to working with huge corporations, websites, assistive technology, and assistive tool companies.

This question comes up when people are talking about digital accessibility. What if you can’t find an entry level accessibility job, digital accessibility job?

Natalie MacLees: Yeah, digital accessibility is a really weird field because nobody goes to university and gets a degree in digital accessibility. As far as I’m aware, that’s not an option anywhere, and the only time that you would really get any kind of training in it formally is if you purposely seek that out. 

It’s not, you know, it’s not gonna be a degree type certification. It’s gonna be maybe a certificate or just a course that you take and you don’t get any kind of certification. So it’s not like you’re gonna go to college and major in digital accessibility and then go get your digital accessibility internship and kind of work into the field.

That’s just not the way that it works. I actually put a question on LinkedIn this week to ask people like, what is your accessibility origin story? Because we didn’t all come into the field that way. And to figure out, like, how did you even find out, number one, that this field existed, and then number two, like how did you figure out you wanted to be involved?

And the answers were all over the place. You know, sometimes people had become disabled themselves. And that made them very interested in the field. Sometimes it was a close friend or family member or just an experience that they had, you know, in a school or at summer camp or something like that, where somebody near them was, was disabled and needed some help, or needed assistance being able to communicate or access resources or things like that.

And it’s kind of one of those things that you just fall into. And so it’s really hard to say. Well, how do you go? How do you go and get started? Because when you talk to the people who are in digital accessibility. Their stories are all different. There’s not one path. There’s no front door, basically.

There’s no front door that’s like, “Enter here. This is how you get in.” There’s just a whole bunch of side doors. And how are you gonna figure out your way in? 

Maybe you’re a developer. And so that’s a good way you can figure out how do I start building things to be accessible and how do I start, you know, advocating to my teammates and being the one on the team who’s saying, “Oh, hold on. We need to make this accessible” and communicating to my management, et cetera. 

That like this is something I’m interested in and which is generally how I got into the field, right? As I was a developer, I was building websites and then I learned that I needed to make them accessible and then I just carried that experience with me through my career where I spent most of my career so far as a web developer, right?

Building things and trying to make them accessible, and then trying to communicate to my coworkers and colleagues and managers that this is something that was important and we need to be doing it. So that’s definitely one way in. 

If you’re a designer, you could do a similar thing and “wow, I need to figure out how to design things that are accessible.”And take the initiative to go and figure out some training and learn as much as you can about it, and figure out how to do it. 

And then again the the whole field of digital accessibility is a whole lot of convincing other people that it’s worth doing. And it can be a very frustrating field in that sense because you are constantly trying to convince everybody else that the field should even exist.

So you do wanna be prepared for that. People do get burned out of having to constantly justify the work and constantly justify, their, you know, why this job exists or why this is an important thing to do. Because it does take extra time and it does cost extra money. So I think be prepared for that.

If that’s a, you know, if you’re interested in a career in digital accessibility, you are going to just constantly be winning people over to your side and fighting the good fight, trying to prove that it is a worthwhile investment in how to do things.

Natalie Garza: So I have two notes. One, I don’t think they’re side doors. I think there’s windows you have to crawl in through the windows. And two, it almost feels like digital accessibility is like a language, right? 

Like if you’re applying for a job, you’re going to say like, “Oh, I speak English, Spanish. I also am fluent in digital accessibility.” But you’re not like going to search for like an English job. You’re not searching for a Spanish job. It’s just like an extra language or extra layer that you can add to whatever work that you do.

Natalie MacLees: In a lot of cases. Yeah. And once you have a, like a certain level of knowledge and a certain level of experience in making things accessible, there are jobs where people are just accessibility consultants or accessibility leads or in a role where they are guiding accessibility adoption in an organization and ensuring that any websites or digital products or anything that a company puts out are accessible. 

Those jobs do exist, but those are all pretty high-level jobs for people who’ve been working in digital accessibility for years, probably, and like getting into there, right through these, I we could say side doors or side windows.

I hope they’re at least ground-floor windows, to come in. But yeah. The, there is so much to know about digital accessibility, and it’s shifting and changing all the time. As new technology comes out, as new devices come out, as new browsers come out, that advice is shifting constantly. 

And also, as people change, like the population changes and what we all do collectively as a group of people, like what we’re interested in changes over time as well. And so sometimes something that was, you know, a best practice recommendation 10 years ago, it’s not anymore because people have changed their behavior or they’ve changed their expectations of how something would work.

So that’s another piece of advice if you love learning constantly and being proven wrong, almost every day, digital accessibility is a great field.

Natalie Garza: Yeah, because there, there’s a lot of gray areas, like we’ve said before.

Natalie MacLees: Yeah, and it’s a lot of balancing priorities, right? Needs of different groups are different and sometimes conflicting. And so trying to figure out what’s the best way forward for the most number of people is sometimes really challenging. 

Natalie Garza: Should somebody get certified in digital accessibility?

Natalie MacLees: It is definitely a thing you can do. So you know the, we’ve talked previously about certification, and there’s the Trusted Tester, which anybody can go do. Anybody can go log on to the DHS website, which is the Department of Homeland Security in the United States, and work through that course and try to get that certification.

It is very challenging, I will warn you. The IAAP has actually kind of gated their, certifications. So it used to be that anybody could go get them, but now you have to have, I think it’s three years of experience in web accessibility before you can even take their certification exams. So that’s not a way into the field really.

It’s something that you would do to further reinforce and kind of prove that you’ve gained this expertise and knowledge by working in the field for a few years already. So you could definitely get them if you want them. Because it can be helpful and you could refer back to that episode for everything we had to say about it, but it’s not gonna be a way to get your foot in the door.

Natalie Garza: Yeah, and should people invest in accessibility courses?

Natalie MacLees: Yeah, I think those are definitely worth doing, and there are just dozens or maybe even hundreds of them that are available online. And there are, of course, sometimes in-person courses through different universities of learning extensions and things like that as well, or conferences. 

But yes, I would absolutely invest in one to get started and then continue taking them because you’re always learning, you’re never gonna stop learning. So take one now, take one tomorrow, take one the day after, and take one next year. Just keep going. 

And you can always ask around and get, you know, recommendations for some really good ones. Google actually has a pretty decent one that’s free, that hasn’t been updated in a couple of years now, but it’s still a good introduction, and it’s oriented for developers. 

So if that’s what you do and you’re interested, you could take that one. And Sara Soueidan has a really good intro to accessibility course that’s not free, but completely worth the price. And there are many, many others as well.

Natalie Garza: If you’re starting a career in digital accessibility, there are a lot of different ways to get into it, but it’s gonna be an ongoing learning experience.

Natalie MacLees: You will never stop learning.

Natalie Garza: Yeah. So with that, Natalie, where can people get started? Where can they start to dig in?

Natalie MacLees: Yeah. So come on over to AAArdvarkAccessibility.com. You can put on your homepage, get that scanned for free, get back some issues. We’ll describe to you what they are, how to fix them, why they’re important, and that’s how you could get started fixing your own homepage.

Natalie Garza: Yes. And if you have tried reviewing the WCAG articles and you’re confused, please go check out our new resource called WCAG in Plain English so you can learn more and dive into digital accessibility requirements for websites. And, with that, we are going to end the episode. This is episode 21 of the AAArdvark Accessibility Podcast. We will talk to y’all next time. Thanks for joining us. 

The project aims to make WCAG requirements more understandable and accessible to everyone, with clear language, illustrations, and a redesigned organization.

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. My name is Natalie Garz, and I’m the co-host. And with me today is,

Natalie MacLees: Natalie MacLees, your cohost.

Natalie Garza: And she is an accessibility expert. And in today’s episode, we’re going to go over this long-time project that we’ve been working on, and we’re ready to announce, launch, and share with everybody. What is it, Natalie? What are we, what are we launching today?

Natalie MacLees: We are launching WCAG in Plain English, a collection of dozens of articles that we have translated from the official WCAG guidelines into easy-to-understand language.

Natalie Garza: Mm-hmm. Yes, because if anyone has ever visited the WCAG website and WCAG articles, what is the problem?

Natalie MacLees: Oh, they’re so hard to understand. They’re very dense. They’re very technical. They also have some bad advice in them. 

Funnily enough, I think because some of the techniques have been around for, you know, a decade or more, some of the advice is actually not very good. For example, telling you that you can use a title attribute on an image instead of alt text. Which we know doesn’t actually work. 

So we took out the ones that we know don’t work. And you did some wonderful illustrations. Do you wanna talk about those?

Natalie Garza: Yes, so every single article was handwritten. We read through all the understanding docs. We went through every single technique page. 

If you’re familiar with the WCAG articles, there’s first off a large page explaining what it is. Like who it applies to. Some examples. It links out to resources, and then it links out to techniques, which are their own separate pages showing you how to implement or how to fix that issue. And any given article, like 1.1.1 has like 30 technique pages that you would have to go visit separately, read through, see if it applies to you, and then come back, just keep going back and forth and back and forth. 

So we went through the trouble of going through all of those for you and translating them into plain language. And on top of that, where it would be helpful, we did illustrations to show you, at a glance, you can see like, “Oh, that’s what the solution would be like, “Oh, like that’s what a caption is. Or like, oh, that’s what it means with contrast.” So we rewrote them. We boiled down the techniques so that you don’t have to go clicking around page to page, to page to page, with clear illustrations. 

And then Natalie, do you wanna talk about the organization of our new resource?

Natalie MacLees: Yeah, so we used all the different ways that WCAG itself organizes them. So you can browse by what level, whether it’s A, AA, or AAA, you can browse by Principle or Guideline, which are the main ways that WCAG is organized, and also by version. So if you’re only interested in WCAG 2.1 or 2.2, for example, you can see just those guidelines.

And then we have some additional taxonomies that are not part of WCAG, which are Themes, which will help you see things related to Gestures or Keyboard, or Wording. And we have Responsibility. So who on the team is most likely to be responsible for that one? Is it code? Is it content? Is it design? And then we also have the Disabilities that are impacted most by that guideline.

Natalie Garza: Mm-hmm. Yeah. So it’s all neatly organized, all contained in one single place. All the articles are easier to read now. And that’s what we’re launching.

Natalie MacLees: With a very clear, very, um, minimalist design that’s easy to deal with. It looks a lot nicer than the official WCAG guidelines.

Natalie Garza: That’s actually a good point. Yes, ’cause if you compare the two, one is like old Yahoo browser from like 2001, and the other one is clear, clean, very similar to our AAArdvark app style and design, which is very minimalistic.

Natalie MacLees: Yes. Very calm, very soothing.

Natalie Garza: Not 10,000 buttons on one page.

Natalie MacLees: Not not cognitive overload. Exactly.

Natalie Garza: No. So aside from WCAG also just being way too technical and way too over complicated. Another reason why we made it is because we wanted to link from the AAArdvark platform. To these guides directly. Do you wanna talk about that?

Natalie MacLees: Yeah, so when you’re looking at individual issues in AAArdvark, you’ve run a scan of AAArdvark on your page, and it finds an issue. Um, we were previously linking to the official WCAG documentation, as here’s some more information on this issue. And we know that not everybody who’s using our platform is tech-savvy, right?

They’re not coders or senior-level developers, which is sometimes what you need to understand some of those WCAG articles. So, now we’re gonna link out to these easy articles. Inside of AAArdvark itself, we do have a nice, short description that attempts to explain, in one paragraph, what the issue is and how to fix it.

But now if you need more information, you’re gonna link to these really friendly articles that will really explain it in depth and in an easy to understand way, explain to you what you need to do to fix the problem.

Natalie Garza: Yeah, cause AAArdvark is not just for accessibility testers, it’s for the whole team, right? So you could have a designer working inside of AAArdvark if they don’t understand this technical stuff. They’re gonna be stuck. What are we, what? How do I fix it? 

Natalie MacLees: Yeah. They’re gonna be stuck. I’ve had that experience in the past where I had told a designer, “Oh, you know, the thing you designed, it doesn’t meet this guideline. Here’s the guideline. You know, here’s the link so you can understand it.” 

And the designer went and looked at the page and then came back to me and was like, “Yeah, I read that. I still don’t, I still don’t know what it is. What do I need to do?” 

So our article should be more helpful. You can send them to the content editor, you can send them to the marketing person, you can send them to the designer, and they’ll be able to understand what it’s all about and why it’s important.

Natalie Garza: Mm-hmm. Yeah. I really like our articles because there’s an explicit section that says, how do I implement this criterion? And most everyone can just skip to that part and get it over with.

Natalie MacLees: Yeah. I like that they each say why they’re important, and help you understand why this is something that I need to do? 

Because I think that’s a piece that’s missing a lot of times for people who don’t really understand. Why is this so important anyway? Um, and once they understand why it’s important, they’re more on board with, “oh yeah, absolutely. This is something we should do.”

Natalie Garza: All right. So, how we made these, we’ve already said, we hand-wrote every single article, but we’ve also pulled from the accessibility community and used a lot of their resources and their help that they’ve published themselves. They’ve also generously shared with everybody else.

Natalie MacLees: Yeah, everybody in the accessibility community is very cooperative and collaborative and always shares resources. You know, people don’t tend to come up with a resource and then kind of keep it to themselves. 

So we built on a lot of the work that other people did, especially when it came to how we organize these articles and make them so they’re easier to find, right? Because just like I think anybody else, we found, the way that WCAG organizes them is not easy to understand or straightforward. 

So some of the people that we use, I’m sorry for the pronunciation, if we get them wrong. So I’m gonna guess it’s Johannes Lehner who created the “WCAG 2.2 Card Deck”, which, if you work in accessibility, you have probably come across this resource.

It’s been around for a couple of years now, and it is fantastic. So they’re basically flashcards of the WCAG guidelines. And they use some different taxonomies on them, right? There are little icons on them to tell you which disabilities it affects and which themes it’s in. And so those are what we used for WCAG in Plain English.

And those themes actually came from another resource, which is Andrew Hick, who created the “WCAG Map”. If you haven’t seen it, it looks like a subway map. And it kind of visually lays out how all of the different WCAG guidelines are related to one another, in a way that is really helpful for understanding what they’re all about.

Of course, we drew on the WCAG documentation itself from the WAI or the Web Accessibility Initiative. 

And then we wanted to have just a short sentence on each success criteria to just give you, a quick overview. This is what this page is about. And those we drew from Martin Underhill’s project called “WCAG, But In Language I Can Understand.”

So very similar name to ours. But those are basically, for the most part, one-sentence summaries of each of the guidelines. And he had a few places where it was more than a sentence, and we edited those to make it one sentence. But otherwise, we pretty much used those as is. And then we have some organizations that have resources available.

The University of Melbourne, I’m American, so I don’t say Melbourne. So “Accessibility Responsibilities by Project Role”. 

The Appt Foundation has “Accessibility Handbook” and IBM’s “Accessibility Requirements”. 

So, thank you to all of those people and organizations for making those resources available for us to use.

They were very helpful in helping us think about how to taxonomize and organize our articles to make them easy to find so that people can access them and really benefit from the content that we hand-wrote.

Natalie Garza: Yes. So a lot, a lot of work went into this. You guys, I’m telling you, we have spent three years finally putting this out so that everyone can actually use it and benefit from it. So, where can people go see this, Natalie? 

Natalie MacLees: Yeah, so we have a shortcut URL set up, so just WCAGinPlainEnglish.com. You can go there. 

You can also find it by coming to our website AAArdvarkaccessibility.com. And if you use our platform and scan your website, you’ll get links out to individual articles that relate to your particular issues.

It is all licensed under a Creative Commons license. So if you wanna take it and do something even more fantastic with it, you are welcome to use it however you see fit.

Natalie Garza: That’s right. It’s a free resource that is completely open to anyone who wants to go and check it out. You don’t have to sign up for any of our platform. You don’t have to sign up using your email. You just go check it out. Please go see it.

Natalie MacLees: Please go see our hundreds of hours of work.

Natalie Garza: So right now, just as a disclaimer, we have only released Level A and Level AA Articles, and Level AAA Articles are slowly but surely coming out each week.

Natalie MacLees: Yes. So we’ll have all of those published very soon, within the next couple of months.

Natalie Garza: mm-hmm. Yeah, we were just ready to come out of the shadows.

Natalie MacLees: We were. 

Natalie Garza: So everybody go check it out. We hope you guys like it. We’ve spent a lot of time, a lot of effort, and spent a lot of tears. Just kidding. Not tears. Maybe sweat. No, not sweat. But we’re really happy, we’re ecstatic. 

We’re in a party mood!

Natalie MacLees: In a party mood.

Natalie Garza: So with that, we’re gonna end our episode. Thank you for joining us. This is the 20th episode, a very special one for us, of the AAArdvark Accessibility Podcast. Thank you for joining us, and we will talk to y’all next time. 

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

Natalie MacLees: Natalie MacLees, accessibility expert.

Natalie Garza: And in today’s episode, she’s going to teach us all about user testing, specifically with people with disabilities. So, to get started, what is user testing in general?

Natalie MacLees: Yeah, so when you’re building a product or a website, you can do testing with real users, and that can look like a few different things that we’ll talk about today. But basically, you sit down real users in front of your product.

And have them try it out. And it is one of the most maddening and frustrating things you will ever do because no matter how carefully you have designed something and you think it’s so beautiful, users will not be able to figure out how to do anything and it will drive you up the wall.

But basically, you sit them down and give them a task and say, you know, “Hey, find information about elephants on this website,” or “put a product in a cart and check out.” You give them a task like that to complete, and then you kind of observe as they go through that task. You see where they run into problems, where they run into issues, and where they get confused, and you keep track of how long it takes ’em to complete the task.

Natalie Garza: Yeah. As frustrating as it can be, it’s probably one of the most valuable things you can do.

Natalie MacLees: Absolutely, you can learn so, so much about your product and you could, you could spend hours looking at a screen of your app, for example, and in two or three user tests get way more information on what should be changed and how it should look, by watching some real users attempt to use it.

Natalie Garza: Yeah, it’s a real eye-opener, ’cause you realize not everyone treats technology the same as you.

Natalie MacLees: And not everybody is super tech savvy, you will have situations where you have a giant flashing red button in the middle of the screen that says, “click here,” and users will go,” I don’t, I don’t see where to click. I don’t.”

And it’s really hard to not just do it for them. 

Natalie Garza: Yeah, you, you can’t help ’em if they’re just staring blankly. You just have to let them.

Natalie MacLees: Yeah. You can kind of step in and kind of gently nudge them if they start to get really frustrated. But yeah, you should generally try not to participate too much.

Natalie Garza: Yeah, and I would say user testing usually is targeted towards like the audience of the product that you’re working on, like if it’s a business product, you’re gonna get the business people to come test it. Or if it’s for non-tech-savvy people, you’re gonna get non-tech-savvy users.

Natalie MacLees: Yeah, exactly. So you wanna figure out who your user base is, and then that’s who you wanna recruit to come in and do the user test.

Natalie Garza: But often disabled users get overlooked, so why should we test with disabled people as well?

Natalie MacLees: Because they are going to be using different assistive technology or just different features of the devices that they happen to be using, and will uncover barriers and issues that users who do not rely on assistive technology or assistive features of products, things that those users won’t find.

So you could uncover issues where you know a button can’t receive keyboard focus. And in a user testing with users that don’t have disabilities, you might never discover that issue. But if you have users come in who rely on keyboard or users come in who use screen readers, they will identify that issue immediately and find it for you.

Natalie Garza: Yeah. What if you are working on a product and you’re like, “okay, well I have an accessibility auditor gonna come check this product,” why should you still test with disabled people? 

Natalie MacLees: Yeah, the auditor is probably gonna do a pretty good job, but most of the time they’re probably not a full-time assistive technology user. And even if they are, they are probably a full-time assistive technology user of one type of assistive technology. And of course there’s all different kinds. You know, people with disabilities are not a monolith.

So there’s not just like, “oh, here we just had one, one user with some kind of disability, come in and use this. So we’re covered now.” There’s so many different ways that people adapt devices and adapt websites, and adapt products to be useful to them, and you need to cover as many different ways as you can.

Natalie Garza: Yeah, we did have another episode where we talked about all the assistive devices and all the assistive tools, too. So if you wanna check it out, put a link up here somewhere or link in the show notes. All right, so how do we find people to test with disabilities?

Natalie MacLees: Yeah, so if you are doing recruiting for user testing, you do maybe wanna ask about that and have that in your recruiting questionnaire, to figure out if this is somebody who uses some kind of assistive technology or assistive features. And you would wanna make sure that you’re including some users from that group in the testing.

If you’re having trouble, there are organizations that you can actually work with who will help you, recruit users, with disabilities for your test. I have personally worked with the World Institute on Disability, which I think is up in San Francisco. But we’ve done everything remotely, so I’m not sure.

But they have been fantastic and they actually can help, recruit the users and run the tests, and they have, I think they have gone to doing it remote now, but prior to the pandemic, of course they had an in-person lab that people would come in and they would have, you know, they’d have each user come in and they would do four or five tests for different clients on the same day.

And they would get paid. Users get paid for doing user testing, and they would record the session and you could watch it live or you could watch the recording later. And then they, give you a report at the end with the findings from the report. There are other organizations as well that can help you out with it.

Fable, who has a website at “Make It Fable”. If you’re in Australia, there’s a company called Intopia. In the UK, a company called Nomensa. And then we also have UsableNet and AbilityNet, which can also help out with this area.

Natalie Garza: Okay. And do they help guide you towards, like, the type of users you need to be in contact with?

Natalie MacLees: Yeah, so they’ll ask you about it. And then, when I’ve worked with the World Institute on Disability, I would always do a phone call with them, and we would talk about what the project was, who I expected the users to be. I know one time I hired them, and it was a website for teenage girls. So, you know, they talk about that kind of thing because they’re gonna try to recruit people from that audience.

Right. If I’ve built a website for teenage girls having, you know, middle-aged men come in and test it is not gonna be the most useful. So we wanna have people who are as close to that demographic as we can. And then we would talk about what are the features on the website and what are the things that we’re concerned about doing?

And they would make some recommendations to me, let’s say like, “oh, we should test two screen reader users and we should test one person who uses a braille display and we should test one person who uses this.” And, they would help me get that all sorted out. And how many testers that we needed to use.

 And they also helped to figure out what the tasks were that we should assign to the testers. So they were very helpful, to help with all of that. And for all of that service, it was very reasonably priced.

Natalie Garza: Okay. And then you said, they give you back a report.

Natalie MacLees: Mm-hmm.

Natalie Garza: Does it have like, “oh, you broke this WCAG success criterion”, or is it more just like I?

Natalie MacLees: It was the same kind of report you would get from any kind of usability testing, which was this user, you know, we gave each user five tasks to do. And we tested 10 users, and they’ll say, okay, eight users were able to complete task number one. And it took them an average of this many minutes.

This many users could complete task number two, and it took them this number of minutes and then they would give you, the places where people got stuck like, “oh the, you know, people couldn’t complete task one ’cause they couldn’t put a product in the cart and these were the issues that they ran into.”

And they would give you that kind of report back of like, here’s the issues they ran into when they couldn’t complete it. And even when they could complete it, maybe they ran into something that they had to figure out how to work around, and so that’s the kind of information they would give you back in the report.

It would not be like an audit where they were telling you like, “oh, you failed 1.4.3.” It was all very focused on the users and the tasks that they were doing, whether or not they could be successful, and whether or not they ran into problems.

Natalie Garza: Okay. And it had the added layer of like, okay, they used keyboard only

Natalie MacLees: Yeah. Yeah.

Natalie Garza: Okay.

Natalie MacLees: And it would inevitably, you would get back feedback that would say something like, “oh, the screen reader users loved this feature, but this other user hated it and couldn’t find their way around it, and it blocked them,” which is one of, you know, we’ve talked about that. 

It’s one of the frustrating things about accessibility, because people with disability are not all the same, right? It’s a group of people with so many different needs and adaptations and, so many different ways to approach things that there’s no, there’s often not like a single solution that’s gonna work for everybody. 

And so you just have to figure out how to be flexible and find what is gonna work for most people.

Natalie Garza: And then you said you said that most of it is online now.

Natalie MacLees: Yeah, so usability testing, I think that this is true not just of testing with people with disabilities, but I think it’s also true just in general with user testing in the world. I think we had to, we just have a lot less of people coming into a lab, to do user testing. There might be a little bit of less data as a result of that because in a lab, you know, they have an eye tracker and there are multiple cameras from all different angles tracking everything somebody is doing.

But it’s also like a very, uncomfortable environment, right? You can imagine that if you were sitting at this like teched out desk and you’re in a room by yourself and there’s a one way mirror, right? Where who knows, you don’t know how many people are sitting back there watching you try to use this website.

And then there’s cameras everywhere, every which way, recording everything you’re doing and your eye movements are being tracked and all of those kinds of things. So how realistic that is because that is not how people use things, right? People don’t sit in isolation in a room with no interruptions to use, to use web applications.

That’s just not, that’s not how it happens. So a lot of it has gone to being online with, you know, like, we’re recording this podcast right now online. We’re not in this; we’re not in a room together. 

But you can get somebody on like a Zoom session and, you know, walk them through and watch them try to use a product, share their screen with you, and watch them try to get through some tasks in your app.

Natalie Garza: Yeah, in that way, it kind of made it more accessible for everyone to participate. You don’t have to live in San Francisco.

Natalie MacLees: Yeah. Yeah, exactly. You don’t have to live in a certain place. You don’t have to travel to a place. You don’t have to sit in that sterile room, be watched while you try to do something. You can be at home, on your own computer, at your own desk, right, and be a lot more comfortable. Which is better for everybody, I think more convenient for everybody.

Natalie Garza: So going back to them guiding you, like if you go through one of these agencies or one of these, what organizations, going to help you pick out the devices or is that something you have to come in and say like, “I want, I really wanna test screen readers. I really wanna test Braille device.”

Natalie MacLees: So that’s what they’ll help, that’s what they’ll help you pick out. And if you do have something like that in mind, like you’re like, “well, I’m just really curious how somebody using a Refreshable braille display would use my app.” Definitely let them know, because they can help you recruit a user with that.

But generally, generally I would say approach it, with an open mind and let them suggest to you kind of, you know, let them ask you a few questions about your application, what it’s for, who’s using it, and let them suggest to you who maybe you should test with.

Natalie Garza: Alrighty, well thank you so much for going over user testing with user’s with disabilities. So, to wrap up, where can people get started with digital accessibility?

Natalie MacLees: Yeah, well come on over to aaardvarkaccessibility.com. You can test your homepage for free, find out what issues it might have, and get suggestions for how you can fix them.

Natalie Garza: Yes. And so with that, thank you for watching. This is the 19th episode of the AAArdvark Accessibility Podcast. We will talk to you guys next time. 

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

Natalie MacLees: Natalie MacLees 

Natalie Garza: and she’s an accessibility expert here to teach us new things about digital accessibility. So, in this episode, we wanted to start the conversation. Not fully go through the whole topic because it’s just so expansive; we wanted to start talking about tools to help with accessibility testing, starting with browser extensions.

Natalie MacLees: Yes, browser extensions, which I think is where a lot of people get started. I think a lot of people, a browser extension is their first experience with scanning a webpage for issues and finding out about accessibility testing.

Natalie Garza: Yeah. And again, disclaimer: there’s a lot of ways, a lot of methods, a lot of tools to help you with accessibility testing. We’re just gonna start cracking the surface here. Natalie, what should we expect from a browser extension, and what’s out there right now?

Natalie MacLees: Yeah, so browser extension, you’ll install it in your browser and they, they have accessibility extensions for Chrome, for Firefox, for Edge. So it doesn’t matter which browser you’re using; you install it, and then usually there’s a little button that you click somewhere in the extension to say, scan this page.

And it’ll go through the page and find any of the issues that can be identified by an automated checker, which is, it depends on who you talk to, but somewhere between 20 and 30% of the different types of accessibility issues that can be found on a page can be found by a checker. And then, it will show you some kind of interface to show you what those errors are so that you can figure out what’s going on in your site and have an idea of how to get it fixed.

Natalie Garza: Yeah, and I also feel like there’s another category of browser extensions where it helps you flag stuff down.

Natalie MacLees: Yeah. That’ll help you turn on different things make information that’s normally invisible on the website visible, so it makes testing easier because you can see something that you wouldn’t normally be able to see.

Natalie Garza: Right. It’s kind of like an x-ray.

Natalie MacLees: Like an X-ray. Sure. An MRI. It’s a CAT scan.

Natalie Garza: Yeah. But without the dangers of radiation poisoning.

Natalie MacLees: No radiation involved. Well, no, that’s not probably not true. I’m sure that all of our devices are emitting radiation at us all the time.

Natalie Garza: True, true, true. EMF. Anyway, do you wanna go over some popular browser extensions and what they do?

Natalie MacLees: Sure. Yeah, so if you’ve watched any of our live streams where I go through accessibility testing live, you’ve probably seen me use the Web Developer extension. It has a very generic name, just Web Developer, and it’s icon is a little purple cog, and it provides, I would say, probably about 50 different tools for doing different things on a website.

And it is not specifically an accessibility focused plugin it’s a web development focused plugin. But it does do some things that are really handy for accessibility testing. So, for example, you can have it make an outline of your document where it will pull out all of the headings and then it will show you the levels.

So you have a heading level one that says this, and then a heading level two that says this, et cetera. And it makes it really easy to check, “Did I remember to have an H1 on the page?” ’cause that’s the best practice. And then, “Did I use all of my headings in the right order, and is everything that should be a heading actually marked up as a heading?” Et cetera. So it makes that kind of thing really easy. It’ll let you identify images that don’t have any alt text on them. And it has a few other really handy features as well.

Natalie Garza: Yeah, and that’s an example of an x-ray extension.

Natalie MacLees: Yeah. It just gives you a lot of insight into your page that it’s hard to get otherwise.

Natalie Garza: All right, so that’s an example of an x-ray one. Web Developer. And again, we’re gonna leave links to all of these in the show notes or in the transcript. Or if you check out our blog, you can find the entire transcript to this whole episode, where you can find links too. So next category is what we first talked about: the scanning browser extensions.

You wanna go into those?

Natalie MacLees: Yeah, so probably the one that I think most people have probably heard of or dealt with is the aXe, which is A X E, and usually it’s small letter A, capital X, small letter E for some reason. And that is made by Deque, the company, like a pretty well known accessibility company. It does have a kind of unusual for a browser extension.

It has a free and a paid version. So you can access the free version and use that just, you know like you would any other browser extension. And if you want the more robust features, you do have to pay for that plugin. But it’s really well-researched. Deque does a lot of work in the accessibility space, and they flag not just actual WCAG failures, but can also find best practices, which is something that’s really helpful and not all plugins do.

One of the strengths of the aXe browser add-on is that Deque is very proud that they have very few false positives with the aXe testing kit basically. The downside of that is that I think they miss some issues because they’re so determined to not have false positives that I think some things get missed.

Because of them being very determined to not have false positives.

Natalie Garza: Right, but it’s better to flag something right.

Natalie MacLees: Yeah, it depends. Everybody’s gonna have their own preference. Some people are gonna prefer that and not have a bunch of extra stuff that they need to look at. And other people are gonna want a more comprehensive list. So it, it depends.

And then another popular tool is WAVE. A lot of people will have come across this one. It’s available both as a browser extension and as just a webpage. So for free you can go to wave.WebAIM.org. Plug in a URL and run a scan on a page right directly there. Or you can do it as a browser add-on.

And WebAIM is a nonprofit organization and they have also done a lot of extensive research around accessibility. They do a lot of audits and accessibility testing, so they have a lot of knowledge in their organization and their tool will flag all of the potential accessibility issues and some actual accessibility issues that are on your page and give you a little bit more information about them.

It also has a little bit of that x-ray, aspect to it. Where it will highlight your document structure, it will highlight your landmarks and things like that, that are otherwise kind of hard to see.

Natalie Garza: Okay, and aXe going back to aXe, they don’t have a webpage or a web app, or it’s just a pure browser extension.

Natalie MacLees: Well, that’s, that’s where things get a little bit interesting with aXe because they have the browser extension, and then they have their aXe library that they package up and make available in a bunch of different ways. So it is actually available if you are doing development work and you want to run an accessibility scan, every time developers make a commit or merge a PR in, you can actually take that aXe package and put it into your CI/CD process, and have scans just run as part of your development process.

And there’s some other ways that they make that library available as well. But as far as like a non-developer user coming to it, it’s just the browser extension.

Natalie Garza: Okay. Whereas WAVE the browser extension, is kind of a shortcut to their webpage.

Natalie MacLees: Yeah. Yeah. It really is.

Natalie Garza: Okay. Do you wanna go into the next and last one we’re gonna talk about for today?

Natalie MacLees: Yeah, the last, last but not least, we’ll talk about IBM actually has a web browser extension called the Equal Access Accessibility Checker. And similar to Deque with aXe, that’s actually a little library that they make available. And the most accessible way to get it is through the browser add-on. But if you’re a developer, you can incorporate it into different things that you might be building as well.

And it’s, a checker that will go through flag accessibility issues, very similar to aXe. It is less focused on avoiding false positives. So it is a little bit more comprehensive in what it finds, but still, we have to keep in mind that even the very, very best automated checker is not gonna be able to find more than 20 to 30% of accessibility issues.

So, you still have to do manual testing even when you’re using a really robust automated tool.

Natalie Garza: Yeah. These should just kind of be accessories for an audit.

Natalie MacLees: They are a great way to actually get started if you’re gonna do an audit. It’s really nice to just run an automated scan first. Because it’ll give you a little bit of the lay of the land, and you can see, “Oh, this page has a lot of issues on it. So I might wanna save a lot of time for doing a manual audit on that page ’cause it looks pretty problematic.”

So even though it’s not gonna find all of the issues, they are actually like a pretty good indicator of this overall state of accessibility on a site. You know, it’s not exact. Like I can’t say, if I go to a site and I run one of these checkers and it finds zero issues, I can’t say, “Oh, when I do manual testing, I’m probably not gonna find anything.”

But I am gonna think, “Hmm, probably this site is in pretty good shape, right?” Obviously, somebody was paying attention and being careful when they built it, and I’m not likely to find. I’m not likely to go into that and find a whole bunch of really severe barriers happening on this site. It’s probably in pretty good shape, and that’s generally a pretty good indicator.

Whereas if I look at another page and I see 500 issues on just the homepage alone, then I know, “wow, that audit is gonna be a lot of work because there’s likely gonna be a lot more issues found manually.” So the automated testing is still, it’s a really helpful first step. In an audit, it helps you figure out which pages do I wanna prioritize, where do I wanna maybe focus my time, how well do I think somebody did at building this site?

And it gives you that kind of insight at first and saves you a bunch of time logging a bunch of issues that you would otherwise have to do manually as well.

Natalie Garza: Right. Do you think any of the browser extensions we talked about help with manual auditing?

Natalie MacLees: The paid version of the aXe plugin does. Yes. It will actually walk you step-by-step by step through running a variety of manual tasks.

Natalie Garza: Oh, very neat. Okay.

Natalie MacLees: Yeah.

Natalie Garza: And then the Web Developer one, does that one help with the audits? Technically.

Natalie MacLees: It has tools that you would definitely use while doing a manual audit. Yes, you know, that’s not what the tool was built for. It’s not what the developer had in mind when they were making it, but just kind of as a coincidence, there are some tools in there that are super helpful for when you’re doing a manual audit.

Natalie Garza: Gotcha. So all in all, these are all free, with the exception of the aXe one who has also a paid version

Natalie MacLees: Yes.

Natalie Garza: And it helps you get started with automated scanning, but you still have to do manual auditing.

Natalie MacLees: You, yeah, you don’t get out of the manual testing, but it does give you a little jumpstart and it is helpful to use it as an indicator of where you might wanna focus most of your manual testing time.

Natalie Garza: Gotcha. We will leave links to all of these browser extensions that we’ve discussed today. And with that, I think we wanna talk about one last tool.

Natalie MacLees: That also has a browser extension; that would be AAArdvark. So you can go to AAArdvarkaccessibility.com and check it out. Our browser extension lets our tool talk to your website so that you can load it up in Visual Mode, which is very nice because you can see little markers on your website exactly where you have accessibility issues and get more information about them and how to resolve them.

Natalie Garza: And AAArdvark has both support for automated scanning and features for manual auditing.

Natalie MacLees: Yes, that’s true. You could do both all in one tool.

Natalie Garza: So go check out AAArdvark. You can get your homepage scanned for free to, just to get a feel for your website.

and we’ll leave a link to that too in the notes and go check out our blog for a full transcript and links to all these as well. So with that, we are gonna end the 18th episode of the AAArdvark Accessibility Podcast. And thank you guys for watching, and we’ll catch you guys next time. 

Resources

• Web Developer by Chris Pederick
  • Chrome Extension
  • Firefox Extension
  • Edge Extension
• axe DevTools by Deque
  • Chrome Extension
  • Firefox Extension
  • Edge Extension
• WAVE Evaluation Tool by WebAIM
  • Chrome Extension
  • Firefox Extension
  • Edge Extension
• IBM Equal Access Accessibility Checker by IBM
  • Chrome Extension
  • Firefox Extension
  • Edge Extension
• AAArdvark by AAArdvark
  • Chrome Extension
  • Firefox Extension
  • Edge Extension

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. This is episode 17. I’m Natalie G, the host and mic MC. And with me today is

Natalie MacLees: Natalie Mac, accessibility expert.

Natalie Garza: yes, she is an accessibility expert here to answer all our questions. And in today’s episode, we’re gonna talk about, “I wanna get my website or app certified as accessible.” Why can’t we get our website certified as accessible, Natalie? 

Natalie MacLees: Yeah, this is something that clients often ask for more often than you might think because they want to have, I think they want two things. I think number one, they wanna have some kind of certification that they can display on the website to say, “Look, my website is accessible.” And then I think the second thing that they’re hoping to get is peace of mind, that nobody is going to be able to sue them or send them a demand letter saying that their website isn’t accessible.

And unfortunately there is no like official accessibility certification. We have talked extensively in other episodes of the podcast and I like all over online, if you could look up information on accessibility. You’ll see WCAG, the web content accessibility guidelines, referred to over and over again.

And those are just a set of guidelines. They’re not a certification scheme in any way, shape or form, and they’re also not comprehensive. So meeting WCAG does not mean that your website is a hundred percent accessible. It’s just a baseline of accessibility. So unfortunately, there is no way to actually certify a website as being accessible. 

Natalie Garza: No, because accessibility is not a one-and-done kind of procedure.

Natalie MacLees: Yeah, that’s definitely one of the challenges because if, for example, there was some kind of website certification, you would have somebody come in, test your site, certify it as accessible, and then as soon as you went in and made one edit, that would be out the window. You would have to start all over again, and it wouldn’t be cheap, right?

It would be pretty time-consuming and pretty time-intensive. Websites change all the time, and it makes it really hard to have, you know, any report or anything that you do is just a point in time, right? On the day that this report was finished, here’s what the state of accessibility was on the site, but it is not

like a certification of that status, because probably maybe even that later, that same day, something on the website changed, something new was added, something was edited, something was removed, and now those test results are invalid.

Natalie Garza: Mm-hmm. Yeah. It’s like trying to certify a human is healthy,

Natalie MacLees: That’s a good analogy.

Natalie Garza: The next day, they can catch a cold. That certificate goes out the window.

Natalie MacLees: You might cut your finger, you might stub your toe

Natalie Garza: A Gator can bite your hand off.

Natalie MacLees: My goodness! 

Natalie Garza: Sorry, Natalie just came back from Louisiana, you guys, Natalie came from Louisiana where she could have gone on the Gator tours, but she decided not to.

Natalie MacLees: Have both my hands, though.

Natalie Garza: Yes.

Natalie MacLees: I did not feed marshmallows and hot dogs to the alligators.

Natalie Garza: As fun as that sounds. She did not get to do that tour. Okay, so we can’t certify websites. We can only do reports which count for a certain point in time. Do you wanna touch on 508? Because there’s some, the word certification gets thrown in there with the certified trusted testers.

Natalie MacLees: Yeah, so the Department of Homeland Security in the United States does offer a certification course and test to anyone who’s willing to invest, I don’t know, a hundred hours of their lives, I suppose, into getting it. There’s no cost. And that is called the Section 508 Trusted Tester Program. And you can go through that program and learn all about web accessibility and how to test for it according to the Section 508 standards, which are similar to WCAG 2.1 AA, but not exactly the same.

And you can be certified as a tester to test for those guidelines. However, the test results that you produce, once you have that certification, those test results themselves are not certified in any way. And part of the reason for that is what we already touched on: websites change all the time, and you can produce

an ACR, an Accessibility Compliance Report based on the VPAT, the Voluntary Product Accessibility Template. But it’s just valid until you make a change on the website, basically. So if I were to finish an ACR today, and maybe you don’t make a change to your site for two days, well, we have two whole days that, that ACR is valid, and

then as soon as you make a change, it’s completely invalid again and would need to be redone. Now, that’s not reasonable. So most people don’t go through and do a whole ACR every time they edit something on their website. A lot of companies will set a cadence, which could be every six months, every year, or every two years, where they’re gonna come back and refresh that and catch up to where they are.

But again, it’s not a certification; it’s just a picture of how well the website is doing in complying with this standard on this day. And that’s all the more it’s doing. Yeah, so the accessibility testers, they tend to get certified, or they have the option to get certified in their practice. But even that, there’s no universal certification for testers either. Outside of that one, there’s nothing else. The IAAP has some certifications. We did an episode on it earlier, but they’re not; they don’t certify you to actually do work in the field. They’re just proof that you have a certain body of knowledge.

Natalie Garza: Yes. Yes. So if you hear the word certification around the accessibility, the digital accessibility space, there’s not too much to back it.

Whether you’re a tester or reporting something on a website.

Natalie MacLees: Yeah, that’s definitely a red flag that somebody is maybe doing something a bit untoward or inappropriate and making some guarantees that they can’t back up. So if somebody’s offering you a badge to display on your site or some kind of official certification, you should definitely be wary because that is not. It’s not likely to be legitimate.

Natalie Garza: Mm-hmm. Yeah, a site can never be a hundred percent accessible.

Natalie MacLees: That’s true. Even if you meet, you know, if you have to comply with Section 508, even if you meet it 100% and pass every single success criteria, or if you’re trying to comply with another standard, whether that it would be WCAG or if you’re in the EU, the EN 301549 standard, you can 100% comply with those standards and your website is still not 100% accessible because there are so many different parts of a website that can impact so many different kinds of audiences.

That you’ll just never get to 100% accessibility no matter how hard you try. Part of the challenge is that some of the needs of one group of people actually conflict with the needs of another group of people. And so you’re always trying to find the compromise there on how can we accomplish this feature or this content without setting up barriers.

For anybody, but there could still be some challenges that maybe somebody would have to deal with some inconveniences, or they might need to be a little bit tech savvy to be able to figure something out. So there’s always those kinds of challenges no matter how hard you try.

Natalie Garza: These are like the gray areas of accessibility.

Natalie MacLees: It’s the gray areas of accessibility and yeah, we have, our most recent blog post on our AAArdvark blog is actually about the things that you can do to help make your website accessible that are not in any guideline, just to give people examples of what kinds of things those are. So you could go and check that out if you’re curious.

Natalie Garza: And while you can’t get your website certified, it’s still nice to put up an accessibility statement.

Natalie MacLees: Yeah, absolutely. And an accessibility statement is also just a statement of, here’s what we have done to try to make our website accessible. Here’s where we know we have failed, and acknowledge that, and here’s who you can get in touch with if you’re running into a problem on the site so that we can try to address it.

Natalie Garza: So if we’re not trying to get our website certified. What should we be aiming for?

Natalie MacLees: Yeah, so aiming for meeting whatever compliance standard would apply to your website is always a good place to get started. Most websites do not comply with whatever standard would apply to them. So if you don’t have another legal standard where you are, then it’s pretty safe to say you should be trying for WCAG 2.2 AA. That would be every website on the web should be trying to comply with those things. So that’s a good place to get started is to try to conform with whatever the compliance rules are for where you are. And then from there, you wanna just be listening to your users, paying attention to where users might be running into problems.

Do user testing with your audience because every website’s audience is slightly different. And just be looking for ways that you can help to reduce friction and make using your website or your app or whatever you happen to be building digitally as accessible as possible.

Natalie Garza: And then also making changes to your workflow right now to slowly start incorporating better practices so that you don’t have to fix mistakes in the future.

Yes, and that is the practice that we call Shifting Left. I’ve never heard of that.

Natalie MacLees: Oh, we haven’t talked about Shifting Left. Okay. Yeah. Well, let’s talk about shifting left for a minute because you will see it pretty often in the accessibility world. You will see people give you the advice to Shift Left. And what that means is, I guess, if your language that you happen to speak is a left-to-right language like English, and you think of the process of making a website where you’re gonna have the initial idea, and then you’re going to do some sketches, wireframes, what have you, and then go to design, and then go to development, and then go to layering in functionality. And if you think of that as a linear process, that would go from left to right. Unfortunately, what a lot of people do is they insert accessibility at the end as the last step before launch.

Natalie Garza: That is not what we wanna do. You wanna move accessibility left in the process so that it’s earlier in the process. And ideally it should be in there right from the very beginning, like right from the point where you’re coming up with the idea and doing the initial sketches of the website. You should be thinking about accessibility there. Okay, so just thinking about accessibility earlier, “shift left” is not a keyboard command.

Natalie MacLees: It is not a keyboard command, and it is not a political statement. 

Yeah, it just has to do with thinking about accessibility earlier in the process of planning and building a website or a digital product.

Natalie Garza: All right, so with that said, we talked about why you can’t certify your website to be accessible. We went over what you should actually be aiming for with your website if you want to start looking into making it more accessible. And now, where can people start? Where can website owners start if they want to make their websites more accessible?

Natalie MacLees: Yeah, you can come over to aaardvarkaccessibility.com and test out your homepage for free. No credit card is required. See where you might have some accessibility issues on your homepage, and it will guide you through explaining what those issues are and how you can fix them.

Natalie Garza: Perfect. So everybody go ahead over to aaardvarkaccessibility.com, get your website checked out or your homepage for free. Create a free workspace. And with that, we’ll end this podcast. This is episode 17. Thank you guys for joining us, and we’ll talk to y’all next time.

Natalie G: Hello everybody and welcome to the AAArdvark Accessibility Podcast. My name is Natalie G. I’m the Mic MC here and with us today is…

Natalie M: Natalie M. Accessibility expert.

Natalie G: Yes, and in today’s podcast, we are going to do the part two to last week’s episode, where we talk about web accessibility when building websites from scratch. This one is geared towards developers and agencies, basically, anybody who is actually making the website.

Natalie M: Professionals who build websites.

Natalie G: Professionals who build websites. And so we’re gonna start off with why is it important to build a website to be accessible from scratch?

Natalie M: Yeah. So we touched on this a little bit last time, but I think it’s worth doing a quick review. Your favorite metaphor, Natalie, you can’t put the chocolate chips in the cookie after it’s baked. So the best way to end up with an accessible website is to build it to be accessible from the very beginning.

It is the most cost-effective option. If you try to come back and make an inaccessible website accessible later, it’s going to be very expensive, very time-consuming, and very difficult, and the end result won’t be as good. And accessible websites are important, of course, because that way, there are no barriers to customers or users to the website.

Everybody has equal access to all of the information and services. The user experience of an accessible website is better for everybody who uses the site. You get a little SEO boost. And you can avoid legal risks ’cause people do get sued for having websites that aren’t accessible. And you could look at increasing your audience and potentially your revenue by about 20% if you are inclusive and allow everybody to easily use your website. 

Natalie G: Yeah, and that means everything on your website, like the checkouts, like the memberships, like the ability To give your website owner money.

Natalie M: Make donations to a nonprofit. Yep. All of it should be accessible.

Natalie G: Yeah, and there’s a lot of misconceptions that developers have when it comes to making accessible websites.

Natalie M: They do, they do. A lot of developers don’t, you know, we talked about in an earlier episode how there’s a real lack of accessibility training in any kind of web development training. If it’s there at all, it’s often just one unit that’s kind of tucked in, in the middle of the class, and it’s not taught holistically throughout the entire curriculum.

And because of that, developers often make a lot of assumptions and think, “Oh, it’s really difficult. It’s really time-consuming. It’s expensive. It will constrain what we can do. It will constrain the design. Can’t be fancy and beautiful.” They’ll think, “Oh, we aren’t gonna be able to build certain kinds of functionality.

And the website is not gonna be as modern or fun or as exciting if I have to make it accessible.” And so they’re reticent to kind of dive in and figure out how to make that all happen. 

Natalie G:  Yeah, I think there’s, just like, an untrue tie with accessibility and, like, maybe government websites. ’cause when I think of accessible websites, I just think of government sites. And they’re all horrible. But they’re horrible for other reasons, not just because they’re accessible.

Natalie M: Yes, that’s true. Government websites are just baseline horrible, and it has nothing to do with accessibility.

Natalie G: No. So when it comes to selling accessible websites, if you’re a professional, you’re an agency, what stuff do we have to keep in mind?

Natalie M: So you are the professional. So somebody is hiring you because of your expertise to do something that they can’t do themselves, which is to design and or develop. A new website, and it is your responsibility as a professional to inform the client about what they actually need and to guide them to make the right decisions.

And if you are thinking of accessibility as an optional add-on, or like an optional upsell, that is the wrong approach. Every website should be accessible out of the box, and you should be educating your client about why that needs to be the case. Why accessibility is important and why you are going to build it into the site from the beginning and help guide their decisions along the way so that they end up with an accessible product at the end. 

Natalie G: Yeah, it’s not something you can tack on months later.

Natalie M: It’s not something you can tack on months later, and it’s not something that I would consider optional for any website. Because any website that you put out there, and this includes if you are building a, like an intranet for internal company use because there are going to be employees of the company who are going to need an accessible platform to go in and request their paid time off or adjust their HR records or to access company resources that is going to need to be accessible as well.

So you’re not off the hook if it’s not a public-facing website, either. It’s just, it’s a really important thing, and you put that out into the world, and now you have a legal liability that if somebody tries to use that website and can’t because you didn’t build it to be accessible, now you’re gonna get a demand letter, or you’re gonna get a lawsuit. Because somebody couldn’t access that resource.

Natalie G: Mm-hmm. Does the demand letter or lawsuit only apply to the person who owns a website or it also trickles up? Trickles up? Also, goes back up to the developer? 

Natalie M: Yeah, so that’s an interesting question, actually, because right no,w it’s just the owner of the website, but there is a law here in California where I live. That they are trying to give the builder of the website, so the developer, the designer of the website, responsibility for that accessibility so that you, as a web developer, could be sued if a website that you’ve built is not accessible. 

Natalie G: Yeah, so what you’re saying is that accessibility should just be a core feature of your offerings. 

Natalie M: Yes, it should be a core feature of your offerings, and it should be something that you are talking about with a client from the very first call that you have with them. 

So, I was telling you about a LinkedIn thread that I saw a few weeks ago. I won’t name any names, but somebody said, “Ugh, we’re 10 months into a big project, and the customer just told me it needs to be accessible.” 

You should never end up in that situation because. It should have been the other way around, right? The developer should have told the customer 10 months ago this needs to be accessible. It shouldn’t have been coming from the client or the customer, right to the developer.

That information should have traveled the other way from the very first conversation they had about the project. That should have been something that they were talking about. It shouldn’t be something that’s coming up from the client’s side 10 months later. 

You are the professional, so you are the one who knows what it takes to build a successful website, and you need to be the one who’s in charge of that and informing your clients what they need when they are hiring you to build that website for them. 

Natalie G: Yeah, because 10 months later, it’s like you’re treating it as an add-on. Right? At that point, you’re just gonna have to rebuild the whole website.

Natalie M: Yeah. 10 months later is too late. And that is, that’s on the developer. That’s the developer’s fault at that point.

Natalie G: What if clients try to give you pushback and say, well, can I get a discount if I don’t want my site to be accessible? 

Natalie M: Yeah. So I run into this situation a lot as a web developer. You know, I ran my own agency for a decade. And clients would often say things like that, “Oh, I don’t have any users who have disabilities,” which is a silly thing to claim because, of course, they do. “I don’t need that. Can we just not do that?”

And I would, take the opportunity to educate them about accessibility and why it’s important. And most of the time that would be sufficient and they would be on board and they would understand why it was important. There were some clients who were really stubborn about that and were just like, “No, I really don’t think this is something I need.

I don’t wanna pay for it.” And at that point I, I can give them two options. You can go to somebody else ’cause I’m not gonna do that, right? Or, I would give them a little, like I would send them a little acknowledgment by email that would just say like, “Okay, well, if you don’t want me to do this in an accessible way, I just need you to acknowledge this email that says, I’ve advised you that this needs to be accessible and that.

You are acknowledging that you’ve received that information and you understand it, and that if somebody sues you because of this not being accessible, you are not gonna hold me liable because this was your decision.” And sometimes that was enough to make them decide, “Oh, okay. Yeah, no, we can just make it accessible.” 

Natalie G:  And in turn, would they agree to your prices?

Natalie M: Yeah. Yeah.

I never negotiated on prices.

Natalie G: Would it be a good practice to send something like that for every single project? ’cause after the website is delivered, a lot of it falls out of your control.

Natalie M: A lot of it does fall out of your control, I don’t think you have to have some people sign something like that every time. You might have a little something in your contract, like I would have a warranty in my contract, for example, that would just say, “Hey, if there’s any issues, you need to report them to me within 60 days or 90 days, or whatever it would happen to be.

And after that, I’m not responsible because you’ve been the one taking care of the website and changing the content and all of those kinds of things. And it’s out of my hands.” So you could just have something like that in your contract, I think that would say, after a certain period after launch, it’s just not, it’s not your responsibility anymore. 

Natalie G: Even if you have them like on a retainer. 

Natalie M: Yeah, the warranty would expire even if they were on retainer. Because you don’t get, you don’t get infinite work on your website forever with the, you know, for no additional cost. So, you know, the retainer would cover what the retainer covers, but there would be a separate contract for the retainer, and that would cover.

The work specified there, but the original development of the website like that coverage would end at some point. 

Natalie G: As the developer, as the agency, would you give your users or your clients like a guide or like a manual to help maintain the website? 

Natalie M: Oh yes, absolutely. And also training in how to do it accessibly. So I have like a pretty standard training that I’ve developed over time for content managers and how to, like think about color contrast and link text and things like that. And I would walk them through that and then leave them a recording of the training so that they could refer back to it at any time.

And yes, they always had a, like a guide to walk them through how to do different things on the website and make updates. Sure.

Natalie G: Okay. So as the web developer, as the agency, you have to be upfront with them.

Accessibility should be a core feature, but then there’s the added training part to help users maintain the work that you did.

Natalie M: Yes. I would just include that as a standard part of a web design package and, you know, price that in from the very beginningand make it clear to the client that that’s something that they’re getting as part of your services.

Natalie G: Yeah. Which it may sound like a lot of work, but in the grand scheme of things, you’re adding more value to your services.

Natalie M: That’s a lot more value. Yeah. When they get not just a new website, but they have a guide, and I had a, like, a way that I would build it right into the website so they didn’t have to keep track of a, you know, a separate document or something like that. It would be built right into their website, like a little guide on how to use it.

How to do different things, how to make different updates, and then some notes on when they needed to call me. Here’s a situation you can’t handle on your own. Call me. I’ll take care of it for you. 

Natalie G: Yeah, and not only does add more value, but it gives you the ability to charge more for your services, like against other web developers, against other agencies, you are worth more money. You have more knowledge. 

Natalie M: You have comprehensive services that are gonna cover everything. You know, they’re not just, you’re not just gonna dump a website on them and like, “Oh, well, it’s your responsibility now. You gotta figure it all out.” Yeah. They’re getting a much better product at the end. They’re, they’re getting this knowledge of how to use it and they’re getting education and how to.

Keep their website accessible and I would include social media training. So if you wanna be using Instagram and different platforms and sharing content there, here’s what you need to keep in mind for accessibility. So I would really give them this comprehensive package and any web development agency has the ability to do that.

Natalie G: Mm-hmm. Yeah. So going back to building the sites, why does it need to happen in the initial stages? I mean, we covered a little bit.

Natalie M: Yeah, because if you try to come back later, if you try to build it like that person on LinkedIn, you’ve been working on something for 10 months, and then you try to go back and make it accessible. It’s gonna be really difficult because you’re gonna have to reverse a lot of decisions that you made earlier.

So maybe you’ve made some design decisions about how form fields look, or color schemes and things like that, that now those decisions have to be redone, which then means whole parts of the website or the application need to be redone. If they were just done accessibly from the beginning, you wouldn’t have to redo things.

You know, it takes an equal amount of time to build a form one way or another. And if you’re gonna build it accessibly, it doesn’t really take extra time to do it. But if you have to do it twice, well now it takes twice as long because you built it inaccessibly first, and now you need to come back and build it accessibly and it’s gonna take twice as long, just by definition.

Natalie G: Mm-hmm. Yeah. Or if your theme is not accessible or the add-ons you chose are not accessible.

Natalie M: Yeah. You end up having to undo and redo a lot of things, and sometimes the undoing actually takes time. So now we’re over double time because now we have to, you know, here’s something that took an hour to do, now I’ve gotta spend 20 minutes undoing it, and then another hour redoing it. And now we’re over doubling the price, right?

Natalie G: Mm-hmm. Yeah, and I mean, at that point, you might just have to eat those costs yourself. Right? Because you already charged the client.

Natalie M: If you told the client that you were gonna build something accessible and then you didn’t, yeah, you need to eat those costs.

Natalie G: Mm-hmm. So gets really messy if it’s not done from the very beginning.

Natalie M: It does get very messy, very expensive, and very frustrating. 

Natalie G: When you start from the beginning, you also get to set the accessibility standards for the team early, the rest of the developers, the rest of the content managers.

Natalie M: Content managers, the social media managers, the designers, the UX people. Yes, everybody’s aware, but this is something we need to be keeping in mind. Yeah.

Natalie G: Cause, like once everybody’s added their content, everybody’s added their blog posts, their pages. And then you say, “Oh, actually, you guys had to keep the headings in mind. Now you have to go through 30, 40 different pages,”

Natalie M: Yeah. Now you need to go back through them all. Check all of your headings, check all of your link texts, check all of your colors.

But you could have just done that from the beginning. 

Natalie G: And then we also wanted to talk about automation and manual testing. Catching issues early. 

Natalie M: Yeah, so it is a good idea to have some kind of accessibility check built into your development process. So there are libraries that you can use where every commit you make to a GIT repo is going to automatically get run through some basic accessibility checks to make sure that you’re not introducing accessibility issues that can be detected automatically.

So that’s a really handy thing to do. You could also set up an accessibility checker. Usually there’s some kind of a development site or a staging site that everybody is updating on a regular basis. You could have some kind of a checker running on that website. Something like AAArdvark, for example, could be hooked up to that website and run a scan every day to check for any issues that might get introduced.

But you would also wanna be doing manual checking of the website as well. So every developer should be testing everything that they’re doing with keyboard alone before they check it in, open up a screen reader, right, and just check it before they check it in. And then there should be an accessibility professional who’s kind of doing final checks on everything as well. 

Natalie G: Yeah, because trying to do that at the very end of the project.

Natalie M: It is not gonna go well. It’s not gonna go well, and things are gonna get missed, and you’re not gonna end up with an accessible website at the very end. You do wanna be doing that all along the way. Yeah.

Natalie G: Mm-hmm. I have an extra question.

Natalie G: Okay. When you keep clients on a retainer, is checking in on the accessibility of their site part of that?

Natalie M: It could definitely yeah.

Natalie G: Okay, so every single, maybe month or two weeks, whatever your retainer is, you can say, “I’m gonna go through your website, I’m gonna tab through it, I’m gonna use the screen readers, and do just a quick check and let you know about any issues.”

Natalie M: Yeah. Yeah. That would absolutely be a great thing to include in a maintenance retainer.

Natalie G: Yeah. And again, this is stuff you can charge more money for. You’re more valuable.

Natalie M: Yeah. You build up this knowledge. It is. It is an income opportunity for sure, but also a chance to make the web a better place and more inclusive.

Natalie G: Yeah. ’cause there’s a lot of stuff on websites like contact forms, checkout, appointment booking.

Natalie M: Forms to leave reviews or write comments.

Natalie G: And if people can’t use those, they’re going somewhere else.

Natalie M: Yeah. They’re gonna go somewhere else. Yeah. Forms to leave donations for nonprofits.

Natalie G: Mm-hmm.

Natalie M: Yeah.

Natalie G: Alright. Do you wanna wrap up with where can web developers go to check on the accessibility of their projects?

Natalie M: Yeah, they could come over to AAArdvarkaccessibility.com and you could hook up a development site that you’re working on. You could hook up a client site that you have under maintenance if you made accessibility part of your maintenance package and run scans on a regular basis, daily, weekly, or on demand, and get back reports and keep track of how your accessibility is improving.

And you can also use it for manual testing. So if you’re gonna say, “Hey, as part of my maintenance package, I’ll manually test five pages of your site a month.” You can definitely use AAArdvark for that as well. 

Natalie G:  So go check out AAArdvark at AAArdvarkaccessibility.com, get your homepage scanned for free. Sign up. Register for an account. It’s free. No credit card required. And with that, we’re going to end the AAArdvark Accessibility Podcast. This is episode 16. Thank you guys for joining us, and we’re gonna talk to y’all next time.

Natalie Garza: Hello, everybody, and welcome to the 15th episode of the AAArdvark Accessibility Podcast. My name is Natalie G, and I’m an accessibility novice, and with us today is:

Natalie MacLees: Natalie Mac, accessibility expert. (Full name is Natalie MacLees, and her nickname is Natalie Mac!)

Natalie Garza: And, in today’s episode, we are going to talk about web accessibility when building websites from scratch. So we ended up making this a two-parter. This one is gonna be geared towards website owners,

(Natalie Garza accidentally set off the built-in Apple Confetti reaction.)

Natalie MacLees: We are really excited about that.

Natalie Garza: Website owners! And the next part is gonna be geared towards developers and agencies. So to kick us off, Natalie, why is it important to build a website to be accessible from scratch?

Natalie MacLees: Oh, it’s your favorite metaphor, Natalie, from Lainey Feingold, that you cannot put the chocolate chips on the cookie after it’s baked. So if you try to build your website and then come back and try to make it accessible, it’s gonna be a nightmare. It’s not gonna be fun, and it’s probably going to at least double the cost of your website.

Because going back to a website that was built without accessibility in mind and trying to make it accessible is very difficult and very time consuming, and it could double or even triple the cost of having the website built to begin with. If you instead build an accessible website from the very, very beginning, I would say you’re probably looking at maybe about 20% more cost to have an accessible website versus an inaccessible one.

Natalie Garza: Yeah, so for one, it’s very cost-effective. But there are other benefits too.

Natalie MacLees: There’s benefits to having an accessible website. They’re more SEO friendly and who doesn’t want their site to be found in search engines? I mean, you put it online because you wanted people to find it, presumably. You can avoid legal risks, so you won’t be getting demand letters. Or if you do get a demand letter, you’ll have proof that you have been working on the accessibility of your website and it has been improving.

The overall user experience of an accessible website tends to be better. They tend to be more performant.

Having an accessible website could also increase your potential audience by up to 20% because there are between one in five and one in four, Americans who are people with disabilities. So you’re gonna capture even more of the market and potentially increase your revenue by up to 20%. 

So, if your website is accessible, it just means more people can interact with it, more people can understand it, can get to all the parts of your website that you want them to interact with, like your contact forms, your checkout pages, all that good stuff.

They can get to all the good stuff and they can get to it no matter what device they happen to be using. If they’re out and about and trying to buy something from your website on their phone, it’s gonna work. If they’re at home on their laptop or their tablet, it’s gonna work.

Natalie Garza: Mm-hmm. Yeah, that’s, I think that’s a good segue to the next question. What does it mean for your site to be accessible? Do you have like an overarching definition?

Natalie MacLees: Yeah, I think roughly what a lot of people think of is that it meets WCAG guidelines, right? And we’ve dug into WCAG guidelines on other episodes, and I’m sure we’ll do it in the future. but there is things that you can do beyond the WCAG guidelines. The WCAG guidelines are really just a baseline, so there’s all different kinds of best practices you can implement, but at the end of the day,a website being accessible just means that it can be used by anybody who happens to show up with whatever device or assistive technology they happen to be using.

They’re gonna be able to use the website without any issues. 

Natalie Garza: Yeah. In our last episode, we covered a little bit about myths about people who have disabilities don’t use websites. That’s not true.

Natalie MacLees: That’s not true at all.

Natalie Garza: Only certain websites need to be accessible, but that’s also not true.

Natalie MacLees: All websites should be accessible. 

Natalie Garza: Mm-hmm. Mm-hmm. 

Okay, So we covered why websites need to be accessible. For one, it’s the most cost-effective option. You get a bunch of benefits as a business, and most importantly, more people can access your site and use your services or understand your content. What does it mean to be accessible? It means everyone can access your site, navigate it, use it. So, how is all this tied to making website from scratch?  

Natalie MacLees: Yeah, so when you’re getting started on a new website project, it is really important that you think about accessibility from the very beginning. And that’s going to impact all of the decisions that you make about the website, who you hire to build it. If you’re gonna hire somebody to build it, if you’re gonna build it yourself, you have to think about what tools are you going to use and are those accessible if somebody else is going to build it for you.

They’re probably, in this day and age, not building that completely from scratch. They’re probably using a platform like WordPress, Drupal, you know, Squarespace, they’re using something as their platform. 

So if you’re hiring somebody to build it, they’re probably also using a platform or a tool that’s going to make it easier for you to update and manage content on your own later on. And you wanna make sure that that tool, whatever gets chosen, is accessible because you can’t fix that later. You have to start over again, if you’re gonna fix it later.

You can’t build a site on one platform, realize that that platform isn’t accessible, and just move it to a different platform. You can’t easily migrate sites like that between different platforms. So you’re gonna have to start over. And the only thing you might be able to skip is if you did an extensive like custom design process first, where maybe you had a designer do some branding and choose some colors, and do some mockups of some designs.

That would be the only thing that you wouldn’t have to start over on. You might even have to start over on that. If those designs weren’t accessible, if they chose colors that didn’t have enough contrast, if they chose different design components that weren’t accessible, you might even have to throw that out and start over.

So there’s lots of different ways that the different stages of building a website, you have to think about accessibility and how that’s going to come into the final product. When you do that correctly from the very, very beginning, building an accessible website is much easier, much more cost effective, but you have to make all the right decisions from the very beginning.

Natalie Garza: I mean, if you already have an existing website. You could also count a lot of the content that’s already written that could easily be migrated. 

Natalie MacLees: Sure. Yeah, if nothing else that can be copied and pasted manually. Right?

Natalie Garza: Yeah, but the pages themselves, like you have to go through and recreate every single page. A lot of copy-pasting.

Natalie MacLees: Yeah. It’s a lot of copy pasting and often when a customer comes to me and says, I’ve got this website and it’s not accessible, and I wanna make it accessible. Very often it is cheaper to just start again and even if the design is all accessible and the way the site looks is fine and there’s plenty of contrast in the colors and all the different custom components and things that are designed can work in inaccessible way.

You still have to kind of start from scratch and rebuild that website. It’s faster to do if you don’t have to make a lot of design decisions and you don’t have to do all that design work. But it is faster and easier to start from scratch and rebuild a website often than trying to take something existing and make it accessible.

It just costs way more money and it’s a lot more difficult. It’s a lot more headaches.

Natalie Garza: Mm-hmm. Yeah, because even if the designer, they chose like a lot of tabs, they chose a lot of dropdown menus or what are those called? Where it’s like stacked I, they open.

Natalie MacLees: Accordions.

Natalie Garza: Accordions, yes.

Natalie MacLees: Yeah.

Natalie Garza: Or, picked really tiny font sizes for your design.

Natalie MacLees: Or put auto-playing video somewhere on the page.

Natalie Garza: Or, used a lot of tables.

Natalie MacLees: Yeah, there’s lots of unfortunate decisions that you can make in the design stage that’s going to impact the accessibility of the site later on. So you wanna be thinking about that and make sure that if you’ve hired a designer to work on your website, that it is somebody who’s versed in accessibility.

And they know how to test and check colors that they’re using for accessibility. And they have some general ideas on how content should be structured, what a form should look like. ’cause this is where things go wrong a lot of the time, is that designers will decide that having labels on form fields look sloppy or cluttered, and they take them out.

And, that is a crucial element of accessibility is to have labels for form fields. So you want somebody who knows that they can’t make those kinds of decisions so that they’re not then turning over an inaccessible design to a developer to be built, and then the developer is stuck having to say, “Well, I can’t build the form that looks like this because it’s not accessible.”

And then you have to decide, are you gonna send it back to the designer to have them redo it? Are you gonna have the developer just ad hoc try to change it? And that might not look good and it might, not mesh with the rest of the design and it gets very, very messy. 

Natalie Garza: Yeah. And then I know with a lot of platforms, they also rely on like third party components.

Natalie MacLees: Yeah.

Natalie Garza: Like, WordPress is notorious for plugins and themes, but it, it’s becoming really popular across other website platforms too.

Natalie MacLees: Yeah, because the platform itself, you can’t build every type of functionality that somebody might want into a platform. You can make some pretty good guesses about functionality most people will want, right?

Like a form builder. Most websites end up having at least one form on them. But other types of functionality like appointment scheduling or newsletters, right? Not everybody’s gonna want that. And it doesn’t always make sense to build that into like a core product, but it does make sense to give people a lot of flexibility to kind of take different building blocks, right?

And put together just the functionality that they need. But then you end up in a situation where now instead of, you know, just if you have a WordPress site, instead of it just being a WordPress site, well now you have a WordPress site with functionality from 20 other random developers who built these plugins so that you can have, you know, e-commerce and you can have appointment scheduling, and you can have, all this other functionality on the site.

It’s not cohesive anymore because it’s from all different people. And do all of those developers know about accessibility? Did they all build their plugins to be accessible? Chances are they didn’t. And so you have to evaluate all of those add-ons before you add them to your site to make sure that they’re accessible. 

Natalie Garza: Yeah. Which ties back to picking the right person to build your site, right? Because you can’t expect your client to know all the different plugins you’re gonna use and whether they’re accessible or not. 

Natalie MacLees: Yeah, as a website owner, you’re just not gonna know those things. You’re not gonna have that kind of technical knowledge. That’s why you’re hiring somebody to help you because you need some help navigating that because it is very confusing and you can build on pretty much any of the popular platforms that are out there like right now, Squarespace, Wix, Weebly, WordPress, Drupal, or like any of those, you can build an accessible website on it, but that none of them make that particularly easy to do.

Like just a lay person with no knowledge of web accessibility probably can’t, which is unfortunate situation. It’s an unfortunate state of affairs. Somebody who does know what they’re doing, who knows about web accessibility and can evaluate all those different packages and add-ons and options that you could turn on or off in the tool.

They can get an accessible website out of that process at the end because they know how to navigate and test and figure out which things they can use and which things they can’t. 

Natalie Garza: Yeah, and it’s really important ’cause down the line, like after you’ve already paid for all these plugins, all these add-ons, if the wrong person built your site. Like a year later, now you have to scrap everything, now you have to throw away all these plugins. It becomes really hard to transition. 

Natalie MacLees: Or even worse, you have somebody build you a website, they do a beautiful job, it’s fully accessible, it’s working wonderfully, and then two years later you decide, “Hmm, I would like to add some functionality. I wanna sell some products, or I wanna have classes,” or something like that. And then you pick a plugin that’s not accessible to add to your website.

Well, now you’ve ruined everything. 

Natalie Garza: Yeah. you lose some of the SEO benefits or expose yourself to legal risks just from adding one plugin.

Natalie MacLees: And you potentially lose some of your customers.

Natalie Garza: Mm-hmm. Yeah, you can lose some of your customers, especially if it’s really important functionality like memberships handling,

Natalie MacLees: Yeah.

Natalie Garza: e-commerce handling 

Natalie MacLees: Yes. If somebody can’t check out from their cart, you’re not gonna get their money.

Natalie Garza: Mm-hmm. they’re gonna leave your site and go to another site. All right, so all in all, it’s the best option to start accessibility from the start,

Natalie MacLees: It is the best way to do it.

Natalie Garza: from scratch.

Natalie MacLees: Yes, from scratch.

Natalie Garza: Yeah. And that relies on finding the right person to do it. Making sure to ask questions along the way. Is this the right platform? Is this the right plugin, the right tools? Because later down the line you wanna switch over.

Natalie MacLees: It can be really painful, very painful, very time-consuming, and very expensive later on.

Natalie Garza: Mm-hmm. Mm-hmm. So with all that said, Natalie, where can website owners get started? Where can they go if they wanna make their sites accessible?

Natalie MacLees: They can come to aaardvarkaccessibility.com, and it can really be helpful for the process of building a website because you could actually hook up your development site or your staging site to AAArdvark. Keep an eye on it all through the development process and then keep using it on production once your site is live.

Natalie Garza: Mm-hmm. Yes. You can monitor it all the way through from staging to production and any changes in between.

Natalie MacLees: From the first line of code to the last.

Natalie Garza: Yes, from scratch.

Natalie MacLees: From scratch.

Natalie Garza: We are baking the cookie. Wait, we’re baking the chocolate chips in the cookie.

Natalie MacLees: That’s the best way to do it.

Natalie Garza: All right, so with that, that is the 15th episode of the AAArdvark Accessibility Podcast. Thank you so much to everyone for listening, and we will talk to y’all next time. 

Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. This is our 14th episode. I’m Natalie G, and here with us today is

Natalie MacLees: Natalie M. 

Natalie Garza: And she is an accessibility expert. While I’m an accessibility novice here to learn along with all of our podcast viewers too. So, in this episode, we’re gonna talk about web development courses and their general lack of accessibility training. What is the current state of web development education, Natalie? What would you say?

Natalie MacLees: I would say most web development courses at any level, whether that’s online courses, boot camps, college courses, et cetera, have either no training at all about accessibility or will have like one unit on it, you know, out of 20 units that you might do. Will have one little unit introducing accessibility.

So, a lot of web developers are coming out of those courses. You know, whatever kind of course it is, with no background, no history, no knowledge of accessibility really at all, or just the tiniest hint that it might be something that they need to pay attention to.

Natalie Garza: What is your journey through accessibility? ’cause you started in web development.

Natalie MacLees: I started in web development, but I’m old. So, I started in web development before there were any courses. So, I started in web development. When you taught yourself, or you didn’t learn, you just figured it out yourself, or you didn’t learn. So, I got super excited, I got my first, internet enabled computer in 1996 and really quickly realized going on AOL that having your own website was an option that you could do.

And I was like, wait, what? You can have your own website. Oh my gosh. And I spent hours, hours and hours and hours, hundreds of hours on this website. And I just got really excited about it. And then a few years later, realized like, wait, this is something people will pay you to do. So I got really excited about it.

And then pretty early on in the year 2000, I got a job at Penn State University, building websites. Specifically, I was working in the chemistry department there and building the websites for the courses. Right, so if you were taking Chem 12, which is like the intro to chemistry that freshmen would take, there would be a Chemistry 12 website.

That you could go, you could get the notes, you could get the study guides for the exams and all of those kinds of things. And that was my job, was doing all of those, course websites. And I was about two weeks into it when one day my phone at my desk rang and it was the disability services office saying, ” excuse me, what do you think you’re doing on these websites?

Students with disabilities can’t use them.” And I was just like, “What? What are you talking about.” And so they provided me, at no cost to me, at their own cost. Tons and tons of training in how to build websites in an accessible way, which was, you know, web development. In the early days, it was the wild, wild west.

There was no training, there was no official certifications, there was just nothing. And so I got all of that training and I learned how to build websites to be accessible and then was shocked when I moved on from that job three years later to find out that that’s not how it worked everywhere, that other jobs were just like, “Accessibility.

What, what is that? I don’t know what you’re talking about.” And they hadn’t learned. And so I just became kind of the defacto accessibility advocate at every job I had since.

Natalie Garza: Can we talk about Penn State here?

Did they have an accessibility expert on the staff? How did you get trained?

Natalie MacLees: Yeah. So Penn State University is actually one of the thought leaders in the accessibility space and has been for a really long time. They’re still very respected. They’ve done a lot of work around accessibility, and their disability services office, which may have a different name at this point, I’m not sure, was empowered to

contact other departments and to contact people like me building websites and tell them they had to do it in an accessible way. So, they were able to actually get things implemented. At some universities, that’s not the case. They’ll have that office, but they don’t have any real power behind them. So they can ask people, “Can you please make this website accessible?”

But they don’t have the power to actually make it happen. And I think the difference at. Penn State was that they did empower that office to enforce that and to really require you to do, you know, it wasn’t just websites, right? It was exams. Professors had to make sure that their exams were accessible and all different areas of campus, buildings on campus, et cetera.

Everything had to be accessible. 

Natalie Garza: Do you think that’s the case for a lot of universities?  

Natalie MacLees: No.

Yeah, Penn State’s not the only one. I don’t wanna make it sound like that, but they were definitely at the forefront of that whole movement, you know, ’cause that was a long time ago. That was over 20 years ago. And they were already enforcing accessible websites at a time when, you know, it was WCAG 1.0.

And nobody even really knew anything about accessibility. And they have maintained that and, you know, I’m sure that all of their online courses and things like that, and they still publish a lot of accessibility information on their website and share with the public things that they have learned.

But I know from talking to students who’ve gone to other universities that that is not the case that all of them, some of them have some real barriers and some real problems in that area. 

Natalie Garza: You mentioned WCAG 1.0. 

Natalie MacLees: I think it was 1999, actually, that 1.0 got published.

Natalie Garza: Okay. Okay. So that kind of explains, ’cause I was thinking like, where are they getting the standards, and like have they done testing? Like where did they get this information for websites early on in the days? 

Natalie MacLees: Yeah. At a time when websites were terrible because there weren’t any best practices for building websites, and so there was some really, just outlandish approaches to building websites early on. And, you know, figuring out what those best practices were and establishing like that whole field of like usability and user experience for websites and the conventions and all of that.

Like that all had to be worked out. That all had to be established still. 

Natalie Garza: So the WAI, they were, they were out there working

Natalie MacLees: in 1999. Early on. Yeah.

Natalie Garza: Wow. Okay. Interesting. And so you started your journey in web development. You 

liked it

so much that you got a job, and then you got a wake-up call.

Natalie MacLees: Yes. Like almost immediately.

Yeah. That was my first paid job doing websites. Yeah.

Natalie Garza: So I imagine somebody like a person with disabilities at the university was like, “Um, I can’t even use this course.”

Natalie MacLees: Yeah, probably that’s what happened. Yeah. Is that a student in one of the classes I was doing the website for, probably contacted that office and said, “I can’t use this website.”

Natalie Garza: Hmm. And good on them for speaking up.

Natalie MacLees: Yeah. Good on them.

Natalie Garza: All right, so you got introduced at Penn State, over the years, have you learned more on your own, or was that the only training you took back in the day? 

Natalie MacLees: I’ve learned more on my own since then. Like, I went and got my certifications from the IAAP when that, when those came out and that made, was made available, because I wanted to support that mission, and I had to do a whole bunch of learning and all of that to pass those tests. And accessibility is one of those fields that the technology is changing all the time.

Browsers are changing all the time. Devices are changing all the time. HTML, CSS, and JavaScript are changing all the time. And so there’s always something new to learn. There’s nobody who knows all of it because it’s all just shifting around and there’s whole areas of it that are gray areas, there’s not a cut and dry like, “yes, this is the right way to do this,” kind of answer.

And so you always are doing research and testing and figuring out what are the best approaches to things. So it’s just one of those fields where you’re gonna learn for as long as you’re in the job. 

Natalie Garza: I mean, the components are kind of the same, right? You still have links, you still have headings.

Natalie MacLees: Yeah, the basics of the web haven’t really changed. That’s true.

Natalie Garza: They’re just getting used in more complicated ways.

Natalie MacLees: For sure. Yeah. 

Natalie Garza: Speaking about always learning. What is the problem with web dev courses and how they set up their curriculum? 

Natalie MacLees: Yeah, so they just, very often, they have no information about accessibility at all, or they’ll just do like one little unit on it as though that’s enough. And I think the ideal would be if they had accessibility built into every unit of their course, and instead of just talking about, “Oh, here’s some basics on HTML, but let’s talk about

the semantic meaning of all of these tags and when to use them and why it’s important.” Which I feel like gets kind of glossed over, and they tend to speed right through the HTML course, right? Because it’s easy, but it’s really easy to get it wrong too. There’s some complexities to HTML that you miss when you just kind of figure out how to use angle brackets and move on.

So they’re really just kind of missing that whole foundation that should be built into the entire course from start to end. And instead they either ignore it completely or try to smash it all into one little unit, you know, three quarters of the way or so through the course is what it appears to be the pattern. 

Natalie Garza: I feel like accessibility is really simple cause it deals with such simple pieces of the HTML, like make sure the label’s tied to the field right. And when you skip over the basics or the simple stuff, that’s where you mess up.

Natalie MacLees: Yeah. That’s where the lack of knowledge about semantic HTML really gets highlighted, I think. And especially for newer web developers who go through a bootcamp, right? And jump straight to building something in React, for example, because there are terrible practices being done by React developers who don’t even use a button tag, right?

They just make a div and put click handlers and things on that, and that does not work with the keyboard by default. You have to do a bunch of extra work to make it work with the keyboard, and you’re really better off just making it a button than trying to make a div work. But there’s a lack of awareness and a lack of understanding and just a lot of ignorance around what accessibility is and why it’s important and how to implement it because it is left out of all of these courses. 

Natalie Garza: Yeah. This is where the acronym POSH comes back in.

Natalie MacLees: Yes. Your, your favorite one? Plain Old Semantic HTML. 

Natalie Garza: Yes. Bring back POSH. Bring back the simplicity of just, if it’s a button, just make it a button element. You don’t gotta make it all complicated.

Natalie MacLees: Get the basics right, and you’re, you’re halfway there really. 

Natalie Garza: Yeah, if it’s an image, make sure it has an Alt attribute, give it an explanation. And I feel like that has to be covered whenever you talk about image elements. 

Not like units later.

Natalie MacLees: When you say, “oh, by the way…”

” Remember when we talked about buttons and images in week one?”

” Here’s some extra stuff you should know about those.” 

Natalie Garza: Do you wanna talk about some of the courses we found online

Natalie MacLees: Yeah. We can talk about some of the most popular courses. So you did find Web.dev had a full course on accessibility, which might be a good choice for somebody who’s looking to learn. We looked at Code Academy, has a tutorial, like an intro to web development kind of tutorial, that has one little unit that is not even accessibility.

It’s “responsive design and accessibility”, as though those two things are the same, so it’s like half a unit maybe of accessibility in that one. And then some really popular courses online are, The Odin Project, which a lot of people may have heard of is a free web development course.

There’s nothing on accessibility in that one. And Free Code Camp follows that same, kind of little model of there’s one little unit about three quarters of the way through the class on here’s accessibility. 

Natalie Garza: So would you say, in general, accessibility is treated as an afterthought to web dev courses?

Natalie MacLees: Yeah. If it’s there at all, it’s often an afterthought. And then web developers graduate from taking those courses and treat it the same way when they go get a job because that’s what they learned. So yeah, it should be front and center. It should be baked into every unit of the course. And it’s just unfortunately not. 

Natalie Garza: What do you think is the reason behind people leaving out the accessibility? 

Natalie MacLees: I do think there’s just a fundamental unawareness of the need for accessibility and how important it is. And the people who are making these courses are web developers who had training themselves that didn’t include it, so they don’t know what they don’t know. And they aren’t including it when they’re creating these courses or are including it as an afterthought, the same way that they were taught.

So there’s something there where it’s just perpetuating itself. There’s also a lot of myths around accessibility. This idea that, it’s not really necessary or only certain sites need to be accessible. This idea that people with disabilities don’t use the web, which I hear more often than you would expect, which is just silly.

 So there’s a lot, there’s a lot of different ideas like that. Or the idea that accessibility is this huge damper on innovation and that you can’t build like a really clever, modern, beautiful-looking, performant website if you have to make it accessible, which is just wrong. That’s just incorrect information.

And what’s causing that, I think, is developers who don’t know how to build a nice-looking, performant, modern website that’s accessible. So they just assume it can’t be done because they don’t know how to do it. But really, accessibility is a real driver of innovation and you can do some really amazing things and make it accessible. 

Natalie Garza: Yeah. The misconception that your website’s gonna not look as good just cause you’re using really basic, simple components, but that’s not really the case.

Natalie MacLees: No, it’s not the case at all. Yeah. You can build a really complex, really intricate website and have it be accessible. 

Natalie Garza: Yeah. We’re in the process of making our own marketing website accessible.

Natalie MacLees: We will always be in the process of making our own marketing website accessible. Websites don’t hold still, right? So accessibility isn’t something that you’re just gonna say, okay, well let’s make the website accessible and you spend a month or two working on it and then you’re done forever. That’s not how it works.

It’s constant. It’s constant work and every time you add content, you’ve gotta check it. You gotta make sure you are gonna add a new feature to the website. You gotta check that. You gotta make sure you make changes to the website. You gotta check that, you gotta make sure. So it’s, it’s a constant investment.

Natalie Garza: Mm-hmm. That’s true. I would maybe rephrase, we’re in the process of making it more accessible.

Natalie MacLees: Yes.

Natalie Garza: Yes. And you would think like, “Oh, it’s a WordPress site. Elementor, you got all these crazy plugins in there,” and yet we’re still making progress.

Natalie MacLees: Yeah, for sure we are. It’s in generally pretty good shape, but it could always be better. There’s no, there’s no such thing as a website that’s, you know, 100% accessible. So, there’s always room for improvement. There’s always something that you could do to make it better and easier to use for people.

Natalie Garza: Mm-hmm. That’s a good way to look at it. Where can people go to learn accessible web development?

Natalie MacLees: Yeah, so you found some nice things and I added a couple to the list too. So WebAIM is a nonprofit organization, “Web Accessibility in Mind”. I think they’re based near you, Natalie, in Austin, if I remember correctly, they do a lot of training. So they’ve got virtual training courses on accessibility.

I know they’ve got a conference coming up in March. That they’re gonna have lots of training at. So, they’re a good one to go and check out The Accessibility Collective, which is A11Y-collective.com, has lots of accessibility courses, and that was put together a couple years ago by some really well-respected accessibility professionals, kind of all work together to create that website.

Deque company, D-E-Q-U-E has been a pretty well-respected company in the accessibility space for several years now, and they’ve got dequeuniversity.com with training for all different kinds of specialties and accessibility, all different kinds of accessibility courses. And then Google actually has a free course that’s available on Udemy.

(Post-editing notes: Oops, we meant to say Udacity, not Udemy!)

That’s a nice intro to web accessibility for developers. And it’s really nicely done and it’s completely free.

Natalie Garza: And there’s resources out there, free online resources. You just have to learn them in addition to your normal web dev courses.

Natalie MacLees: Yes, yes, for sure. And not all of the courses are free. Some of them are paid, and they’re very much worth paying for. I think, Natalie, we could add also to the course, Sara Soueidan has an intro to web accessibility course that is excellent.

Natalie Garza: Mm-hmm.

Natalie MacLees: That is a paid course. 

Natalie Garza: And lastly, where can web devs go to figure out the state of their websites or the projects that they’re working on?

Natalie MacLees: Yeah. Well, that’s what we do. We make AAArdvark, so come on over to AAArdvarkaccessibility.com for free with no credit card required. You can enter in your homepage, scan it and get back a list of all of the issues. You’ll get information on why they’re issues and how to fix them, and we’ll walk you through it and provide that educational information on each of those, and then you can track your progress over time on improving your website. 

Natalie Garza: And quick note, we’re very close to launching a very special project called “WCAG in Plain English.”

Geared towards developers. 

Natalie MacLees: Yeah, geared toward anybody really who’s just curious about accessibility. So, we’re explaining all of the different WCAG success criteria in very easy-to-understand, less technical language. So if you’ve struggled to understand the official documentation, you could come over to AAArdvark and check out what we’re working on. 

Natalie Garza: Yeah, I would say original WCAG is very geared toward developers. 

Natalie MacLees: Yeah, it’s very technical, very dense. Can be pretty difficult to understand, especially if you’re not a developer. If you’re a designer, or a content editor, or a social media manager who’s trying to do your job in an accessible way, WCAG can be really difficult to understand. 

Natalie Garza: Yes, WCAG in Plain English, coming to AAArdvark very soon.

Natalie MacLees: Very soon.

Natalie Garza: Yes. So with that, we wanna end the podcast. Thank you guys for joining us for the AAArdvark Accessibility Podcast, episode 14. Thanks for joining us and we’ll talk to y’all next time.

Natalie G: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast. This is our 13th episode, and here with us today is,

Natalie M: Natalie MacLees.

Natalie G: And she’s an accessibility expert, and I am Natalie G, the other Natalie, an accessibility novice. And in our 13th installment, we are going to talk about acronyms, numeronyms, and keywords in accessibility. Cause if there’s anything you’ll notice once you start learning is that there’s a lot of acronyms and a lot of keywords and a lot of things from like coding backgrounds and you may not understand all of them, but we’re going to cover them all today.

Natalie M: All!? That’s ambitious.

Natalie G: A lot of them

Natalie M: I bet we forget something.

Natalie G: Yeah. If we 

Natalie M: forget anything,

There’s just so many.

Natalie G: leave a comment in the description below. What? Leave a comment in the comments below. Alright, so do you want to start with the one overwhelming, most commonly used, everywhere you see the accessibility, this is mentioned too, acronym. 

Natalie M: Yeah, WCAG or WCAG or WCAG, the Web Content Accessibility Guidelines. So a set of around 80, I think, total success criteria that basically lay out how to build an accessible website or web application.

Natalie G: It covers a lot of different tests, different standards, different rules you should follow for web content.

Natalie M: Yes.

Natalie G: And it’s everywhere because… 

Natalie M: It applies to all websites. 

Natalie G: Yeah. Applies to all websites and it’s the most commonly enforced across laws.

Natalie M: Yes, most of the accessibility laws around the world are either directly say to implement WCAG or indirectly have a set of rules based on WCAG.

Natalie G: Yeah. And there’s different versions of WCAG too. 

Natalie M: There are 1.0, which is very old, 2.0, 2.1, 2.2, and they’re working on 3. Yes. 

Natalie G: And, there’s different levels of WCAG.

Natalie M: Yes, A, AA, AAA. A being the easiest one to achieve, but also the least accommodating, and then AAA being the most accommodating and the most difficult to achieve. Most of the time, people are going to try to comply with AA, so just that sweet spot right in the middle, and most of the laws refer to WCAG AA.

Natalie G: And funny enough, the A’s are not actually acronyms.

Natalie M: No, they’re not. They’re just letter grades.

Natalie G: A, 2A, and 3A.

Natalie M: Yes.

Natalie G: And they’re not acronyms in AAArdvark either, in the name AAArdvark.

Natalie M: No, they’re not.

Natalie G: It’s just a play on words.

Natalie M: Exactly. 

Natalie G: Alright, next acronym. What makes up WCAG in terms of principles?

Natalie M: Yeah. So we talked about WCAG before and how it’s divided into different levels. The very top level, like the highest level of divisions, is the principles, and there are four of them, and they spell out the acronym POUR, P O U R, for perceivable, operable, understandable, and robust.

Natalie G: As just helpful to remember the different principles, right?

Natalie M: Yes. Yes.

Natalie G: I did have a misconception before. I thought each principle was connected to like a type of disability. That’s not true.

Natalie M: Oh, no, that’s not true. Perceivable, for example, just means that everyone who comes to your website can perceive the information with whatever senses they have available. So that could be somebody who is blind, can perceive your website by hearing it or with touch with a braille keyboard. It could be someone who’s deaf can perceive any spoken or sound content by reading a transcript or captions or by looking at sign language interpretation, et cetera. So they’re not specific to one certain audience or anything like that. 

Natalie G: Next set of acronyms.

Natalie M: The ones we talked about last time.

Natalie G: Yes. The 

Natalie M: WCAG cousins, A-TAG or ATAG or A T A G, the Authoring Tool Accessibility Guidelines, UAAG is our best guess, or U A A G, the User Agent Accessibility Guidelines, and then, what we said was PDF/UA or PDF slash UA, which is PDF Portable Document Format Universal Accessibility. 

Natalie G: That’s an acronym combo. 

Natalie M: Yes, yes. Two acronyms in one. 

Natalie G: Yeah. And ATAG, a quick overview, is for authoring tools, which just means anything that lets you create content.

Natalie M: Yes.

Natalie G: They have their own set of guidelines. And I did look it up, they do have their own little success criterion.

Natalie M: Nice. It’s not as extensive,

Natalie G: but it does.

Natalie M: Nice. 

Natalie G: And then UAAG, user agent. That’s for any browsers, media players. I read that it’s anything that renders web content.

Natalie M: Okay. Mostly, that’s browsers. There’s a few other things you might use, but mostly that would be browsers.

Natalie G: Yeah. It made me think of Kindles or e-readers.

Natalie M: Sure, but that just has a browser built into it.

Natalie G: Does it?

Natalie M: I worked at an e-reader company.

It had, It had a separate browser built into the firmware, yeah.

Natalie G: Interesting. You did work at an e-reader company.

Natalie M: I worked a lot with that browser. I know all about it.

Natalie G: Was it accessible? No. Oh no.

Natalie M: No, it was a terrible browser.

Natalie G: Oof. All right, well, we should contact them and introduce them to UAAG.

Natalie M: Yes, they’ve gone out of business, so

Natalie G: Oh, no,

Natalie M: that’s what you get for not being accessible.

Natalie G: Yes, and UAAG also, after the last episode, does not apply to operating systems.

Natalie M: Okay, that’s good that you looked that up.

Natalie G: Operating systems, they each have their own set of guidelines that they made up themselves,

Natalie M: Interesting. Okay.

Natalie G: Anyway, and then PDF/UA, PDFs, in addition to using WCAG, because a lot of the same principles apply, they also have to use PDF/UA, Universal Accessibility Guidelines.

Natalie M: Yes.

Natalie G: And if you want to learn more about these cousins, watch our last episode! We’ll move on, we’ll move on. Alright,

Natalie M: All right.

Natalie G: Big acronym you see a lot in accessibility. Do you want to talk about VPAT?

Natalie M: VPAT that gets used incorrectly more than probably any other one.

Natalie G: Mhm, mhm,

Natalie M: So we have two acronyms that go together, which is VPAT and ACR. VPAT is a Voluntary Product Accessibility Template. And ACR is Accessibility Compliance Report. You use a VPAT to create an ACR. But everyone just calls the final report a VPAT, which is not,

Natalie G: mhm.

Natalie M: it’s not, the VPAT is the template you use to create the report and the report is called an ACR.

Natalie G: Yes, the long lost forgotten other uncle, ACR.

Natalie M: Yeah. It is really weird that they have such two different names, but I don’t know. I don’t know who named them.

Natalie G: Yeah, maybe like, it should have been like VPAT and CPAT.

Natalie M: or just like Accessibility Compliance Report and Accessibility Compliance Report Template. Ha ha ha.

Natalie G: Ah, yeah, that’s true. 

Natalie M: Oh well, what are you gonna do?

Natalie G: Yeah, well that’s VPAT and ACR. Next, W3C, WAI,

Natalie M: Yeah, W3C, the overlords of the internet. So the World Wide Web Consortium, so they say W3 instead of WWW or dub dub dub. And yeah, that’s the organization that develops all of the standards that we all use for the web, like not just the accessibility guidelines, but also HTML, CSS. And then I think they have finally given up the ghost on ECMAScript and just given into calling it JavaScript.

And some other, some other web standards as well. But yeah, that’s the body that does that.

Natalie G: and

Natalie M: oh, within them is the WAI, the Web Accessibility Initiative, which is one of the working groups that works on the WCAG guidelines.

Natalie G: So the overarching organization W3C.

Natalie M: Yes, and there are working groups within it that focus on all the different standards. And WAI is just one of those groups. 

Natalie G: And they are specializing in accessibility

Natalie M: Yes, that’s what they do 24/7.

Natalie G: And they’re the ones building WCAG 3.0.

Natalie M: Yes, they are in public. You can go keep an eye on what they’re doing.

Natalie G: Yeah. Isn’t there like a draft page or like

Natalie M: Oh yeah.

Natalie G: they have so far?

Natalie M: Yeah.

Natalie G: very, very different.

Natalie M: Yes. They’re completely rethinking WCAG, which is good. I think it needs that.

Natalie G: I think it needs that, too. Because each level, or I guess each version of WCAG, just builds on top of the previous one.

Natalie M: So far, so far, that’s how it’s worked. And so with three, they’re going to start fresh. 

Natalie G: Okay. Next acronym. ARIA.

Natalie M: ARIA, a girl’s name, but also Accessible Rich Internet Applications. And ARIA is basically a set of attributes, but it’s confusing because they don’t work on their own most of the time and need JavaScript to go along with them. But it’s a way that you can make custom components accessible so that they can communicate their value and their state and what type of control they are to assistive technology.

So if you need to build like a custom checkbox or a custom select dropdown or something like that, you would need to look into ARIA and figure out what all the different attributes you need to use and how those need to interact with your JavaScript to make sure that somebody who’s using assistive technology can still use your fancy custom components.

Natalie G: Yeah. And ARIA is, it’s like a fallback solution. 

Natalie M: Yes. Yes. The first rule of ARIA is don’t use ARIA. You

should try everything you can to not have to use it.

Natalie G: Yeah, the first letter in ARIA means “avoid”. I’m just kidding. And if you are looking at the guidelines, you will see ARIA referenced a lot.

Natalie M: Yes, there’s lots of like sufficient techniques and recommended techniques for the different success criteria that refer to different ARIA attributes and rules and components and things like that.

Natalie G: And if you’re still not sure what that means, then contact your local developer to learn more.

Natalie M: You’re a friendly local front-end developer.

Natalie G: I think that’s a really highly technical term, but you will see it a lot. So I wanted to include it.

Natalie M: Yeah, ARIA is very technical, yeah.

Natalie G: Next, we have AT. 

Natalie M: Assistive Technology!

Natalie G: Is that one common? I haven’t seen it that much.

Natalie M: Yeah, it gets used quite a lot in accessibility, like, communities and things like that. Yeah, because “assistive technology” takes a long time to say.

Natalie G: Yeah, and it is, if you have to type it ten times.

Natalie M: Uh huh. Yeah.

Natalie G: Okay, I think we can do like a speed thing now. I think we went through the most important ones.

Natalie M: Okay. 

Speed round. 

Natalie G: What’s ICT?

Natalie M: Information and Communication Technology. I think it might be a term invented by Section 508.

And it just refers to, this is what Section 508 refers to. Yeah, I’m not positive about that, but that’s the first time I heard that term was in connection with Section 508.

Natalie G: I see. I can see how it’s probably used with laws

Natalie M: Yeah. 

Natalie G: Speaking of 508, do you want to talk about 508?

Natalie M: Yeah, Section 508 of the Rehabilitation Act of 1978?

Natalie G: Three?

Natalie M: 3? Yeah, sometime in the 70s. Yeah, it’s just the 508th section of that law and requires Government agencies to have accessible websites and for any organizations or institutions that get government funding to have accessible websites, but also all of their information and communication technology has to be accessible.

So if they use kiosks, like to check in for your appointment or phone systems, like all of those things have to be accessible.

Natalie G: All their ICT.

Natalie M: Yes. All are ICT.

Natalie G: I guess I’m, I think there’s some confusion there. 508 is not really an acronym.

Natalie M: No.

Natalie G: But it’s shorthand for Section 508.

Natalie M: Sure.

Natalie G: All right, next. CAPTCHA.

Natalie M: Oh, this one is my favorite. Completely Automated Public Turing Test to Tell Computers and Humans Apart.

Natalie G: I didn’t know this was an acronym before I read into this. 

Natalie M: It’s a stretch, because as you see, there’s way too many words.

It should have a few more letters in it, but that’s okay.

Natalie G: Yeah, there’s “test”, “to tell”, “and”. They missed a few.

Natalie M: Yeah. Yeah. And Turing is named after Alan Turing, the computer scientist. And yeah, a Turing test is just a test to distinguish between a machine and a human.

Natalie G: Yeah, and CAPTCHA comes up a lot in accessibility because CAPTCHAs are typically not accessible.

Natalie M: Notoriously inaccessible. Yes. I mean, even somebody without disabilities hates  CAPTCHAs. We just don’t wanna deal with them. . Yeah. 

Natalie G: From my current guideline research, it’s because the tests can be inaccessible. If

Natalie M: Yes.

Natalie G: it’s a visual test, it also has to be auditory too, or have the option to change.

Natalie M: Yeah. There is a weird carve out in WCAG for  CAPTCHA to let people still use it, even though it’s inaccessible. There are newer versions of  CAPTCHA that are much easier, that are just check a box, or sometimes they’re completely invisible and you don’t have to interact with them at all. And that’s a good direction to move in because those are obviously gonna be way more accessible than click all the images of a bus.

Or slide this slider over to the right, or do this math question, or decipher this text that’s impossible for anyone to read.

So they are moving in a good direction, but they do still have accessibility issues.

Natalie G: Yeah, I just realized there’s also the cognitive tests.

Natalie M: Yeah, what’s three plus seven? Then you have to answer, yeah.

Natalie G: Just another, another layer to the CAPTCHA chaos

Natalie M: Yeah.

Natalie G: All right, next! Acronym, ADA.

Natalie M: The Americans with Disabilities Act just requires that any businesses open to the public and government agencies have to be accessible. So this is the law that gives us, you know, handlebars in restrooms and ramps into buildings. And also according to some recent Department of Justice rulings, accessible websites.

Natalie G: It’s not fully, fully enforced though.

Natalie M: There’s definitely some issues with it. And then the only way for it to be enforced is with lawsuits, which are of course expensive and time consuming and exclusionary because not everyone can afford to file a lawsuit. Yeah, there’s lots of problems with it.

Natalie G: And that wraps up the acronyms.

Natalie M: Yes.

Natalie G: Now we move on to the numer-numeronyms.

Natalie M: All right. I think we can do these in a speed round. 

Natalie G: Yeah, these can be more speedy. 

Natalie M: All right.

Natalie G: A11y. Accessibility, 

Natalie M: Because there are 11 letters between the A and the Y, you put and write the A, and then you replace all the other letters with the number 11, and then you write the Y. That is how numeronyms work. 

Natalie G: And there’s a really popular one for the literal word, accessibility. A11y.

Natalie M: Which looks a little bit like the word “ally”. Because a one looks like a lowercase l, kind of. So sometimes people will pronounce it ally, or ally, even.

Natalie G: If I see it, I just say accessibility.

Natalie M: Yeah.

Natalie G: Do you want to go through the rest of the numeronyms?

Natalie M: Sure! I18N. Internationalization. L10N, localization, T9N, translation. So those are all closely related concepts, subtly different from one another, but they all deal with putting text in many different languages and date formats and things like that to use the formats that are used in different countries in different areas of the world.

So those are all really common. And then we have C14N, canonicalization. Which is just having canonical URLs for your data and things like that. That’s a whole other thing. I don’t think we’ll dig into too much here. And then Natalie, the one that you coined is…

Natalie G: T13G.

Natalie M: Yeah.

Natalie G: Because, in our own company, we are constantly saying “troubleshooting”, and I got tired of writing it out, and so I coined T13G. I mean, if translation gets one, troubleshooting can get one too.

Natalie M: All right, has it caught on?

Natalie G: Some of my team members have told me they’re confused about what I’m saying, but they will learn eventually.

Natalie M: Did anybody say quit trying to make fetch happen? 

Natalie G: They’re like, “You don’t even go here!” It’s gonna, watch, after this episode goes out, it’s gonna be like a shockwave went through the internet. Everyone’s gonna start saying T13G.

Natalie M: Okay, all right, I look forward to it.

Natalie G: Yes, me too. Okay. Keywords to help wrap up this podcast before we go into the 40 minute mark like last time. Keyword you will see a lot in accessibility. Alt text. 

Natalie M: Yes,

That is just a text replacement for images, so anybody who can’t see your images, they’re going to get this text instead. 

Natalie G: Contrast Ratio. 

Natalie M: The color difference between text and the background color it’s sitting on. So black text on a white background has a really high contrast ratio. And say pale gray text on a white background has a very low contrast ratio. And there is a specific numerical formula for figuring that out.

There’s tools you can use that will do it for you, don’t worry. You just put in your foreground and background color and there is a minimum threshold in the WCAG guidelines for what that color contrast should be.

(Post-editing notes: Check out WebAIMs contrast checker tool.)

Natalie G: Favoring higher contrast.

Natalie M: Yes, to make it nice and bright and clear for everyone to perceive.

Natalie G: Keyboard navigation.

Natalie M: Yeah, so we have lots and lots of users who can’t use a mouse in the traditional sense who rely on a keyboard or some kind of keyboard replacement. So you should always be able to navigate any web page or web app with just the keyboard without using your mouse. You should be able to get to everything, work all the different controls, fill in all the information.

Natalie G: Focus order.

Natalie M: That’s related to keyboard navigation. And that’s when you when you’re navigating through a website or a web application with a keyboard to move from one thing to the next, you hit the tab key and it will move focus to each different little element. And typically you’ll see some kind of indicator, like usually it’s some kind of highlight ring around The item that has focus, so that you know where you are on the page and focus order is just the order that that happens as you go through the page.

Natalie G: And focus order has to have a rhyme and reason. You can’t just be

Natalie M: Yes.

Natalie G: to the bottom to the middle

Natalie M: Jump in and yeah, if you have a, if you have a form with eight fields in it, it should go 1, 2, 3, 4, 5, 6, 7, 8, not jumping around unpredictably in the form. Yeah.

Natalie G: Alright, next. Skip links. 

Natalie M: Oh, another one related to keyboard navigation. So, these are little links that help you skip to certain parts of the content. So, most commonly, there is one on a page, and it’s right at the very top. It’s the very first thing that you’re going to encounter using a keyboard. You might be thinking, but I’ve never seen one of these.

Most of the time they are hidden until you actually tab, hit the tab key. So you can start trying that on websites and you’ll see a little tag pop up usually at the top left corner. And it will say skip to main content. And when you press the enter key, it will just skip over that whole header, the sidebar, skip all that stuff, and just take you to the main article or the main content of the page.

Natalie G: Sometimes they can be different, right? They can be like, “skip to contact”. 

Natalie M: Sometimes there’s skip to nav, skip. Yeah, they can skip to all kinds of things, skip to the help button. Skip. Yeah, you can skip to anything.

Natalie G: Whatever’s important on your page.

Natalie M: Exactly.

Natalie G: Next. Semantic HTML.

Natalie M: Oh you missed an acronym opportunity here with POSH. Plain Old Semantic HTML.

Natalie G: Oh, Jesus.,

Natalie M: So Posh is making a little bit of a comeback right now. This it was a term that was popular maybe about 20 years ago among web developers, and it’s making a comeback now because a lot of developers using front end frameworks like React and Vue have forgotten about the importance of semantic HTML.

So it’s just using your HTML tags the way they were meant to be used. They actually have a meaning to them. Right? An H1 tag doesn’t just make text big and bold, it actually has a meaning that this is a heading that’s telling you what the content afterward means, so. That’s semantic HTML, is using all those tags correctly according to their meaning. 

Natalie G: Next. Live regions.

Natalie M: That’s an ARIA concept for announcing changes on a page to screen reader users. So if you have a dynamic page, kind of change where maybe you type a few letters into a search bar and the search results automatically update. If you’re using assistive technology, there’s no way that you know that that just happened.

And that’s not a typical thing that happens on websites. So that’s a case where you would use a live region that would then announce, “Oh, search results were updated.” So that, The person who’s using the site knows, “Hey, something just happened, something just changed.”

Natalie G: Yeah. And then you also see regions in the guidelines too. So it doesn’t have to be dynamic, the regions,

Natalie M: Regions don’t have to be dynamic. No.

Natalie G: But live regions are.

Natalie M: Live regions are, yeah. 

Natalie G: Alright, form labels,

Natalie M: All of your form fields have to have a label that is visible at all times. You can’t just use a placeholder and you can’t just have a form field with no indication of what it’s for or why it’s on the page.

Natalie G: And if you click on the label,

Natalie M: It will focus the form field and or check the checkbox or check the radio button. 

Natalie G: Next, error identification.

Natalie M: Yeah, that’s just helping people out, if they filled out your form and they do something wrong, you have to explain to them what went wrong so that they know how to fix it. Because I know I’ve had this experience and I assume most other people who use the internet have where you fill out a form and you click submit and it says error.

It was like, but what’s wrong? I don’t know what to fix. I don’t know where the problem is. And it’s very frustrating. So error identification is you’re telling somebody which field has a problem and some instructions on how they can fix it, right? Like maybe their formatting of their phone number is wrong or their email address is invalid or they skipped a field and left something blank that was required, but you need to say which field it was and how you fix it. 

Natalie G: Last one, very similar to the first one we covered. Text alternative.

Natalie M: Yeah. So, um, I think when we talked about alt text, we only touched on images, but of course there’s other kinds of non-text content besides just images. There’s videos, there’s audio, there’s animated animations, there’s infographics, charts, graphs, all kinds of different things that are not text, that communicate information.

And no matter what kind of those you’re using, you have to have some kind of text alternative for people who can’t perceive. Whatever the content you’re presenting is.

Natalie G: So you have alternative text, which is an attribute, and then you have text alternatives, which is like captions, transcripts.

Natalie M: Yeah.

Natalie G: Also counts as alt text.

Natalie M: Yeah. It’s a text alternative for something. Yeah. Or like a long description of what’s happening in a chart or a graph or a big description of all the information presented in an infographic. Like all of that would be text alternatives.

Natalie G: Yes. That is the end of our list, you guys. We made it through the acronyms, numeronyms, keywords, and learned a few other things along the way.

Natalie M: Yeah.

Natalie G: POSH and 

Natalie M: POSH! 

Natalie G: T13G  

Natalie M: Yeah.

Natalie G: So with that, Natalie, where can we go to learn more about accessibility?

Natalie M: Oh, you can check out aaardvarkaccessibility.com, scan your homepage for free, no credit card required, and learn all about the accessibility issues on your page and how you can fix them.

Natalie G: And so with that, that wraps up episode 13 of the AAArdvark Accessibility Podcast. This is Natalie G, and with me is Natalie M, and thank you for watching!

(Post-editing notes: We forgot all the accessibility certification acronyms! Check them out in our Types of Accessibility Certification podcast.)

Natalie Garza: Hello, everybody, and welcome to this episode of the AAArdvark Accessibility Podcast. My name is Natalie G, and with me today is,

Natalie MacLees: Natalie MacLees.

Natalie Garza: Yes, thank you for joining us today, Natalie.

Natalie MacLees: Thanks for having me.

Natalie Garza: Yes, this is the twelfth episode, and in this podcast episode, we’re gonna talk about WCAG’s cousins. Let’s talk about cousins. They are ATAG, UAAG, and PDF/UA.

Natalie MacLees: Yeah, I’m pretty sure those are the official names.

Natalie Garza: Yes, we’re gonna go over each one.

Natalie MacLees: The other accessibility guidelines.

Natalie Garza: Yes, the not-so-mentioned, often forgotten, but they’re here, and we’re gonna talk about them. Alright, Natalie, what is, what is WCAG? It’s just a refresher for our audience. 

Natalie MacLees: WCAG, W C A G, stands for the Web Content Accessibility Guidelines, and it’s what applies to any kind of online content or software, even though the name is web content. So like online web apps and things like that, it also applies.

Natalie Garza: Yes, and I feel like if you put any attention into the accessibility space, that’s all you hear. WCAG this, WCAG that.

Natalie MacLees: Yes, you do hear it a lot. People talk about WCAG a lot and they don’t talk about its cousins.

Natalie Garza: What are the cousins, Natalie? We want to start with ATAG?

Natalie MacLees: I usually say A-TAG, but okay, we can call it whatever you want. ATAG, Authoring Tool Accessibility Guidelines. You’ll notice they all end in A G because they’re all accessibility guidelines. And this is a set of guidelines meant for authoring tools. So things like your favorite CMS. Whether that’s Drupal, WordPress, Wix, Weebly, Squarespace, etc.

There’s literally hundreds of them at this point and ATAG should be applying to all of these things. Unfortunately, it is not very evenly implemented. And ATAG aims to do two things with an authoring tool. Number one, it aims to try to make sure that people with disabilities can use the tool. And, so in that way, it’s all of the WCAG rules just applied to, you know, the admin editing interface of, you know, WordPress or whatever to make sure that if you’re using a screen reader or your keyboard only, or, you know, whatever kind of assistive technology you’re using, you can go in and write blog posts and add images and all of those kinds of things. The other part of ATAG is to help you, as an author, make sure that your content that you’re creating is accessible. And so it should have little tips and little warnings that show up. If you try to put white text on a pale yellow background, you should see some kind of warning come up that just says, “Oh, hey, you might want to pick a different color here. This isn’t accessible.” It should have little reminders, “oh, hey, maybe you want to add alt text to this image, right?” It should help you. It should help guide you through because we, we just can’t expect with like tens of thousands, hundreds of thousands, millions of people who are creating content on the web. It’s not fair to expect that they’re going to be aware of all of the WCAG guidelines and know how they’re doing that. And so these tools should be guiding people through creating content in that accessible way.

Natalie Garza: Right, yeah. When I was doing research for this, I didn’t realize how many other tools also fall into this category, right? It’s anything where you’re technically the author and making content. So that’s like Canva, that could be like the Adobe Suite, what else do they have? Grammarly, Notion. 

Natalie MacLees: There’s so many ways to make content on the web these days. Any social media platform, really, is letting you offer content.

Natalie Garza: do you want to talk about Reddit? We looked at Reddit earlier. 

Natalie MacLees: Yeah, we discovered Reddit used to let you go wild, I guess, when you were the host of a subreddit. I don’t know, creator of a subreddit, you could set all kinds of typefaces, and you could change all the colors, and that seems to have definitely gone away, or at least been way toned down, because we looked at a couple of examples on the old Reddit or classic Reddit that were definitely not accessible.

Natalie Garza: Yeah, so in a sense, it is an authoring tool, Reddit.

Natalie MacLees: Sure, yeah, people go on there, they create content, yep. They post, you know, not just text, but they post pictures and videos, and sure.

Natalie Garza: Yeah, I liked your example too about Gravity Forms. 

Natalie MacLees: Yeah. So, um, Gravity Forms recently did a lot of work to make their, to make their tool accessible. Gravity Forms is a plugin for WordPress that lets you create custom forms. And it implemented some of the ATAG guidelines, so when you’re editing a form, if you try to make a choice, like hiding the labels for your form fields, or trying to include a multi-select, it will warn you and let you know that’s not accessible, maybe you want to try a different approach to what you’re doing.

Natalie Garza: Yeah, so that’s an example of an authoring tool within another authoring tool.

Natalie MacLees: Yeah, that’s true.

Natalie Garza: There’s multiple levels.

Natalie MacLees: And some of that’s been built into WordPress too, because I know if you’re in the block editor and you try to put you know, a light color background with white text, you will see a warning that will let you know, “hey, maybe you should make one of these colors darker, because this isn’t going to be enough contrast.” 

So it’s not that it’s not implemented at all. It’s just implemented very unevenly and not fully, unfortunately. And so that makes it harder for you know, people who are coming on the web, who have no background in coding, they don’t know HTML, they don’t know CSS, but they start a blog or they get really active posting on social media or whatever it is, and they don’t know.

And that’s not something we should expect them to know, but we should expect the tools to guide them through and help them to make better choices.

Natalie Garza: Yeah, I would like to see heading tips implemented in WordPress because you can go crazy with those headings if you really wanted to.

Natalie MacLees: Yeah. And a lot of tools, I think you and I had come across this in an email tool that we were using recently that made it very easy to make text large and bold, but actually made it kind of difficult to figure out how to make it an actual heading and not just big, bold text.

Natalie Garza: Yeah, or even the other form tool we were looking at who told us to just add paragraph as a label for a field. They didn’t have the option to add an actual label.

Natalie MacLees: Yeah, they didn’t even have the option to have labels for form fields. Yes, that’s terrible. Yeah,

Natalie Garza: That would be a failure on the authoring tool.

Natalie MacLees: That is definitely a failure on the authoring tool, which leads to then a WCAG failure on the front end of the site when users are coming to it. Yeah,

Natalie Garza: It trickles down, you guys. It goes wrong somewhere up above, and it comes down.

Natalie MacLees: We should demand better authoring tools.

Natalie Garza: Yeah, I was telling Natalie, I’ve been thinking about this, and since I read about A-TAG or ATAG, I feel like the authoring tools should be held more responsible. 

Natalie MacLees: Yeah,

Natalie Garza: To me, it seems like you’re trying to fight the symptoms instead of fighting the actual disease here.

Natalie MacLees: Yes, and any, any improvements that we make to an authoring tool, right, then trickle out to the tens of thousands or hundreds of thousands or millions of people who use that platform. Right.

Natalie Garza: Mhm. Yeah. That’s just like how the social media platforms recently added alt text fields for images. I feel like that was a more recent development.

Natalie MacLees: It was definitely an afterthought, unfortunately, for most of them. Yes.

Natalie Garza: Yeah, or even Reddit, right? Just now we’re redesigning 10 years, 15 years later. 

Natalie MacLees: Yeah, way after the fact, way too late, way too late after way too much content is already created and is now hanging around, hanging out there, just being inaccessible. 

Natalie Garza: All right, do you want to talk about the next cousin?

Natalie MacLees: Yeah, what are you calling it? 

Natalie Garza: Let’s go into UAAG (ooh-aug)

Natalie MacLees: UAAG! 

User Agent. So there’s two A’s: User Agent Accessibility Guidelines, UAAG. And I don’t know, for all I know, people do call it UAAG (ooh-aug). I’ve never heard anyone talk about it. So that’s how tragic things are. And so this is, you know, browsers mostly but also media players and ensuring that those are accessible, that they are integrated fully with the accessibility API, that if I’m using any particular browser, it’s going to work with my screen reader, or it’s going to work with my screen magnifier, or, you know, whatever assistive technology I happen to be using. So these obviously have a pretty huge impact on users because, you know, when we look at the number of products that are impacted by WCAG, it’s billions of them, right? And things impacted by ATAG, it would probably be in the millions by now, if we look at all of the social media platforms and all of the web authoring tools and all of the other ways that you can put content online, there’s probably millions of them.

And then when we get to User agents, there’s less than a hundred probably that are in common use. I mean, there’s probably way more than that, but like if you ask somebody what browser they use, there’s like a 99 percent chance it’s one of like five, right? It’s not going to be some wild extra choice. So it’s a very small number. And so the impact here of implementing accessibility correctly is even bigger because we’re going to have millions and millions of users of every single one of these tools.

Natalie Garza: Do you think “user agent” also applies to operating systems? Or is that a different set of guidelines, maybe, I didn’t find?

(Post-editing note: No, UAAG does not apply to operating systems. Each operating system has developed its own set of accessibility guidelines that they follow.)

Natalie MacLees: I don’t actually know if there is explicitly a set of guidelines that apply to operating systems. That’s a good, that’s a good question that we could look into.

Natalie Garza: Yeah, cuz, like I said, I just got a new iPhone update, and they introduced a bunch of accessibility features, and they’re honestly pretty similar to, like, what Chrome would.

Natalie MacLees: Sure.

Natalie Garza: Also in my research, it seems like UAAG is actually more commonly implemented than you would think, right? Like, Chrome, Firefox, Safari.

Natalie MacLees: Yeah. Yeah, they do. The user agents do tend to do a pretty good job. They aren’t super even, which is why we end up with situations where if you want to use VoiceOver as your screen reader, for example, pretty much you have to use Safari because that’s where it’s going to work best. If you want to use JAWS, you have to use Edge as your browser.

And if you want to use NVDA, you’re kind of stuck with Firefox, and it’s not that those screen readers won’t work with other browsers. It’s just that they work so much better with the one that they are kind of paired up with. And there’s no, like, as far as I’m aware, there’s no, like, official relationship, I mean obviously except VoiceOver and Safari, but like for NVDA and Firefox, and JAWS and Edge, like there’s no official relationship between those, it’s just kind of where the developers of those tools have focused their time.

Natalie Garza: Yeah, cause you can’t, you can’t fix every browser as a screen reader, right? 

Natalie MacLees: Right, yeah, every browser’s got its little quirks and its little shortcomings, and then the screen readers have to figure out how they’re going to deal with that, yeah. 

Natalie Garza: I guess they each just decided to capture their own little share of the market in browsers.

Natalie MacLees: Yeah. I mean, they, they have limited time and resources, so they’re going to focus in, you know, if you can make one thing really well, then that’s better than to try to do five things not very well. And especially when you’re talking about something like a screen reader, the people who are using a screen reader are very dependent on that. And so it’s very important that it works really well. And so you definitely would want to focus on, well, let’s just do this one thing and do it really well, especially because the user agents are all free. You don’t pay for Chrome or Firefox or Arc browser or Safari or Edge, right? Like they’re all free.

You just go online and you download them. So there’s not really a bit, you know, there’s not a cost barrier there. You can use whichever one you want. 

Natalie Garza: Let’s, let’s talk about the next cousin. PDF/UA (p-duff-oo-ah).

Natalie MacLees: My favorite name.

Natalie Garza: Mmhmm. After this video, we’re going to share a PDF (p-duff) with everybody.

Natalie MacLees: Yeah. We’re going to share a downloadable PDF (p-duff). Oh, a PDF, PDF UA, which this one gets an extra U in there and no G.

So PDF. Oh, do you know what PDF stands for?

Natalie Garza: Printable, printable, no?

Natalie MacLees: No.

Natalie Garza: Are you sure? Portable? I thought it meant something like printable ready.

Natalie MacLees: No. Portable Document Format is PDF.

Natalie Garza: Interesting. I don’t believe that. I’m going to see if there’s another acronym. (Searches online to double-check PDF acronym in disbelief)

Natalie MacLees: All right. So I can’t talk over your clacky keyboard.

Natalie Garza: Sorry, sorry. Yes, you’re right. It does mean Portable Document Format. What the heck?

Natalie MacLees: I, my secret hidden talent is I’m really, really good at internet acronyms.

Natalie Garza: Yeah, you kind of have to be if you’re going to be in accessibility.

Natalie MacLees: I know what they all stand for.

Natalie Garza: Okay, PDFs. Continue.

Natalie MacLees: Portable Document Format, Universal Accessibility. So WCAG applies to PDFs, as you discovered when you were looking into this topic for the podcast. But then there’s some extra PDF-specific things that you have to do to make sure that PDFs are accessible. There’s document tagging and reading order and things like that, that you can modify in Acrobat and other PDF editing tools to ensure that your PDFs are accessible.

But to be honest with you, if you have some content and you really want it to be accessible, make it HTML. PDFs are, are pretty problematic most of the time, from an accessibility standpoint.

Natalie Garza: What, I guess, what reasons would you need a PDF then? Just like if you want to share like a flyer. Yeah, printable flyer.

Natalie MacLees: Yeah, people like them to have something that’s printable, right? Like, oh, download my printable planner for whatever. So they like to have it for that. And then of course, at least in the US, I think this might be true in other countries as well, the government just loves a PDF. They just, any government website has, I don’t know, a library of tens of thousands of PDFs.

Everything’s a PDF instead of just being like a blog post. I don’t know why. There must be something about their, like, internal approval process or something that goes more smoothly when things are a PDF. 

Natalie Garza: Yeah, right now, it’s tax season. There are so many ridiculous, stupid PDFs from the government. Don’t get me started.

Natalie MacLees: Yeah, it does make for, like, one advantage of a PDF over a webpage. If it is something that you are going to try to print, you can get a more consistently nice-looking, nicely laid-out result from a PDF instead of a webpage. That is, you know, that is something that we can’t overlook. It does have that advantage to it. But it is really tough to make a PDF truly accessible, and it’s a whole, in fact, document accessibility is a separate specialty branch of accessibility professionals. Document accessibility specialists, that’s all they do, is work on things like PDFs, Word files, Excel files, PowerPoint files, things like that, and make them accessible.

It is. I can’t do that. I’ve tried. It’s terrible. You need like a PhD in, in PDFs.

Natalie Garza: Yeah, because there’s some pretty fancy PDFs out there where, like, you can tap through the field, fill them out, check boxes, signatures.

Natalie MacLees: Yeah, they get pretty fancy, and it’s really rough. It’s really hard. The tools are not great.

Natalie Garza: But see, like, we’re website people, right?

Natalie MacLees: Yeah.

Natalie Garza: If you want a from, just put a form on your site, I don’t get why we need a PDF for it. That’s what I think, that’s what I have to say about that.

Natalie MacLees: Yeah. Just putting the form online is so much easier. There’s so many lovely, fully accessible online form solutions. 

Natalie Garza: Thank you. Yes. PDF/UA, you’re like the third cousin removed. That’s why you don’t have a G in your name, you have a different you came from the other side of the family.

Natalie MacLees: PDF/UA is from the wrong side of the tracks.

Natalie Garza: You’re from the dad’s side.

Any last remarks about PDF/UA, Natalie? Or UAAG, or ATAG?

Natalie MacLees: No, I will say I was talking, I was speaking at a conference one time, and I was talking to an audience of people who were building an authoring tool. And I started talking about WCAG and everybody was like, yeah, yeah, we’ve heard all this before. And I was like, okay, well, what about ATAG? Who’s heard of ATAG? A room with maybe like 300 people in it. Not one person raised their hand. Not one person had heard of ATAG, and they were all building an authoring tool.

Natalie Garza: Wow. Is it okay, I have some questions, actually.

Natalie MacLees: Okay.

Natalie Garza: I guess I didn’t research this as deep as I should have. Does ATAG and UAAG have success criterion? Just like WCAG and techniques that link to them.

Natalie MacLees: I don’t actually know.

Natalie Garza: Okay. I wonder if it’s like the same thing, like a little directory of success criteria they link up to techniques and failures.

Natalie MacLees: Yeah, we can definitely put links to them in the show notes and people can go explore them for themselves.

(Post-editing notes: They’re similar but follow different structures:

• ATAG is structured with principles, guidelines, and success criteria, similar to WCAG, but it’s focused on authoring tools.
• PDF/UA follows a standard approach rather than WCAG-style guidelines. It has requirements for accessible PDFs but not structured success criteria.
• UAAG has guidelines and checkpoints rather than formal success criteria.)

Natalie Garza: Yeah.

Natalie MacLees: But now that you know that these exist, if you’re using an authoring tool that’s not helping you make accessible content, you should file a support ticket.

Natalie Garza: Yeah. Cause I feel like it should, we should hold authoring tools more responsible. I feel like we crack down a lot on web content, but like a lot of people just don’t really know. Like there’s millions and billions of people out there like making WordPress sites. Mm

Natalie MacLees: Yeah. And it’s, it’s a lot, it’s a lot to put on them to say you have to know how to do all these things to have a website. It’s pretty, that’s a pretty difficult thing to demand of people who are not technical. And a lot of WCAG is pretty technical, right? And if you don’t, if you’re not technical and you don’t know code, it’s not very fair to expect that you’re going to be able to produce accessible content.

But if your authoring tool helps you do it. There’s no reason why you couldn’t. 

Natalie Garza: Mmhmm. Yeah, it’s just like a form building tool, right? Like, if you let people make inaccessible fields I mean, that’s not the person’s fault. They just bought your form plugin. I don’t know.

Natalie MacLees: Yeah. They’re just using the settings that you made available in your tool, right? But your tool could limit people’s choices. And I do think that that plays into it a little bit is that these tools are a little bit afraid that they’re going to lose users or that users are going to get upset or frustrated that they can’t, you know, that they can’t make a pale yellow background with a white text on it, right? They’re going to be mad. Well, I want to do this. Why aren’t you letting me do this? And I think they’re, they’re a little bit afraid that they’re going to get some blowback from their users. Who say, no, I want to be able to say I should be able to make inaccessible content if I want to. 

Natalie Garza: I mean, I want to go 90 on a 60-mile-per-hour road. I don’t know what to tell you!

Don’t put yellow text on a white background! 

I want to go to the store and just take what I want! I want to go get a new flat screen and walk out with it! That’s too dang bad! You can’t put yellow on white! I don’t know what to tell you!

I don’t know. That’s, that’s, that’s my opinion.

Natalie MacLees: Well, I, I agree with you. I agree with you. I think if ATAG were more robustly implemented across all the different authoring tools that are out there, we would see a lot of improvement in general web content accessibility across the web. Yeah.

Natalie Garza: It trickles down. File support tickets.

Natalie MacLees: File support tickets. I’ve always been a fan of filing support tickets for inaccessible things.

Natalie Garza: Yeah. I guess what would you do if they respond and they’re like, “Sorry, it’s not a, it’s not a priority for us.”

Natalie MacLees: Well, if I had the option, I would probably look for another tool that would take it more seriously. That’s not always an option. So you can always write back to them and say, can you please escalate my, you know, my request? Because here’s the, the reasons that it’s important. necessarily going to get anywhere, but if you don’t do it, not going to get anywhere at all, ever, right?

Natalie Garza: Yeah.

Natalie MacLees: And I think if we all started being more proactive about demanding accessibility from the tools that we use, the companies implementing those tools would have to start accommodating all of us. 

Natalie Garza: Yeah, because I feel like the, the bigger companies, they have, they have the budget.

Natalie MacLees: Sure.

Natalie Garza: Like, I feel like cracking down on the small business who just has like a little WordPress site, doesn’t really know any better, you can crack down on the bigger company. Why’d you let them, why’d you let them put light yellow on a white background 

Natalie MacLees: Without even so much as warning them, right? Or why do you let them put a hundred images up without telling them they should add alt text to it? Because how else were they going to know? How else were they going to find out that that was something they should be doing? 

Natalie Garza: I think little warnings at least to help people understand, is one step. One step. 

Natalie MacLees: It’s a step in the right direction.

Natalie Garza: Yeah, so step in the right direction, but enforcing it?

Natalie MacLees: Yeah, I mean, I think it is mostly up to the marketplace to enforce something like that and to just say, listen, if your tool’s not, it doesn’t help my users, you know, I want to, I’ve this big company with a hundred people writing blog posts, and I want them to all make sure they’re accessible. And if your tool doesn’t help them do that, I’m not going to use it. 

Natalie Garza: I guess it’s kind of a case of you pay with your dollars. Oh, you vote with your dollars. You don’t put

your eggs in one basket.

Natalie MacLees: Are we just saying, are we just saying sayings now?

Natalie Garza: How the turntables…

Okay, we’re getting too carried away. We need to end the podcast.

Natalie MacLees: All right.

Natalie Garza: Why, why does WCAG get all the attention, Natalie? Do you want to go over that really quick and then we can wrap up?

Natalie MacLees: Yeah. I mean, I think generally, the number of websites and web apps that WCAG applies to is, you know, maybe billions, right? But at least hundreds of millions. And so it’s just a much bigger area. And when we look at authoring tools, that’s a much smaller subset, right? There’s probably like one authoring tool for every several thousand or, you know, Websites. then when you get to user agent, that’s even smaller, right? There’s even a tiny number of user agents that everyone in the world is using, just these handful of different user agents. So I think that’s mainly what it is is that it’s just the number of things that it applies to is the difference between, you know, billions versus maybe tens of thousands versus literally like 10 user agents.

Natalie Garza: I think the ATAG is like the middle child, right? Forgotten.

Natalie MacLees: It is the middle child, the forgotten middle child.

Natalie Garza: Yeah. Like, UAAG, they have a few browsers. All eyes are on them. They’re the first child.

Natalie MacLees: Yeah.

Natalie Garza: The last child? WCAG.

Natalie MacLees: That’s the baby of the family.

Natalie Garza: Yeah. 

Natalie MacLees: What’s, what’s PDF/UA?

Natalie Garza: PDF/UA is the uncle. 

Natalie MacLees:The uncle who lives in his van. 

Natalie Garza: Smells questionable.

Natalie MacLees: The uncle from Napoleon Dynamite.

Natalie Garza: “I bet I could throw a football over those mountains right there.”

“If coach would’ve put me in fourth quarter.”

Yeah, that’s PDF/UA.

Natalie MacLees: All right.

Natalie Garza: We’re getting carried away again! The drama, the drama with these cousins, it’s too much.

Natalie MacLees: All this family drama.

Natalie Garza: Yeah, the family drama, we’re getting too carried away. Okay, let’s wrap up the podcast.

Natalie MacLees: All right. I think we have to say something to wrap up

Natalie Garza: Yes. Okay, so with all that said, you guys, those are WCAG’s cousins. Much less known, but now you know they exist, so reach out to your authoring tools, if you spot any accessibility issues or any, anything that could help you make your content more accessible, send the messages, move them, make, shake them, and then

Natalie MacLees: Vote with your dollars.

Natalie Garza: vote with your dollars.

Let the turntables . We met UAAG, the other cousin for user agents of browsers. Maybe? Operating systems, not confirmed. And then we met PDF/UA, the weird uncle, who is used in conjunction with WCAG. But there’s extra accessibility guidelines, just for PDFs. 

Natalie MacLees: You might need to say that again. 

Natalie Garza: Um Was it? Oh yeah. And we met PDF/UA, the weird uncle, who is used in conjunction with WCAG, but there’s also additional guidelines just for PDFs. They’re very finicky. So with that said, thank you for joining us for the 12th AAArdvark Accessibility Podcast. Natalie, do you have any last words? Where could we learn more about WCAG? 

Natalie MacLees: Yeah, if you want to test out your homepage for free, you can come to AAArdvarkaccessibility.com. Find out all the WCAG success criteria that you might have failures on your homepage. 

And AAArdvark now has a PDF remediation available as a service. So if that’s something you’re interested in, get in touch.

Natalie Garza: Yes. $10 a page.

Natalie MacLees: $10 a page.

Natalie Garza: So with all that said, thank you guys for joining us!