Smarter Accessibility Technical Standards Phill Jenkins IBM Research Human Ability & Accessibility Center April 201

1. Smarter Accessibility Technical Standards Phill JenkinsIBM ResearchHuman Ability & Accessibility CenterApril 2011

2. About the U.S. Access Board 25 board members: 13 Public members appointed by the President to four year terms 12 Federal members: Justice GSA Interior Labor Defense Transportation Education Housing and Urban Development Post Office (USPS) Commerce Health and Human Services Veterans’ Affairs Independent Federal Agency $7.3 million budget 28 employees Rule making in progress Emergency Transportable Housing Passenger Vessels Transportation Vehicles Outdoor Developed Areas Shared Use Paths Public Rights of Way Classroom Acoustics Medical Diagnostic Equipment Information & Communications Technologies (ICT) Self-Service Transaction Machines

3. Guidelines and standards development ABA: Architectural Barriers Act of 1968 ADA: Americans with Disabilities Act of 1990 Telecommunications Act of 1996 (Section 255) Rehabilitation Act Amendments of 1998 (Section 508) Patient Protection and Affordable Care Act of 2010 Technical assistance and training Research Compliance and enforcement U.S. Access Board programs

4. Joint update of: Section 508 standards for electronic and information technology (procured by Federal agencies) Section 255 guidelines for telecommunications Advisory Committee (TEITAC) report April 3, 2008 Advance notice of proposed rulemaking (ANPRM) March 22, 2010 Next step – proposed rules (NPRM) ICT Accessibility Standards & Guidelines

5. Adobe Systems, Inc. American Association of People with Disabilities American Council of the Blind (ACB) American Foundation for the Blind (AFB) AOL LLC Apple, Inc. Association of Assistive Technology Act Programs Assistive Technology Industry Association (ATIA) AT&T Avaya, Inc. Canon USA, Inc. Communication Service for the Deaf CTIA - The Wireless Association Dell, Inc. Easter Seals European Commission Hearing Loss Association of America Human Rights and Equal Opportunity Commission (Australia) IBM Inclusive Technologies Industry Canada Information Technology Association of America Information Technology Industry Council Japanese Standards Association Microsoft Corporation National Association of State Chief Information Officers National Center on Disability and Access to Education National Federation of the Blind (NFB) National Network of Disability and Business Technical Assistance Centers Panasonic Corporation of North America Paralyzed Veterans of America SRA International, Inc. Sun Microsystems, Inc. Telecommunications Industry Association The Paciello Group, LLP Trace Research and Development Center Usability Professionals’ Association U.S. Department of Homeland Security U.S. Social Security Administration WGBH National Center for Accessible Media World Wide Web Consortium (W3C) – Web Accessibility Initiative (WAI) ICT Advisory Committee (TEITAC)

6. Self-Service Transaction Machines • In November 2010, the Board decided to separate the rulemaking on ADA self-service transaction machines from the rulemaking on ICT (508/255) • Departments of Transportation (DOT) and Justice (DOJ) are undertaking related rulemakings that present an opportunity to work collaboratively to develop a single set of technical requirements that would be referenced and scoped by each agency • Next step – proposed rule

7. Collaboration with other agencies Participating on technical committees: Election Assistance Commission (EAC.gov) • Board of Advisors • Technical Guidelines Development Committee (TGDC) Consulting on Rulemakings: • Section 255 (FCC); • Medical Diagnostic Equipment (FDA); • Outdoor Trails (Federal land management agencies); • Section 508 (GSA, DOJ) Research: National Institute on Disability and Rehabilitation Research(NIDRR) (Department of Education)

8. Technical accessibility standards

9. Proposed ICT standards & guidelines

10. WCAG 2.0 Standard • 12 Guidelines/4 Principles • 61 Success Criteria • 25 Level A • 13 Level AA • 23 Level AAA How to Meet Interactive – gives views by priority and technology • Understanding WCAG 2.0 • Rationale and Benefits • Examples • Sufficient Techniques WCAG 1.0 (May 1999) vs WCAG 2.0 ( Dec 2008) • WCAG 1.0 Standard • 18 Checkpoints • Rationale • Techniques • Test Procedures • Examples • How To Test References: WCAG 1.0 Techniques • WCAG 2.0 Techniques • General (G1-G199) • HTML (H2-H91) • CSS (C6-C63) • SCRIPT (SCR1-37) • SERVER (SVR1-4) • SMIL (SM1-14) • TEXT (T1-T3) • ARIA (ARIA1-4) • Common Failures (F1-F89) 508 Techniques IBM Techniques

11. Understanding Level A - 25 requirements Notes: Links are active. The link takes you to the source reference documentation at the W3C Web Accessibility Initiative web site. 1.2 Time-based Media Recommendation to watch the FCC rulemaking process on the U.S. 21st Century Communications and Video Accessibility Act of 2010

12. Evolution of WCAG 1.0 to WCAG 2.0 • WCAG 1.0 • WCAG 1.0 was published in May 1999. • Can you remember what the “Information Superhighway” looked like 12 years ago? • Accessibility checkpoints were: P1 (must satisfy), P2 (should satisfy) and P3 (may satisfy). • These priority levels cumulatively map to WCAG 1.0 conformance levels of A, AA and AAA. • Focus on static HTML conformance and enabling support with the early assistive technology: • Images for content and navigation (alt text), scripts, forms, Skip to Main Content, Frames, Table Headers, Cascading Style Sheets, Colour & Contrast, Blinking, Moving or Flickering Content, Timed Responses, Text-Only Page, Descriptive Hypertext Links, Correct Markup to Convey Presentation & Structure • Technology in May 1999: • Dialup Internet for home was common • Windows 98 • Internet Explorer 5, Netscape 4.5 • JAWS 3 screen reader – issues with poor JavaScript support • No smart phones • Assistive technology was a niche field and very expensive.

13. Evolution of WCAG 1.0 to WCAG 2.0 WCAG 2.0 Many of the P1 & P2 checkpoints are incorporated into WCAG 2.0 Level A Success Criteria. That is, the base of WCAG 2.0 (A) is significantly more comprehensive and capable in terms of enabling access to the web than WCAG 1.0 P1 was. WCAG 2.0 was published in December 2008: • 25 Level A success criteria • 13 Level AA success criteria • 23 Level AAA success criteria. • Note: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content. • More about the success criteria on the next pages … Technology in 2008: • pervasive high speed internet access, multiple channels & devices • Content includes video (e.g. YouTube), audio • Growth of collaboration spaces – blogs, SharePoint, instant messaging • Windows XP and Vista, Linux on the desktop • Rich internet experience – Flash, Silverlight and other rich Internet media formats. • Internet Explorer 7, Firefox 3, Chrome, Opera, Safari • Smart phones – RIM, Apple, etc. Beginning the explosive growth phase of smart phones like Blackberry and iPhone, Android and now the Windows phones. • 13 months before the introduction of the iPad – tablets were a tiny niche in 2008

14. Differences between Level A and AA – testable success criteria • Success Criteria • For each guideline, testable success criteria are provided to allow WCAG 2.0 to be used where requirements and conformance testing are necessary such as in design specification, web application development, product purchasing, regulation, and contractual agreements. • The following conditions must be met for a Success Criterion to be included at all: • All Success Criteria must be important access issues for people with disabilities that address problems beyond the usability problems that might be faced by all users. In other words, the access issue must cause a proportionately greater problem for people with disabilities than it causes people without disabilities in order to be considered an accessibility issue (and covered under these accessibility guidelines). • All Success Criteria must also be testable. This is important since otherwise it would not be possible to determine whether a page met or failed to meet the Success Criteria. The Success Criteria can be tested by a combination of machine and human evaluation as long as it is possible to determine whether a Success Criterion has been satisfied with a high level of confidence.

15. Differences between Level A and AA • Levels • In order to meet the needs of different groups of persons with disabilities and different situations, three levels of conformance are defined: A (lowest), AA, and AAA (highest). • Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. • Some of the common factors evaluated when setting the level included: • whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can't make content accessible) or whether there are no workarounds if the Success Criteria is not met (Level A). • whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology) • whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the Success Criteria could be acquired in a week's training or less) • whether the Success Criterion would impose limits on the "look & feel" and/or function of the Web page. (limits on function, presentation, freedom of expression, design or aesthetic that the Success Criteria might place on authors) • whether the need could more efficiently be met by the browser (not the content). See Agent Accessibility Guidelines (UAAG)

16. Differences between Level A and AA continued • Accessibility Supported • Many of the Success Criteria deal with providing accessibility • through assistive technologies (AT) or • special accessibility features in mainstream browsers, or both • Success Criteria require that something be done in Web content that would allow assistive technologies to successfully present the content's information to the user: • For example, a 'show captions' option in a media player. • For example, a picture that you were supposed to click on to go to a topic would not be accessible to a person who was blind unless a text alternative for the picture were provided in a way that browsers including AT can find and present it to the user. The key here is that the text alternative must be included in a way that browsers including AT can understand and use – in a way that is "Accessibility Supported.“ • For example, custom controls or widgets (carousel, some pop-ups, etc.), included on a Web page. In this case, a standard browser may not ordinarily be able to present an alternative to the user. If, however, information about the custom control including its name, role, value, how to set it etc. are provided in a way that assistive technologies can understand and control them, then users with supporting assistive technologies will be able to use them. • When new technologies are introduced, two things must happen: • First, the new technologies must be designed in a way that browsers including assistive technologies could access all the information they need to present the content to the user. • Secondly, the browsers and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies. "Accessibility Supported" means that both of these have been done and that the technology will work with browsers and assistive technologies.

17. Differences between Level A and AA continued • Assistive Technology support needed for "Accessibility Supported“ new Web technologies This topic raises the question of how many or which assistive technologies (AT) must support a Web technology in order for that Web technology to be considered "accessibility supported". WCAG 2.0 does not specify which or how many AT must support a Web technology in order for it to be classified as “accessibility supported”. This is a complex topic and one that varies both by environment, by language, and changes over time. There is a continued need for an international dialogue on this topic: • “Accessibility supported” varies by environment • Inside an enterprise where all employees are provided with particular user agents and assistive technologies, Web technologies may need to only be supported by those user agents and those assistive technologies. • Content posted to the public Web may need to work with a broader range of user agents and AT. • “Accessibility supported” varies by language (and dialect) • There are different levels of assistive technologies support in different languages and even countries. • Some environments or countries may provide free, but not fully supporting assistive technologies. • New technologies won't be supported in older assistive technologies • Clearly, a new web technology cannot be supported by all past assistive technologies, so requiring that a technology be supported by all assistive technologies is not possible. • Users will need to update, upgrade, re-configure, and be trained to use new assistive technology support • Support for a single older assistive technology (for a given disability) is usually not sufficient • Newer Assistive Technologies may not be affordable by the general public • When capabilities of free or low cost AT are improved, then much of the burden is removed from the Web content owner / developer. • The difficult “costs tradeoff equation” between many web sites owners and the fewer ATs needs to be addressed.

18. Questions to ask when setting policy regarding Level AA • When should Level AA requirements become part of a policy, regulation, procurement, design specifications, or contractual agreements? This question raises many possible considerations and factors that need to be take into account for each Success Criteria. Some notes to help in understanding and exploring this topic are: • Should each Level AA “Success Criteria” be evaluated individually? • Yes - It is not necessarily “all” or “none”; and can (should?) change over time. • Costs tradeoffs between all web sites owners meeting the requirement vs working with the smaller community of browser and AT developers to meet the requirement? • Should each Level AA “Success Criteria” apply differently – depending on: • Type of Jurisdiction: public web sites, private, company, university, business, news, gaming, etc. • Type of Content: e-commerce (retail), training (education), job application, informational video, entertainment, etc. • Type of Hardware Platform: Desktop browser, Mobile Phone browser, Tablet browser, etc. • Could the Level AA “Success Criteria” be easily enforced in authoring and developer tools? • Are there content creation & development tools that support W3C Authoring Tool Accessibility Guidelines (ATAG)? • What is the support (or lack of) by each specific criteria? For example, video descriptions 1.2.5 ? • Other factors: • Subjective human evaluation required? “Testable” does not mean only “machine testable”. • Changes and progress since 2008? Are more accessibility features built into browsers and platforms? (yes) • How does (or doesn’t) making the Level AA a policy requirement drive innovation up and costs down? • Limits on the “Look & Feel” ( e.g., logos, branding), functions, presentation, freedom of expression, design or aesthetic that are placed on the web content owner / author / developer.

19. WCAG 2.0 Level A and AA checkpoints • Details of WCAG 2.0 Level A and AA • The table on the following pages summarizes each of the guidelines and the related success criteria in WCAG 2.0, for Level A and AA. • Notes are provided summarizing each of the criteria. • Guidelines are listed in the second column. • Level A criteria are listed in the third column – click the link to get more details from W3C. • Level AA criteria are listed in the fourth column – click the link for more details from W3C. • Notes are provided in the fifth column. • For the Level A criteria, the notes will simply recap the W3C description. There are no contentious Level A criteria. You can skip the details of the Level A notes. • For the Level AA criteria, questions and comments are provided. These are prefaced with “AA:” and are in larger text to focus your discussion.

20. WCAG 2.0 Level A and AA checkpoints

21. WCAG 2.0 Level A and AA checkpoints

22. WCAG 2.0 Level A and AA checkpoints

23. WCAG 2.0 Level A and AA checkpoints

24. WCAG 2.0 Level A and AA checkpoints

25. WCAG 2.0 Level A and AA checkpoints

26. WCAG 2.0 Level A and AA checkpoints

27. FYI … • What’s happening in: • Canada • Federal lawsuit in November 2010 ordered the Government of Canada to make its Internet web sites accessible within 15 months. • Manitoba has started public dialogue on accessibility standards. • Quebec standards underway – public sector website. • United States • Standards refresh underway – very comprehensive – web, technology, telecom, kiosks. • US standards influence multi-level government procurement policies – highly influential • Justice department position – private sector web sites are an extension of a physical place of business and therefore subject to anti-discrimination laws (Americans with Disabilities Act). • Target is an examples of large American company that has been successfully held accountable in court and have settled litigation at $6 million. • Australia • Federal, state and territorial government sites to WCAG 2.0 A by Dec. 2012 • Federal sites to AA by Dec. 2014, states and territories to AA or AAA • Applies to all government websites (Internet, Intranet) • Japan, China, Britain, European Union • All moving to adopt WCAG or WCAG-based web standards

28. CSUN 2011 Technology presentation 'CSUN 2011', the largest annual conference on technology and persons with disabilities. Over the years, the conference has grown to almost 5,000 participants, with presenters and exhibitors representing the U.S. Federal government, all 50 states, numerous universities and industries, and over 35 foreign countries: We will briefly cover the following sessions: WEB-2045 Making Web Applications (WAI/ARIA) More Accessible DHH-2003 IBM AbilityLab Digital Media Captioner and Editor WEB-3049 HTML 5 Accessibility Panel WEB-2040 Advancing Mobile Usability and Access for Everyone WEB-2032 Accessible Analytics: Complex Charts, Large Datasets, and Node Diagrams