Disability Discrimination Act Advisory Notes
Ten Common Web Accessibility Failures
Ten Common Web Accessibility Failures
1. Failure to include appropriate text descriptions (such as “alt-text” labels) for images;
2. Failure to provide accessible alternatives when using a visual CAPTCHA;
4. Failure to use HTML features appropriately to indicate content structure such as the hierarchy of headings;
5. Failure to explicitly associate form input controls with their labels;
6. Failure to ensure sufficient difference between foreground (text) colour and background colour;
7. Failure to identify data tables with Summary or Caption, and failure to mark-up data tables correctly;
8. Failure to provide a way for users to disable content such as advertisements from flashing rapidly (rapidly-flashing content may cause seizures in susceptible individuals), and failure to provide a way for users to stop a page from auto-refreshing;
9. Failure to ensure that web pages can be used from the keyboard (that is, without the mouse);
10. Failure to alert the user to changes on a web page that are triggered automatically when selecting items from a dropdown menu.
How to Meet WCAG 2.0
1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
1.2 Time-based Media: Provide alternatives for time-based media.
1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
2.1 Keyboard Accessible: Make all functionality available from a keyboard.
2.2 Enough Time: Provide users enough time to read and use content.
2.3 Seizures: Do not design content in a way that is known to cause seizures.
2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
3.1 Readable: Make text content readable and understandable.
3.2 Predictable: Make Web pages appear and operate in predictable ways.
3.3 Input Assistance: Help users avoid and correct mistakes.
4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
Migrating from WCAG 1.0 to WCAG 2.0
Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
NO MATCHING WCAG 2.0 S.C.
Issue is addressed as part of "Conformance requirements".
Conformance requirement 4: Only accessibility supported technologies are relied on to satisfy the success criteria. AND
Conformance requirement 5: If technologies that are not accessibility supported are used, they do not stop users accessing the rest of the page.
Accessible Rich Internet Applications (WAI-ARIA) 1.0
New technologies often overlook semantics required for accessibility, and new authoring practices often misuse the intended semantics of those technologies. Elements that have one defined meaning in the language are used with a different meaning intended to be understood by the user.
· When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
· Content and functionality that is provided through scripting must be made accessible to assistive technologies.
· Web pages that utilize scripting must be fully navigable using a keyboard.
So what will you find here?
· A list of form guidelines based on current and on-going research into accessibility, usability and web standards.
· Simple examples of accessible forms including: a login form, a search form and a contact form.
· Examples and help on each form element.
· Styling forms with CSS.
· A comprehensive list of external form related articles and resources.