![Learning objectives ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Lecture 9 Accessibility Original
Similar to Lecture 9 Accessibility Original (20)
More from Sur College of Applied Sciences
More from Sur College of Applied Sciences (9)
Recently uploaded
Recently uploaded (20)
Lecture 9 Accessibility Original
- 3. What is accessibility and why is it important?
- 5. Accessibility is about all of us. World population: 6+ Billion Worldwide number disabled: ~1 Billion (16%) United States population: 281 Million United States number disabled: 54 Million (19%) Source: Population Reference Bureau, United Nations and. Forrester Study Commissioned by Microsoft Physical Disabilities Disabled population 16% of world population is disabled Mobility Deaf Blind Other conditions that inhibit I T use Aging By 2010, 60% of US population will be over the age of 35 Poor hearing Failing vision Color blind Nonnative speakers In the US, 17.9M people speak a language other than English at home Temporary disabilities Everyday situations disable certain senses temporarily Noisy environments (hearing) Driving (sight) Accessibility affects many people, especially with the growing need to embrace aging workforces, customers, and citizens.
- 7. Example of user experience with slight visual impairment Example of 20-year-old user who has 20/20 vision. Example of 50-year-old user who has 80% of original vision and slight colorblindness.
- 9. Accessibility laws and regulations
- 10. Accessibility standards are not all the same. US Section 508 W3C/Web Accessibility Initiative (WAI) Accessibility Guidelines
- 12. 508 Web guidelines are different from W3C WCAG priority 1s. 4.1 p1 Identify changes in language (rare access issue) 14.1 p1 Clearest and simplest language appropriate for site (subjective) and an additional 28 priority 2s Additional W3C Priority 1s and 2s 6.3 p1 Turning off scripts required (p2 otherwise) 6.3 p1 Turning off applets/plug-ins required (p2 otherwise) 10.2 p2 Position labels on forms 12.4 p2 Explicitly label form controls 13.6 p3 Group and provide method to skip l. Accessible JavaScript OK m. Applets, plug-ins, and other OK if 508 software compliant n. Electronic forms o. Skip navigation links p. Timed responses Different 1.1 p1 Alternatives for non-text elements 1.4 p1 Synchronized captions and descriptions 1.3 p1 Provide auditory description of video 2.1 p1 Color independent 6.1 p1 Style sheets not required 1.2 p1 Server-side image map 9.1 p1 Client-side image map 5.1 p1 Column and row headings 5.2 p1 Complex tables 12.1 p1 Titles for frame 7.1 p1 Avoid flicker 11.4 p1 Text-only if necessary 6.2 p1 Update dynamic content equivalents a. Alternatives for non-text b. Multimedia c. Color independent d. Style sheets not required e. Server-side image map f. Client-side image map g. Column and row headings h. Complex tables i. Titles for frames j. Avoid flicker k. Text-only if necessary Identical (Declared in 508 preamble) Web Content Accessibility Guidelines (WCAG 1.0) Priority 1 & 2s 508 Web Accessibility part Section 1194.22 Paragraphs
- 13. Most additional WCAG priority 2 requirements increase usability; many are solved by browser + assistive technology. There are 23 additional priority 2 requirements shown on the next two charts. Section 508 Web Accessibility Section 1194.22. Paragraphs a through p do NOT map to any of these W3C WCAG priority 2s. Yes M 7.5 Don't auto redirect Yes M 7.4 Don't auto refresh Yes M 7.3 Avoid moving content Yes M 7.2 Avoid blinking L 5.4 Don't use table markup in layout tables Yes H 5.3 Don't use layout tables that don't linearize L 3.7 Use quotation correctly M 3.6 Use list markup correctly Yes M 3.5 Use heading levels in document structure Yes H 3.4 Use relative sizes Yes H 3.3 Use style sheets to control layout/presentation Yes L 3.2 Validate markup H 3.1 Use markup when appropriate (i.e., SMIL) Yes M 2.2 Background and foreground contrast Workaround supported in A T or browsers Impact to developer Web Content Accessibility Guidelines (WCAG 1.0) Priority 2's
- 14. Most additional WCAG priority 2 requirements increase usability; many are solved by browser + assistive technology. M 13.4 Use consistent navigation L 13.3 Add site map and TOC L 13.2 Add metadata M 13.1 Clearly identify target of link Yes H 12.3 Divide information into groups M 12.2 Describe purpose of frames Yes M 11.2 Avoid deprecated W3C features Yes H 11.1 Use W3C technologies Yes M 10.1 Don't spawn windows without notifying user Workaround supported in A T or browsers Impact to developer Web Content Accessibility Guidelines (WCAG 1.0) Priority 2's
- 18. Understanding the impact of disabilities on an I T user
- 20. Blind users must use a screen reader and the keyboard. User presses Alt key to access menu. User presses right arrow key. The menu must be coded in a standard way so that the screen reader understands and can convey the information to the user.
- 21. Users with low vision need enlargeable fonts and high-contrast settings. Font Size Larger font size Even larger font size Low Contrast High Contrast Large fonts and high contrast A screen magnifier is needed when user needs go beyond operating system capabilities.
- 23. Color deficiency (continued) It is okay to use color, as long as color is not the only way to convey information.
- 31. A closer look at some Web coding techniques
- 40. Identify row and column headers using the scope attribute. Inaccessible table headers <tr> <td> </td> <td>Percentage with any disability</td> <td>Number with any disability<td></tr> <tr> <td>Population 5-15 years</td> <td>5.8</td> <td>2,614,919</td></tr> <tr> <td>Population 16-64 years</td> <td>18.6</td> <td>33,153,211</td></tr> …… Accessible table headers using scope <tr> <td> </td> < th scope=“col” >Percentage with any disability< /th > < th scope=“col” >Number with any disability< /th ></tr> <tr> < th scope=“row” >Population 5-15 years< /th > <td>5.8</td> <td>2,614,919</td> <tr> < th scope=“row” >Population 16-64 years< /th > <td>18.6</td> <td>13,978,118</td></tr> ……
- 41. Identify row and column headers using headers / id attributes. Inaccessible table headers: <table summary=“Job openings by position> <caption=“Technical Job Openings as of Nov 1, 2003” <tr> <td>Job Position</td> <td> Level</td> <td>Location</td> <td>Agency</td></tr> …… . <tr> <td>Computer Scientist</td> <td>GS-17</td> <td>US-MS-Vicksburg</td> <td>Army Research Lab</tr> <tr><td>Army Corps of Engineers</td></tr> <tr> <td>US-MD-Prince George County</td> <td>Army Research Lab</td></tr> …… Accessible table headers using headers tag <table summary=“Job openings by position> <caption=“Technical Job Openings as of Nov 1, 2003” <tr> < th id=“col1” >Job Position</th> < th id=“col2” >Level</th> < th id=“col3” >Location</th> < th id=“col4” >Agency</th></tr> … .. <tr> < th headers=“col1” id=“compsci” >Computer Scientist</th> < th headers=“col2” id=“gs17” >GS-17</th> <td headers=“compsci gs17 col3” >US-MS-VicksBurg</td> <td headers=“compsci gs17 col4” >Army Research Lab</td></tr> <tr> <td headers=“compsci gs17 col4” >Army Corps of Engineers</td></tr> ……
Editor's Notes
- Welcome to the lecture Introduction to Accessibility .
- This training provides an overview of accessibility issues and technologies. The focus of this training is on making information technology accessible to people with disabilities. By the end of this training session, you should be able to: Define accessibility Explain why accessibility is important Describe accessibility regulations Define assistive technology Identify different disability types Explain checklist items from accessibility guidelines Locate accessibility resources
- First, we’ll take a look at what accessibility is, what it means, and why it is important in the context of information technology.
- In its narrowest sense, a ccessibility means making I T accessible to people with disabilities, such as people who are blind, have low vision, are deaf, have reduced ability to hear, or have limitations in mobility. Generally, making I T accessible involves designing or modifying equipment, hardware, or software to allow access by people with disabilities. As you’ll see later in this presentation, though, people of all abilities can benefit when I T is accessible.
- To get an idea of the size of the disabled population, consider that there are over six billion people in the world. Approximately one billion of those people have some type of disability. But accessibility is not confined to what we know as physical disabilities. From our perspective, accessibility means providing access to information technology for all, regardless of age or ability. For example, consider the relationship of aging to physical ability. A number of conditions, such as diminished hearing or a lessened ability to see color, are associated with the aging process. Consider also that people with no diminished physical capacity are often in situations where they cannot easily hear or see. “Situational disabilities” are conditions that temporarily restrict a person. As an example, people working on an aircraft carrier cannot hear because of the noise. Similarly, people can have restricted movement from a common condition such as carpal tunnel syndrome. For that matter, when you are driving, you are temporarily visually impaired; you need to keep your eyes on the road, and you can’t easily look at a visual display. Accessibility is important because it benefits all users. Accessibility is about all of us.
- Have you ever tried to learn a new language? If so, then you probably know that it is usually much easier to understand a speaker if, at the same time, you can read what he or she is saying. In fact, many online language learning courses are designed this way; the student hears the words spoken while the words appear in text on the screen, all in the language the student is trying to learn. This is exactly what speech-to-text technologies, which are designed for the deaf or hard of hearing, do; they simultaneously change spoken words into written captions. Notice that, in regard to nonnative speakers, we aren’t talking about translation but about simple captioning in the same language that the speaker is using. Simply having the dual input – both the speaker’s voice and the captions – can significantly boost comprehension. Similarly, because hearing and eyesight often become less acute with age, technologies to enable the user of a computer program to adjust font size and contrast, or to caption on demand, can be very helpful to older people. Designing these helpful technologies into your Web site and advertising them to older audiences is a way to differentiate yourself and to show that you understand the needs of your audience. Think of it this way. There are ramps built into sidewalks in most American cities. Originally these were added to comply with the Americans with Disabilities Act (ADA) to accommodate wheelchairs. But if you watch on any street corner, all sorts of people use the ramps – package delivery personnel with wheeled carriers, kids on skateboards and roller blades, people pulling wheeled luggage. A feature that was built in to accommodate a relatively small group of people has benefits beyond its original design. Accessibility is important because it helps businesses serve their customers better, often giving the business a competitive advantage.
- As an example, this computer simulation was performed with an IBM tool called aDesigner. The contrast between the two images illustrates the impact that aging has on the ability to view Web content. On the left you are seeing what a person with 20/20 vision sees. Notice that the colors are crisp and clear and the wording is easy to distinguish. On the right is an example of what a 50 year old who has lost 20% of his vision sees. The older person in the example is not blind, but has lost some ability to distinguish color and contrast, making it harder to read a Web page. So imagine seeing all Web pages the way the person on the right does. The words don’t contrast sharply with the background, and you can’t easily tell that the text uses several colors.
- One last key point: accessibility is important because, in many places, it is the law. Legislative and regulatory bodies around the world are realizing the need to address and mandate requirements to meet accessibility needs. For example, the U.S. has Section 508 and the ADA. In addition, some U.S. states, such as Arkansas, Colorado, Kentucky, Maryland, Minnesota, Texas, and Virginia, have their own regulations. And many more are looking to adopt state versions of the federal Section 508. Legislation has passed or is pending in many countries: Canadian legislation includes the Canadian Human Rights Act and the Ontarians with Disabilities Act, 2001. In Europe, many countries, including the U.K., Germany, Italy, Switzerland, Spain, Ireland, the Netherlands, and Sweden, have already enacted legislation. In Japan, the government and industry are cooperating to establish the JIS standards with a focus on Web accessibility. There's also legislation in Australia and New Zealand, which includes the Disability Discrimination Act and the guidelines from the Australian Communications Industry Forum. And, as mentioned earlier, in the U.S., the main regulation is Section 508 of the Federal Rehabilitation Act. The Web Content Accessibility Guidelines 1.0 (WCAG) from the Worldwide Web Consortium (W3C) represented the first major effort to establish guidelines for accessible design. This standard consists of 14 guidelines, each with three checkpoint levels for Web developers to meet: priority 1, priority 2, and priority 3. Accessibility standards help developers identify and address accessibility issues.
- In this section, we’ll take a closer look at some of these laws and regulations and how they differ in some cases.
- One of the key issues for developers is that accessibility standards are not all the same. As an example, we’ll take a closer look at how the primary U.S. procurement standard, Section 508 of the Federal Rehabilitation Act, differs from the W3C standards, which are worldwide standards. We mentioned earlier that the Web Content Accessibility Guidelines (WCAG) from the W3C represented the first major effort to establish guidelines for accessible design. This standard consists of 14 guidelines, each with three checkpoint levels for Web developers to meet: priority 1, priority 2, and priority 3. In individual countries, national standards emerged later. Section 508 of the Federal Rehabilitation Act in the United States is based on WCAG priority 1 checkpoints. These same checkpoints serve as the basis for standards in Australia, France, Germany, and many other countries. The Common Look and Feel standard in Canada and Guidelines for UK Government Websites in the United Kingdom are based on priorities 1 and 2 of the WCAG.
- A key difference between the W3C guidelines and Section 508 is that the W3C addresses only the Web. Section 508 covers all information and technology: software, hardware, and equipment such as printers and copiers. This chart shows a comparison of the Section 508 and the W3C guidelines. Section 508 addresses software in section 1194.21, Software applications and operating systems. The W3C guidelines address software through the Authoring Tool Accessibility Guidelines (ATAG) and the User Agent Accessibility Guidelines (UAAG). Web content is addressed in the Section 508 standard by 1194.22, Internet and intranet content and applications. The W3C standard is WCAG – the Web Content Accessibility Guidelines. The remaining standards are not covered in the W3C guidelines but are covered in Section 508. These include printers, copiers and kiosks, computer systems and hardware, and documentation. In addition, Section 508 addresses telecommunication products, video and multimedia products, and functional performance criteria that would be used for products that don't fall into the other categories of software, hardware, printers, computer systems, and documentation.
- The next two charts show the differences between the Section 508 Web guidelines and the W3C Web Content Accessibility Guidelines, or WCAG 1.0. This chart looks primarily at the WCAG priority 1 guidelines and compares them against Section 508. It seems that they are the same for the most part. There are two significant differences. These relate to JavaScript and the use of applets and plug-ins. In Section 508, JavaScript, applets, and plug-ins are perfectly acceptable as long as they meet the accessibility guidelines. But in WCAG 1.0, a Web site must be accessible with scripts and applets turned off. This can have a significant impact on many Web sites because JavaScript is used extensively now and many sites use applets such as Java applets. Another difference is that Section 508 not only looks at priority 1 guidelines in WCAG but also addresses some priority 2 and priority 3 guidelines, including skip navigation, which is a priority 3 in WCAG, and the requirement for accessible electronic forms, which are priority 2 guidelines in WCAG.
- This chart shows the differences in priority 2 requirements that are in WCAG 1.0 but are not covered as part of Section 508. Most of these guidelines increase usability. Examples include using list markup correctly, using style sheets to control layout, and using quotations correctly. Some of these are part of the Section 508 guidelines. Now that you have seen examples of the differences in two of the major standards, you should understand the importance of both standards and realize the necessity for coding to be compliant with these varying standards.
- This section should help you understand the difference between assistive technologies and accessibility.
- Users with disabilities frequently rely on hardware and software to access I T content. These tools, known as assistive technologies or A T, range from screen readers to touch screens and head pointers. Assistive technology can only be effective when the software and hardware it interfaces with is accessible. For example, a screen reader cannot read Web pages unless the developer has followed the standards to make them accessible. A screen reader cannot read informational graphic images unless the developer has provided alternative text for those images. If the alternative text is missing, the screen reader cannot provide the information, and the page is inaccessible.
- The relationship between accessibility and assistive technology is an important concept in accessibility. Accessibility is an attribute of information technology that allows the technology to be used by anyone regardless of abilities. Assistive technology is specialized technology that someone with a disability uses to access information technology. On the far left under “Inaccessible I T” are some characteristics of applications and products that are inaccessible. If the font size is static, someone who needs larger fonts or a different color contrast won’t be able to see the application. Inaccessible I T requires the use of the mouse even though many people with disabilities cannot use a mouse and rely on the keyboard or other input technologies. Graphics can't be read by screen readers unless the graphics have text alternatives. And inaccessible hardware has hard-to-reach controls and latches. When assistive technology tries to work with inaccessible information technology, the two do not fit together, as shown in this chart. Assistive technologies such as screen readers, magnifiers, speech recognition software, and special keyboards and switches can work only if the end technology they are interacting with has been designed to be accessible. The chart on the right shows how accessible information technology and assistive technology work together. If an application has color and font settings that can be adjusted by the user, if the mouse is optional and someone can use the keyboard, if there is text such as alternative text for graphics, and if latches and controls are easy to reach, then that application can work successfully with assistive technology. The key to this relationship is the use of standards and A P I s—for example, Microsoft Access Accessibilities (MSAA), the JAVA Accessibility API, and standard Windows controls. If an application uses an interface that is recognized by the assistive technology, then the two work together and you have an accessible solution.
- Understanding accessibility requires an awareness of the special needs of users with disabilities. Each person with a disability may encounter one or more barriers that can be eliminated or minimized by the software or Web developer, the assistive technology, or the underlying operating system software and hardware platform. As developers, you should be aware of the disability types that your audience might have. These include visual, hearing, mobility, and cognitive disabilities. The following charts discuss the different types of disability and then summarize the requirements that must be met so that people with each type of disability can use information technology.
- People with visual disabilities are blind, have low vision, or are color blind. They require a screen reader and the keyboard to access information. Because using a mouse requires hand and eye coordination, someone with a visual disability uses the keyboard instead of the mouse for navigation. Someone who is blind needs text equivalents for the graphics because assistive technology cannot obtain the information from the image. Someone who has low vision needs the assistance of a hardware or software magnifier to enlarge the text beyond simple font enlargement. People who are color blind or who have low vision benefit from good contrasting colors.
- Someone who is blind needs a screen reader and the keyboard to access information technology. The screen reader speaks the information that is displayed on the screen. For example, to access the menu, you press the Alt key on the keyboard and the screen reader says, “File submenu press F.&quot; When you move the arrow, the screen reader says, “Edit submenu press E.&quot; The menus have been coded so that the screen reader understands this information through the use of standard controls on Microsoft Active Accessibility on the Windows platforms. This is important so that the screen reader can convey to the blind user the same information that sighted users see on the screen.
- Some users with low vision only need to be able to enlarge the font size. This capability exists in the operating system. Other low-vision users might need only to change the color contrast setting. Text and graphics with low contrast—in this example, light blue text on a dark blue background—cannot be seen by many users with low vision. They need something with higher contrast—for example, yellow text on a black background. Some users with low vision need both larger text and high contrast. When the capabilities they need go beyond what the operating system provides, they use a screen magnifier (a type of assistive technology) to enlarge the fonts and create greater contrast.
- An estimated nine to twelve percent of the male population suffers from some form of color vision deficiency, commonly called &quot;color blindness.&quot; As a developer, you should take this into account and eliminate any potential confusions that can arise because of color vision deficiencies. Color-blind users need more than color differences to communicate information, so the graphic shown on the left is not good practice. In this design, green signals that a server is online, and red signals that a server is offline. But the color-blind user sees only one color, as in the graphic on the right.
- It is acceptable to use color as long as color is not the only way to convey information. The graphic shown here is good practice. Color is not the only way to communicate information here. In addition to color, the check mark and X indicate different statuses.
- People who are deaf or hard of hearing require visual representations of auditory information. The primary concern is to ensure that audio output information is provided in a redundant equivalent visual form. Captions and visual equivalents are required to make audio content accessible to someone who is deaf. In addition, someone who is hard of hearing needs to be able to increase the volume of content so they can hear it. In this example, a picture of Abraham Lincoln is displayed on the screen and the Gettysburg Address is being spoken. The caption displays the words as they are spoken: “Four score and seven years ago.” Without a text transcript of the speech, the content would not be accessible to someone who is deaf. Someone who is hard of hearing needs volume control. Application developers can provide volume control in applications or use the support for volume control in the operating system.
- People with mobility disabilities have physical impairments that substantially limit movement and fine motor control, such as lifting, walking, and typing. Someone with a mobility impairment may have difficulty using the computer's input devices or reaching buttons and latches on a copier. Accessibility support for someone with a mobility impairment is often provided through accessibility settings in the operating system. For example, the Sticky Keys option allows someone to type a sequence of keystrokes such as Ctrl-Alt-Delete one at a time. Someone with limited or no use of their hands needs keyboard accessibility features and alternative input methods. The alternative methods include speech recognition software, which enables the user to speak information instead of typing it at the keyboard. Other alternative hardware devices for entering data include joysticks, switches, mouth sticks, and alternative keyboards. In addition, many accessibility features are included in the operating system. These include the Mouse Keys option, which allows you to use the keyboard arrow keys to move the mouse pointer, and the Sticky Keys, Slow Keys, and Repeat Keys options.
- People with cognitive disabilities, such as dyslexia and short-term memory deficit, need more general solutions, such as consistent design and simplified language. These solutions also include speech synthesis, speech recognition software, word prediction, and highlighting tools that highlight the text as it is spoken so that the reader can follow along. For example, by using a template, you can reuse the same layout and design for each page, so the Web site is easier to navigate. People with cognitive or learning disabilities can also benefit from redundant input, such as both an audio file and a transcript of a video. By simultaneously viewing the text and hearing it, they can use their auditory and visual skills together to better comprehend the material.
- Maximizing accessibility involves following established standards. As an example, IBM developers are required to use detailed IBM accessibility checklists. These extensive checklists are based on the U. S. Standards for Electronic and Information Technology developed by the Access Board for Section 508.
- This chart provides a very brief overview of the checkpoints covered in the IBM Web accessibility checklist. A key focus is on providing text equivalent for images, audio, and multimedia. In addition, the checklist addresses navigation issues, such as skip navigation in frames and making features such as tables accessible. More details can be found on the IBM accessibility Web site. The link to the site is included at the end of this lecture .
- Software requirements drive the way that code is implemented. This chart shows an overview of the IBM software checklist. The checklist covers several key areas, including keyboard access, object information (which relates to how you make your information technology accessible to screen readers), sounds, and multimedia displays and timing. Again, a more complete listing with details can be found in the software checklist on the IBM accessibility Web site. You can find the link at the end of this lecture.
- This chart shows the documentation and support services that are also covered in the IBM checklists for Section 508. The documentation checklist talks about the requirement to provide documentation in an accessible format and to ensure that accessibility features are documented. Section 508 also requires that support services accommodate the communication needs of users with disabilities. And of course, once you've implemented the techniques, you need to test to ensure that the implementation is correct and accessible. This is done with accessibility checking tools, assistive technologies, and some manual verification. All of this is explained in detail in the IBM accessibility checklists; there are reference links for the checklists at the end of this lecture.
- Now let’s take a closer look at some Web coding techniques. Keep in mind that one standard is to follow the Web accessibility standards in making a Web site accessible. The following charts are intended to provide a practical overview of the techniques in making Web content accessible. However, keep in mind that accessibility is not limited to Web content only. It also includes other facets of information technology, such as making software, hardware, Flash technology, documentation, and other means of information accessible to people with disabilities.
- The rest of this lecture focuses on the specific HTML techniques you need to know to implement Web sites that are accessible to people with disabilities. This section covers the following areas. The first is images. Images can be a problem area because screen readers can’t read images and graphics unless they have a text equivalent provided through the use of the alt attribute. We’ll talk about the specific techniques for doing that. The second area is frames. Screen readers read pages sequentially. This can be a problem because it takes a very long time to get to the main content of the page. However, using frames can provide a quick way of navigating the page and getting where you need to go. The problem is that many Web sites that use frames do not provide meaningful frame titles. As a result, when a screen reader user listens to the list of frames on the site, the names aren’t meaningful and don’t help the user navigate to the page. Data tables are the next area. These can be a problem because screen readers must be able to read row and column header information to their users. If the HTML has not been coded properly, the screen reader user hears the data in the individual table cell, but not the row or column header, which means that the information is very difficult to understand. The last area is online forms. The important issue with forms is that screen readers must be able to identify programmatically the label of all input fields. We’ll talk about how they do that.
- The most common problem on Web sites today is probably the lack of alt text. This Section 508 requirement says that text equivalents for every non-text element must be provided. This means that every image, graph, and chart on your Web page must have alternate text. You implement alt text through the alt attribute in HTML. The syntax is alt= and, in quotation marks, a description of the image or chart. If you have an image that’s unimportant or is just used for eye candy or is redundant, you still have to provide alt text. You do this through use of null alt text, whose syntax is alt = and then two quotation marks. This is not the same as providing no alt text or forgetting to add the alt attribute. If the alt attribute is missing, the screen reader assumes that the information is important and reads the only data available, which is the name of the URL or the image itself. This is not accessible design. You have to use the alt attribute for all images, regardless of whether you provide a specific text description or use null alt text. Null alt text is not appropriate for image links unless they are redundant. Some Web sites have a text link and a graphic link that go to the same place together. In the case of the graphic link, it is acceptable to use null alt text because there is an equivalent text link immediately next to it. Some tools and some developers also use alt= with a quotation mark, a space, and another quotation mark to indicate null alt text, but this is not null and causes the screen reader to read the item. Accessibility checkers check for the presence of a text description or null alt text for all images that are on a Web page. In the first example here, the picture is a picture of the man and the alt text is alt=“Sam” , which is the man’s name. You may want to make it more descriptive, but alt=“Sam” is sufficient in most cases. The next example looks at the use of spacer images, which are commonly used on Web sites. In this case you want to use null alt text. You do not want to use alt= space or gif because that’s exactly what the screen reader will read every time that this spacer image is encountered. Another use of alt text is on an image button. Generally speaking, the image alt text should be the alt description. In this case it’s a go button and the alt text description is alt=”go” . It is incorrect to use alt=two quotation marks as a null link unless there is an equivalent text link immediately next to it.
- The next two techniques deal with navigation of Web pages. The Section 508 requirement states that you must provide a method to skip repetitive navigation links. Screen readers read Web pages sequentially. Unfortunately, this means that someone who is listening to the Web page with a screen reader must listen to the navigation link from the top of the page and then all the navigation links down the left side of the page and eventually they’ll get to the main content, which is what they really wanted to hear in the first place. The skip to main technique enables screen reader users to bypass all these navigation links and go straight to the main content of the page. The correct coding for the skip link requires the use of HREF and the anchor tag. Most Web sites take a spacer image and apply the alt text of ALT=skip to main content . This way, when blind users are listening to the Web page, one of the first links they hear is “skip to main content.” When that link is activated, it skips over all of the other links and goes to the content and the anchor that is the main part of the page. It’s important to note that skip-to-main-content links cannot be tested by current Web accessibility checking tools. The only way to know if the skip link works is to listen with a screen reader. You have to verify that you hear the link and that, when the link is activated, it actually skips over and goes to the main content of the page.
- The next technique for Web navigation deals with frames. The Section 508 requirement states that frames must be titled to facilitate frame identification and navigation. As stated on the previous page, screen readers read content sequentially on Web pages, but a framed site provides a great opportunity for screen reader users to jump to the frame they want to hear instead of having to listen to frames that may contain things like navigation or logos. It’s important to provide meaningful titles for each of the frames so they can be used for navigation. Examples of meaningful titles are “name,” “content,” “navigation,” or “logo.” In this case, when screen reader users list the frames, they hear names that are useful so they can select where they want to go without having to listen to the pages sequentially. Each assistive technology uses a slightly different algorithm to identify the frame title. Screen readers use the page title. If that’s not provided, the reader looks at the frame title attribute. If that’s not provided, it looks at the frame name attribute. If that is not provided, the screen reader just says, “Untitled” or “No title.” Accessibility checkers check for the existence of the frame title attributes. They can’t tell if it’s meaningful, but they do verify whether the title attribute has been provided. The correct coding for the frame element uses the title attribute. The syntax is title = and then, in quotation marks, a meaningful title for that frame. Incorrect coding for frame elements has a title attribute that’s missing or a title attribute that’s not useful—for example, title=body center or title=blue . These attributes don’t tell the purpose of that frame, so they can't be used for navigation.
- Web accessibility checking tools can verify the existence of the title attribute, but they can’t verify that it’s meaningful. You have to really listen with assistive technology to verify that the frame titles are meaningful. One way to do that is to use a screen reader. A quick way to use a screen reader to verify frame titles is to bring up the frame and list the appropriate screen reader command. Doing that lists all of the frames on the Web page. You can also move from frame to frame using screen reader commands, but the frame list is a little quicker for testing. The frame list lists all of the frame titles. If a frame has an accessible title such as “logo,” “main content,” or “navigation,” it passes the requirement. If the frame title is inaccessible or you can’t determine the purpose of the frame, the page is considered inaccessible. If the frame title has not been provided at all, the frame list says, “Untitled,” and that is unacceptable.
- Many Web sites include forms, and these forms have to be accessible to someone using a screen reader. The Section 508 requirement states, “Forms shall allow people using assistive technology to access the functionality required for the completion and submission of the form.” Basically this means that someone using a screen reader must be able to tab to all the information in the form and hear all the information that a sighted user sees. The critical part of this is to use the label element to identify the labels for input fields. Most form elements, including text fields, check boxes, and radio buttons, require explicit labels. They must be programmatically associated so that assistive technology clearly understands which label goes with which input field. It is not sufficient to put them close together. Proximity helps a sighted user determine which label goes with the input field, but it doesn’t help assistive technology. All accessibility checkers verify the presence of the label element to determine whether a form is accessible. The correct coding of the text field for accessibility is shown on this page. For example, for a search text input field, the syntax is label for= and then search in quotation marks and the search label itself, followed by the closing of the label. On the input further field it is important to use the ID attribute that matches the “for” attribute in the label element. Web sites that have unsuccessfully tried to implement the label element have a number of problems. Of course, the easiest problem to spot is the missing label element, and all accessibility checkers find this problem. Sometimes someone implement the full attribute on the label element but neglect to use the ID attribute on the input element. Most Web checkers find this problem. too. They also find the next one, where the “for” attribute and ID attribute are there but they are not matched. Some Web sites use the implicit label without the “for” attribute. This is syntactically correct in HTML, but it does cause inconsistent results in different screen readers, so its use is not advocated, and most assisted accessibility checkers flag this as an error.
- Web accessibility checking tools can verify that you have correctly implemented the label and “for” attribute for your form element, but you can also use the assistive technology to listen to the form and verify that the labels are correct. In screen readers this can be done in a variety of ways. First you can use the Where am I? command. You tab to the field that you want to verify, press the appropriate screen reader command, and the screen reader speaks the type of entry, regardless of whether it is labeled. It will also tell you where you are in the form and on the page. This example shows a Search for text entry field. When you use Where Am I? , the screen reader tells you “text entry labeled search for form 1 at 28% of the page.” The key information here is that the screen reader understands the text entry, it is labeled, and the label search for matches the text that is displayed on the screen. You can also use the links list in a screen reader to list all of the form labels. Control reading mode is the fast way to move through a form. In this mode you can use the arrow keys to move to each of the input fields from the form. Screen readers are usually easier for most sighted users to use because you can see and hear the Web site. Screen readers show the graphical view of the page in the top frame of the window. Below that, screen readers display a text representation of the Web page. As the screen reader is speaking, the item being spoken is highlighted in both views. The text view can be saved to provide an excellent test record of the page. Below the text view, the information view is displayed. Information from the screen reader Where am I? command is displayed in this frame. The left frame is the history list view. This view displays a list of Web sites that have been visited.
- Tables can also be a problem area on the Web. The Section 508 requirement states that row and column headers must be defined for data tables. A sighted user scanning through a data table can clearly see the row and column headers. A blind user listening to the table listens sequentially. As blind users tab through the table, they hear the data cell content, but if the table hasn’t been coded correctly, they don’t hear the row or column heading that gives meaning to that data cell. The way to define the row and column header is to use the TH element in HTML. For simple tables, that can be sufficient. The scope attribute can also be used to identify whether it’s a row heading or a column heading. If a table is complex, it’s important to use the headers and the ID attributes. Accessibility checkers don’t do a very good job of identifying whether a table is accessible. Generally speaking, they identify possible violations, but it’s very difficult for them to distinguish between data tables and layout tables. Another technique for making tables accessible is to use the caption element. A caption element associates a title with the table. This is much more helpful than just using the paragraph tags to identify the title of the table. If you use the caption element, the screen reader reads the captions when the screen reader user presses the screen table navigation keys to move through the table. The summary attribute provides additional information about the table and is very helpful but is not required.
- These examples show how to use the TH element and the scope attribute to identify row and column headers in a simple table. This simple table of three columns and five rows can be coded for accessibility only by using the TH element. But the scope attribute adds another level of user ability to the table. The syntax is scope = col or scope = row , depending upon whether it’s a row or column heading. When the screen reader user moves through the table, the screen reader identifies the row and column headings.
- This page shows the correct coding for row and column headers of complex tables using the headers and ID attributes. The TH element must still be used to identify all row and column headers; however, for complex tables with rows or columns that span multiple rows and columns, you must use the ID headers attributes to correctly identify the heading cells .
- Web accessibility checking tools cannot do a thorough job of identifying any data table errors on your Web page. You have to listen to the Web page with an assistive technology to verify that the row and column headers have been coded correctly. Screen readers can read table headers and are very simple to use. If you use table jump reading mode, you can use the left and right arrow keys to quickly navigate all tables on the Web page. Using the appropriate screen reader command, you can also activate table reading mode. In this mode, when you press the arrow keys, the screen reader moves to the next table and reads the caption for that table if the caption has been provided. It can also read the table summary if it’s been provided, and can give you information about the table, such as its size—for example, three rows and five columns. After you find the table you want to test, you can use table navigation reading mode to read the specific contents of the table, using the arrow keys. In table navigation mode, when you use the arrow keys to move through the data table cells, the screen reader reads each new row or column heading. If the TH element has not been used to identify row and column headers, the screen reader reads only the data cell content and not the identifying row and column headers.
- Let’s look at a specific example of using a screen reader to listen to a data table and verify that it’s accessible. If you listen to a table where the headers have not been coded correctly, you can get a variety of results, all of them incorrect based upon the assistive technology that you’re using. In this example, the table shows the enrollment of students at Buffalo Rangers College. The highlighted data cell has the content 523 . The row headings for this cell are Matriculated Students and in state . The column headings are College of Education and Undergraduate . If you are sighted, the meaning of “523” is obvious. However, if you are a blind person listening to this table and the table headers have not been coded correctly, you may hear only “matriculated students, college of education, 523.” You may have missed the information that the students are undergraduate in-state students. Some assistive technology will read only “matriculated students, undergraduate, 523.” The only way you can guarantee that the blind user with a screen reader will hear the same information that a sighted user can see is to correctly code the table with the TH element and the headers and ID attributes. If you listen to the table and the headers have been defined correctly, you hear “matriculated students in state, college of education, undergraduate, 523.” You get all of the visible information in the table.
- We’ve covered some very specific techniques for making your Web pages accessible with regard to using the alt attribute for important images and the null alt text for unimportant images. Regardless of whether the image is important, you must always use the alt attribute. For navigating Web pages, we talked about two cases. First, the skip-to-main-content link can be visible or invisible on the Web page and allows a blind user to skip over all of the navigation links and go to the main content. Second, the navigation technique for framed sites revolves around the use of the title attribute on the framed element to give meaningful names to the frames so they can be used for navigation. We talked about data tables and the importance of using the TH element to identify row and column headers for all tables and, if tables are complex, the requirement can use the header and ID attributes. The scope attribute can be used on tables that are not complex and that clearly identify the row headers and the column headers. We also talked about the use of the caption element and the summary attribute, although those are not required for Section 508 compliance. And lastly we talked about the use of accessible forms and the label element with the “for” attributes. All of these techniques are clearly described in the IBM Web accessibility checklist. Refer to the list for more detail and especially for additional detail about testing with a screen reader.
- This presentation has provided a brief overview of accessibility. It discussed the different types of disability and what people with each type of disability need so that information can be accessible for them. It discussed the accessibility checklists and provided a basic overview of Web coding techniques. There are many more resources for learning more about accessibility. The IBM Accessibility Center Web site provides a comprehensive guide to many resources and references on the topic. The URL is www.ibm.com/able. On this Web site, you can find IBM accessibility checklists with techniques and guidelines referred to in this presentation. This Web site also includes IBM Home Page Reader (a type of screen reader) and test instructions for using Home Page Reader as a testing tool, as well as a free trial download of the software. Another great reference is the guide to Section 508 standards for electronic and information technology. This can be found on the Section 508 Web site at www.access-board.gov/sec508/guide. There are also a number of free, high-quality tutorials available on the subject of Web accessibility This concludes the Introduction to Accessibility lecture. Hopefully, this training session has provided you with a general understanding of accessibility and the importance of providing accessible products, and you are ready to explore more detailed techniques to ensure that you develop accessible products. We encourage you to review additional resources to make your Web sites or products accessible. Many of the resources listed on this page should give you a start on providing accessible products. Thank you for your participation and interest in accessibility.