Home

Plans & Pricing Get Started Login

« Return to video

10 Tips for Creating Accessible Web Content with WCAG 2.0 [Transcript]

LILY BOND: Welcome, everyone, and thank you for joining 10 Tips for Creating Accessible Web Content with WCAG 2.0. I’m Lily Bond from 3Play Media, and I’ll be moderating today. I’m joined today by Janet Sylvia, who’s the leader of the Web Accessibility Group, founded at the University of Georgia, as well as a web accessibility trainer. And with that, I’m going to hand it off to Janet.

JANET SYLVIA: Thank you, Lily. OK, so could you please confirm that my first slide is on your screen?

LILY BOND: Yeah, it looks great.

JANET SYLVIA: OK, super. Thank you, and thank you, everyone, for being here today. This is the agenda for our session. We’ll begin with an introduction to web accessibility, and as requested, this includes legal requirements for higher education. Then we’ll have an overview of the Web Content Accessibility Guidelines. The acronym is WCAG and pronounced “wih-cag” 2.0. We’ll focus on 10 tips for creating accessible web content and discuss accessibility checking as we cover the content.

So we’ll begin with an introduction to web accessibility. For our audience members in the US, Section 508 of the Rehabilitation Act Amendments of 1998 states in part that “electronic and information technology must be equally accessible to people with and without disabilities.” 508 was written by and for the US federal government. However, in many states, the higher education authorities have determined that Section 508 applies to college and university systems as well.

508 was signed into law over 15 years ago. It remains a solid foundation for understanding accessibility, including web accessibility. And at the same time, there have been many changes in assistive technologies, web design, and web delivery methods. Thus, the Section 508 Refresh is forthcoming. By all accounts, the refresh is expected to reference WCAG 2.0, which we’ll discuss in more detail throughout this presentation.

We also have the US Department of Education guidelines regarding the Assistive Technology Act, which says that all states that receive funding under the Assistive Technology Act must comply with Section 508 for these programs and services, and this applies to all 50 states in the US and the territories.

Many people ask about the Americans with Disabilities Act and how it relates to web accessibility in particular. The ADA covers places of public accommodation. So while at this time it does not specifically mention the internet, courts have ruled the intent of the law includes the internet as a place of public accommodation. And for our international audience, your home province, territory, or country may have similar laws with which you are required to comply.

So the question was asked, what happens if we don’t comply? Well, first and foremost, there will be a loss of equivalent, or what’s called equally effective, access to your website, your web-based content, and your online courses for people with disabilities. Individuals can take their educational needs and their tuition dollars elsewhere.

There is also legal recourse. Specifically in the US, individuals can visit the website for the US Department of Education or the US Department of Justice, Office of Civil Rights, and file a civil rights complaint against your institute of higher education. The online complaint forms indicate the individual is encouraged but not required to contact the university directly.

Individuals can also file a lawsuit in state or federal court. If you’d like to read more about these cases and what the complaints cover and the remediation plans, links are available on today’s handout. This is valuable information that can be used to remediate our own web-based environments before any potential complaints come our way.

So people often ask the difference between standards and guidelines. Standards in general refer to legal requirements or federal laws. WCAG 2.0 are international guidelines or recommendations for making your web content accessible. We also have accessibility best practices, and these are recommended by accessibility experts at your college or university. And together, all of these ensure the accessible delivery of electronic, information, and communications technology.

There is a specific relationship between the upcoming Section 508 Refresh and WCAG 2.0, and for our international audience, the same may be true in your home country. And that is the Section 508, or the laws as written, incorporate by reference WCAG 2.0 Levels A and AA. So Section 508 will still be the legal requirement, not WCAG 2.0 itself.

It is worth noting that in higher education, the civil rights complaints and lawsuits just mentioned, the remediation plans already require conformance with WCAG 2.0 Levels A and AA. So we should not wait for the release of the 508 Refresh, which could be one to two years from now, in order to learn about WCAG 2.0. Instead, the time to begin learning is now.

One last note– it’s important to keep in mind that WCAG 2.0 alone is not enough. Section 508 and the upcoming refresh cover more than just web-based content. 508 covers procurement policies and hardware and software, and both 508 and the refresh cover telecommunications devices.

So the bottom line is this. We’ll always be required to comply with Section 508. The Section 508 Refresh is expected to direct us by reference to conform with WCAG 2.0 Levels A and AA for our web-based content. And again, for our international audience, the same may be true in your home country.

So next, we’ll cover a brief overview of WCAG 2.0. WCAG 2.0 is based on four principles of accessibility– Perceivable, Operable, Understandable, and Robust, and this acronym is POUR, pronounced “pour.” Within these 4 principles, there are 12 guidelines. And then nested under these 12 guidelines are the heart of WCAG 2.0, and that is the 61 success criteria for creating accessible web-based content.

The criteria are assigned conformance levels. In the US, we’re required to conform with Levels A and AA. And any time we can achieve the highest level of conformance by meeting the Level AAA guidelines, we should do that also. There is very thorough documentation available from the W3C Web Accessibility Initiative. This is the authoring group of WCAG 2.0. And their documentation includes how to meet WCAG 2.0, techniques for conformance, and this includes sample code and links to great external resources that are very valuable, and also documentation for understanding the success criteria.

All total, there are well over 400 pages of documentation. If you are experienced with web accessibility, I highly recommend reading through the WCAG 2.0 documentation for each success criteria that applies to your web-based content. It is a remarkable and very thorough resource.

If you are a beginner, this documentation can be overwhelming, especially if accessibility compliance is not your primary role at your college or university. So for beginners, I always recommend using WebAIM’s WCAG 2.0 Checklist. WebAIM is based at Utah State University, so they’re also a higher education group here in the US.

On this screen is a screenshot of the top page of the WCAG 2.0 Checklist, which I will describe verbally for our audience. Each of the four principles are listed, as well as the guidelines. Then under the guidelines are each of the 61 success criteria. Below each success criteria is the level of conformance.

So again, when we’re going through this checklist, we’re looking for everything designated Level A and AA. Alongside each success criteria are WebAIM’s recommendations for conforming with the success criteria, and they use an easy-to-follow checklist format. So as you go through the checklist also, if you need additional information, you can just select the hyperlink text for that success criteria. It will take you back to that specific section in the WCAG 2.0 documentation that covers that particular criteria. So this is a great way to slowly introduce or acclimate yourself to the WCAG 2.0 documentation if you’re a newcomer.

There is an important concept in the world of accessibility and, also, that’s conveyed in both the Section 508 Refresh and WCAG 2.0, and this is the idea of usable accessibility, or what’s sometimes called functional versus technical accessibility. So what does this mean? Well, your website may pass an accessibility checker, but is the content actually usable by the intended audience?

So for example, this slide demonstrates this concept, and I’m going to use the example of meeting the technical requirement for alt text for an image. If you are new to the concept of alt text, I’ll describe this in more detail as we get into our tips. But on the screen, I have an image, and the image is just a white box. And we don’t know exactly what this is an image of. And we need to determine what the image is, based on the alt text provided.

So on the screen, I have the image tag using the alt attribute, and the alt text provided says “Logo.” Well technically, the accessibility requirement has been met through the use of alt text, but is this functional? Does the word “logo” fully convey the meaning or the contents of this image? What is this a logo for? It leaves us guessing, and it’s not accessible.

To remediate this, we can change our alt text to be more specific. And in this case, I have changed my alt text to “Global Accessibility Awareness Day,” and also I’ve used the logo for this event. So functional goes beyond merely meeting technical requirements. We’re being asked to ensure that when we implement accessibility strategies that what we’re doing is actually usable by our website visitors.

So now we’re going to go into the 10 tips for getting started with WCAG 2.0. Tip number one, provide page titles, headings, and use semantic structure properly. So beginning with page titles, we need to use the title tag on all our web pages.

So the image on this slide shows library shelves filled with books, and there’s a young man standing in front of the shelves, reading a book. So if you can imagine visiting a library, and the shelves are filled with books but there are no titles on the bindings, it would be very difficult to find the information you’re looking for. You’d need to open each book and flip through the pages to determine the contents. So the same is true for our web pages that don’t provide a title tag. So use the title tag to provide a descriptive title of your web page contents.

Regarding headings, all web pages should have a Heading 1. Typically, there is one Heading 1, or h1, tag per page. The text used in your h1 tag should be the same or at least contained within the text of your title tag. Then, use the Heading 2 or the h2 tags for all your section titles, and Heading 3 or the h3 tags for all your subsection titles.

Now, for most web pages, this will be sufficient. But if you have a more complex page, you may need to use heading levels 4, 5, and all the way down to heading level 6. What we can’t do is use Heading 1 for the heading or title of our page and then skip down to a Heading 6 because that’s the font size we’d like. The font size should be controlled in your CSS or your style sheet, and not by your choice of heading. So we need to use our headings properly to assist with both the navigation and comprehension of our web page contents.

There are a number of free accessibility toolbars that are available, and several are listed on today’s handout at the bottom of page two. I’m using the Web Accessibility Toolbar because that’s the one that I use regularly. And if you want to check for your title and your heading structure on a web page, you can use this toolbar and select Structure, Heading Structure.

And then what you’re looking for first is that there is indeed a title listed. If not, you can remediate this by adding the title tag to your HTML code. And then you want to ensure that there’s just one H1 tag, and that the text is either the same or contained within the text for your title. Then review all of your H2 tags and be sure they are truly section titles. If you have any H3 tags, they should be nested below an H2, and that text should truly be a subsection title. And you can review all of the headings on your page this way.

More information about semantic structure– use ordered lists, or the ol tag, any time you have information that needs to be provided in a progression or sequence. If you have information that needs to be provided as a list but in no particular order, you can use the ul tag, and this is similar to providing a bulleted list. What we need to do is to avoid using either of these lists for either just indent or layout purposes.

And then, just as a reminder, be sure to use the strong tag instead of bold and the em or emphasis tag instead of italics. Bold and italics are both visual indicators only. They’re not reflected in the underlying source code that’s read by assistive technologies.

So to check a web page for a list, again, using the Web Accessibility Toolbar, you can select Tables and Linearize. And this slide shows a screenshot of the results, which I’ll describe. What you’re looking for is any information that’s provided as a numbered or bulleted list, and you want to ensure that that information is truly a list and it’s not being used for layout purposes. And likewise, you should check through your page contents to ensure that any information that should be provided as a list doesn’t appear as a sentence instead.

So tip number two– provide descriptive hyperlinks. Your hyperlink text should always make sense when it’s read out of context or as a standalone document. The link text should describe the destination, such as your website or your document title, and it should be unique for each unique destination.

What we want to avoid is using vague terms like click here or email me. These are not accessible. And also, avoid using what’s called a fully-qualified URL, and that’s http://www et cetera. To be accessible, we must provide descriptive text for our hyperlinks.

And how would you check this on a web page? Again, using the Web Accessibility Toolbar, you can select Doc Info and then List Links. And this slide has a screenshot of the results that I’ll describe. It provides the total number of links on the page.

And then at the top of this particular page are two image links, and these are images that are being used as links. And as we mentioned earlier, your alt text should be descriptive here. Next, review the entire list of links that appear on your screen, and ensure that all of the hyperlinked text is indeed descriptive so that it’ll be accessible.

Tip number three– provide alt text for all your non-text content. Every image requires alt text or the use of an alt attribute. It might be a photograph, a chart, a graph, a map. It could be a Search button or a Submit button.

Alt text is a clear, concise description, approximately 120 characters or less. Some screen readers truncate alt text at 120 to 140 characters, so we try to err on the side of caution and make sure it’s a maximum of 120 characters. Your alt text should convey the function or the meaning or purpose of an image.

Also, provide a long description. This is in addition to your alt text when the alt text alone isn’t enough information to convey the meaning or purpose of the image. And your long description is provided in the surrounding text, or you can provide a descriptive hyperlink to a separate accessible document.

So this slide is an example of a long description. And there is an image of a map, and it has point A and point B. And there’s a line drawn from point A to point B. And I also have two image source tags, and I’d like to describe the first one. The first one is the image tag. It has the alt attribute, and the alt text is Map to Student Center.

And then, in the text surrounding the image– I won’t read through all of this text– but the text is the driving directions from point A to point B. We don’t need to describe all the other streets that people will pass by, just the driving directions from point A to point B.

The second sample image tag, it uses what’s called null text. And so we have the alt attribute, and then we have begin quote, end quote. And this is the universal symbol for null text. If the information in your alt text is also provided in the long description, you can use null text for your alt text. So the alt attribute must always be present, whether it conveys meaning or it’s designated as null text.

So to check images on a web page to ensure that you have alt text and it’s been used properly, using the Web Accessibility Toolbar, you can select Images, List Images. And this is a screenshot of the results that I’ll describe. All of the images on the page will be listed. Below each image is the image tag. And when you’re reviewing images on your own page, you’re looking to make sure that all images have the alt attribute and that the alt attribute contains either text that describes its function or purpose or, where applicable, that you’ve provided null text.

Tip number four, accessible documents– documents provided as links to download information from a web page or an online course must also be accessible. This is often overlooked on websites, and it’s very important to make sure that all of the documents that people can download from your site are indeed accessible.

So the tips that we’re covering today, most of the information in the tips will also apply to documents if you use an HTML editor, maybe in a learning management system like Desire2Learn or another system, if you create PDF documents, or if you use Microsoft Office or Open Office. So you can use these tips to ensure, or to begin to ensure, that these documents are accessible also. Additional information is needed to create accessible documents of all types. It’s beyond the scope of our session today, but I have provided links on today’s handout for more information on creating accessible documents.

Tip number five, accessible multimedia– if you use audio only, like a podcast or audio lecture, we must provide a text transcript of the spoken word. And that text transcript should be a document that’s accessible, preferably HTML, but it can be an accessible document of another format. If you provide video only, you need to provide a video description. This is a text description of the key visual elements that are required for comprehension of what’s taking place in the video.

You have audio and video combined, provide synchronized closed captions, the text transcript, and the video descriptions. These two documents can be combined for audio and video. And also, be sure to provide an accessible media player. We’ll talk more about this on the next slide.

So tip number six– don’t auto-play video. We must provide an option to turn off all multimedia on a website or in an online course. And what this means is that the Pause and Stop buttons must be keyboard accessible, and the controls, as a general, need to be screen reader accessible. So to ensure your media player is accessible, depending on the player you’re using, you may need to do an internet search.

But in higher education, it’s very common to put content on YouTube, so I’d like to address YouTube directly. On YouTube, the default media player is not accessible. You should instruct your site visitors to request the HTML5 player instead. If you embed YouTube video on your home page, you should embed the YouTube HTML5 player. You may also use JW Player, or, again, another media player that you’ve investigated and that you know it is indeed accessible.

This screen is a screenshot of the page to request the YouTube HTML5 player, and I’ll describe this. There is a section where it tells you what player that your browser is currently using. And in this example, it says the default player is currently used. There is a label, a Submit button or form button that’s labeled Request the HTML5 Player. Your audience can also log in to their YouTube account and set up their preferences to always default to the HTML5 player.

Tip number seven– ensure that your JavaScript is device independent. And this means that the functionality of the JavaScript does not rely on mouse-only or keyboard-only actions. Now, it used to be that people said don’t use JavaScript, but that’s not true anymore, that many screen reader users have JavaScript turned on. There was a recent survey where it said over 95% use JavaScript.

JavaScript itself can increase the accessibility of your web page by allowing you to provide prompts or warnings, instructions, and additional information. JavaScript can be very widely used in a lot of different ways. So there’s no easy, single fix for all JavaScript.

What you really need to do is evaluate your web page, determine how you’re using that JavaScript, and then perhaps devise unique solutions. If this is new for you, there’s a great article. It’s listed on your handout today under tip number seven– to WebAIM’s “Accessible JavaScript” article. And they give you examples of how you may be using JavaScript, whether it’s accessible or not, and then some information about remediating your JavaScript if needed.

Tip number eight– ensure keyboard accessibility. This is an often overlooked but significant aspect of website accessibility. How do you test? Well, in general, it’s very simple. Unplug your mouse. Use the Tab key on your keyboard to move forward, Shift-Tab to move backward. And you want to be sure that you can use the Enter key on your keyboard to activate all links, all buttons, Submit buttons and form controls, et cetera.

Since this is often overlooked on websites, I’d like to go through the five accessibility requirements for keyboard accessibility. And number one says, the focus indicators should be visible via Tab. Now, most folks that I talk to are not familiar with this, so what I’d like to do is go to the WebAIM site and demonstrate what this should look like when you check keyboard accessibility on your own page.

So what we should be seeing now is the WebAIM page on your screen, and I’m going to select the Tab key on my keyboard. At first, it will go through the browser. And we’re going to let it just go through my browser. And then the first thing that you are responsible for on your own web page is the Skip to Main Content link. This should be provided. It allows users to skip repetitive navigation and jump straight to the main content. Again, there’s a link on the handout today on how to set this up, if this is new for you.

And next, I’m going to select Tab again. And this time, the Tab has landed on this image link. And what I’d like to point out is around this image, there’s a dotted box. On your own website, if you don’t see this visual focus indicator or this dotted box, likely it’s because in your CSS, you may have turned off display colon or display:0 or display:none, and that turns this off. So you may need to go back into your style sheet and turn that back on.

I’m just going to Tab through a couple more things. We’ll Tab once. And you’ll notice Services is highlighted. It also has the box around it. Articles– it’s going through the natural and intuitive navigation order. It stops on Resources. And now you’ll notice it does jump and land on the Search box as well as the Submit button to submit a search.

So I’m going to go back to our presentation. And now, I hope it makes more sense as we go through these, now that we’ve seen this. So again, number one, focus indicator should be visible when you use your Tab. Two, the navigation order through a keyboard should be logical and intuitive. All interactive elements should be accessible via the keyboard. Number four, scripted elements and widgets should be accessible. And number five, lengthy navigation, which applies to most of our websites, need the Skip to Main Content.

Be sure that you use your headings, and also ensure that you’re using ARIA landmarks. If any of this is unfamiliar to you, again, there is a link on the handout that provides information on how to set this up on your own web page.

If you’d like to check the Tab order using a Web Accessibility Toolbar, you can select Structure and Tab Order Structure. There will be numbers, and it will tell you the order in which you will go through the web page. And you can check your Tab order this way as well.

So tip number nine– ensure sufficient color contrast. We want to choose a high color contrast scheme between our foreground, or our text, and our background colors. Avoid large blocks of text that have a dark background with light text. If an individual needs this as an accessibility preference, they can set that up on their own preferences.

Also, ensure the background does not overpower the text. This is very common on PowerPoint presentations and Keynote presentations, and sometimes on websites as well, where the background overpowers the text. So we need to be sure we don’t do that. And then also avoid color coding. The use of color is perfectly acceptable, but what we don’t want to do is have color coding, like red team and green team, where color is the sole source of conveying that important information.

So in this example, which provides better contrast? And I’ll explain– describe what’s on the screen. There are two boxes. Box A has a brown background with light color text, and box B has a tan background that looks sandy, and overlaid is a design that looks like some fish, about 10 of them on the page. And then that’s overlaid with plain white text.

So which of these provides better contrast? Well, visually, we’ll be tempted to say A is better. And even though it’s better, does that mean A is accessible? And the answer here is no, it is not. So when you remediate your color schemes, you always want to compare what you’re choosing as a new color scheme to the best possible option for high contrast, which tends to be C, which is a light background with a dark color text.

We don’t have to use visual acuity to determine our color contrast. There are a number of tools available. I like to use the Colour Contrast Analyzer. It’s built into the Web Accessibility Toolbar. And I’d like to share with you just a moment how easy this is to use. You can use it on your web pages, your PowerPoint or Keynote slides. You can use it if you use color in spreadsheets. And so it’s very easy to use. It has keyboard shortcuts. And I’ll describe how it works with the mouse.

So under Foreground Color, there’s an eyedropper. And you click on that eyedropper, and then you hover over. And also on this screen, I have a screenshot of my opening slide. Hover over the color of your text and click. It will put that color in the color select box. If you’re a web designer and you know your hex code, you can also type that in here.

And then, for your background, select that eyedropper, hover over your background color, and click. It will place your background color in the Color Select box. And then the analyzer will immediately analyze your results. What you’re looking for results is to ensure that there are four check marks.

Now, I mentioned earlier that we’ll be required to comply with or conform to WCAG Levels A and AA. This Contrast Analyzer passes Level AAA. And I mentioned that any time we can, we should also comply with Level AAA, and it’s easy to do– or fairly easy to do– most of the time with color. You might select just a lighter text color or a darker background color, and that will allow you to pass all four areas.

And our last tip, number 10, is provide an accessibility statement. This is for your web page or your website. You can provide it in your template, on your syllabus, on your online course. Be sure to provide an accessibility statement. You should use the statement that’s provided by your college or university.

If you’re not able to find a statement that’s endorsed by your university system, you may like to use or adapt the text that’s on this screen, and I’ll read it. It says the, and then you fill in your organization name, complies with– and for our international audience, you may change these laws. For our US audience, complies with Section 508 and endorses conformance with the WCAG 2.0 guidelines for web accessibility, or accessibility of web-based content. Please contact us if you cannot access information on this site. Be sure to provide your name, your email, and a telephone number.

So you should also check with your home institution or your university system about requirements for responding to any accessibility requests that you receive. This might be your equal opportunity office or your disability resource center. On your campus, you may have an ADA compliance officer, a 508 compliance officer, or a similar position based on your home country.

For the state of Georgia, our state ADA office advises we respond to a request within 24 hours, or one business day. This doesn’t mean that you can remediate the problem in one day, but we do need to respond to that request in a timely manner. If you are not the person who should remediate the request, be sure that you elevate that request immediately. It helps to ensure the proper person and accommodations are provided.

So this is a summary of the 10 tips that we’ve just covered. They are designed to help you get started with WCAG 2.0. It certainly isn’t WCAG 2.0 in its entirety, but you may be familiar with the quote, “the secret to getting ahead is getting started.” And these 10 tips are designed to do just that.

So I’d like to end with a quote from a video called World Wide Access that was produced by the University of Washington DO-IT Center. And it says, “if you can design a website, you can design an accessible one.” We learned how to create websites, documents, digital media, online courses, either self-taught or through classes, where accessibility may not have been included in that learning experience. And so as a result, we learn techniques that do not generate accessible web-based content, but we can change that.

We learn to create inaccessible content. We can learn to create accessible content. And by developing new habits and techniques, together we can ensure a more accessible web for everyone. So Lily, I will put my questions slide on and turn it back over to you.

LILY BOND: Thank you so much, Janet. What a great presentation. So we are about to go into Q&A. As I compile some questions, I wanted to mention a few upcoming webinars that we have, one on CVAA legal requirements on May 27. And then in July, we have a webinar on DIY workflows for captioning. And in August, we have a quick start to captioning. And you can register for those on our website.

As we go into questions, I want to urge people to continue to ask questions, and we will try to get to as many as we can. So Janet, I’m going to start out by asking you, who is responsible in a university setting for working on web accessibility?

JANET SYLVIA: Well, thank you. That’s a great question, and we do hear that a lot in higher education. The bottom line is that it’s everyone’s responsibility. We have administrators who are responsible for establishing policies on our campus. We have procurement personnel who are responsible for purchasing accessible hardware and software.

Then we have in academics, faculty and their designates who are responsible for the accessibility of online course content. We have IT personnel who are responsible for websites and website developers. We have digital media developers. It’s about everyone doing their part to benefit the whole. So ultimately, it’s everyone’s responsibility.

LILY BOND: Great. Thank you. Someone is asking, do you have any tips for Google Docs that are published to the web?

JANET SYLVIA: No, actually, I don’t. We have had some problems, and I know some others may be familiar, that some of the Google Apps are not accessible. And so we have not dived into those. So I don’t have any tips for those.

LILY BOND: No problem. Someone else is asking if it’s OK to activate a link via a Space Bar instead of an Enter key.

JANET SYLVIA: Everything that I’ve read says that the Enter key should activate a link, so I wouldn’t say that right now. I would need to do some more research on that and invite also the individual– if you could do research, in case we don’t connect after this event, and check online. Everything I’ve read says use the Enter key, so I don’t want to answer that for sure.

LILY BOND: Great. So what is the difference between using a toolbar to check your web pages and using an automated checker?

JANET SYLVIA: That’s a great question, and we do hear that question a lot in higher ed trainings. A toolbar allows you to manually check items on a single web page, element by element. An automated checker does this work for you, and sometimes, especially– there are a number that you can purchase, or there are some free, that will crawl through your entire site.

But the problem that most people encounter is they’re not quite sure how to read the reports or remediate errors when they use automated checkers. And I’ve heard of a number of people who will run an automated check. Then they get the report. They’re not quite sure what to do with this. So using a toolbar first provides you the opportunity to learn what you should be looking for on those reports. It puts you in a better position to use automated tools in the future.

And just a side note, it’s good to involve people with disabilities to help test your website as well for accessibility in addition to toolbars and automated checkers. We should be willing to pay these individuals for their time. They’re providing a service based on their expertise, so we should be willing to hire people to assist us with this as well.

LILY BOND: Great, thank you. So there are a few questions here about YouTube, so maybe we’ll just go through those in a row. The first one is the most general one. Could you explain a little bit more about in what ways YouTube is not accessible?

JANET SYLVIA: So what I had mentioned is that the YouTube default player is not accessible. And so an individual may be able to Tab to the controls, but they can’t Tab through the controls. So they can get to where across the bottom of a video you’ll have Stop, Pause, Play, the CC button to turn on the closed captioning, and the Settings button. They can get to it, but they can’t Tab through it.

Another concern with YouTube is the Show More, if you– and I’m anticipating what might be coming in terms of accessible YouTube content. Below your video, where you provide descriptive information, there’s a Show More where you can expand and provide more information about the video.

And what we typically recommend is, to ensure that your YouTube video is accessible, is to post a link in your description field to the text transcript and also to your video description. That Show More button is not accessible or available to all people. I have some friends who have used screen readers, and they don’t even know the Show More button is there.

So when you make your YouTube accessible, part of it is posting a link to your text transcript and video description. Post that first in the description field, and then it will appear above Show More and that people will be able to access that.

LILY BOND: Great, thank you. So along those lines, you mentioned an HTML5 player for YouTube, and people are wondering, is it the responsibility of the viewer to request that player, or the person who is embedding the YouTube video? And similarly, how do you embed an HTML5 YouTube player?

JANET SYLVIA: OK. To embed the player, you can search through the Google documentation. They provide step-by-step instructions on how to embed it. As a service to our YouTube folks who visit our site and want to watch the video, it’s best for us to mention to be sure to use the YouTube HTML5 player.

LILY BOND: Great, thank you. Someone along the video lines is asking if a transcript only of a video is acceptable according to WCAG guidelines, or whether captions would be required.

JANET SYLVIA: OK, so for a video– and since they mentioned a transcript, I’m going to assume that the video has an audio component as well. And so if it has both audio and video components, it needs the captions. It also needs the text transcript as well as the video description, and the transcript and the description can be combined into a single document instead of two separate documents in that case.

LILY BOND: Perfect. Someone is asking– I’m the head of my campus disability support office, and I’m trying to get our campus IT on board with web accessibility. We’re not. What would be a good starting point to begin educating them?

JANET SYLVIA: That’s a great question for higher education. We have some very unique challenges in higher ed, and typically, on a university campus, the web designers are distributed. Or it’s a distributed environment, meaning every college or department may have their– it may be like a silo. They have their own web team, and those individuals are responsible for accessibility. And they don’t know what somebody in the next department might be doing. So it’s very distributed in that case.

We experienced the same thing on our campus, and it was the reason we established our web accessibility group. And what we did was start offering trainings that were announced campus-wide. We also have groups on– I recently retired– but on the university campus specifically for web designers and developers. And so we would send the invites specifically to their listserv as well.

And another thing to keep in mind that may be happening at your institution as well is that sometimes when a university department or college within a university uses what’s called a content management system– and it’s like a template– and then anyone within that college could be that person that’s responsible for posting content online, providing links to download documents. And in our experience, it has been anyone from a secretary, could be a student worker. It could be an IT person, but not necessarily.

And so it’s really important to announce any kind of trainings that you offer to help people– to help raise awareness and get people on board with this accessibility. If you make sure that you don’t really target only the IT teams but be sure to target the entire university, and then that helps people who are interested come, and we get to train those folks. And then the word spreads that way.

LILY BOND: Great answer. So someone is asking more generally, where do you get an accessibility toolbar?

JANET SYLVIA: Oh, great. They can be downloaded, and I’m looking at the handout right now. On the handout, at the bottom of page two, I have a link to download, and these are all free. The Web Accessibility Toolbar– there is a Firefox Web Developers Toolbar plus an accessibility extension. There’s the WAVE toolbar.

And also, today I just showed how to use the Web Accessibility Toolbar, but there is a great resource on the W3C site. Again, that’s the authoring group for the WCAG 2.0. And they have something called W3C Easy Checks. Their checks are similar– a little bit different, but similar– to the tips that we went through today. The link is also in the Accessibility Checker Section of the handout, at the bottom of page two. They give you step-by-step instructions for using the Firefox toolbar and using Safari web browser to check accessibility. So most of these are free, and links are available on your handout.

LILY BOND: Great. And the handout that Janet mentions we will email along with the recording and slides, so you’ll have that shortly. So Janet, someone is asking if you have any thoughts on what to do with multiple h1s in the HTML5 documents.

JANET SYLVIA: Hmm. I haven’t really examined that closely. I know that people are using multiple h1s, but they can cause problems with orientation or navigation through a web page. And so at this time, I personally would not use them until I was sure from the accessibility community as a whole that multiple h1s were acceptable. I don’t know that they are, so I wouldn’t recommend doing that.

LILY BOND: Someone else has a question about headings. They’re noting that headings are so helpful for screen reader users, but WCAG 2.0 points them at that Level AAA. So when teaching accessibility, how do you explain to people the importance of headings, when Level AA is the standard?

JANET SYLVIA: OK, so I’m looking at my notes also because under headings, I have a number of the WCAG. I have it under three areas, a Level A, a Level AA, and a AAA. And the question you just asked said, how do we get people on board if it’s a Level AA? Was that right?

LILY BOND: They’re asking if Level AA is the standard that people are starting to use most frequently, how do you get people on board for implementing something that’s a AAA standard?

JANET SYLVIA: Right. And the first thing I would just do is to convince them of the need. Tell them how important it is. And they can be easy to implement, and so it shouldn’t be difficult to just include. And as I mentioned, the minimum requirements are Level A and AA, but it doesn’t preclude us from not going the step further and doing the AAA because we know that’s the most accessible.

And I might mention also with headings, we encounter this a good bit where, on the campus where I work, they used– a lot of faculty members used Word documents or Open Office. And so we would teach them how to use those headings in those documents. And if you do, there’s an easy way to then turn your headings into a table of contents. That’s an active table of contents for a Word document.

So if you’re trying to get faculty members on board, once they realize they don’t have to update their table of contents manually, and any time they change information, as long as they’ve used that heading structure, they can just click a button to either create or update their table of contents, that would be great. They love it. All the faculty I’ve worked with love it.

And I think just for websites in general, just to share how important it is for navigation. You might find testimonies from individuals who use screen readers and ask them to share how important it is to use those headings as well, and that might help get buy-in if there’s any concern with people going to Level AAA. What we tend to do in our trainings is we provide the information not necessarily that this is a Level A and go through all the As and then all the AAs. We just give them the great information.

LILY BOND: Great. So Janet, given these 10 tips, if you were new to accessibility, how would you suggest getting started?

JANET SYLVIA: Oh, great. So it can depend on what type of content you create and whether you’re working as a team or alone. If you’re a website designer or an instructional technologist or a faculty member, it might be a little bit different as to how you proceed. In general, everyone can begin with number 10, and that’s about adding an accessibility statement to their website or their syllabus or their online course.

And then from there, as you create new content, you can keep the 10 tips handy and implement them during the creation process. As you learn the 10 tips, you can maybe graduate to the WebAIM checklist for HTML content and then also the WCAG 2.0 documentation.

To remediate any existing content, if you have a team that you can assign each person a task– for example, we have web teams where one person went through and remediated all the hyperlink text, and another person was responsible for remediating images and alt text. And you can also divide up the responsibilities by team members.

LILY BOND: Great. So I think we have time for one more question. So Janet, I’m going to ask, do you have any success stories to share specifically of faculty working on accessibility?

JANET SYLVIA: Yes, actually, we do. I’ve been training faculty for more than 10 years on how to create accessible content. Most are very open and excited to learn. Over the last couple of years, I’ve actually taught this one-hour seminar as a half-day workshop for academic faculty and instructional designers. And we would meet in a computer lab, where faculty could log into their online course or bring their online course materials on a USB drive and then plug it in and open their content that way.

As we covered each tip, we would allow the faculty time to stop and remediate their existing content. So they would gain experience using the technique in an environment where there were people to assist them. And then, by the end of the workshop, people who were new to accessibility were able to end the workshop with both knowledge and experience in making their course content accessible, plus they had content that was ready to go and accessible.

Several of our faculty members actually later became accessibility advocates among their peers. And so I would highly recommend targeting faculty members as groups to share these types of 10 tips with.

LILY BOND: Wonderful. Well, Janet, thank you so much for your presentation. It was very informative, and people are really thrilled with it, so thank you for sharing.

JANET SYLVIA: Thank you.

LILY BOND: So I hope that everyone has a great day, and thank you again for joining us.

Interested in Learning More?