A11y: Myths and Misconceptions
Join 12 fantastic women speakers for exciting talks on web development, JavaScript, tech culture and career development.
Inclusive content writing is more than providing atl descriptions for images and transcripts for videos. It’s authoring material that is considerate, respectful, and accessible to a diverse audience, regardless of their background, identity, abilities, and learning styles. Inclusive content writing ensures everyone can engage with and understand the presented content. Attendees will gain a better understanding of how people with various neurological disabilities perceive content and how to apply the applicable WCAG 2.1 Success Criteria. This talk also covers a few best practices for authoring inclusive content to improve the user’s experience. We will also dive into modern technology, such as AI, to assist with the writing process.
I’m a Front-end Developer with over 28 years of experience in the field and an independent recording artist. With a background in Behavioral Psychology, specializing in Neurology and Graphic Design, I bring a wealth of knowledge and expertise to my role. As a Staff UI Engineer, certified accessibility professional, and international speaker, I focus on advancing accessible front-end development.
Homer Gaines 0:14
Thank you very much. Hello, everyone. Today I’d like to speak with you about, you know, beyond all descriptions and authoring accessible content. As Brian said, I am a certified accessibility specialist, as well as a front end engineer and public speaker. Majority of the time when I’m dealing with public speaking aspect, I am talking about accessibility issues around the web, because it’s very important that we all do our best to make sure that we are the products that we are building are as inclusive as possible. So again, excuse my voice, allergy season kicked off, and it decided to rob me of my speaking voice yesterday. And so I’m still getting it back. So if you hear the cracks and things, you know, if you roasted me on social media, that’s fine. I have thick skin. But um, so let’s talk about accessibility real quick.
Homer Gaines 1:13
So accessibility as developers, especially when we’re dealing with content, we’re usually the last ones who have to touch all of the files before they actually go live. But these are the times where we have the ability to spot some of the issues that actually may make it out into the public high for users and for customers. And these are actually the times when we can actually make those corrections. So accessibility, for those of you who are not familiar here in the United States is governed by the Americans with Disabilities Act of 1990. There are several different economies, in fact, 770 different economies all over the world who have some type of accessibility law, on their books that require applications and websites, to some degree, to be accessible to individuals with disabilities. Here, if you’d like to learn more about that, you can always go to va.gov and find out a whole lot of more information about accessibility. So what I get this question a lot are the statement. You know, people with disabilities don’t use our products. This couldn’t be further from the truth. Typically, when you mentioned someone with a disability is the physical aspects that appear in someone’s mind. So we may picture someone with mobility disabilities who are using a wheelchair or they have a prosthetic limb. Or you may see someone who is wearing glasses and they have a cane, that person is blind. These are disabilities that you can visually perceive and attribute to that person. But not all disabilities are visible. The largest group of disabilities is cognitive. There are a lot of people throughout the world who have cognitive disabilities. And since we’re talking about content, we need to be concerned about individuals who have visual disabilities. And low vision is something that is classified as a visual disability that cannot be fixed, using corrective measures such as, like these glasses and so forth. The other thing is dyslexia. There are various forms of dyslexia, colorblindness, things like that. We have to be aware of all of these different disabilities that our users could potentially have when they are interacting with our application so that we are able to provide the best user experience for them.
Homer Gaines 4:08
So one place that I always recommend developers and anyone start is with the WCAG. Currently, we have the WCAG 2.1 2.2 is set to be released sometime this year. It’s in review, but we see but the WCAG is short for Web Content Accessibility Guidelines. And one of the important parts of the WCAG is that we adhere or work towards the level doubleplay. Success criterias that are within side. The WCAG is broken up into four major sections Perceivable, Operable, Understandable, and Robust. What I want to talk to you today about really deals with perceivable and understandable for how we’re dealing with content First of all, let’s look at the use of color, which falls underneath perceivable. Use of color is very important because people have to be to, one perceive the content that you have on your website, whether it’s marketing, whether it’s documentation for an application that you’re building, whether they’re very important instructions for a user to follow when filling out a complex form, or even just a simplified form. So one point 4.1 use of colors states that color is not used as the only visual means of conveying information, indicating an action, prompting a response or distinguishing a visual element. But why is this important? I like to use this example blue yellow color blindness. The reason I like to use this example is because the native color of text links Online is blue. However, if we start to manipulate that, we can cause Pete and we can cause problems. For those who have blue yellow colorblindness. For example, take this paragraph, there are links inside of this paragraph, those links are blue. But because you really can’t tell them from the rest of the body copy is easy to miss. Now, for anyone who can perceive blue, it’s very possible that you’ll understand or perceive that headings are primarily mechanisms used by screen reader users to navigate content at the top of this paragraph, that’s the link. However, if someone were to have blue yellow colorblindness, this is what the content would look like to them, it makes it harder to perceive that that is a link. And therefore, they would not know to click on that, and could miss it entirely. So when it comes to not just using color alone, to convey meaning, meaning that this is a link. That is why we use our underlines.
Homer Gaines 7:07
A lot of us have seen copy throughout the web where these types of affordances have been removed. But it’s important to remember that even though you may be able to perceive the color of the link or tell that as a link, not everyone has that ability to do so. Color contrast is another aspect of the web that seems to be overlooked at times, it also falls underneath perceivable. Here are a few of the categories or the success criteria within the WCAG. That would apply three, three, or 131 and four relationships, one for one use of color, which is what we just discussed 143 contrast minimum is a level double A 146. Contrast, enhance is a level triple A, and one for 11 is for non text contrast, that’s for things like images, or images of text itself is really important to make sure that we have good contrast for our copy. Or else someone may not be able to perceive it, especially those who have various forms of color blindness, or low vision.
Homer Gaines 8:22
There is a website that’s out there now a company called webbing. And every year, they do a survey where they test 1 million websites. And those websites come back with various accessibility issues that they discover. These tests are both automated through through AI, but also manual tests. But what they have found is that 83.6% of the homepage is that were tested, have some type of contrast, minimum failures. So there are a lot there’s a lot of opportunity for all of us to pay attention to the content that we are designing and developing to make sure that it is meeting the minimum requirement for users to be able to proceed. Because if our if our users use our product, and they can’t detect or perceive or understand any of the information that’s there is pretty much useless to them. So with the contrast minimum, one dot 4.3. The visual presentation of text and images of the text has to have a contrast ratio of at least 4.5 to one. This will help ensure that there is that minimum contrast for anyone to be able to perceive it such as the text that is on my slides right now. But if I were to go back to this slide, you can obviously see that the color is much more faint. This is a lighter shade of gray For anyone who may have low contrast, visual, visual disabilities, or they even may have their monitors brightness, set all the way up as high as it can go. Or even, let’s say a situational impairment, such as they are in an extremely bright environment, the sun may be coming over their shoulder, this will be difficult for them to see, because of the lack of contrast. The other part that I’d like to get into since we’re talking about is headings, headings are also perceivable. Headings help us find our way around a document that is structured correctly. It has rule with inside the WCAG. One that 3.1 info and relationships, information structure and relationships conveyed through the presentation, camera can be programmatically determined, or are available in text. And what this means is that we are writing our content in a way that is is accessible to not only those users who can visually see the content, but by providing it in a programmatically determined way. It is accessible to people who use screen readers, refreshable braille readers, and so forth. That way it is available to them. 64% of screen readers according to a study that was done at a university and in Australia, 64% of their screen readers use headings to navigate the page. For anyone who was sighted in their reading content, you have the ability to scan quickly through a document. But someone who has to use a screen reader who may be blind, the way that they scan through a document is by jumping through the headings. So if you have your document structure correctly, that means your headings are in the correct order. That means that the information and the context is received correctly.
Homer Gaines 12:11
We can all think about how we used to use Word documents or structure Word documents. When we were back in school when you had to write reports, and you would often see something like what I have on screen now in a drop down menu where heading one was often the largest heading one heading two was slightly smaller and may have a different visual style to it and heading three was smaller as well and going down the line. Well, what happened over the years is that we had learned to take this same type of pattern onto the web. But it kind of messed us up. Because if you were to natively just use h one and h two and H threes in your HTML document without using any CSS to style them, you will notice that they have a predetermined setting that dictates how large they are how they actually render on the screen that follows how we use the right word documents. Well, the problem is this. A lot of times we’d like our headings to be uniform. And as a result, we end up in creating documents that have incorrect heading structures. For instance, this document that I have here, it shows several different headings within this document. It should be headings that are at different levels. But unfortunately, the author of this document, use all h ones when putting this dot when authoring this document. And so what ends up happening, it’s a very flat document that does not allow you to have the proper structure and understand what information falls under which particular heading. And for those who weren’t. Sure, here are the different headings that are here. That were all h ones. So we hear an argument, you know, often when we’re writing our content, where it’s like, you can use multiple H ones on a webpage without any problems. Yes, you can. But the problem is this. When it comes to the HTML spec, the suggestion was put out there to allow for browsers and other agents to be able to support the use of H ones. But that suggestion never was implemented. And as a result, the support for multiple H ones is not out there in the world. And for assistive tech such as screen readers, legacy and new or or any other types of technology that are being used, they do not have that support built in. And so what you end up doing is running the risk of confusing your users. Because you may have multiple H ones. In such as the example that I have here, you want your heading structure to follow the sequential order, each page should already have an h1 on it. From there, you should have an h2 and h3 something that goes all the way down possibly, to h6, anything above an h6 is definitely invalid, because an h7 does not exist in the HTML spec. So if you see if you see content that has an h3 and h1 and h2, and another h1 and an h5. You know right now, from that, that it’s incorrect, that headings structure is incorrect. And if someone were traversing those headings using screen readers, that means that they would be bouncing all over the place because they’re not in sequential order. So it’s best to have them in sequential order, start with an h1. And then your next one would be h2, you can have as many h twos as you need, you can have as many h threes as you need, and so forth down the line. But rule of thumb, you always want one, h1. And then when it comes to styling, well how should we style them if they already have the h1 is supposed to be the largest. That’s when you want to separate the styling from the actual HTML element itself. So in some documents, you may see that there is a style css directly applied to the heading such as an h1 and h2 or an h3, well, that’s going to be incorrect. Because this does not allow you to maintain the style while using the correct HTML heading in your markup. Instead, what you want to do is apply a class to those headings that has the desired visual appearance that you need. That way, you can have the h1 and the h2 and h3 and if you wanted all of those to have the same visual appearance, but structurally set up the document so that it is correct, then using classes will be the better way to go.
Homer Gaines 17:24
Same with body copy, body copy falls underneath understandable. So it’s readable, the language of the page, the reading level, and labels or instructions. All these come into play when we are writing our body copy, because we want the individuals to be able to understand the copy that they are reading so that they can get the information that they need. Because it’s very important this to them and us, using the clearest and simplest language appropriate for the content is the way to go. We’ve also seen documentation that is written in such a way that you have to scratch your head or you have to go back and you have to read it several different times because it may be using industry jargon that you’re not familiar with. Or just may be using a different language that you’re not even familiar with, using phrases and slang that you’re not familiar with how many times have you found yourself reading something, you have to go and google that Word or Google that acronym, till you at least get an understanding of you know what was just presented to you. So using plain language, simple language, body copy tips. Keep your body copy conversational. Write it as a way in a way that you are speaking to someone not speaking to a computer, but speaking to someone for them to actually follow along with you and understand, be able to comprehend and be able to take and gain some value out of the information that you’re presenting. Be mindful of the industry jargon and acronyms. Not everyone may be familiar with your business, your line of work, the services you provide, or your application in general. So when you start to use a lot of industry terms, you could actually lose that person. For instance, if I’m speaking to someone about typesetting and I start to mention kerning and letter height and ligatures. If they are unfamiliar with kerning and typesetting, and so forth, they will not understand what that is. So when said I start to speak about the spacing between letters or the spacing between each line, but as I’m explaining that, I am also giving them the word while explaining the definition so that they can follow along. One thing we definitely need to be aware of is that literacy does not equal education. 79% of the adult population in the United States is literate. They understand that literacy means that that person has the ability to communicate and write and understand that in their native language. However, only 54% of adults are below the sixth grade literacy level. That’s where the education aspect falls in.
Homer Gaines 20:29
So if you’re writing your documentation, say, for instance, at a master’s degree, if it’s written like research journal, you may be over the heads of your audience, regardless of who may who may be reading it, you may have this persona in your head when you are authoring your content. But keep in mind that over half the population is below or at the sixth grade level for literacy. Statistics also show that of the 54% 34% of those adults, English is not their first language. So we have to be mindful of everyone who may be reading the content that we have, because our products are open to everyone. We’re not discriminating or at least you shouldn’t be discriminating against, who can use your product and who can’t. So therefore, keep in mind, all of the population, anyone that may be able to access your product, so that we can provide the information in a more user friendly way for them.
Homer Gaines 21:43
Throughout the web, we’ve seen this example plenty of times, click here. There is a problem with links that just say click here. Right now, there is no other context around these words. So therefore, if you see this, you don’t know what the context is either. It’s just click here, right? It’s a mystery to us all. Reason being, it lacks the content. Because we are more focused on the mechanics of the action that is used. This will be more like a CTA call to action. Yes, click here. But what am I supposed to do? Instead, what we want to do for our links, and for our buttons, this falls underneath understandable. We want to avoid leaning into the mechanics of the language, or leaning into the verbs for the of the language that we use, such as this example, tell me more about accessibility. If you were to remove all of the other content, tell me more. It’s the only thing that’s left. Tell me more about what someone who is using a screen reader, such as a Mac, voiceover voiceover has a very unique way of allowing individuals to jump through the content, and it’s called use is called rotary menu. If they were to see this, tell me more would be the only thing that they would see or perceive. Instead of having Tell me more, which is the verb, have more about accessibility as the link, because now, as they go through the content, as they would jump through those links, even if they miss the tell me, at the beginning of the sentence, more about accessibility provides more context about what that link is going to do. This is an image of the rotary screen, it shows all of the links, it has menu, link menu, link menu, link menu link, we’ll just stick with those four examples at the top menu link menu link, and you link manually for different links that have incorrect labels. They all have the same label, but don’t tell the user what they are. All of our links should be unique in such a way that when someone is using an assistive tech, void of all the other content, they are able to understand what length they’re going to go to, and what that link is supposed to provide for them.
Homer Gaines 24:25
And when it comes to testing, screen readers, screen readers will be your best friend, screen readers. For those of you who have never used them. I will admit they can be scary at times. The first time that I ever used a screen reader. It was definitely scary for me. But over the years, I grew us to be able to use screen readers. I use screen readers in my day to day activities. I use screen readers when I’m testing other applications for accessibility support. If you have a Mac If you have a screen reader built in, it’s called VoiceOver, I highly recommend that you go through the tutorial, and learn to use it for your testing. If you’re on a Windows machine, you have two options, well, you have more than two options, you have NVDA, which is an open source screen reader that you can use. And you have Jaws, which is the number one screen reader. It comes with a license even though there are other screen readers narrator is built into Windows. And then also if you are using a Linux machine, you have orca that you can use, testing is paramount. It will help you understand how individuals who use screen readers and other assistive tech actually integrate, interact with and perceive the information inside of your website, your application, your product.
Homer Gaines 25:55
And that leads us into empathy. Empathy means that you learn and understand how someone else feels. There are three types of empathy. There’s cognitive empathy, there’s emotional empathy, and there’s compassionate cognitive empathy, our ability to understand what someone may be thinking, and how they feel. This is very important, we need to be able to understand what that person might be going through, which leads us into the emotional empathy. Once we can understand, then we can begin to put ourselves in that person’s shoes so to speak, we can start to walk the same path that they are walking experience the same things that they are experiencing. Now, granted, it may not be you directly but say for instance, you are using a screen reader, you are now learning how your application sounds to someone who must use a screen reader in order to be able to interact with your software, it puts us in that person’s shoes even more so you can relate to what that person is going through. And compassionate empathy, compassion and empathy is where it really gets real. This is where we actually take what we have learned and apply it. This is us recognizing that our application has accessibility shortcomings. And now we are doing something to make it better for users. We have, we have an example that we use in the accessibility space, where we talk about curb cuts. For those of you who are not familiar with what a curb cut is, I’m pretty sure you have come across one in your life as you’re walking down the street, and there’s a ramp that slopes down to the street level off of the sidewalk. And there’s a ramp that slopes up to the other side. That is called a curb cut. Now, it seems very simple and easy to navigate. Because those of you who are sighted, you can perceive it and walk without any problem. It’s a nice transition. It benefits you even though you may not have a visual disability, accessibility benefits, everyone, you do not have to have a disability in order to gain or have a positive user experience from accessible code. And in this aspect, accessible content. So thank you for allowing me to speak with you all today. Thank you for listening. Thank you for attending. Hopefully Have a blessed day.
Brian Rinaldi 28:56
Homer, that was fantastic. I’m so glad that you got your voice back so that we could have this session because I think it was really important for everybody to see. So you know, get to thank you for that. So we did have a couple audience questions, but I just wanted to like this thing that struck me was kind of that your last point there which I had been thinking throughout the whole thing because you were talking about how you know do this and that to improve accessibility and like that, that improves for everybody. everything right? Like I mean, like it’s not benefiting somebody with a disability. That’s just going to make your site better.
Homer Gaines 29:32
It makes your site better. Yeah.
Brian Rinaldi 29:34
Great tips. Okay, so we have a few questions from the audience. I’m going to just kind of start with those. So Richard asks, when dealing with accessibility issues detected through automated testing, say the WAVE tool, or warnings considered not passing success criteria? For example, skipped heading levels.
Homer Gaines 29:56
Okay, so skipped heading levels is what my slide was referring or to when the headings were all out of order. The problem with that it does fail the WCAG, which is what the automated testing, those rules are written against. So that’s why you’re going to have that failure. So for anyone who just may be visually, looking at the documentation, they’re not going to see any issue with that, because they’re not aware of the h1, h2, so forth. This is at the machine level. So because you have those skipped levels, when someone is navigating, just using the headings, they can lose the context of your documentation. If your headings skip those levels, so say, for instance, the first paragraph, or the second paragraph requires knowledge of the first paragraph, or the third one requires knowledge of the second paragraph. If the user goes from the first paragraph to the third one and a completely skip the second one, that’s information that was missed, that can cause friction in the users experience, it can cause them to make errors, if it’s something important that was necessary. So that’s why it’s important to make sure that your documentation is structured correctly, structured correctly from a market perspective, designed how you like, but again, your design should not be so out of the box, that the structure itself that you lose the ability to actually read that document in a correct way.
Brian Rinaldi 31:45
Okay, yeah, that’s, that’s good info. So, like, I think, even if, even if you say, as a matter if you go, say, from h1 to h3, even if they’re technically like, but you skipped one, even if they’re technically in order, do you have to have that like h2? Or? Or just Yes,
Homer Gaines 32:06
you want you want that h2, you shouldn’t use h3 If there’s no, there’s no need for it, don’t use it.
Brian Rinaldi 32:13
Okay, that makes sense.
Homer Gaines 32:14
There was a document that I was remediating, that had me cracking up because for some reason, they invented an H nine. And you styles, but the thing is, because it wasn’t valid. Screen readers weren’t picking that up. So those sections were completely missed. But again, if I’m jumping through all of the H TOS in a in a document that is structured correctly, the h1 lets me know, this is the page that I’m on. This is our About Us page h1 title. Okay, cool. I’m going to hit the H TOS because I want to see what the rest of the content is. And if all I’m doing is going through the H TOS if you didn’t use an h2, and all of a sudden you interjected stuff in an h3, and I’m not looking at h threes, or using h three, navigate because I expect to follow a logical reading order. I’m going to miss that content.
Brian Rinaldi 33:14
So you’re saying that H’s are not infinite?
Homer Gaines 33:19
Yeah, no, no.
Brian Rinaldi 33:23
Okay, Nick asks, I’ve only used MAC OS voiceover, how much does the screen readers differ? Or do they offer the same feedback?
Homer Gaines 33:33
Screen readers are different? They are. The accessibility space is fragmented. You know, just like the differences you’re going to have between a Windows machine versus a Mac versus Linux, you know, you will have those differences. Do they all accomplish the same thing at a high level? Yes, they allow the user to perceive the information that is on the screen that is important to them. How you interact with screen readers are different. Out of the box, screen readers have different configurations. The key commands that are used to manipulate NVDA, which is a screen reader that I use on a regular basis is not it does not have the same key commands as JAWS, it definitely does not have the same key commands as VoiceOver on a Mac, which I also use. So you have to be mindful of that. In addition to that mobile devices have screen readers. There’s talkback on Android devices which use and then there’s VoiceOver on iOS devices, which somewhat behaves like VoiceOver on a Mac, but there are subtle nuances, but for the most part, using a screen reader to be able to report back the information is going to, you know, do the same thing. I mentioned language of parts. You know, if you are working on a website or an application that requires you to use multiple languages, he will see the differences there. If you do not call out or use the language attribute around that particular language block, like say, for instance, your content is in Spanish, French and English all on the same page. What do you want to do for individuals who are using assistive tech is using language attribute that wraps that content. That way when they’re using their screen reader, the screen reader will automatically switch over and use the correct pronunciation for those words in that language. Because if you don’t, then you end up say, for instance, if your United States, you end up with a screen reader reading back French, and Spanish with an English accent, which I don’t know if you’ve ever heard it is awful. Don’t. So that’s the importance of that. But that’s the subtle differences that you will notice in the screen readers. Now. Again, if you’re on a Mac, and you only have access to voiceover, you don’t have a PC or anything like that. Use your Mac. Use your Mac is better than not using anything.
Brian Rinaldi 36:24
Right. Good. Good. Good tip. Okay, so we got a bunch of questions. And we only got a couple minutes. So I’m going to, I’m going to get one more question in and then I’ll let you tell people how they can reach out to you and hopefully get their get their questions answered. So what is your Christopher asks, What’s your opinion of tools such as Accessibe, Do you know this tool Accessibe?
Homer Gaines 36:51
Oh, goodness, are we talking about overlays, don’t use an overlay, I will find you do not use overlays. There is a website out there called overlay factsheet believes.com, or dot info. overlays are not a solution to fix accessibility issues. They just aren’t, they cause more problems than they help with. In many cases, in order to activate an overlay, you have to be able to see the button or perceive the button in order to turn it on. If you have to go through that to activate accessibility, you’ve already failed. Because someone who cannot perceive it get to that button is never going to be able to do anything. What they’re doing is using JavaScript to manipulate the DOM in such a way that they think that it’s accessible. But there’s plenty of research already. Tons of lawsuits already that prove that overlays are no one’s friend. So I recommend avoiding them.
Brian Rinaldi 38:05
Okay, that’s good to know. Okay, so that was like I said there was more questions, but we are out of time, unfortunately. So how can people reach out to you if they want to ask these questions?
Homer Gaines 38:16
Anyone can hit me up either on LinkedIn, my name Homer games, you can find me on LinkedIn. If you’re on socials, whether it’s Twitter, X, whatever we call it these days. Or if you want blue sky, I am xirclebox. So feel free to hit me up there. If you have any questions I’ll be happy to to answer
Join 12 fantastic women speakers for exciting talks on web development, JavaScript, tech culture and career development.
Join 12 fantastic women speakers for exciting talks on web development, JavaScript, tech culture and career development.
Obinna Ekwuno makes the case for prioritizing web accessibility based upon our sense of self and of empathy.
TheJam.dev is a 2-day virtual conference focused on building real-world applications using the Jamstack.
TheJam.dev is a 2-day virtual conference focused on building real-world applications using the Jamstack.