Don’t Ignore 100 Million Users: Make Your Website Accessible Today

In 2018, Section 508 web accessibility rules have grown more robust and detailed — creating new challenges for anyone who manages a website. And given that more and more organizations are being sued for offering non-accessible websites, it’s critical to understand the new accessibility guidelines.

In this example-filled webinar, we’ll explore how you can adhere to these new rules. By the end of this lively, eye-opening talk, you should be able to:

• Describe why web accessibility matters to everyone
• Implement basic accessibility practices in your website CMS
• Distinguish between the different levels of Section 508 and WCAG standards
• Use basic principles to build websites that adhere to the newest rules
• Test your websites for accessibility errors

If you’re able to guarantee that you meet Section 508 standards, you’ll be able to build more usable, bigger, and better-respected sites.

TRANSCRIPTION OF WEBINAR

Stephen Tidmore:

Hi, everyone. My name is Stephen and I’m happy to be conducting this webinar today and just talking about some high-level topics about web accessibility. So let’s go ahead and jump in.

So, just a quick agenda—and the first thing I want to say is that this is meant to be a pretty high-level overview and not necessarily a deep dive into any particular accessibility topic, because we could spend a long, long time talking about any topic on accessibility, even minute details, because there’s a lot to cover, but I do want to make sure that we cover these four main things.

So, by the end of this talk, you should be able to at least understand what web accessibility is and why it matters. We’re also going to introduce you to the new Section 508 accessibility requirements, again, at a pretty high level, but I want you to have some understanding around what the new guidelines are. And then you should also be able to learn a little bit about how to implement some basic accessibility best practices on your own website. And then we’re also going to cover some useful testing tools, so you should be able to test your website for accessibility.

Okay, so what is web accessibility? Most of you may already know this, some of you may not, but this is just a quick definition. So, web accessibility, it is websites, apps, or applications, and digital technologies that are designed and developed so people with disabilities can use them. So, at a very basic level, it means, if we’re talking about websites, that your website can be used by a variety of users with different disabilities.

So why does accessibility matter? Well, here are a few statistics. There are 56.7 million Americans, which is 18.7 percent of the US population, that have some type of disability—and these numbers come from the 2010 census here in the United States. Out of those, there are some different categories. So 19.2 million people have difficulty listening or grasping. What that means as far as web accessibility is concerned is this could prohibit their use of a mouse or a keyboard, for example, and they have to rely on a variety of assistive tools to type or just to speak into the computer.

15.2-million people have some form of cognitive, mental or emotional impairment. And so while that may not always be thought of as web accessibility, it does play a pretty big role in making sure that your website is usable, that people who have some form of cognitive impairment, they may have difficulty understanding a complex set of tasks that have to be created on a website or a complex form you have to fill out or a complex navigation, and so it is something we definitely want to make sure we take into account.

8.1-million people here in the US have some form of vision impairment. This is one that is often thought of when we’re talking about web accessibility. Most people go straight to this one because these are people who may be completely blind; they may have to rely on a screen reader, which actually reads out all the text and links of a web page; they may have to rely on a screen magnifier or a zoom tool so they can just zoom in on certain sections of a webpage; or they may even just have some form of color blindness, so they may not be able to differentiate between different colors.

There are 7.6-million people also that have a hearing impairment. And so what this means, of course, is that they might need to rely on transcripts and / or captions for audio and video.

This number comes from a Pew Research study in 2016 and 50 percent of adults living with a disability use the internet every single day. So if you doubt or think that most people who have a disability aren’t using the internet, that is not true. Fifty percent use it every single day. This is across all age ranges. The numbers actually jump up if you just look into 18-to-64-year-old age range. There are 70 percent of adults who had disability who use a Smartphone and 67 percent use a desktop or a laptop computer. So just in the 18-to-64-year-old age range, people are using these technologies and they’re using your website, for sure. And the aging population is predicted to triple to 1.5 billion by the year 2050. What that means, of course, is as people age, they tend to have more disabilities, and so you need to be taking accessibility into account, not only for now, but definitely for the future, because the number of people who have disabilities is just expected to grow.

What all those numbers mean is that if your website is inaccessible, you’re potentially excluding, right now, about 20 percent of the population from the conversation on your site, and that number is going to keep growing. So between being accessible for your visitors now and thinking about your future audience, it’s clear that implementing web accessibility initiatives should be a very high priority in your organization. So another big reason to make your site accessible is simply because it’s the law.

The big one that we’re going to talk about today and that you may have heard of before is called Section 508, originally of the Rehabilitation Act of 1973, and it was just refreshed. We’re going to talk a little bit about what those refreshes are here in a little bit, but Section 508 applies to all federal websites—and often other government websites require Section 508 compatibility, and other organizational sites. So even though it may not be the law for them to require compatibility with the Section 508 guidelines, a number of organizations will say they require Section 508. There’s also state guidelines. So, for examples, here in Texas, we have TAC 206, which is the set of guidelines that Texas state agencies have to meet, and so states have their own laws across the country.

Some people think that only government websites have to be accessible because of the Section 508 laws. However, there are a large number of lawsuits that have been filed against regular companies for not having accessible websites, and the reason is this one right here, which is Title III of the ADA, and the ADA is Americans with Disabilities Act. And what Title III says is that it prohibits discrimination against someone with a disability in places of public accommodation. And so that word right now, public accommodation, that phrase, so far, has been defined by the courts to include websites. There has been some debate over that and there’s definitely going to continue to be a debate about that in the courts as for whether or not websites are defined as places of public accommodation, but the fact remains, for sure, that any website can be a target for a lawsuit. In fact, there were 7,663 businesses in the US that were sued over accessibility in 2017. Here’s a quick chart and it just shows you that the number of these lawsuits have been increasing over the past years. And while this particular number includes physical accessibility lawsuits as well, it’s just not web-accessibility lawsuits, the numbers and the increase in numbers seems to be driven a lot by the number of web accessibility lawsuit filings.

I only expect this number to continue to increase as websites become more and more integral to our everyday lives and it’s easier to define those websites as places of public accommodation. And there’re some huge names here that have been sued, such as the NBA, NCAA, Toys “R” Us, Domino’s Pizza, Reebok, Panera Bread, AMC Theatres, Target. Target paid—this was a while back, but had to pay $6 million to settle a lawsuit filed by the National Federation of the Blind, plus $4 million to cover their legal fees. So you definitely don’t want to ignore accessibility, even if you’re not required to meet Section 508 guidelines. You still want to do all you can to make your websites accessible to all users, for sure, not just because it’s the law, but because of the number of people that you’re excluding from your site if you don’t.

Okay, so Section 508. This is one of the main topics. Let’s do a quick poll here. You guys should see a poll pop up here on your screen in a minute. I’m curious to know how many of you have even heard of Section 508. And so you should be able to answer that now as it’s popping up on your screen.

Laurena Jech:

We’ll give another second or two.

Stephen Tidmore:

Okay, great. It looks like a majority right now. We have about 67 percent of you that have heard of Section 508—68 percent now. So a majority of you have heard of it, but there are a number, about a third of you, who have never heard of Section 508. So let’s talk a little bit about it.

So Section 508, like I said, is the law governing the accessibility of information technology in the federal government. It is a big law, there’s a lot of guidelines, but it does also specifically deal with websites, applications, basically anything that the government defines as information technology. This law has been around for a long time, obviously, since 1973, and there’ve been a lot of changes in information technology since then. They’ve been going through a refresh for quite some time, and so, the new standards have been updated recently.

There was a compliance date for the new Section 508 guidelines for January 18, 2018. So that was the compliance date. However, there is a Safe Harbor provision for existing websites, and basically what that Safe Harbor provision says is that existing websites that are not altered after the compliance date don’t need to be upgraded to meet the new standards. So if you have an existing website and you don’t alter it, you’re not altering it after January 18, 2018, that you don’t have to retroactively go back and upgrade your site. However, if a website is altered after the compliance date, any of those alterations have to comply with the new standards. So basically, moving forward, anything you do on your website has to comply with these new standards.

Okay, so, that begs the question what are the new standards. So the new Section 508 guidelines basically just point to another set of accessibility standards. I know this is another acronym for you, but the acronym is WCAG, and what it stands for is the Web Content Accessibilities Guidelines, and it’s developed with the W3C, which is kind of the organizing body of the web, more or less, and of technologies, and they have this set of standards of WCAG. WCAG is a much more modern and robust set of guidelines compared to the old Section 508 guidelines that does a much better job of describing the functionality of a website needed for a variety of users who have disabilities. The WCAG is really a much better set of standards, in my opinion, than the old Section 508 guidelines. And so the new Section 508 guidelines have started to point to the accessibility standards that are built into WCAG.

There are three levels that you need to meet within the WCAG standards. The first one is just called Level A, and this is the most basic web accessibility features. The second is Level AA and this deals with the biggest and most common barriers for disabled users, so it’s the biggest barriers that a variety of users with different disabilities would encounter when trying to use a website. And Level AAA is the strongest and the strictest accessibility rules, so it’s the highest level of web accessibility standards you can meet within the WCAG guidelines. What the new Section 508 guidelines have done is that they’ve decided they’re just going to point straight to WCAG AA as the new standards. So, moving forward, if your website is compliant with WCAG AA, it will also be compliant with Section 508.

So, let’s look a little bit at a high-level what is involved with the WCAG standards. The WCAG standards are organized around four main principles of accessibility. What these principles do is they make up the foundation for anyone to access and use web content.

So the first principle of accessibility is called Perceivable. What this says is that anyone who wants to use the web must have content that is perceivable, which means that the content and the user interface components can be seen and heard. So, basically, your website, the content and the way you interact with that website can’t be invisible to all of their senses. So you can’t exclude someone because they may be blind or because they may have a hearing impairment. So you need to make sure that the content is perceivable to everyone, which makes sense.

The second principle of accessibility is operable, so anyone who wants to use the web must have content that is operable and must have content that they can interact with, so they need to be able to interact with the interface and the navigation. So, at a more technical level, basically the interface cannot require an interaction that is impossible for them to perform. So if they’re unable to use a mouse, the website cannot require them to use a mouse to hover over something to use that website or that interaction. If they’re unable to use a keyboard, they must have an alternate way to use that website.

So it makes sense. Again, all these are pretty common sense when you think about it at a high level. If someone wants to use your website, then it needs to be perceivable and operable. It also needs to be understandable. So what understandable means is that the content and the operation of the user interface can be understood. And I know that the language here may seem a little bit confusing, but at a high level, basically, it just means that people need to understand how to use your website and they need to understand what you’re writing on it. So they need to understand the information as well as the operation. It can’t go beyond their understanding. This is where the users we were talking about who may have some form of cognitive, emotional or mental impairment, you definitely need to take them into account. You also need to take into account just things like reading level. So, for example, in the United States, the average reading level is the eighth grade, and so, if you’re writing content on your website that is at a much higher grade level, then you are excluding a number of people from being able to understand the content of your site.

The fourth principle of accessibility is robust. This one is a little bit trickier to describe, but basically all it means is that the content needs to be interpreted by a wide variety of user tools. So if someone is not able to use, again, a keyboard or a laptop or a screen or a mouse, then the content on your site has to be interpreted by the tools that they can use, which include assistive technologies. And, as these tools evolve, then the content should remain accessible. So, basically, the content needs to be robust enough to where it isn’t limited to where you have to read it on a laptop screen that’s thirteen-inches wide. You need to have content that is robust enough to be interpreted by a wide variety of tools. Even Smartphones. You can think about it as simple as that. Even Google. So Google may be something that you need to consider, because the content needs to be robust enough to where those tools can read the content. So if any of these principles of accessibility are not true, then users with disabilities will have trouble using your website.

So those are the overall principles for WCAG, but those don’t really provide a lot of information for what you should actually do to help make your site accessible. How WCAG gets structured is that under each of those principles there are guidelines and criteria and techniques to help guide you when building a website. And so the guidelines are kind of the top level and they’re descriptive – and I’m going to give you a samples of this in just a minute, but just so you get a high-level overview – the guidelines are descriptive, but they’re not really easy to test for. These are basic goals that you should work toward in order to make content more accessible.

Under the guidelines, there’re success criteria and these are more testable success criteria—and this is where those labels of A, AA and AAA come in, so each criteria actually gets a label of A, AA or AAA. And then under those success criteria are what they call techniques, and they actually call them sufficient and advisory techniques, and these provide some recommended ways to meet each criteria. Okay, so you see it’s kind of a hierarchy. So let’s go through an example real quick to try to make it a little bit more clear.

The example I’m going to use is WCAG Guideline 2.4. So WCAG Guideline 2.4 is “navigable.” What it says is that you need to provide ways to help users navigate, find content and determine where they are. Okay, makes sense. But it’s not really super easy to test for that, so under that there’s a success criteria, 2.4.1, and what this particular success criteria says is “Bypass Blocks – a mechanism must be available to bypass blocks of content that are repeated on multiple pages,” and this is a Level A criteria. And so what that means is that if you have navigation that repeats on every single page, you need to give users a way to skip that if they’re navigating through a keyboard or navigating via a screen reader, because otherwise they have to listen to that entire header content and navigation on every single page.

Under that, there’s two techniques really that get you to meet this, but the one I’m going to use an example of is they give you this Technique G1, which says that you can add a link at the top of each page that goes directly to the main content area and skips the header and navigation. So if you guys kind of see on that structure, so it starts at a very high level of just kind of a conceptual guideline, and then drills down into here’s what you actually should do on your site. So here’s an example of meeting that particular technique. This is on Deque’s website, who’s a large accessibility company. If you’re navigating via a keyboard, you’ll have this link pop up at the very top of every page which says “Skip to main content,” and if you click on that link or you press enter, it’ll jump you down to the main content and you can skip over all that navigation. So this is an example of a technique that you could use to actually meet that guideline.

So since you guys are going to get this presentation – we’re going to send it out later – here’s just a couple of links for you to refer back to later. The first one is the W3 Quick Reference, and that’s a great, great quick reference site. It just goes over the high level of WCAG guidelines. The second one is the WebAIM WCAG Checklist. WebAIM is another accessibility organization, and they have a great checklist, which they’re very careful to say this is not the WCAG guidelines, but is their version of the checklist to help you kind of see if you’re meeting those guidelines.

So with all of that covered – so you guys understand at kind of the very high level why accessibility matters and some basics about Section 508 and WCAG – we’re going to go through some basic accessibility techniques. What I’ve tried to do is go through some of these that would be understandable to most people, even if you’re not a developer, so I’ve tried to pull out any code or anything like that. Now, obviously, at its core, a lot of accessibility does involve actual code, but the ones that we’re going to talk about here are generally ones that you guys can start thinking about using on your website today.

So the first one is link text. So screen reader users will often have the screen reader just read out links on a page if they’re trying to figure out where to go to quickly, and so every link needs to make sense if the link text is read by itself. So if you can imagine yourself navigating by clicking around on a keyboard and you’re jumping from link to link to link trying to figure out where to go, each of those links need to make sense if it’s read by itself. So you need to provide context in your link text and avoid uninformative link text. So what does that mean? Well, at a very simple level, something that you may see on a lot of websites that you shouldn’t do, you should not use “click here” as the link, you should not use “Read More” as the link and you shouldn’t use long links such as “link to hppts://www.google.com,” because none of those examples actually give you any information about what you are about to click on or go to. If you are reading that by itself, “click here” doesn’t make any sense whatsoever. Now, if you are a visual person and you are navigating, you can see that “click here” may be referring to the content right in front of it, but if you’re a keyboard or a screen reader user or using some other assistive tool that’s jumping around the links, those don’t make any sense.

Also, if you have a link that’s a URL, try not to make it an extremely long URL they have to listen to. So if you need to link to another website or webpage, you can say we’re going to go over to Google.com, but what you don’t want to do is make that a really long URL that’s going to take them thirty seconds to listen to. So do what you can to help out with this and make sure that you use descriptive links. So imagine if you’re reading that link by itself, are you going to have any idea of where you’re going.

If an image is the only thing within a link tag, then it must have alternative text. And we’re going to talk about alternative text in a minute, but I did want to put that note here because it kind of goes along with the links, for sure, that if an image is the only thing with a link tag, it has to have ALT text or it’s essentially invisible.

Skip Links. Okay, this is what we just covered in that WCAG guideline example. You need to provide a method that allows users to skip navigation or other elements that repeat on every single page; for example, a “skip to main content” or a “skip navigation link” at the top of every page which jumps the user to the main content of the page. Now normally this link is hidden until you use a keyboard to access it, normally, and this is something you would have to have a developer at your side if it isn’t there already. It may not be something you can easily add if you’re not a developer, but it is something that’s important. You can also provide structure to your site. So if you are defining the areas of your website by saying “this is the main content area,” “this is the navigation,” that helps as well, that it gets users to skip the top navigation area as they’re going through.

ALT tags for Images. So this is a big one and this is the one that most of time when I talk to people about web accessibility, they almost always talk about ALT tags, because it’s one that is a little bit easier to grasp initially, but I also see this done incorrectly on a number of websites, and so I want to spend a little bit more time with this one, because it is important. There are images all over the web and so we want to make sure that those images are accessible to everyone.

So, what an ALT tag is is it is a little tag that goes in the actual image tag in the HTML that describes what that image is about. Generally if you have a content management system set up, there’re ways to add ALT tags to images through that content management system, so this is not something you need to worry about jumping into the code to do typically. But you should add meaningful ALT tags to any images on your site that need to convey meaning. So if an image does not need to convey meaning – and we’re going through some examples here – and the image is purely for visual interests, then it is entirely appropriate for an empty ALT tag to be used. So an empty ALT tag basically will just skip—it’ll skip by that image for people who may be using a screen reader or other assistive tools.

You want to make sure you have an ALT tag on your logo, especially if it’s a link to the Home page, because if it’s a link and you don’t have an ALT tag, then it is invisible. And you want to train your content admins on how to write good ALT tags, and we’re going to cover some examples of good ALT tags here in just a minute, but you want to make sure that this is something that you actually train people on and you cover. There’re a lot of tools out there that help with this, but we’re just going to go through some basics.

First off, I just wanted to show you a quick example. So, on our website, this is an example of how we would add ALT text to an image on our website, and there’s usually going to be a field either labeled ALT text or a description or something within the image area for each site that you can add an ALT tag to.

Good ALT Tags. So what makes a good ALT tag? A good ALT tag should present the content and the function of the image. People often times forget about the function, and usually the function plays in when an image is a link. And so, if an image is a link, it actually has a function on the site and you need to describe what that is, but otherwise it should be presenting the content of the image. Good ALT tags depend very heavily on the context of the image. So the same image can be used on five different websites and the context for that image may be completely different, so the ALT content for that image may be different.

ALT tags should not be redundant, so they should not repeat any other adjacent text. So if you have a caption or a body text or something that goes along with that ALT tag, then you don’t want to repeat the same thing inside of the ALT tag because you’re forcing people to deal with that twice.

ALT tags also should not use the phrases “Image of” or “Graphic of” to describe the image, because most screen readers – and JAWS is a large one, for example – JAWS actually precedes the alternative text with the word “Graphic,” or if the image is a link, JAWS will precede it with graphic link, and so you don’t need to say this is an image. People know that it’s an image, so you don’t need to start with “Image of.” You just need to say what the image is actually of.

Context is everything. I just wanted to highlight that again. So the alternative text for one image may be vastly different based upon the context and surroundings of the image itself.

So let’s go through an example. This is a screenshot I took from the University of Texas Home page actually just a couple of days ago, and it may still be up. I’m just going to give you a minute, and this isn’t a formal poll or anything, but in thirty seconds I want you guys to think about what the ALT tag for this image should be—and look at the context. This is on the Home page and there’s a summary of the article below it.

So, again, it depends very heavily on the context. So, right now, what this ALT tag is, or when I pulled it, the ALT tag was “Rick Church,” and you can see that here on the left-hand side. That’s what the actual image tag looks like. And, again, most of you won’t be going in and adding the ALT text in this manner, but that’s what it looks like in the actual code.

So “Rick Church” may be sufficient; however, I think that you can make an argument that if that’s all the ALT tag is, then people who may have a visual impairment may be missing out on some of the other content of that image and the information that image provides. The image shows “Rick Church” and he’s giving the “Hook ‘em Horns” sign and he’s in front of the large Longhorns’ band drum. You may know it’s “Rick Church” already because there’s a summary below it and some other information, but I would probably argue that it would be a little bit more helpful to write an ALT tag with a little bit more description – you don’t want to make it too long – but something that “Rick Church showing the Hook ‘em Horns hand sign,” because it provides a little bit more context about what the actual image shows.

Bonus points for any of you guys who noticed this, but there is another accessibility error here on this example. I don’t know if you saw it, but at the bottom of the screenshot there, you can see a “Read More” link. So “Read More,” again, was one of the first things we covered, which doesn’t provide any information for someone who’s just navigating by links, and so that, ideally, the actual title “Longhorn Band Alumnus Pays it Forward” would be the link instead of “Read More.”

Okay, so there’s another example. This is from a wonderful website that I encourage you to check out called GiantGummyBears.com, which provides a large variety of gigantic gummy products, and this is one you can buy right now. For $7.45, you can buy a gummy burger. So there’s an image on the left and a description of this product and the way to add it to the cart on the right. So, same exercise. Just take ten seconds and think about what you think an ALT tag should be for this image.

Okay, so there is definitely some information that you get from this image that you don’t get from the description of the product on the right-hand side, and, in particular, what I get from this image is how big this gummy burger is because it shows that in someone’s hand, and so you kind of get a sense that this really is a giant gummy. And, in my mind, the ALT text for this image should actually kind of describe the fact that it’s a burger that is taking up someone’s hand and someone’s holding it as a real burger. You could also provide some additional information in the summary, and so you could leave the ALT tag blank if you provided more information about the size of the gummy burger in the actual summary, because you wouldn’t want to repeat that content.

Last example here. This is also from the same website, GiantGummyBears.com. And I’m not going to spend as much time on this one, but I did just want to highlight this real quick because this is an example of where an ALT tag would need to describe the function of an image. So these images here are actually links, and when you click on them, they take you to a sort of category page where you can shop for only cherry-flavored gummies or orange-flavored gummies. And so the ALT tag in this case should actually describe the function, which is to shop for cherry-flavored gummies, shop for orange-flavored gummies, and so you wouldn’t necessarily need to have an ALT tag that said “Two Cherries on the Stem.” You’d want to provide information about what the link is actually doing, which is taking you to a filter page so you could shop by those flavors.

Okay, so that is a quick overview of ALT tags. Again, you could spend a long time going through examples, and I would encourage you to do so, but what I do want you to do is start thinking about the images that are on your website and start thinking about the context of those images and what good ALT content should be.

Okay, so the next basic web-accessibility technique is page structure. What this one is is basically use page structure that makes sense. And you guys probably all have some form of Whizzywig or a text editor or something on your site, usually in a CMS, and so you want to use the tools that you have available to you, things like headers, heading 1, heading 2, heading 3, things like lists, bulleted lists or ordered lists that have the numbers, things like block quotes, which actually call out the text as a quote, and you want to use those to provide some structure to the page that makes it easier for users using assistive tools to navigate and to understand what the page structure actually is. So you want to try to use, I don’t know, maybe more structure than you would offline, because you want to make sure that it’s very clear what the page structure is. So think of it as an outline. If you’re doing a formal outline, you don’t jump around and just kind of decide how you want it to be organized. You actually need to build a structure into the outline.

Your page title should always be an H1 tag and you should follow the hierarchy for the rest of the header tags on the page, so H1, H2, H3. There are a lot of times we’ve all seen sites that may jump from an H2 to an H5 – and this is something, again, you can normally choose on the text editor on your site – because they like the way it looks. However, that just causes from confusion for users using assistive tools. It’s not a gigantic issue, but it does make it harder to navigate through the content and understand what that content is. So you generally want to follow the structure. And if you need an H3 tag that looks like an H5, then you should work with your designers and developers to create that instead of just organizing those randomly.

Color. Color is a big one, but color should not be the only indicator used for information on your website. And there are ways to check color contrast, and you want to do that because color blindness affects eight percent of men, one in twelve, and 0.5 percent of women. So eight percent of all men have some form of color blindness and there are around twenty-five million men in the US with color blindness. And there’s an easy way—basically, what you want to do is check the contrast to make sure that the colors have enough contrast difference between them so that even if you can’t tell what those colors are, you can tell that there’re different text or you can tell that there’re different colors there. There’s a link here at the bottom for the WebAIM Color Contrast Checker, which is just a really fast way to do it, and you put in two color values and it’ll tell you whether it meets the contrast guidelines.

Captions and Transcripts. Okay, so video and audio must have captions and a transcript. And so captions are the words that actually play along at the bottom of the screen. So if you have a hearing impairment, you can read what’s going on. The transcript also is just basically a written-out version of whatever that’s happening on the video and the captions. And so you want to provide an alternate transcript that you can link to that describes the video.

This one is obvious. It’s been an issue in the past, but it’s gotten a lot easier, thankfully, but the video player must be accessible to keyboard-only and screen reader users, and this has gotten much easier with the advancement of HTML5 Video Player technology. And Youtube has come a long way, so the Youtube player actually is pretty decent at this now, and Youtube also allows you to add captions to videos using their built-in tools, and it’ll actually even auto caption the videos for you, which I would highly encourage you to not just use that without looking at it. You need to double check it and you have the ability to edit those captions. But it’s a great tools that built into Youtube.

Something else that you should definitely consider but would take more work is to use a separate description track that describes what’s happening in the video. So if you think about someone with a visual impairment who is listening to a music video, for example, and there’s a great example of this which I don’t have time to play for you now, a Stevie Wonder video, but if you think of someone who is listening to the video and it’s a music video, you’re going to hear the music, but you’re not going to have any idea of what’s happening in the music video. And so what a description track is is that it actually would describe what is happening in the video along with the music, and it just kind of naturally flows, and it would give someone a much better idea of what’s actually happening, the content, again, of that video.

Language Attribute. This one’s pretty quick, but because a screen reader pronounces the words aloud, it must first know which language to speak in. Okay, sounds obvious. I think this is the only piece of code I have, but this top example, and this is something that should be built into your website automatically, the language at the very top-level HTML tab that says “This is an English website.” However, what a lot of people don’t think about is that we use a lot of words in English that actually need to be pronounced not as English words, or if you’re trying to use a phrase that’s from another language, like in this example, C’est la vie, if the screen reader user doesn’t know that this is French, it may try to pronounce this as Cest la vi, which isn’t going to make a whole lot of sense to someone. And, so, you should be able to do this, again, in the text editor on your own website, whether it’s WordPress or Drupal or whatever. You should actually be able to switch over to code view, and I know that may be a little much, but that’s really the best way to do this and actually add a span tag around it defining that language. And if you need help with that, talk to your web developers or talk to us, but there should be a way to do that on your site.

This link is an example of what happens when you don’t do that, and, again, I’m not going to take the time to jump over there now, but it will read out a long paragraph of English text trying to pronounce it as if it was Czech, and so it’s kind of interesting to listen to. So if you guys a chance later, go check it out.

Dropdown-down Menus. Okay, drop-down menus can be kind of problematic, but the short version is that you want to use a drop-down menu that can be operated with a keyboard alone. Don’t require someone to hit a hundred-and-twenty-seven different keys just to use your drop-down menu. So try to use your drop-down menu with a keyboard. And use a drop-down menu that can be operated by people who have trouble keeping a mouse in one place for long periods of time. You don’t want to have a drop-down menu that requires you to keep the mouse super still and scroll it way down this huge long list of options. You want to make sure that you can use your drop-down menu if you’re not able to keep the mouse super still.

Okay, so those were some very quick, basic accessibility techniques that you guys can start thinking about for your site today, and so next I want to talk a little bit about how to test for accessibility. So here’s another quick poll again that you should see popping up on your screen here in just a minute, but on a scale of one to five, with one being horrible and five being perfect, how would you rate your website’s accessibility today? And just take a guess.

Okay, I’m seeing some responses coming in here. Great. A lot. You can go ahead.

Laurena Jech:

We’ve got time for another second or two.

Stephen Tidmore:

Yeah, it looks like we’re kind of right in the middle. It’s definitely a bell curve going on here, with most people sort of right at number three, a few people at number one for horrible and a few people at number five for perfect. So that’s great, but a lot of you guys are right in the two-three-four range.

Okay, so if you’re unsure or if you’re kind of right in the middle, I’m going to give you a few tools that you can use just to start seeing what it would look like to test your website for accessibility. And the first one is the WebAIM WAVE Tool and this is a really easy and free way to check the accessibility of a page on your site, so it only works one page at a time. This is not an entire site scanner, but it’s actually just a web tool, but it makes it really easy to test it and see if there’re errors.

This is a screenshot of what a test looks like. Now I know that this may be a little overwhelming, but I actually ran this test I think on Friday for Amazon’s Home page, which I was kind of shocked to see the number of accessibility issues that this tool found very quickly on Amazon’s Home page. But you can see here on the left where it’s giving you errors, there’re twenty-five errors, and it describes each of those errors, and each of those little icons, actually, you can click on it and it’ll jump to the section of the site that has that error that it’s referring to. And then it also lists sixty-one alerts—and alerts may be things that aren’t going to be a huge issue, but they’re definitely things you should try to fix. And, so, again, I know this is kind of overwhelming, but it does give you a quick view. You can just plug in your Home page or whatever other page on your site you want to and have it run a test and it’ll show you a list of what issues it finds very quickly.

The second tool I’m going to give you is called Sortsite, and, this, in my opinion, is I think one of the better, reasonably-priced full site scanner, and I say reasonably priced because in order to get a full site scanner tool that’s just an automated tool, there’re a lot of them out there that are very, very expensive, and Sortsite, I think, is fairly reasonably priced for what it does. And it’ll fit out a tool and you can set it to run once a week if you want to on your site and it’ll fire out and scan the entire site, and you’re going to get a result like this. This is the accessibility tab and it shows you what page have issues with Level A of WCAG, Level AA, Level AAA, and you can see here that it actually breaks out Section 508 from the old regulations from 2000 and the new ones from 2017, and then it’ll list out all the issues down below, and you can just scroll through this and see all the issues on your site. It’s organized pretty well, definitely, but if you have a lot of accessibility issues, then it definitely takes a while to get through, but it provides sort of the same service as the WebAIM Wave Tool, but it’ll scan your entire site and do so on a regular basis.

The last one I want to give you is called aXe from Deque and it’s a free browser extension that you can install for FireFox or Chrome. And so what you can do for this one is just install it on your browser and navigate to any page and you can run this extension and it’ll give you reports for that page. So, again, it only works one page at a time. But this is what the results look like from that tool. So it’ll show you a list of the violations. You can see here it has thirty-five violations. Up in the top left it tells you that. It’ll give you a description of those and you can actually inspect the element on the page with what it calls Inspect Node and see what the issues are in the code. But it’s another decent one if you just want to run it as a browser extension.

However, the best way to ensure accessibility really is manual testing. You can run automated tools all day long, it’ll go through a checklist of things and it’ll certainly help a lot. You shouldn’t have any issues that are found through automated tools. But you should strongly consider manual testing. You can do a lot of testing on your own, but it does take a lot of time and you need to learn to use the tools in a similar manner to someone who has a disability, so if you’re using a screen reader and you don’t know how to use that screen reader, you may think there’re a lot of issues on your site that someone who’s a native screen reader user is not going to have, and so I would encourage you to certainly think about manual testing, but take the time to learn the tools. At a simple level, you can try using your website with only a keyboard for sure. Try using it in monochrome. You can set your computer to be monochrome and make sure that you can tell the difference in the elements on the page so you’re not relying on color; or you can use a screen reader, but, again, take the time to learn it.

And, of course, you can also work with an accessibility testing company. So you can work with a company like us or there’re a number of other companies that actually will do manual testing on your site with a variety of users who have disabilities, so native screen reader users, and have them test your site and report back with issues.

Okay, so a quick little summary. Accessibility is important, not only because there’re laws requiring compliance, but because it affects so many people. Section 508 now points directly to the WCAG guidelines. There’re a few small things we covered that you can start implementing on your websites now, or at least start to thinking about how you would implement those on your websites now; and you should start testing your website using simple tools today; and you should also look for opportunities to test manually moving forward.

Thank you guys so much for listening to me talk for this long. I think we’re going to open it up for a few questions.

Laurena Jech:

Yes, thank you, Stephen. Wow, great job. That was very informative this afternoon. So a few questions did come in. First one is from Ryan. He asked “How does altering the link text impact SEO?”

Stephen Tidmore:

Good question. Generally, they should go hand in hand, where if you’re improving the link text for accessibility, you’re also improving it for SEO because you’re giving Google more information about what the page is you’re about to visit. So, usually, they should go hand in hand, and if they don’t go hand in hand, then the SEO techniques you may be trying to use may not be totally relevant or they may not be totally above water. Generally, and this is kind of a typical rule across all accessibilities, that making your website more accessible for users with disabilities also makes it easier for Google to figure out what the content is on your site. So it should be hand in hand.

Laurena Jech:

Great. Okay, so another question that came through is from Tammy, and I’ll go ahead and read that. She said “Our cafeteria menus are provided as a principle calendar using a non-accessible form provided by the USDA. I’ve done my best to rework the form, but I’m not entirely happy with the results. Would it be acceptable to also provide the menus as a principle plain text list? Does that cover us if the USDA menus are not completely accessible?”

Stephen Tidmore:

So, Tammy, I’m going to take your question to be about the menu and not necessarily the form, I think. Form accessibility, I didn’t touch on that at all in this topic because we can talk a long time about form accessibility, and unfortunately it does have to involve code, but, yes, I think if you’re providing it as a printable PDF – something else we didn’t cover is PDF accessibility – but if you’re providing it as a principle PDF, if you make sure that that PDF is accessibility – and there are some tools out there that will check PDF accessibility – then I think you would be fine as long as you make it really obviously, give people a way to access that in the same manner as the regular printable calendar.

Laurena Jech:

Great. Okay, so we had another question come in from Edy. She asked “I was taught years ago to add a period to the end of an ALT text cause the JAWS reader to pause. Is that still true or does the reader do that anyhow?”

Stephen Tidmore:

That is a really good question. I have not added that typically, and there’re so many different screen readers now that people use—JAWS isn’t kind of the one tool that most people rely on as far as I know. I don’t think you would have to add a period, but if it’s a sentence, then you should add a period. Most people who use screen readers are listening to this content very, very quickly, and so they would typically be able to differentiate that.

Laurena Jech:

Great. And we have time for about one more question. John asked “How often do these accessibility standards change? Do we need to be reviewing these every month or every year? Or what is the protocol around that?”

Stephen Tidmore:

Typically not that often. The WCAG guidelines have been updated just a couple of times, I think. Section 508 itself isn’t updated that often. I think it’s been seven years, or eight years, since it was last updated. It’s not something that you would normally have to worry about keeping on top of every month for sure, but you do want to stay on top of the WCAG guidelines if they’re adding new guidelines or new techniques. And, again, the robust concept comes in here, where you want to make sure that whatever you’re doing is robust enough to adapt as accessibility tools adapt.

Laurena Jech:

Great. Awesome, well, thank you so much, everyone, for attending our webinar this afternoon. Just as a reminder, we’ll send out a link to the recording along with the slide deck later this afternoon. And if you have any additional questions, Stephen’s email is here on the slides and you can reach out to him directly or email us at info@mightycitizen.com and we’ll be in touch. Thank you so much and have a great afternoon.