Web Accessibility Including People with Disabilities- Introduction
Some people with disabilities use adaptive technology to access computers. Web accessibility standards provide guidance to allow adaptive technology to function with websites and to allow people with disabilities to have more equal access to information. As librarians, we may be in an especially good position to promote web accessibility.
| Group* | Examples of web accessibility affecting some members of this group | Example of adaptive technologies sometimes used |
|---|---|---|
| Motor |
Individuals who do not use their hand to use a mouse may rely on various other input devices, such as the keyboard. Keyboard accessibility: allows people to reach everything on the page with the keyboard. A quick, rough test for Libguides authors who are sighted: Open a Libguide in Internet Explorer and see if you can reach all the parts of a page using the Tab key. IE shows a dotted line around the active part of the page. |
|
| Cognitive |
Some people with learning disabilities, such as dyslexia, learn better by hearing content aloud. PDF accessibility: If a pdf is accurately ocr'ed (optical character recognition), the Kurzweil 3000 adaptive software can read the pdf aloud. |
Kurzweil 3000. Reads articles and text aloud. |
| Hearing |
Captioning: Allows access for Deaf and hard of hearing users, as well as improved access for language learners and others. |
|
| Vision |
People who are blind generally use screen readers to read the computer screen aloud. Screen readers are intended for use with a keyboard, not a mouse. Keyboard accessibility: allows people to reach everything on the page with the keyboard. PDF accessibility: If a pdf is accurately ocr'ed (optical character recognition), the screen reader adaptive software can read the pdf aloud. Audio description: brief, audible description of visual content of videos. |
Screen readers: Jaws, Voiceover on Macs. Reads a computer screen aloud. Used with a keyboard, not a mouse. |
*These groups were taken from WebAIM's Introduction to Web Accessibility. These are not official categories or diagnoses; rather, they are ways to understand how some people are affected by web accessibility. As WebAIM explains, "Though estimates vary, most studies find that about one fifth (20%) of the population has some kind of disability. Not all of these people have disabilities that make it difficult for them to access the internet, but it is still a significant portion of the population. Businesses would be unwise to purposely exclude 20, 10, or even 5 percent of their potential customers from their web sites. For schools, universities, and government entities it would not only be unwise, but in many cases, it would also violate the law....Each of the major categories of disabilities requires certain types of adaptations in the design of web content. Most of the time, these adaptations benefit nearly everyone, not just people with disabilities. Almost everyone benefits from helpful illustrations, properly-organized content, and clear navigation. Similarly, while captions are a necessity for deaf users, they can be helpful to others, including anyone who views a video without audio. "
Following are some tips to assist Libguides authors to make our Libguides more accessible. This isn't intended to be comprehensive, but is intended to cover some common or significant accessibility topics.
Adding a description, called alternative text, or alt text, to your images will allow blind users to hear a description. (Screen reader adaptive technology cannot read images.) When you add an image in Libguides, you will get the following popup box. The Alternative Text field allows you to add your description.
Usually, a very brief description is best. If the image is purely decorative, you can leave out a description to save your blind users time.
If the image conveys significant information, such as a screen shot of part of a webpage, you might decide to add a longer description. You could mention important features to which screen reader users can quickly navigate, such as the wording of links, or the existance of search boxes, or buttons. It is best not to use "left" or "right" when explaining page layout, as screen readers don't identify what is on the left and right. Screen readers generally tend to read a page from top to bottom by default, but they sometimes do not read columns from left to right, as the columns are visually presented.
However, if you already explained the image in your webpage text, you might just describe the image as "screenshot explained above [or below]". That way your blind users won't hear the same thing twice.
For more information, here is a list of Jaws keystrokes, which shows many page elements to which screen readers can jump. Jaws is a widely used screen reader.
WebAIM offers additional guidance about writing alt text and about accessibility of images.
People with some physical disabilities and blind users typically do not use a mouse. Keyboard accessibility allows people to reach everything on the page with the keyboard.
A quick, rough test for Libguides authors who are sighted: Open a Libguide in Internet Explorer and see if you can reach all the parts of a page using the Tab key. IE shows a dotted line around the active part of the page.
Within Libguides, while most of the interface is keyboard accessible, it may be most relevant to test keyboard accessibility for apps and widgets.
A common keyboard barrier is the video control buttons on many streaming video players. Although the video control buttons on Youtube are not accessible, the Youtube video will start playing when the page opens. If you cannot find an accessible video player and you have the video on Youtube, providing a link to Youtube can give your blind users partial accessibility. It may also be helpful to know that, although many large streaming video vendors are not yet keyboard accessible, Kanopy and NBC Learn do promote their keyboard accessibility.
Screen readers typically begin reading a page from beginning to end. Screen reader users often will listen through a page in detail the first time they access it, in order to become oriented to the page. As you can imagine, this can take a very long time, particularly listening to excessive preliminary text, like tiny text for login, or navigation bars, that sighted users typically skim over.
Here are features that allow blind screen reader users to navigate more quickly:
WebAIM offers additional information about semantic structure and designing for screen reader compatibility
For some users with cognitive and learning disabilities, it is helpful to have plenty of space on a page and as little clutter as possible. Libguides authors may want to consider limiting the number of columns on a page, and avoid using very small text. Screen readers and mobile devices read Libguides columns from left to right and top to bottom. Therefore, you may want to consider putting the information that you want users to access first in your left column, or merge the left and center columns.
If a pdf is accurately ocr'ed (optical character recognition), text to speech software used by some people with learning and visual disabiliites can read the pdf aloud. A quick test for sighted users to see if a pdf is ocr'ed is to check whether you can highlight an individual word using the mouse. If so, it is ocr'ed. If the whole page is highlighted. It is not ocr'ed.
If you have Adobe Acrobat Professional, you can quickly and easily ocr a pdf. Alternatively, if your pdf is not ocr'ed and you have the same information available in html or Word, you could link to the other format, which a screen reader could read.
A second step to making pdf's accessible is tagging and correcting the reading order. This allows screen readers to read columns in the correct order, to access descriptions of images, charts, graphs, and more. To check whether your pdf is tagged, you can right click, go to document properties, and it will say Tagged: Yes or No. If it is not tagged and you have the information available in html or Word, consider linking to a format other than the pdf.
Adobe Acrobat provides more information about tagging, correction the reading order, and ocr using Adobe Acrobat Pro.
Videos produced in house:
Planning time to type out a transcript while creating a video can give you a more professionally produced product, as well as allowing you to sync the transcript with the video to add captioning. Some video capture software, such as Captivate and Camtasia, make it fairly easy to sync transcripts with videos. Youtube will also allow this. Youtube's automatic captioning may help you produce a transcript. However, it is important to edit the auto-captioning to avoid frequent and hilarious "craptioning".
It is helpful to add brief descriptions of visual content for users with visual disabilties. For example, if you create a video showing some text, you could read the important text aloud within the video. For videos showing screen shots of webpages, it could be helpful to name important features to which blind users could navigate, such as the wording of essential links, search boxes, or buttons. American Council of the Blind offers more information and examples of audio description
Linking to text of a transcript can be useful for many users, including Deafblind people who use refreshable Braille to read the web.
Commercial videos (VHS, DVD, streaming):
Audio description and captioning may each be on separate tracks, which can be turned on and off. Unfortunately, audio description is not yet widely available. If you list commercial videos on a Libguide, it could be helpful to note whether or not captioning or audio description are available.
Michigan State University Libraries' offer code to improve accessibility of embedded media. They explain, "When you embed media, such as a video, Google form or search widget into your guide, LibGuides uses a "container" called an iframe to display the media on your page. One way to make iframes more accessible is to add a title, so that the user knows what he or she has encountered on the page. LibGuides does not automatically assign meaningful titles to iframes, but you can do so yourself when embedding media into your guide. This is a quick bit of text that you will add directly into beginning of the embed code. [See code]"
Webaim offers a quick explanation of table accessibility.
In summary, it is best to use tables for data rather than for layout. In Libguides, you will get the following popup box when inserting a table. Using the header dropdown, will allow screen reader users with visual disabilities to identify the table headers.
For authors who want to edit your own code to create a form, Webaim offers a guide to making forms accessible. In summary, adding a tag to associate the form element with a form label can allow screen reader users to understand the form. Forms provided by Libguides need to be checked for accessibility.
First, web accessibility guidelines can be quite detailed! Many Libguides authors may find high quality secondary sources like WebAIM's Introduction to Accessibility more useful.
There are two, similar, prevalent sets of guidelines:
