Difference between revisions of "Web accessibility/WACC101/announcements"

Welcome to Introduction to Web Accessibility

We are very happy to offer this course — the first in The Chang School series on Web Accessibility. And, we're happy that so many peoplefrom all over the world have signed up to learn about this important topic.

Over the next four weeks, we will help you build a practical understanding of what web accessibility is all about. We will be using the W3C Web Content Accessibility Guidelines (WCAG 2.1) as the framework for that understanding. WCAG has become the de facto standard for web accessibility, upon which many laws and regulations around the world are based. Here, in Ontario, Canada, for instance, the Information and Communication Standard of the Accessibility for Ontarians with Disabilities Act (AODA), is based on WCAG almost word for word. You will likely find that rules and regulations in your part of the world are also based on WCAG.

But, for the average person WCAG can be difficult to comprehend. This course will help you build a practical understanding of WCAG and potential barriers on the Web, through a wide range of practical exercises that will give you first-hand experience with web accessibility.

This week, the focus is on getting you setup to take this course and providing some background on WCAG and its many parts, before getting into the details of the individual guidelines next week.

There is a lot to do this week. In fact, this week will be the busiest of the four weeks of this course.

This week's tasks:

• Get started by reading over the Course Home page and the Course Start page. Here, you will learn about the requirements for the course and what needs to be done.
• Once you have familiarize yourself with the requirements, introduce yourself in the Introductions Discussion Forum, and read through others posts to see who your classmates are. Respond to a few other posts, if you are inclined.
• Complete Unit 1 - Why Learn About Web Accessibility
• Complete the Unit 1 Activity - Experiencing Barriers
• Complete Unit 2 - WCAG
• Complete Unit 2 Activity - WCAG Scavenger Hunt

Week 2 Announcements

Week 1 Recap

One of my favourite aspects of this course, and the others in the series, is going through the responses from people on the screen reader activity. For those who have not used a screen reader before, it can be an "eye-opening" experience — no pun intended. The experience can often change how people think about accessibility, making it a permanent part of how they look at the Web, and how they look at the creation of web or other digital content. You can try this activity yourself on others, if you want to help another person to understand what accessibility means in practical terms.

The goal of the screen reader activity is to create awareness and empathy for what people with vision impairments can go through when they navigate the Web. Granted, many of you are novice screen reader users, and lack of experience using a tool like ChromeVox will contribute part of the frustration associated with the experience. Even expert screen reader users will experience frustration when they encounter websites like Lulu's Lollipops. Likewise, they can be pleasantly surprised when they encounter a website like the Showcase site. If you took your time navigating the Showcase site, you would have noticed a variety of accessibility enhancements that add to the overall usability of the site.

You'll have more opportunities to practice with ChromeVox as the course goes on.

The WCAG Scavenger Hunt is intended to give you an overview of the various pieces of WCAG, so when you need to find answers to accessibility questions, you know where to look for them. If web accessibility is part of a career move for you, it would be a good idea to spend some time going through guidelines, success criteria, and techniques. Not necessarily to memorize them or to recall specific guidelines or techniques and so on, but rather to be able to recognize, based on a particular accessibility challenge, where to look for solutions.

• • Key Point**: Be sure to subscribe to forums so you are not missing replies to your posts, particularly when the instructors are providing feedback that may affect your mark on the activities. If you are not subscribed, be sure to scan through the forums regularly. Choose the "Watching" option to subscribe to the forums, located at the bottom of the message thread.

Week 2

This week we get into the details of WCAG, starting with the guidelines and success criteria for __Principle 1: Web content must be perceivable__. Sight and sound are the primary ways we perceive web content. There are many, however, that won't be able to use sight, sound, or both, when they navigate web content. Alternatives need to be provided whenever sight or sound are needed for comprehension. In most cases, this means providing text alternatives, such as alt text for images or captions for audio and video content. As you will learn, text is special when it comes to web accessibility.

This week's tasks:

• 1. Read through the pages that describe Guidelines 1.1 to 1.4. While doing so pay particular attention to the nature of guidelines or, rather, success criteria at the different levels. Note whether failing to address issues at each level creates absolute barriers, usability problems, or more of a nuisance. This will help you remember, and prioritize issues.
  2. __Attempt the "Try This" mini activities__ scattered throughout the unit (in purple boxes) and continue to build your practical understanding of web accessibility.
  3. Complete Unit 3 Activity - Creating Closed Captions. This activity will introduce you to the process of creating captions and transcripts for video. If this is your first time, you'll likely find it cumbersome in the beginning, but with just a little practice, you can generate captions for a couple minutes of video, in 10 to 15 minutes, or less.

Week 3 Announcements

Week 2 Recap

Last week the focus was on Principle 1: Web content must be perceivable. Much of the time, that means providing text wherever meaningful visual or auditory content is presented.

The activity in this unit introduced you to Amara, a free tool for creating closed captions, or rather, subtitles. Captions and subtitles are essentially the same thing. Subtitles make foreign languages accessible to people who don't speak the language, much like captions make audio content in video accessible for those who cannot hear it.

Week 3

This week, we get into the details of __Principle 2: Web content must be operable__. This essentially means that anything in web content that functions with a mouse must also function with a keyboard, and vice versa. There will be many people who cannot use a mouse, which requires sight to be able to follow the mouse pointer. Instead, people will use a keyboard and, generally, the Tab and arrow keys to navigate through functional elements and the content on a website.

It goes without saying that all functional elements need to work with a mouse, as that is how most of us interact with web content. But, there will also be people who rely on a mouse while using technology such as a head mouse and switches to operate a computer, along with an onscreen keyboard.

__This week's tasks:__

• 1. Read through the pages that describe Guidelines 2.1 to 2.5. Again, pay attention to whether failing to address issues at each level creates absolute barriers or usability problems or is more of a nuisance.
  2. Guideline 2.1 Level A has an interesting "Try This" activity, which will give you practical understanding of the challenge that drag-and-drop features can have for screen reader users. It is still a rarity to find drag-and-drop elements on the Web that work with a screen reader. (There's also a keyboard trap on this page you can experience. It requires Flash.)
  3. Complete Unit 4 Activity - Understanding the Limitations of Automated Accessibility Checkers. Though automated accessibility checkers are an easy way to scan a website for barriers, it is important to understand their limitations. They are particularly lacking when it comes to assessing meaning, like whether alt text effectively describes the image it is associated with. For the time being, humans have to make these types of decisions.

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.