Content Recap
The material here focuses on describing the accessibility requirements of the W3C Web Content Accessibility Guidelines, also known as WCAG 2.1. This latest version of the guidelines was released in late 2018, building on WCAG 2.0. It adds guidelines and success criteria for accessibility as it relates to mobile devices, and includes additional success criteria for making web content accessible to people with cognitive disabilities.
Unit 1: Why Learn About Web Accessibility
Before getting into the details of WCAG, this first unit provides background on why these guidelines are needed. You are introduced to the idea of “curb cuts,” which are representative of accommodations for people with disabilities that have come to improve access and usability for more than just those with disabilities. Business cases are also introduced, showcasing why addressing accessibility is good for businesses in a variety of ways. For those in Ontario and for those who want to know about how Ontario is addressing accessibility for people with disabilities, the Accessibility for Ontarians with Disabilities Act (AODA) is introduced, as well as accessibility laws emerging around the world. Many of these base their web accessibility requirements on WCAG. To round off the unit, you are introduced to disabilities and the types of barriers different groups encounter. In addition, you learn how to use a screen reader, the primary technology used by people who are blind to access computers and the Web.
Unit 2: WCAG
This unit introduces the parts of WCAG. The four guiding principles state that web content must be: perceivable, operable, understandable, and robust. Next, Levels of Accessibility help prioritize potential accessibility issues based on their impact on people with disabilities, with Level A being the most important. WCAG consists of Guidelines and Success Criteria, which describe the general requirements to meet those guidelines. Each success criterion is accompanied by Sufficient and Advisory Techniques, which are technology-specific strategies that can be used to remove barriers or improve accessibility. The idea of compliance is introduced, along with what is needed in order to claim compliance. You also learn why the WCAG 2.1 update is needed and how WCAG is related to AODA and other accessibility laws around the world.
Unit 3: Perceivable
The perceivable principle and its associated guidelines and success criteria are covered in detail in this unit, which looks at each success criterion from a practical perspective. In general, content needs to be presented in a way that can be perceived through multiple senses, so if a person is missing a sense (e.g., sight), they are able to access content through other senses (e.g., hearing and touch). Since people who are blind tend to face the most barriers in web content, a significant focus is placed on providing alternatives for visual content, like images and multimedia.
This principle also introduces the idea of adaptable content. This is content which can be accessed in different ways, not only through multiple senses but also through a variety of devices and assistive technologies, using different learning strategies or styles.
Being able to perceive content also means being able to distinguish that content from the background in which it appears. In the case of colour, foreground text needs to provide sufficient contrast with its background in order to be readable by those with low vision. Additionally, when colour is used to represent meaning, that meaning must be communicated through some means other than colour. In the case of audio, spoken dialogue in multimedia needs to be sufficiently loud enough to be distinguishable from background noise.
Finally, in this unit, you have an opportunity to use captioning tools, like Amara or YouTube, to create captions and a transcript for a short video.
Unit 4: Operable
Next to providing alternatives for visual and audio content, it is critical that content, such as forms, links, interactive applications, and widgets, be operable with both keyboard and mouse. Since people who are blind typically cannot see a mouse cursor on the screen, they will generally rely on a keyboard to navigate. Many others rely on a keyboard to access content. Developers, often mouse users themselves, may not be aware how critical keyboard accessibility is.
This unit also introduces you to keyboard traps, which create problems for those who rely on a keyboard to access content. These traps are created when navigating into an object, like a Flash-based activity or an embedded content editor, then getting stuck there. A trap may prevent access to any content that follows it.
Timing is also a potential barrier. People with disabilities often take longer to complete tasks, so when timing is used, there needs to be ways to either extend time or to disable it.
Flashing content is discussed, along with its potential to initiate seizures and other physical reactions in people with various photosensitive disorders. Moving content can cause physical reactions similar to motion sickness for people with vestibular disorders. Web content developers should avoid content that flashes between 3 and 50 flashes per second. And, where there is content that moves, developers should provide a way to disable movement.
Part of being operable is the ability to navigate through web content effectively. This involves providing consistent, logically arranged, and conventional navigation features throughout a website or application, so users only need to learn to navigate once. Then they can use their past experience with that web content to help make sense of navigation elements across websites. Navigable also means being able to move through pages of content in efficient ways, perhaps by using bypass links, WAI-ARIA landmarks, and properly nested headings. When these elements are missing, navigating through complex content can be unnecessarily time-consuming for people who rely on a keyboard.
With the introduction of smart mobile devices in 2007 with the first iPhone, a new set of potential barriers was created. The first smartphones typically relied on the ability to complete various gestures, like tapping, pinch zooming, and swiping, among other means of navigating and operating smaller screens. For those with various types of mobility disabilities, gestures can be difficult and sometimes impossible. WCAG 2.1 introduced one new guideline and a series of related success criteria to provide guidance on developing for mobile devices in a way that does not create barriers.
Finally, the activity in this unit introduced you to automated accessibility checkers. While these checkers are a good first pass to identify potential barriers, they cannot be relied upon to identify all potential accessibility problems. When evaluating accessibility, it is important to include a variety of test strategies, including automated checkers, manual tests, and human decision making.
Unit 5: Understandable
One of the primary requirements under the understandable principle is that content should be readable. Readable can mean different things. First, the language of a page of web content needs to be defined. This is done in the opening HTML of a web page by defining the language in a lang attribute, using a standard language code as its value (e.g., lang=”en”). Typically, assistive technologies will default to pronouncing content with English pronunciation if no language has been defined. It is particularly important to define languages when other languages are used, so the appropriate pronunciation is used by the assistive technology. Otherwise, languages such as French, German, or Chinese will sound strange (at best) or not be understandable at all (at worst). The same is true for changes in the language of content, for example, having French phrases in an otherwise English document. Those phrases in French need their language defined, so assistive technologies will switch from English to French, reading the French text with French pronunciation, then continue to read in English.
Abbreviations and acronyms can also be problematic, not only for those using assistive technologies (which often try to pronounce short forms) but also for readers who may not be familiar with a short form. Providing the full text of an abbreviation or acronym will be helpful for many people and may be necessary for those using assistive technologies to comprehend it.
Reading level is also discussed in this unit. Typically, the content of a web page should be written at a level appropriate for the audience. However, when the audience is the general public, it should be written to be understandable by a 15-year-old (i.e., lower-level high school student). You were introduced to a number of tools that can be used to measure the reading level of text, including strategies that can be used to reduce reading level, like reducing the length of sentences, using more common words, and writing in the active voice.
An important element for comprehension is predictability. This is related in part to convention, discussed under the operability principle. Many features on the Web function the same way, no matter where you might access them. An HTML Select box, for example, functions the same way regardless of the website it appears on or the browser/device used to display it. When developers create custom elements that function differently than what one might predict, confusion can often set in.
Changes in context may also upset predictability. These changes often occur when web content changes without the user explicitly requesting the change. For example, a splash page may redirect to a new location after 15 seconds, or a form element may load a new page when it receives focus. These are both examples of unrequested changes in context. These kinds of changes can be quite disorienting for some assistive technology users, who may become lost or confused as a result.
Another important part of understanding is being able to recover from an error and knowing that a process or series of steps has completed successfully, without errors. Providing accessible messaging is important for many people. Preventing errors before they happen, typically with warning messages, can greatly reduce the effects of errors, not only for people with disabilities but for everyone. Feedback after completing an action, such as submitting a form, is a necessary element for people using assistive technologies, who may spend a significant amount of time confirming that a form they submitted was successful. And, for anyone else, reading a simple “The form was submitted successfully” is a more efficient way of confirming that than having to go through the content that was submitted to make that confirmation.
Unit 6: Robust
This final unit is most useful for developers and programmers, though, for non-developers who are studying web accessibility, it is important to be aware of some of the technical aspects of implementing web accessibility. The aim of this principle and its associated guidelines is to ensure that web content works with as broad a range of technologies as possible and will continue to work into the future as associated web technologies evolve. This typically means using web technologies, like HTML, to standard. When there are non-standard uses, a standard fallback should be provided.
Developers will want to use a markup validator to ensure that the HTML of the web pages they create is valid HTML. When web content contains broken or invalid HTML, assistive technologies may behave inconsistently and even be unable to access the content contained in the broken markup. Though current web browsers are pretty good at fixing broken markup on the fly, they cannot be relied upon to correct all markup errors.
You were introduced to the importance of effective messaging with the discussion on error feedback, and in this unit you are introduced to WAI-ARIA’s version of effective feedback. WAI-ARIA alert, status, and log roles can be used to automatically announce feedback messages injected into already rendered web content without reloading the page.
To wrap up we discuss WAI-ARIA. It can be used to make custom web content accessible, using a combination of static and dynamically generated WAI-ARIA. WAI-ARIA elements, like landmarks, can be added directly to HTML, while much of it requires JavaScript to control states, and sometimes properties, as various interactions within the custom content occurs.
