Web accessibility/Links/WACC301/Announcement2

{{IDevice
 * theme=line
 * type=Tell us a story
 * title=Week 2 Announcements
 * body=''

Week 2 Announcements
These announcements tend to be long (sorry for that), and text heavy, which may give you the urge to skip over them. But, please do read announcements. They’ll often contain important information that is not found elsewhere in the course. If you really don’t like reading, at least skim for the **bolded** words. Or, have ChromeVox read the announcements for you.

Recap of Week 1
The screen reader activities, particularly for those who have not previously used one, should give you a good feel for where the "**pain points**" are on the showcase website.

Many of you pointed out the **lack of instructions** on the Carousel in Activity 2. In each of the widget coding activities that follow, providing instructions is the first item covered in the accessibility updates for a widget. Hopefully that experience with missing instructions will remind you to include them when you’re adding accessibility to a widget

A number of you also pointed out in your navigation improvements, something along the lines of "this would work better if you could navigate this way, or that way" so to speak. One of the things to keep in mind when developing navigation patterns is to **stick to conventions** to start, then add on additional ways to navigate. For most of the widgets we’ll cover, conventional navigation patterns are provided (though in some cases we have not implemented them all).

Many of you being novice screen reader users, experienced some minor difficulties when navigating the site. There should be no “barriers” on the showcase site, though there are a few **usability issues** (e.g. missing instructions). Many of you eventually figured out how to navigate, though you may or may not be accustomed to **conventional navigation patterns**, like arrow keys in a tree menu instead of the Tab key. Not using the Tab key for navigating a tree menu (like the showcase navigation menu), although it may seem unintuitive for those who don’t use a screen reader regularly, it allows an assistive technology user to easily skip past the menu.

For the **experienced screen reader** users among us (i.e. you are blind), your thoughts on navigation conventions, posted to the course forum, may be helpful for others who are just starting out with screen readers and want to understand conventional navigation patterns. What navigation patterns are you accustomed to when using menus and navigation bars, and what issues do you encounter when you come across these elements?

Week 2
-

This week will get a little more hands on, working with code and markup, to add in accessibility.

We’ll distinguish further between static WAI-ARIA, that can be written right into HTML, and dynamic WAI-ARIA, that gets added to HTML through scripting. Even if you are not familiar with JavaScript, there is still a fair amount you can do with static WAI-ARIA to add accessibility elements to web content.

In Activity 4 - WAI-ARIA Landmarks and Alerts you’ll have a chance to apply some static WAI-ARIA to a website to improve navigation, and to provide more usable feedback for assistive technology users.

Then in Unit 4 we’ll get right into coding dynamic WAI-ARIA. First you’ll take a look at the Toggle Button example activity, to help you understand how the remaining activities work. Then you’ll spend the rest of the week working on the Suggestion Box, Tooltip, and [|Progress Bar] widgets to make them accessible.

From this point on in the course, any questions or discussions regarding the widgets you’ll be working on, should be posted to the General forum. Everyone should subscribe to this forum and monitor it for coding related discussions that will help with the activities, and so you’re not asking questions that have already been answered, and it will give you an opportunity to help your fellow participants when you’re able.

'' }}