The Enabling Change Partnership program is supported by the Ontario government, aimed at assisting government and business transition to the accessibility requirements set out by the Accessibility for Ontarians with Disabilities Act (AODA). The Understanding Web Accessibility course development project is one project being supported through the program. This project will be undertaken in parallel with the Enabling Change AChecker Redesign project.
Understanding Web Accessibility will be a freely distributed Web-based course intended to be available when the W3C Web Content Accessibility Guidelines (WCAG) 2.0 becomes a final recommendation, preparing Web developers to effectively respond to the new guidelines. It will be composed of four learning units following the structure described below. Each unit will be bundled into a reusable content package, and released under the Creative Commons Non-Commercial Share Alike (NC-SA) license, which allows free distribution and modification of the course to anyone under the terms of the license.
Units will be assembled in the ATutor Learning Content Management System, from where they can be exported as content packages that can be used in other systems, and from where they can be presented as a course of study, and either taken as self-guided instruction, or as a moderated course for users accessing the course within Ontario.
Units can be imported into other learning management systems, or they can be downloaded and viewed offline in the accompanying viewer.
Course and Unit Structure
The course will begin with an introductory unit that provides context for the four primary units contained in the course. It will describe who the course is intend for, what is and what is not covered in the courses, how one should approach the content to get the most out of it, and a description of what learners should know after completing the course.
Each of the four learning units in Understanding Web Accessibility will take on a structure as follows:
Each of the four units will introduce one of the WCAG 2 principles, with an introduction that outlines the principle, and an overview of the learning unit that describes the reasons why these guidelines need to be followed.
In the second part of the unit, a simulation will demonstrate barriers associated with the principle being studied. Using the first principle as an example, the simulation might include a screen reader reading a Web page, requiring a user to navigate without being able to see the screen (etc.). The simulation is intended to help learners experience what a person with a disability might experience when they encounter Web content that is not accessible to them.
The third section of a module will focus on strategies that can be used to remedy common barriers, with a more technical look at accessibility, then go on to describe WCAG 2 Success Criteria for conforming with particular guidelines, followed by a description of Sufficient and Advisory Techniques used to avoid creating barriers and to improve usability, respectively. Techniques will be drawn from those described in the W3C documentation, and expanded with additional information to help learners internalize what they are studying.
There are four guiding principles in WCAG 2.0 that provide a foundation for learning about Web accessibility. Four learning units will cover one of the four principles each. These Principles as described in WCAG 2.0 are as follows:
- Principle 1: Perceivable -Information and user interface components must be presentable to users in ways they can perceive.
- Principle 2: Operable - User interface components and navigation must be operable
- Principle 3: Understandable - Information and the operation of user interface must be understandable
- Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies
Each Principle has associated with it several guidelines. There are 12 primary guidelines distributed across the four principles. These provide a framework and overall objectives to help authors understand the success criteria for conforming with the guidelines and better implement the techniques.
- Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language
- Guideline 1.2 Time-based Media: Provide alternatives for time-based media
- Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout ) without losing information or structure
- Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background
- Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard
- Guideline 2.2 Enough Time: Provide users enough time to read and use content
- Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures
- Guideline 2.4 Navigable: Provide ways to help users navigate, find content and determine where they are
- Guideline 3.1 Readable: Make text content readable and understandable
- Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways
- Guideline 3.3 Input Assistance: Help users avoid and correct mistakes
- Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies
Reasons for using Accessibility Strategies
Web authors are often unfamiliar with barriers as they might be experienced on the Web by a person with a disability, generally because they've had little exposure to people with disabilities, and even less exposure to persons with disabilities navigating the Web. Having never witnessed a blind person navigating the Web for instance, one might easily ask "Why do I always need alternatives to images in my Web site?" Logically speaking, it seems reasonable to assume that a blind person can not see the images. But, without having witnessed or experienced a blind person navigating their Web site, it might not occur to a Web content developer that the images won't be accessible.
Reasons why a particular accessibility strategy might be used start with a question like the one asked in the previous paragraph. In most cases there are a variety of reasons why using an accessibility strategy is necessary. For example:
"Why do I always need alternatives to images in my Web site?
- A screen reader can not read to its user what is being displayed in an image, so adding an "Alt" attribute to an image that provides a description of what's in the image, gives the screen reader text it can read aloud.
- A person navigating the site with an older browser, or a text based browser, or perhaps using a slow Internet connection and has images turned off, will not see the images, or even be aware they are present. By including an "Alt" attribute with images, the text it contains is displayed in place of the images.
- A search engine cataloging a site will not be able to determine what is contained in images for purposes of making the site, and its images, searchable. By including an "Alt" attribute with an image, search engines can make images searchable.
- When a screen reader reads through HTML, and encounters an image with no "Alt" text, it will read the file name of the image, which may or may not be meaningful. In some cases images contain no usable meaning, such as a decoration or a spacer image. Without "Alt" text the file names are read, potentially interfering with comprehension of the surrounding meaningful information on the page being read aloud. Including an "Alt" attribute in this case is necessary, but the value should be left empty, so the screen reader reads the content of the "Alt" attribute, but outputs nothing, essentially ignoring the image.
Providing reasons for using accessibility strategies helps Web content authors understand the "why" behind using them. However, they still need to remember to use them, and simply reading about strategies is often insufficient to bring the strategies to mind when developing Web content. Experiencing the barriers themselves greatly increases the likelihood authors will remember to apply accessibility strategies when they are needed. For each unit, each representing one of the WCAG 2.0 principles, a simulation of common barriers will help learners experience what it is like to navigate the Web when one is blind, or does not have the use of a mouse, or is using a text based browser, for instance.
Ideas for simulations follow:
Simulation 1: Is Content Perceivable?
These simulations will reproduce the experience of a user who can not perceive certain content, such as a user who is blind encountering an image without a text alternative, or a user with colour blindness asked to complete a task that requires the ability to distinguish colours, as well as other experiences where sensory characteristics of the content are removed. The following ideas represent potential activities to be included in the simulations:
Colour Blindness: A user looks at a screen and is asked a series of 5 simple question and asked to press the green button if the statement is true, or the red button if it is false. In the second question the buttons rotate then stop so the green and red buttons have switched places, so as to remove the ability to predict which button will be the green one. On the third question the colour begins to fade. In the forth question the buttons rotate but end up as identical greyscale buttons, at which point the users will be experiencing what a colour blind person might experience. On the fifth questions the grey buttons will have the words True and False added to them, which mimics the accessibility rule of providing more than colour alone when expressing meaning. In the latter case, users can tell which button to press without having to rely on colour. The followup will explain something to the effect, "You have just experienced how providing additional perceptual characteristics in addition to colour, might be experienced by a person who is colour blind. By adding the words to the grey buttons, they are made accessible to people who are colour blind. Many other strategies might have also been applied, such as making the true button square and the false button round, or the True button always left, and the false button always right, for example.
Hidden Link Text: Another colour blindness simulation might include searching through text for links and reporting how many are present, first with typical underlined coloured text for links, then with the underline removed, and the colour removed from the screen. This could be followed again in greyscale with the underline removed but with links displayed in bold. Users will discover that links become invisible when the underline is removed, and no other feature except colour distinguishes the link text from the surrounding text. The follow up might explain "When the typical underline is removed from links, for aesthetic reasons for instance, it can make links disappear for colour blind users. If the underline is remove, then some other distinguishing feature other than colour needs to be added, such as changing the font type, making links bold, or perhaps adding a background for links.
Screen Reading: A learner looks at a Web site and is asked to perform a number of navigation tasks while the Web site is visible to them. A task might include "Using the site's search tool, search for information on XXXXX, and report the number of results returned." Then the view of the Web site fades until it is no longer visible, but is still present to navigate using the keyboard and audio output, mimicking what a screen reader user might experience. A learner is then asked to "Use your keyboard and its Tab key to find your way to the search tool, listening to the audio output as you navigate, and search for information on XXXXXXX and report the number of results returned. Immediately the learner should experience that time to complete the task increases greatly without the ability to see the screen or use a mouse to navigate. Users will likely experience confusion the first time they are asked to navigate without using sight, so a slider will allow them to bring back the display momentarily to see where the cursors is located on the screen, but they will not be able to navigate and see the screen at the same time. This mimics what a blind person might do when navigating a site, developing a mental image of the layout and following it in their minds eye as they listen to the audio output while navigating.
Text Browsing: This simulation will begin with a visual browser viewing an image intense site, where the learner will be asked to complete a simple task, such as "select the image of the famous scientist to open his profile," selecting the image of Albert Einstein from a selection of five famous people displayed. Then the screen will fade and reappear as it might appear in a text-based browser, such as Lynx. In the second task the Alt text will be missing from the images of each famous person, so there will be no way to tell which one to click when asked to "Select the famous actor to display his profile." The learner is then presented with a button "Add Alt Text Where images Appear," which when clicked adds the names of each famous persons to the Alt attribute for each image. Learners will experience why Alt text is important, and receive an explanation of what they just experienced "Text based browsing is less common today, with the vast majority of users using graphic browsers, but browsing with a text browsers is very much like browsing with a screen reader. When there is no text associated with images, browsing can be difficult, and sometimes impossible. By adding Alt text to images in Web content is made accessible to users using a text based browser, and more importantly to users using screen readers navigating the text in a Web page."
Simulation 2: Is Content Operable?
These simulation will reproduce the experience of a user who can not operate a mouse, for example a blind user, and ask learners to complete a task using only keyboard input, within a specified time period, and with poorly defined interface features.
List of event handlers http://www.w3schools.com/dhtml/dhtml_events.asp
Forms without Labels: To demonstrate how a blind users might understand a form when encountered with a screen reader, a form will be created in a table layout in which the text describing each field (its implicit label) is located in a table cell to the left, and their respective form fields appear in a table cell to the right. In this case users navigating through the form by keyboard, listening the speech output such as that output by a screen reader, will discover that they don't know what should be entered into the form fields because the labels for each input field have not been properly associated. In a second example, with the exact same layout, the HTML Label element will be used to associate explicitly, the labels on the left, with their associated form input field on the right. This time when navigating through the form, it is clear what should be entered into each input field. The followup will explain "In the first example the form fields were only announced as "Text input" because the labels were not properly associated with their respective field. When form labels do not appear immediately next to their respective field, screen readers will often not be able to make the association. In the second task the labels have been explicitly associated with their respective form fields using the HTML Label element, so despite the labels not being immediately next to their form field, a screen reader is able to make the association between label and input field. Many screen readers will attempt to make an association between the input field and the closest text, so in some cases it is possible to create accessible forms without using the Label element to make explicit associations. Good practice however, should be to always use the Label element to associate labels with input field regardless of their proximity to their input fields, so if by chance the screen is resized and the labels move away from their respective input fields, they still remain associated, and the form remains accessible.
Targeting with a Mouse Pointer: To demonstrate another reason why it is important to explicitly label form fields, a series of 3 multiple choice questions will be presented. The first question will be a typical multiple choice question, for which the user clicks a radio button to answer. In the second question, when a user attempts to select a radio button, the cursor will shake and and appear to avoid the radio button, making it difficult to select the appropriate radio button, mimicking what a person with a fine motor disability might experience. In this question the HTML Label element is not used, so the label itself is not clickable. Only the tiny radio button is available as a target. In the last question the Label element is used, so the target area becomes larger, thus easier to click with the shaky mouse pointer. The followup will explain: "The last question was easier to answer because it was possible to click the label for the small form fields that were difficult to target in the second question. In the last question the HTML Label element was used to associate the label with the input field, and as a side effect created a large target area. For a person with a shaky hand, adding a proper label to form field gives them a much larger target area to click on."
Simulation 3: Is Content Understandable?
These simulations will reproduce the experience when Web users encounter content whose meaning is not well defined, changes dynamically, or has input controls that are not labeled in a meaningfully way.
Reading Data Tables: Learners will be presented with a data table and asked to navigate through the table to find a specific piece of data. The table will be setup with years listed across the top row, and countries listed down the first column. A task might ask "Using only your keyboard navigate through the table and find out what were the number of reported case of cancer in Canada in 1996?" (data used in this task to be determined). In the first case the table will be visible as a whole before the task, but when the tasks beings, only the table cell in focus will be visible, hiding away other data cells, and the header row and column cells, requiring the user to either remember what each row or column represents, or require them to navigate by keyboard to the header row or column to make that determination. In the followup task a similar question will ask " Using only your keyboard navigate through the table and find out what were the number of reported case of cancer in the US in 2005?" In the latter task however, the table will be marked up with proper TH elements and the SCOPE attribute, so when using the keyboard to navigate through cells, the corresponding header row and column cells are also visible, thus there is no need to navigate to the header cells to determine what the data in the data cells represent. After the task is completed, a followup explanation will describe why it is important to include properly marked up tables "Without proper row or column headers, some users will only be able to access one cell at a time, and must therefore remember what appeared in the headers labels, and keep track of where the focus is in the data table in order to determine what the data in the cell represents, while in the second example, the header rows have been explicitly associated with data cells, in this case using the HTML TH element with the "scope" attribute that allows these users to access the data cell as well as its header row and header column at the same time, removing the need to remember the headings in the header cells, and removing the need to keep track of where focus is in the data table."
Meaningful Links: Users will be presented with a page of content and asked to find the link that opens a profile for a famous artist, and be timed in how long it takes to find the link when non-meaningful link text is presented (e.g click here) where they have to search through the surrounding text to discover which meaningless link opens the correct profile. In a second task, all the text other than the meaningless links will be hidden, which duplicates what a screen reader users might encounter if they use the common extract links function to navigate through links on a page. Users will discover only trial and error can be used to find the correct link in this case. In the third case, learners will be asked to find open the link to a famous singer, but this time the links in the text will use that actual name of the famous person as link text, making it easy to scan the page as a sighted user to find the link, without the need to read the surrounding text. In the final task the surrounding text will be hidden so only the links using names of famous people will be displayed, duplicating what a screen reader user would encounter if using the list links function in their screen reader. The followup to the activity will explain:
"Notice that as a sighted user it is much more difficult to find links in the first case, when one has to search through the surrounding text to determine which "click here" link is the correct one, and when only the links are displayed, as might be the case for a screen reader user navigating the links on the the page, the only way to find the link is by trail and error. When the links are meaningful, using the person's name as link text instead of "click here," it take a fraction of the time as a sighted person to find the link by scanning the page, and when only the links are displayed, it is quite obvious which link to click. For a screen reader user selecting from a list of links all labeled with a persons name, it is going to be much easier to find the right link than if they are all labeled "click here," This demonstrates the importance of making link text meaningful, so it can stand on its own, describing what one would find, or describe the functionality of the link, without having the search through the surround text."
Simulation 4: Is Content Robust?
These simulations will reproduce the experience when Web users encounter content that is technology specific, or has been created in such a way that certain technologies are unable to understand the content due to non-standard or sloppy markup practices.
Screen size barriers: In this simulation users will be presented with the Web page that has been created using absolute measurements, and presented at a typical 17" monitor size, where they will be asked to find a link to a famous business person, followed by a similar task on a tiny screen the size of a PDA or cell phone screen. Then they will complete the same tasks, but presented in a Web page that has been created using all relative measurements, first on a full screen then on a PDA sized screen. They will notice that in the first and second cases, finding the link on the full size screen is much the same in both cases when viewing content with absolute sizing on a large screen. However, when viewing on a small screen, the second case is much easier because use of relative measures allows the page to resize to fit into the small area of a PDA screen, while the content of the absolutely size pages flows off the screen, and users are required to scroll inorder to find the link.
In a second demonstration, the screen size will remain the same full sized screen. In the first task, with absolute measures used to size components of a Web page, increasing the size of the text in the page causes the information to wrap and fall out of position relative to other features on the page, and makes finding the link more difficult, while on a screen where relative sizing is used, the screen all increases in size at the same rate, so the positioning of the enlarged content remains the same as it was at normal size.
Ways to Avoid Creating Barriers
In virtually all cases multiple strategies can be used to remove barriers, some more useful than others, and some easier to implement than others. This section of a learning unit will present the more useful or more common strategies that can be used in Web content to avoid accessibility problems, with an emphasis on more useful and easy strategies. In many cases the more useful "Sufficient" techniques described in the WCAG documentation will be covered, with some added detail, with additional "Advisory" techniques added where they are useful for improving the usability of Web content. Sufficient techniques are those that can be applied to correct barriers, and to conform with the requirements of a guideline. Advisory techniques are those that go beyond accessibility, often addressing usability issues.
Keeping with the examples so far, Failures in meeting the requirements of guideline 1.1, as well as Sufficient, and Advisory techniques to avoid accessibility problems related to the guideline, will be structured something like the following:
This section of each module will be free form text, where issues or considerations not directly addressed by WCAG 2.0, can be discussed.
For example,with regard to alternative for images.
Resources and Information
This section will include links to additional information regarding the guidelines being discussed, such as references to the guideline itself, links to additional techniques, or to other reference materials. A Resources section for the above example might look like the following:
Each learning unit will include a self-administered quiz that reiterates the content of the unit, and helps learners further internalize what they've learned. Tests will be created using the ATutor Test & Surveys manager, which provides tools for creating tests with various question types, including multiple choice, multiple answer, true or false, matching, and ordering questions (as well as several open ended questions types, which will not be used in this course). Tests will be made up of several question types, and will provide instant feedback when a learner has completed the test. Learners may take the test as many times as they like, until they receive a perfect score. Tests can also be imported and exported as interoperable test packages, and can be combined with content packages, so tests and content can be imported and exported together in any compliant system.