A variety of users will navigate your web pages so it is important to take the extra effort to increase your website's overall accessibility and usability. CMS 210: Introduction to Web Accessibility will help you with this important aspect of website design. The 30-minute video course will cover topics including why accessibility is important, different types of disabilities, making elements of your web page accessible, and proper heading use.
Prior to taking this course, we recommend you first complete CMS 110: Introduction to the CMS. For more on this course visit Introduction to the CMS.
CMS 210 Training Video
Below, please find the full transcript to this video.
Within our Help Center:
Full Video Transcript
>> Hello and welcome to CMS 210: Introduction to Web Accessibility. What is web accessibility? Web accessibility refers to removing barriers that prevent people from successfully reaching and interacting with web material. Over here on the right, we have a different example of accessibility. We have an individual in a wheelchair staring up at a second floor that they cannot reach due to the fact that there are no ramps. They are probably very aware that they are in a wheelchair and they are probably very frustrated. So what did the world do? Let's take a look at a bus example. The world started off with the concept of accommodation. They took an existing system and sort of augmented it, tried to accommodate these individuals. In this example here, we have a man. He's sitting in a chairlift. The bus is having to wait for him while they do this. People are staring at him while they're doing this and it slows everybody down and doesn't make anybody comfortable at all. It's not really an ideal solution. The next thing that people tried was universal design. We're going back to our bus example here. The bus kneels. They include a built-in ramp and now not only is this bus accessible to people in wheelchairs but it adds functionality for everyone else, such as this father who is using a stroller to go to a park. He can actually bring that stroller onto the bus, something that was not available in the previous incarnation of those buses. So universal design. It addresses the larger issues of usability by making things easier for everyone. You can reduce fatigue, you can increase speed, you can decrease errors, and you can decrease learning time. And these are some of the concepts that are covered in the usability first link here on the bottom right. Those of you that are interested, you can download this presentation and click on these links. I won't keep bringing that up but these links are there for you folks that want to download this presentation. So something to think about. We have 8.5% of the population that has a disability that affects computer use, 8.5%. And this is excluding cognitive learning disabilities and people with color blindness. So the percentage is even larger, but 8.5% of the population has a disability that affects computer use.
So let's stop here for a second and think about this. How could not having access to the internet have a negative impact on lives? How could it have a negative impact on your life? What happens if you had difficulty getting at the internet for your daily tasks? Feel free to pause the video and think about this of, if you're in a group, you can discuss and continue forward when you're done.
We're going to look at some experience of students with disabilities and we have students in the following video and they'll share some of their experiences with the web in accessibility.
[ Music ]
>> When I was 14, I lost my sight and I just remember -- I was like surfing the web and it was just so much easier, like I liked to get on it so much more. And now it's just so frustrating because you can't see the graphics and like what's gone on sometimes and it's just frustrating.
>> I use the internet connected to school subjects quite often and I use it for projects and tests but also one of my most recent projects -- the only way I could get it done was to go to google.com. All the other recommended websites were not very accessible.
>> Without captions, it's hard to understand what you're doing. I just have to try and make it up. With captions, I know exactly what's going on, I know the specifics of what they're talking about.
>> It's kind of hard to be required to do something and not be able to do it and you have to find somebody else to come and help you do it on their own time.
>> And I can't navigate by myself. And I like to be independent. It gives me a feeling of pride and it is also slower if somebody needs to help me, which they would.
>> And something that would help out a lot of visually impaired people is just for that person to go the extra step, which isn't much at all, to make the websites accessible so that we're able to do our assignments.
>> Okay. Those of you who want to, rewatch this on YouTube, you can feel free to. Click on our handy YouTube link here. And we're going to go ahead and move on. These users were talking about assistive technology. So those of us that are listening today -- uses assistive technology. And feel free, again, to pause the video, think out loud, talk amongst yourselves. We're going to move on. Would it shock you to realize that if you're using glasses you are using assistive technology? It's not in a computer but it is a piece of technology that allows you to see. We have different categories of disabilities and here's a WebAIM link. We have visual, which covers blindness, low vision, and color blindness. We have hearing. This covers deafness and hard of hearing. Motor -- some people cannot use a mouse. Others have slow response time and others still have limited fine motor control. And then finally, we have cognitive. Those cover learning disabilities, distractibility, and inability to remember or focus on large amounts of information. Some assistive technologies and the web -- I thought it would be nice to go through some of these more common technologies that you will probably come across. People with blindness will be using screen readers, refreshable Braille devices. This is a device that kind of looks like a giant typewriter, there's no monitor. My sister uses one of these. There is a line of Braille, she reads across, and then the system will move down to the next line. On your webpage, the Braille will refresh so the dots will move and she will rescan and move through the web content in that fashion. Now we have people with low vision -- screen enlargers, screen readers; color blindness -- maybe they're using color enhancement overlays on their web browsers, which we'll go into in a bit -- or glasses. Deafness -- this is where if you have YouTube videos, you need to start thinking about captions and transcripts. I won't go into the rest of this but please feel free to read through the rest of this table as you have time.
So the big one -- what are screen readers? Screen readers are audio devices -- or audio interfaces, sorry -- and rather than displaying web content visually for users in a window or a screen on the monitor, like we're all familiar with, screen readers convert text into synthesized speech so that users can listen to the content. What does that mean? Let's take a look at Mac OS X's VoiceOver screen reader.
>> Voiceover on Chrome. Welcome to UCSB Student Affairs window. Welcome to UCSB Student. Chrome button. Leaving toolbar. Internal link. Skipped to content. Ask a question or search. Edit text. Ask button. Search button. Entering banner landmark. Heading, level one, Division of Student Affairs. Leaving banner landmark. Entering navigation landmark. Menu bar seven items. Link. Home. Menu bar seven items. Link about. Link goodspeed intern welcome message. Menu three items, level two. Link, Office of the Vice Chancellor for Student Affairs. Link, principles of community. Link, departments and services. Menu bar seven items. Landmarks, five items. Links, 30 items. Headings, five items. One, Division of Student Affairs. Two, office of the Vice Chancellor for Student. Three, spotlight on. Form controls, three items. Web spots, zero items. Tables, zero items. Landmarks, five items. Banner. Search. Navigation. Main. Link. Leaving navigation landmark. Michael Young is retiring after a 40-year career in Student Affairs, over 25 of those at UCSB. All are invited to a retirement reception on Friday, January 23, 2015 from 3 to 6 PM in Corwin Pavilion. Image.
>> So a screen writer is moving through your webpage. What are some of the tips and tricks? What can you do to make your webpage sound sensible to a screen reader? Let's start off with the obvious: blind people can't see images. By itself, an image is meaningless to a blind person because screen readers can only read text. To the rescue come image descriptions, or alt text. They're read by a screen reader when the image is selected and they're displayed if an image does not load. So here we're coming back to the idea of universal design. If someone has images disabled or if their browser's unable to load them for any reason, we can see John Doe, if that is the image description. We are, as a visual user, able to get more out of this webpage than before we worked on web accessibility. My rule of thumb for image descriptions are what text would you use if you could not use the image in 255 characters or less? In the CMS, you put this into the image description input field while working inside the insert edit image dialogue and it's highlighted down here in red. Let's work through a few exercises and you can feel free to pause this video and talk amongst yourselves. The first image up is our MSU Researchers Test Computer on Space Station and one of our professors. What image description would you use for this image? Well, I might say something like, MSU Researchers Test Computer on Space Station and MSU photo by Adrian Sanchez Gonzalez. What about for this? It depends on context, right. If this image is talking about how wonderful the weather is in Gallatin Valley, the whole point of this image might be to say that the grass is green, the weather is wonderful during the summers. Maybe that's your image description? Or if this image is on a page talking about the expansion of the MSU campus, you might say X number of buildings present at MSU as of 1999 or something like that. It all depends on the context and what is the point of your image. And finally, an infographic. What would the image description be in this case? If my purpose of this infographic was merely to describe the fact that most of our users were split pretty evenly between Chrome and Firefox, that would be my image description. Most of our users are split pretty evenly between Chrome and Firefox. I don't need to go into details like blue pie slice 4.5% Safari, red pie slice 2.3% Opera, etc., etc. I just need to describe why I put this image on this page. Most of my users are pretty evenly distributed, say between Chrome and Firefox. Next up, unfortunately, not all people can see colors. Completely blind people cannot see any colors. People with low vision may be able to see some or most colors but not be able to distinguish between the two. And people with color blindness, they may be able to see some colors just fine but they may not be able to distinguish between certain combinations of colors, such as reds and greens. Who here recognizes this from elementary school? It's the old color blindness test. What are the numbers? And feel free to pause. I see 16, 9, 74, and 12 going from left to right, top to bottom. People without color blindness will be looking at our MSU home page like this, this is the normal view. Someone with protanopia, red-green color blindness, will see our home page like this. And let's focus on the visit, connect, and apply buttons. Even though connect and apply are now pretty much the same color, we are still able to discern the point of each element. One is connect and the other is apply. We've added text underneath those icons to give it meaning, text that we can see and text that a screen reader can read. Well, let's look at tritanopia, blue-yellow color blindness. The connect and apply, those are still roughly the same color. However, we still have the text and we still know that one is connect and one is apply. So the moral of the story, do not rely on color alone to convey meaning. Let's look at a simpler example. Over here on the left, we have some text in red. Maybe that text appears amongst black text paragraphs. What happens if I can't tell the difference between black and red? I will not know that my midterm is due on the professor's desk by 5 PM Thursday, February 26. I'll be out of luck. But what happens if that professor on their webpage put together an alert, has a nice border, he puts the word "important," so if I am visually impaired my screen reader will read the word important. I will be alerted to that fact and pay more attention to what's to come. And I will know that my midterm is due on his desk or her desk by 5 PM. Colors should also be chosen that don't make reading difficult -- so contrast. It is hard for some people to view text content if the color and brightness of the text are too similar to the background behind the text. Let's stop and take a look at this example and feel free again to pause. Is the text below easy to read? For me, it's fine. I have a dark to semi-lightish blue with nice white text, evenly spaced, very easy for me to read. And then the word "Journey" in orange above black jackets, I can see that. It's high contrast. The highest contrast is white against black or black against white and there's a resource link again. And many people invert or switch to high contrast color schemes in their browsers. So let's go back to the MSU homepage example. Here we have the normal webpage, normal color scheme. People like my sister will actually invert their monitor so they are looking at our home page like this. I can still tell the difference between the connect and apply buttons because we have that text -- we're still covered. Some people might even be looking at it with this high contrast yellow on black. Visit, connect, apply -- I still can figure out which one is which. Video and audio -- not every user can see video or hear audio. If you are deaf, you won't be able to hear what people are saying or what is going on. But fortunately, you can add video closed captioning. You can do this on YouTube but we ask that you watch out for YouTube's auto captioning and that you enter your own captions on YouTube. We have a fun little example here. In red is what is actually being said, so the accurate captions, and they are "ah, man...just hold the phone up in the air and let me hear the ocean." What Google's Auto will hear is "uh red just hold the phone up in the end of the Indians." That doesn't make any sense. So let's look at an example of closed captioning.
[ Video ]
>> So that's a nice example of closed captioning. You can see them down at the bottom of the window. Transcripts -- the only way to make video or audio content accessible to someone who is both deaf and blind is via a video transcript. If you already have captions, you can use them to start building your transcript. You don't need to build from scratch. So here we have a sample video transcript. I have started off by placing the captions that I've already written into it and sort of filling in some extra bits here and there and then I'm done. Now a lot of us are under time constraints and we have a lot to do in a very short amount of time. So if you must choose between captions and transcripts, do transcripts. Transcripts can be read by a screen reader, they can be converted into Braille. So those refreshable Braille devices can allow someone to move through the material of an image -- or a video -- and that audience member is now able to get at the content. And back to the concept of universal design, they can be translated into other languages. So if you have a Chinese-American student whose English isn't the best yet, they can translate that transcript into Chinese and very quickly get at the content. So you're helping out all of your audience members by building a transcript. Headings -- webpages need to be easily navigable. So as an exercise, let's think about this for a second. When trying to find information on a lengthy webpage, what do you do first?
Well, I might use "find" or headings or just read the page. Would it surprise you to know that over 65% of people using assistive technologies use headings? Headings are really important. Screen reader users must listen to webpage content and can't just glance at it like you I can. A lot of us will typically scan through a page, looking for that large text that are headings two, three, four -- we will find the particular heading that we need and we will start reading halfway down the page. But a screen reader will present those headings in a tree structure. It will rattle them off very quickly and someone using the screen reader will say -- okay, stop, I want that heading. And the screen reader will navigate down to that part of the page. So headings are very important. Just a recap on what headings are. They create a natural nesting of content on a webpage. Over here on the left, we have some heading two, a nested heading three underneath it, another heading two, a heading three, heading four, back to a heading three. Pretty much what you would expect from Microsoft Word or any other editor on the planet, so just those tree structures of headings. And then on the right, we have from our WYSIWYG, our editor in the CMS, we have the headings two, three, four, five, and six. Everyone should be pretty familiar with those now. Heading one is reserved for the page title. So while you're using headings, please stick with two, three, four, five, and six and do so in sequence. And don't start a webpage off with heading four, start off with a heading two. And then finally, do not fake a heading, make a heading. What do I mean by that? Let's take a look at this example. Over here on the left, we have some manually bolded text, a sentence, another manually bolded text, and so on and so forth. When a screen reader looks through this content, it's just going to rattle it off. It doesn't care that things are bold, it doesn't understand that we intended for them to be heading-like. We want to, on this good example, convert things to heading two, have the sentence, maybe the sentence underneath with the bolded text we wanted it to be nested under the heading two so we might make that a heading three, and so forth and so on. So make a heading, don't fake a heading. Links. Where does the link go? Before clicking on a link, do you know where it will take you? Who listening will click on a link in their email that says something like, "click here for awesomeness?" I wouldn't, it's probably linking to spam. Same sort of idea for people who are looking through your webpage and clicking on links. We want to make sure that the link text accurately describes the destination or purpose of the link. And many screen reader users will use the tab key to go through and read the links on the page out of context, so they won't even hear the surrounding text. You and I might see this paragraph. We understand that, okay, it's the logo that Bozeman second-graders designed, so I understand that's what the link is going to go to, for Bozeman second-graders. And then I finish reading through the paragraph and it's talking about the prototype and it's being tested on the ISS so I know if I click on "here," it's going to be about the more information on that topic. Here's what a screen reader will effectively see. "Bozeman second-graders" and then the word "here." Well, that's not very helpful. So let's try looking at some alternative content and link text. So let's come back to our paragraph. This time, I'm changing the link text to encompass the word "logo" and the word "designed." So now my link is "logo Bozeman second-graders designed." Okay, cool. Now I understand what that is. And then down at the bottom, instead of saying "read more for more information" or whatever, we actually change the last sentence to say "read more on LaMeres and the ISS tests." Now for us as sighted users, the paragraph actually makes a little more sense, it's a little more cohesive. And for a screen reader, they have "logo Bozeman second-graders designed" -- check, understand that. And they have "read more on LaMeres and the ISS tests." Okay, both of those make sense, we're set. Tables. Tabular data is not just for the sighted. Blind users cannot see a table's visual organization and without using header cells and data cells, screen readers will just read the content of a data cell without adding any context. If this is sounding terribly complicated, it is, building accessible tables is complicated. But we have an available table snippet or two available for use. You can look through Montana.edu/web/CMS, there's a help documentation link that will take you right over to table snippets or you can download this presentation and click on this link. So here's an example of what our snippet produces. We have our nice table caption, it says "spring 2017 exam scores." We have some table headers. Those table headers have markups saying that they pertain to the column. So exam one is talking about those scores directly underneath it, midterm, etc., etc. And it also has markups saying that the table header "John" pertains to the row. So that 79 is John's exam one score. If you use our snippet, then the screen reader will read "John exam one 79, midterm 98, exam three, 92, and final 84." If you build your own table and you don't put all of that structure together yourself, then a screen reader's just going to be rattling off these rows, it's not going to care what is a header, what is, you know, data in the table and, when it gets to John, it's just going to say, "John 79, 98, 92, 84." A screen reader user's going to have to try to remember that 92 pertains to exam three, they won't be told. PDF documents. Who listening has a PDF document on their website? Probably most of you. PDF files need to be accessible too. We know that PDFs are far more accessible than Microsoft Office documents, such as Word and PowerPoint. But you need to create something called a tagged PDF and this will add markup to PDF files in much the same way that you would add markup to HTML files, these webpages that you're building and we've been talking about so far. And you need to do it using it Adobe Acrobat Pro. You will need to mark text as headings, paragraphs, lists, tables, and other semantic elements. It is a lot of work to make a PDF accessible. But remember that webpages are infinitely more accessible and you already know how to make one. So rather than producing something in Microsoft Word, saving to PDF, finding your website and uploading and publishing it and then adding a link, why not just cut out two-thirds of that process, go make a new webpage, build the content out just like you would have in Microsoft Word? And you're done. It's a third of the work, a third of the work. And it's already accessible, you don't have to reinvent the wheel. And if someone has -- maybe one of your student workers or coworkers -- has produced a beautiful brochure, you know, it's got graphics all over it. You can put together a webpage sort of similar to that content and you can upload and publish that PDF and provide it somewhere on that page and say, "download our brochure" or something. You can produce a page that serves both audiences, both those that, you know, want that PDF and those that just want to read the content, maybe the when, the where, what to bring, who's going kind of thing. We have more information on PDFs, feel free to download the presentation again, click on these links. We have the accessibility in PDFs directly from Adobe's mouth, WebAIM cheat sheets -- WebAIM is a group that works on web accessibility and they also some rich media accessibility tips and tricks for those that are interested. Additional information. Testing -- so we have the web accessibility evaluation tool, or WAVE, and this can help you audit a site after an initial development is complete. Don't try this until you've taken the concepts you've learn today and applied them to your website. Otherwise, you're going to have a lot of noise that's going to be very overwhelming. Go through and try it first -- try making your edits first, rather -- then run the WAVE tool. But perhaps more importantly, try using your website with a screen reader and your monitor turned off. That will probably give you the most accurate picture of what folks with visual impairments will be seeing or will experience as they interact with your website. Fire up a screen reader, open your website, and turn your monitor off and go. The accessibility principles. So according to WCAG 2.0, web content must be the following in order to be accessible: it must be perceivable, operable, understandable, and robust. Well, what does that mean? POUR, you know, it's the acronym here, P-O-U-R. Well, let's take a look. So let's start off with perceivable. Some users rely on hearing or touch. Operable, this comes to mice, keyboards, and other input devices. We take care of this through our web templates to make sure that people can navigate using the keyboard, you don't need to worry about that. Understandable -- it needs to be perceptible but also comprehensible content, that's back at you guys. And robust comes back to us and our web templates. Our web temples are compatible across multiple platforms -- phones, tablets, you name it. Our web templates can handle it.
The web accessibility initiative. So the World Wide Web Consortium, or W3C, they are the group that manages the technical specifications for HTML, XML, and other web technologies. And in 1996, the W3C formed the Web Accessibility Initiative, or WIA. And they did this to create technical guidelines for making web content more accessible to people with disabilities. Some legal requirements and laws. The Americans With Disabilities Act, so ADA -- this pertains to places of public accommodation. We have Section 508 of the Rehabilitation Act and we have the 21st Century Communications and Video Accessibility Act. And there are links for those that would like to learn more. Takeaways. We been talking for over half an hour now but the things that I want you all to take away from this presentation are: writing sensible image descriptions; do not fake a heading, make a heading; use headings in order -- two, three, four, etc.; and make link text that makes sense when read alone. And if you do these simple things, then even people like Stephen Hawking, who can only interact with computers now using a muscle in his cheek, he will be able to successfully navigate through your website. So thank you and be sure to check out our web accessibility help documentation. And again, try it for yourselves. Go back to your desks, fire up your website, turn on a screen reader, ITC -- or rather, UIT will have some options, and turn your monitor off and try it out.