AAArdvark® Accessibility Podcast

Adding Digital Accessibility to Your Web Agency Services Part Two

Episode 36 of the AAArdvark Accessibility Podcast explores actionable steps for integrating accessibility into various services offered by web agencies, from web development and SEO to branding, marketing, and website maintenance.

Adding Digital Accessibility to Your Web Agency Services Part One

In the 35th episode of the AAArdvark Accessibility Podcast, co-hosts Natalie Garza and Natalie MacLees [https://www.linkedin.com/in/nataliemac/] discuss the critical importance of incorporating digital accessibility into web agency offerings. Natalie MacLees, an expert with over 20 years of experience, explains the increasing legal requirements for accessible websites, the risks of non-compliance, and the benefits of accessibility, including improved SEO and expanded market reach.

Accessibility Meets SEO: Boost rankings and usability with the same fixes?!

Join co-hosts Natalie Garza and digital accessibility expert Natalie MacLees for episode 34 of the AAArdvark Accessibility Podcast. This episode delves into the overlap between accessibility and SEO, highlighting how both can benefit from keyword targeting, content readability, page titles, link purposes, headings, and adaptable content. The hosts discuss various Web Content Accessibility Guidelines (WCAG) criteria that also enhance SEO and provide practical tips for making your website more accessible and search-engine-friendly.  INTRO: ACCESSIBILITY MEETS SEO Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast [https://aaardvarkaccessibility.com/podcasts/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 [https://ahrefs.com/blog/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 [https://aaardvarkaccessibility.com/wcag-plain-english/1-1-1-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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-2-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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-4-link-purpose-in-context/]? 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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-guideline/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-guideline/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [http://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.

Keyboard Accessibility 101: Basics You Can’t Ignore

Join Natalie Garza and Natalie MacLees on the AAArdvark Accessibility Podcast as they discuss the importance of keyboard accessibility in web design. The episode highlights why some users rely on keyboards instead of mice or touchscreens and provides key insights and practical tips for ensuring websites are fully navigable via keyboard. Topics covered include the importance of using semantic HTML, testing custom components thoroughly, and understanding native keyboard interactions. Natalie Garza: Hello everybody, and welcome to the AAArdvark Accessibility Podcast [https://aaardvarkaccessibility.com/podcasts/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 [https://aaardvarkaccessibility.com/wcag-plain-english/1-3-1-info-and-relationships/].  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.  [https://aaardvarkaccessibility.com/wp-content/uploads/2025/08/Native-date-picker-2-1024x538.png]HTML code for a date input with min, max, and default value, displayed with a native date picker showing June 22, 2026. 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.  [https://aaardvarkaccessibility.com/wp-content/uploads/2025/08/Native-range-slider-1024x272.png]HTML code for a range input controlling volume, shown with a styled slider set to 60. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-1-1-keyboard/#4a236bec]. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-1-2-no-keyboard-trap/] 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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-7-focus-visible/]. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-1-2-no-keyboard-trap/]. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-3-focus-order/], 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-1-bypass-blocks/]. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/2-4-13-focus-appearance/]. 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. [https://aaardvarkaccessibility.com/wp-content/uploads/2025/03/2.4.13-Examples-of-different-focus-indicators-v2.png]An annotated webpage showing various visual focus indicators like borders, drop-shadows, background and text color changes, underlines, insets, and outlines on different elements. 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 [https://aaardvarkaccessibility.com/wcag-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. [http://aaardvarkaccessibility.com]  Natalie Garza: Yeah, and you can also sort by the theme of keyboards [https://aaardvarkaccessibility.com/wcag-theme/keyboard/], 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 [http://aaardvarkaccessibility.com], you can sign up for an account and for free [https://app.aaardvarkaccessibility.com/register] 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.

Making Social Media Posts Accessible

Join Natalie MacLees and Natalie Garza in the 32nd episode of the AAArdvark Accessibility Podcast as they discuss how to make social media posts accessible. They cover using emojis, shortened links, adding alt text to images, creating easy-to-read text, avoiding fancy decorative fonts, and ensuring videos have captions and audio descriptions. Learn practical accessibility tips to enhance the inclusivity of your social media content! SOCIAL MEDIA WITHOUT BARRIERS Natalie Garza: Hello, everybody, and welcome to the AAArdvark Accessibility Podcast [https://aaardvarkaccessibility.com/podcasts/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 [https://aaardvarkaccessibility.com/the-good-the-bad-and-the-ugly-emojis-and-accessibility/]. 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 [https://aaardvarkaccessibility.com/wcag-plain-english/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,” [https://aaardvarkaccessibility.com/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) [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://aaardvarkaccessibility.com/wcag-plain-english/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 [https://www.videotovoice.com/audio-description-matters/camel-case/]‘) 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 [https://aaardvarkaccessibility.com/wcag-plain-english/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) [https://aaardvarkaccessibility.com/wcag-plain-english/1-2-2-captions-prerecorded/], 1.2.3 Audio Description or Media Alternative (Prerecorded) [https://aaardvarkaccessibility.com/wcag-plain-english/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 [http://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 [https://aaardvarkaccessibility.com/free-accessibility-test/]. 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.