Hi Everyone,

Well, I've done it again! After last week's respite, I've provided a ton of good info with lots of links at the end. I anticipate a lot of chatter this week. As always, please feel free to comment on my replies or on the posts of our peers so we can expand some of these great conversations and contributions.

bg

Week 4: The Basics of Web Accessibility …in 10 easy steps

Creating Accessible Web Content

1. Apply text equivalents for all images
2. Use headings to aid in page navigation
3. Supply a mechanism to skip repetitive links
4. Label form controls explicitly
5. Use appropriate data-table markup
6. Provide accessible multimedia (video and audio clips)
7. Convey information by means other than color alone
8. Ensure device independence (i.e., can operate from keyboard alone)
9.  Write context-independent links
10. Ensure that fonts respond to user settings

1. Text equivalents for all images - the most basic rule of Web accessibility

• While blind users benefit most from alt text, so do sighted people who use the Web with the browser’s images turned off.
• Alt text identifies or provides a brief description of an image
• Alt text should be concise – a short sentence at most.  
• For unimportant or decorative images (eye-candy) and for spacer images, always use null alt : <img alt="">
• When an image requires more description than is appropriate for alt text, provide a longer description use longdesc (long description) or aria-describedby

2. Use headings to aid
in page navigation

• Screen readers can extract the headers on a Web page and place them in a list.  Blind users can then scan this list of headers, which eases navigation.
• Use header levels in proper order, and use them to convey document structure: use <h2> to indicate a subhead of <h1>, <h3> to indicate a subhead of <h2>, etc.  

3. Supply a mechanism to skip repetitive links

• Repetitive links make it difficult for a screen-reader user to navigate pages requiring the reader to wade through the same set of links each time a new page loads. This is, of course, a tiresome task.
• Use ARIA landmark roles to denote specific regions of the page (nav links, search, main content, footer, sidebars, etc.)    
• Use headings to identify important areas of the page (navigation, search, main content, etc.)
• Use a skip link (hidden or visible) to skip repetitive links (this is less desirable than the previous two options)

4. Label form controls explicitly

• Screen readers voice form controls by interpreting explicit form mark-up. When the mark-up isn't there, screen readers try to provide access (with varying results) by guessing at the association between on-screen text and form elements.
• Proper form markup means using HTML’s <label> element and the for, id and title attributes.
• Use ARIA labelledby to associate form elements with labels
  • EXAMPLE:

<form>
<p id="username">Username:</p>
<input aria-labelledby="username" type="text" />
<br/>

<p id="password">Password:</p>
<input aria-labelledby="password" type="text" />
</form>

• Use ARIA describedby to supply additional information about a form element.
  • EXAMPLE:  <label for=“firstname”>First name</label>
<input type=“text” id=“firstname” name=“firstname” … />
• When label can’t be used, use the title attribute on the form control element.
  • EXAMPLE: <input type=“text” name=“dep_month” title=“first name” … />

5. Use appropriate 
data-table markup (not tables used for layout/design)

• If the headings are not clearly indicated, screen readers will guess at X- and Y-axis information (not good)
• Mark-up table headings with <th> element
• Mark-up data cells with <td> element

6. Provide accessible multimedia (video and audio clips)

• We will discuss this in-depth in Week 5
• Captions: deaf and hard-of-hearing users benefit from closed captions added to multimedia
• Descriptions: blind and visually impaired users benefit from audio descriptions added to multimedia

7. Convey information by means other than color alone

• For example, indicate warnings with both a color and text/symbol

8. Ensure device independence (keyboard accessibility)

• All areas of the site should be operable without having to use a mouse
• Make sure [drop-down or roll-over] navigational menus can be opened from the keyboard if not, link the first item to a page containing all sub-links

9. Write context-independent links

• Screen readers can extract the links on a Web page and place them in a list.  Blind users can then scan this list of links. Alternatively, blind users can visit a Web page and simply press the tab key to jump from link to link. In either case, the links are read aloud out of context from surrounding text
• Avoid this: "To read more about this Thing, click here: www.website.com"
• Instead, be specific about the target and use names like this: <a href="http://www.website.com"> Read more about this Thing. </a>

10. Ensure that fonts respond 
to user settings

• Many users benefit from larger font sizes
• Internet Explorer doesn’t resize absolute fonts (e.g., points or pixels).
• FireFox, Opera, NetScape, Safari will resize text regardless of font-size specification
• Specify relative font sizes (e.g., ems, percentages)

What about Flash?

• Many Flash elements can be made accessible.
• Basic tips for developers: Activate  the "make accessible" feature in Flash's accessibility panel, and then specify options such as a name, description, keyboard shortcut and tab-index order.
• Provide alternate text for images and animations.
• Provide labels for buttons and other interactive objects.
• Learn about building accessible components that can be used by screen-reader and keyboard-only users. (CS4 comes with a set of pre-built accessible components.)
• Set wmode to window rather than transparent

Test and Validate your Code!

• Valid code is not necessarily more accessible, but it is not less accessible!
• Test pages using a multiple screen readers on both Windows and Mac, as results may vary
• Test for keyboard-only accessibility with and without a screen reader
• Check your spelling and grammar
• Some tools you can use:
  • NCAM QA Favelet
  • AIS Web Accessibility Toolbar
  • Chris Pederick’s Web Developer Extension

Recommendations and Guidelines

• Section 508:  1194.21  and 1194.22
• WCAG 2.0 Overview
• WCAG 2.0 At A Glance
• Full WCAG 2.0 recommendation

Assignment

* Read: WGBH's Accessible Digital Media Guidelines (especially Guidelines A, C, D, F, G):

* Do: Begin implementing the 10 steps of basic web accessibility in your work and personal websites.

* Discuss: Everything!