Web accessibility/Links/WACC101/Announcement4

Week 4: The Understandable and Robust Principles

Announcement 4

Week 3 Recap

Last week, our focus was on making functional elements on the Web accessible. Most of the time, this means ensuring that all interactivity operates with both keyboard and mouse. As you recall, it is important to provide text alternatives for visuals in order to make them perceivable. Just as important — if not more so — is making functional elements operable with a keyboard. There are lots of people who rely on a keyboard to navigate, and they may be unable to use a mouse effectively.

Operable also means providing enough time. Some people with disabilities take longer to complete tasks than others. When time limits are set, they can be disadvantaged. Preventing seizures also falls into the operable category of guidelines. Needless to say, if flashing content triggers a seizure, these persons are going to have trouble operating anything. Providing multiple ways to navigate is also important to making web content operable. Some people may not be able to scan a page for the content they need, and they may be forced to navigate through the sequence of content before reaching what they are looking for. Providing bypass links, landmarks, and good use of headings can make web content more operable for many.

Mobile devices present a new challenge for navigation. Being able to quickly tap, double tap, pinch, or split tap (among other gestures) can be problematic for some people. Fortunately, if keyboard accessibility has been addressed, it can often be a fallback to gesture-based input. So, when gesture input is specifically defined in the programming (similar to mouse-specific operations), keyboard access also needs to be provided.

In last week's activity, you compared three accessibility checkers. The aim of the activity is to raise your awareness of their limitations and the differences between the results each checker generates. It is unlikely that automated checkers will be able to identify all accessibility issues anytime soon. This should always be in mind when using these tools to identify problems and making recommendations for fixing accessibility problems. They are just one tool to be used within a collection of other tools, along with manual, human review.

Week 4 (Final Week)

This week we'll be looking at Principle 3 and Principle 4:

• __Principle 3: Web content must be understandable__. Principle 3 is something non-developers should be able to relate to. The main issues this principle addresses is content readability, consistency in presentation and navigation, and preventing and recovering from errors.
• __Principle 4: Web content must be robust__ (that is, compatible with a range of technology). Principle 4, on the other hand, is aimed primarily at web developers. Specifically, it identifies what they need to do to ensure web content is usable across a range of scenarios and devices and ensures that web content continues to be usable into the future as technology evolves. This often means building content to standard (e.g., using valid HTML), and, when non-standard features or strategies are used, there's a standard version to fall back on. We won't go into too much detail on Principle 4, which is covered more thoroughly in the developer course in this course series. But, for non-developers, it is still good to be aware of what developers should be doing, even if code is "Greek" to you.

Week 4: Final Tasks

__This week's tasks:__

• 1. Read through the pages that describe Guidelines 3.1 to 3.3. Again pay attention to whether failing to address issues at each level creates absolute barriers, usability problems, or more of a nuisance.
  2. Complete the Unit 5 Activity: Writing for the Web. This activity will give you a chance to experiment with reading level test tools. For most content available to a public audience, aim to have the reading level in the "lower level high school" range (grade 8 or 9). Be sure to capture all the meaning in the original message, in your rewritten, lower level high school version of the paragraph for full marks,
  3. Read through the pages that describe Guideline 4.1. As well as the introduction to WAI-ARIA found in Unit 6.
  4. Complete the Unit 6 Activity: HTML Markup Validation. Though it generally takes someone knowledgeable in writing HTML to correct HTML markup errors, anyone can run a markup validator to see the quality of the code behind a website. It is not uncommon for assistive technology to have problems when invalid or broken markup is encountered.