Can a modal dialog be made to work properly for screen-reader users on the web? | Everett Zufelt A while back I started a discussion in the jQuery Accessibility group: Screen-readers and UI modal dialog. I was really happy with the quality of the discussion that my question generated, and thought I'd take a moment to share some of my thoughts and conclusions. I want to be clear that the ideas that I am sharing here were only made possible through the people who were so willing to collaborate with me in this discussion. What is a dialog? A dialog is a little window or box that pops up over-top of the window that you are currently working in and generally asks you a pretty simple question. On the web there are two ways that a dialog can be generated. Note: that using a client-side-scripting language you can invoke some types of browser dialogs. What is the challenge for screen-reader users? Being a screen-reader user I tested several modal dialogs, including the jQuery modal dialog, with several screen-reader / browser combinations. Technologies Results of Testing Firefox 3.6 and JAWS 11
WCAG 2.0 at a Glance WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities Site Navigation W3C Home Web Accessibility Initiative (WAI) Home Discover new resources for people with disabilities, policy makers, managers, and you! Translations WCAG 2 at a Glance This page provides a paraphrased summary of Web Content Accessibility Guidelines (WCAG) 2.0. Please see the following key resources for learning and using WCAG 2.0: Perceivable Provide text alternatives for non-text content. Operable Make all functionality available from a keyboard. Understandable Robust Maximize compatibility with current and future user tools. Print Version This page is formatted for printing (without the navigation) as PDF files for A4 and 8.5" x 11" paper: Document Information Status: Updated 6 December 2011 (preface wording updated 22 February 2012, first published July 2008) Editors: Shawn Lawton Henry and Wayne Dick. Copyright © 2016 W3C ® (MIT, ERCIM, Keio, Beihang) Usage policies apply.
s WCAG 2.0 Checklist You are here: Home > Articles > WCAG > WCAG 2 Checklist Important! The following is NOT the Web Content Accessibility Guidelines (WCAG) 2. It is a checklist that presents our recommendations for implementing accessibility principles and techniques for those seeking WCAG conformance. The language used here significantly simplifies and condenses the official WCAG 2.1 specification and supporting materials to make it easier to implement and verify for web pages. Guidelines for using this checklist: This checklist should not be referenced in policies or in policy adoption. Success criteria added in WCAG 2.1 are marked as such and have a light green background. A PDF version of this checklist is also available Perceivable Web content is made available to the senses - sight, hearing, and/or touch Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content Guideline 1.2 Time-based Media: Provide alternatives for time-based media
Web Content Accessibility Guidelines (WCAG) 2.0 This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Additional information about participation in the Web Content Accessibility Guidelines Working Group (WCAG WG) can be found on the Working Group home page. Other previously active WCAG WG participants and other contributors to WCAG 2.0
WCAG 2.0 Overview WCAG 2.0 is divided into four principles. Each principle is divided into guidelines, and guidelines are divided into success criteria. All success criteria is marked by a certain level of conformance. Four Principles The four principles are the following: It is not essential to remember the principles, their only purpose is to order the many guidelines into a logical order. Guidelines Altogether, there are 12 guidelines under the four principles. Success Criteria This is where things get interesting. Three Levels of Conformance Each success criterion is indicated by a level of conformance, which could be Level A, Level AA and Level AAA. Level A: when you conform with Level A, it means that you eliminate the major accessibility barriers. Level AA: this conformance level ensures a very good level of accessibility. Level AAA: this conformance level is very meticulous, ensures a very high level of accessibility, but it is also very difficult to maintain.
Understanding Conformance | Understanding WCAG 2.0 All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining if content satisfies them. Testing the Success Criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web. Testing and testable in the context refer to functional testing, that is verifying that the content functions as expected, or in this case, that it satisfies the Success Criteria. Although content may satisfy all Success Criteria, the content may not always be usable by people with a wide variety of disabilities. What does conformance mean? Conformance to a standard means that you meet or satisfy the 'requirements' of the standard. Note: This means that if there is no content to which a success criterion applies, the success criterion is satisfied. Most standards only have one level of conformance. Understanding Conformance Requirements Understanding Requirement 1
Mapping Section 508 to WCAG 2.0 Wayne Dick and Tom Jewett This is a summary of a presentation that we gave at the 2009 International Conference on Technology and Persons with Disabilities (CSUN), titled “How to Use W3C Guidelines to Achieve Legally Compliant Web Sites.” Also contained here, but not presented in that talk, is a listing of the suggested WCAG 2.0 techniques for each of the Section 508 paragraphs 1194.22 (a)–(p). Introduction At first glance, the new World-Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0 may seem to be “just more work” for developers who believe that they are “only required” to meet legal standards such as Section 508 of the (United States) Rehabilitation Act. WCAG 2.0 techniques can be used to unambiguously meet every one of the Section 508 guidelines. The mapping strategy We state the need for this criterion: “Non textual information like pictures, graphs or charts cannot be perceived by many users. Suggested techniques Text alternatives Multimedia Color Style sheets
Web Content Accessibility Guidelines 1.0 W3C Recommendation 5-May-1999 This version: (plain text, PostScript, PDF, gzip tar file of HTML, zip archive of HTML) Latest version: Previous version: Editors: Wendy Chisholm, Trace R & D Center, University of Wisconsin -- Madison Gregg Vanderheiden, Trace R & D Center, University of Wisconsin -- Madison Ian Jacobs, W3C Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. Abstract These guidelines explain how to make Web content accessible to people with disabilities. This is a reference document for accessibility principles and design ideas. This document is meant to be stable and therefore does not provide specific information about browser support for different technologies as that information changes rapidly. This document includes an appendix that organizes all of the checkpoints by topic and priority. Status of this document 1. 2. 3. 4. 5. Note.
Designing for Screen Reader Compatibility You are here: Home > Articles > Designing for Screen Reader Compatibility Overview Screen readers are audio interfaces. Screen readers do not read web content quite like human beings do. Two of the most common screen readers are JAWS, by Freedom Scientific, and Window Eyes, by GW Micro. Content Linearization Audio interfaces present content linearly to users, one item at a time. Skimming Through Content Despite the linear nature of audio interfaces, there are some ways in which screen reader users can "skim" through the content. Headings Another way to skim the page to get an overall impression of a page's content is to jump from heading to heading. Implication: Authors should organize content with headings. Landmarks and page sections Users can navigate via ARIA landmarks and HTML5 sectioning elements, such as <main>, <nav>, <header>, etc. Implication: Define appropriate ARIA landmarks and use HTML5 elements appropriately. Paragraphs and page elements "Skip navigation" links Others Important