Web Accessibility

Lay-person’s explanation of the WCAG 2.0 conformance levels along with a brief history of the WCAG 1.0 and 2.0 requirements.

http://www.karlgroves.com/2013/05/20/understanding-wcag-level/

University of Washington’s DO-IT introductory video on web accessibility that discusses how users interact with web resources with adaptive technology. The video in itself serves as a wonderful example of accessibility with prompting and captioning for users with hearing disabilities.

YouTube Link: http://www.youtube.com/watch?v=MO2gpA91fR8&sns=em

WCAG 2.0 at a Glance – http://www.w3.org/WAI/WCAG20/glance/WCAG2-at-a-Glance.pdf

WCAG 2.0 Priority Levels Defined

• Priority Level A
• Priority Level AA
• Priority Level AAA

*Courtesy of the UC EALT

This list ranks the top 10 accessibility issues found in a survey of 8 major UC websites. They are ranked by a “Priority” measurement, which aggregates the impact of an issue on disabled users, the frequency with which it occurs, and the expected difficulty of fixing it. For example, a problem that would be difficult to correct that has a minor effect on visitors would be ranked lower than one that is easier to correct, or has a significant effect.

Because of the nature of automated testing, most of the issues identified have the greatest impact on two major groups:

• Blind and low-vision users, who use a Screen Reading program to read the contents of a web page to them (“Screen Reader users”)
• Users with motor control disabilities, who have difficulty using a mouse or cannot use a mouse at all, and rely on a keyboard or alternative input device (“Keyboard-only users”)

ACCESSIBILITY ISSUES

1. Provide explicit labels for form fields (6 sites) – Without a properly identified label, a screen-reader user may not know what information is being requested, preventing them from using a form. A label also provides a larger area to click, for users with difficulties using a mouse.  For example: Name:  <label for=“name”>Name:</label> <input type=“text” name=“name” id=“name” />
2. Provide alternative text for images (5 sites) – Images often include information crucial for understanding a website, but any information in the image is lost to screen reader users. The Alt tag serves two functions: Convey information not found in text elsewhere on the page, and when used in a functional element such as a link or button, provide text describing the element’s function. Images that don’t need alternative text (those that are merely decorative, or are redundant with other page text) must have a blank (alt=“”) attribute.
3. Ensure headers and cells are properly associated (7 sites)
4. Ensure table headers are used in a valid fashion (7 sites) – Data tables generally include a lot of information in a very small space. While sighted users can look at a table and infer headers from their position or color, a screen reader does not have the same context. If headers are properly marked up as column headers (<th scope=“col”>) or row headers (<th scope=“row”>), a screen reader can read the headers for each cell.  While they will often guess correctly for simple tables,  for complex tables this becomes more difficult.For example, even if this table contained hundreds of commodities and dozens of data about each, a user could determine that $7.76 is the price per bushel of corn:<table summary=“Commodity Prices”>
   <thead>
   <tr><th scope=“col”>Commodity</th><th scope=“col”>Price</th></tr>
   </thead>
   <tbody>
   <tr><th scope=“row”>Corn, US$ per bushel</th><td>7.76</td></tr>
   </tbody>
   </table>
5. Ensure the sole use of device dependent event handlers is avoided (3 sites) – Many commonly available Javascript plugins can only be used with a mouse. If you cannot use a Javascript tool with a keyboard, then both screen reader users and keyboard-only users are likely unable to use it. Any mouse actions should be paired with an equivalent keyboard action – for example, an “onmouseover” action should usually be paired with an “onfocus” action.
6. Ensure the language of a document is set (4 sites) – This tells a screen reader how to pronounce words. If the language is not set on a page, screen readers will assume the language of the user, which would make the text unintelligible to a visitor from another country. Simply start the document with: <html lang=“en”>­­­­­­
7. Ensure frame titles are meaningful (3 sites) – When a document has frames, screen reader users select a frame to read using only the Title attribute to distinguish between the frames. Meaningful titles like “Main Menu” and “Content” allow a user to navigate the page. Example:<iframe src=“/includes/menu.shtml” name=“f_mm” Title=“Main Menu”/>
8. Ensure heading elements are properly ordered (5 sites)
   All documents should use H1, H2, etc. tags to identify sections of a document. This helps ensure that a document is understandable to all users by breaking it into clearly identified chunks, and particularly helps users with cognitive impairments such as dyslexia or short-term memory loss to maintain context. Screen reader users can also use headings to find the relevant portion of a page also can use them, similarly to how a sighted user scans a page. However, if the headings are not organized hierarchically (i.e. if headings skip levels), screen reader users may not know the lower levels exist, decreasing the page’s usefulness.

   Example:
   <h1>Today’s News</h1>
   <h2>Local News</h2>
   <h3>Man Bites Dog!</h3>
   <p>A local man grew tired of a meandering mutt, and …. <p>
   <h4>Dog claims attack was unprovoked</h4>

9. Provide valid, concise, and meaningful alternative text for image buttons (2 sites) – Buttons are labeled with their action – e.g. “Delete” or “Save”.  When images are used for these buttons, screen reader users can’t tell which button to use – which could clearly be disastrous in this example! Add an alt tag with the same text (alt=“Save”) to the button to fix this.
10. Ensure lists for indentation are not used (3 sites) – HTML tags should only be used for their semantic meaning, not for their appearance. In this issue, a list tag (<ul> or <ol>) should be used only to display a list of items in <li> tags. Instead, it may be incorrectly used to indent content. This can cause screen readers to describe the content in a way that is confusing to users. Instead, use CSS styles to indent content. Example: <p style=“margin-left:  2em”>…. </p>

http://staff.washington.edu/tft/tests/menus/

How to Meet WCAG 2.0 Requirements – http://www.w3.org/WAI/WCAG20/quickref/

(3:14:25 PM) Shawn Pullum: http://www.htmldog.com/articles/suckerfish/dropdowns/
(3:25:44 PM) Shawn Pullum: hey
(3:25:45 PM) Shawn Pullum: http://simplyaccessible.com/examples/css-menu/option-3/
(3:25:55 PM) Shawn Pullum: this is another example of the same thing we did if you want to check it
(3:26:09 PM) Shawn Pullum: if this one works, maybe we can adapt its techniques
(3:43:50 PM) roberte@uci.edu/e39e18de: That 2nd technique works like a charm. It doesn’t let the user use arrow-keys but you can tab through all the entries.
(3:46:18 PM) Shawn Pullum: option 2?
(3:46:27 PM) roberte@uci.edu/e39e18de: yes
(3:46:31 PM) Shawn Pullum: http://simplyaccessible.com/examples/css-menu/option-2/
(3:46:39 PM) Shawn Pullum: there are a few of them
(3:46:40 PM) roberte@uci.edu/e39e18de: good explanation: http://learningtheworld.eu/2008/accessible-drop-down-menus/
(3:46:45 PM) Shawn Pullum: oh ko
(3:47:55 PM) Shawn Pullum: check this out
(3:47:56 PM) Shawn Pullum: http://simplyaccessible.com/?s=menu
(3:47:58 PM) roberte@uci.edu/e39e18de: both techniques seem to work
(3:47:59 PM) Shawn Pullum: there are a lot of options
(3:48:11 PM) Shawn Pullum: the focus thing
(3:48:30 PM) Shawn Pullum: how did it work with the new tool
(3:49:23 PM) roberte@uci.edu/e39e18de: Whats the focus thing? I did a search on the page and didn’t find anything
(3:50:11 PM) Shawn Pullum: http://simplyaccessible.com/wordpress/wp-content/themes/simply_accessible/stylesheets/screen.css

http://codex.wordpress.org/Accessibility

Article on how to make your blogs accessible.

http://office.microsoft.com/en-us/access-help/about-accessibility-for-people-with-disabilities-HP005270024.aspx

Microsoft article on the accessibility of MS Access. The UC is considering the use of  “Point-and-Click” software for it’s system wide database. Will need to do some further investigation to validate it’s accessibility to all disabilities.

Content Editor’s Guide – http://www.oit.uci.edu/computing/wcg/cmsCE/index.html

Cascade Developer’s Guide – http://www.oit.uci.edu/computing/wcg/cmsdev/index.html

It includes information and resources like:

• WCG supported services

• Sites@UCI

• Faculty Websites

• iTunes U

• CMS Resources

• Cascade Server

• WordPress

• Drupal

• Writing for the Web

• Code Snippets

• Accessibility

• User Interface/User Experience Help
It is available on our OIT website at: http://www.oit.uci.edu/computing/wcg/index.html

University of Texas Beginning Tutorial of CSS – http://www.utexas.edu/learn/css/

Article verifying the inaccessibility of Google Apps:

http://jebswebs.net/blog/2011/03/nfb-questions-google-apps-accessibility/

Still no improvement to date.

Shawn Foster’s Blog on Google Apps