1 / 40

Rich Schwerdtfeger – CTO Accessibility, IBM Software Group

Next Generation Web 2.0 Accessibility Test Tooling Open Ajax Alliance Accessibility Tools Task Force. Rich Schwerdtfeger – CTO Accessibility, IBM Software Group Mike Squillace – Accessibility Engineer, IBM Research Nathan Jakubiak – Software Development Manager, Parasoft

indra
Download Presentation

Rich Schwerdtfeger – CTO Accessibility, IBM Software Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Next Generation Web 2.0 Accessibility Test ToolingOpen Ajax Alliance Accessibility Tools Task Force Rich Schwerdtfeger – CTO Accessibility, IBM Software Group Mike Squillace – Accessibility Engineer, IBM Research Nathan Jakubiak – Software Development Manager, Parasoft Constantine Grancharov – Product Manager, Rational Policy Tester, IBM Iosif Viorel (Vio) Onut – Accessibility Focal Point, Rational Policy Tester, IBM Dylan Barrell – V.P. Product Development, Deque Jon Gunderson, Ph.D. – Illinois Center for Information Technology Accessibility (iCITA), University of Illinois at Urbana/Champaign

  2. Speaker: Rich Schwerdtfeger – CTO Accessibility, IBM SWG • Problems with Today’s Web Accessibility Tooling • IBM Goals for Establishing Accessibility Tools Task Force • OAA Accessibility Tools Task Force

  3. Problems with Today’s Web Accessibility Tooling WCAG 2 not fully understood Do not address dynamic, rich internet applications Limited to static web site “snapshots” Does not test for *W3C WAI-ARIA Does not test for UI component structure Applications run on client and server Do not address testing throughout the development life cycle * WAI-ARIA – Web Accessibility Initiative Accessible Rich Internet Application Specifications

  4. IBM Goals for Establishing Accessibility Tools Task Force Use WAI-ARIA leadership to accelerate Tools Providers to support WAI-ARIA/WCAG 2 Enhanced Rule Sets and reporting best practices Grow Third party ARIA support in third party conformance servers Open source plug-in to supply conformance servers with updated DOM Define/publish Rules set which support WAI-ARIA and WCAG 2 Support open source servers-based logging and analysis tool prototypes Address accessibility throughout the development cycle Development tools Functional Verification Test Site-wide governance Address Code Isolation for accessibility errors Address server and client generated Can and how do we get industry uptake Success is not measured by a single company

  5. OAA Accessibility Tools Task Force Active Members of the OAA Accessibility Tools Task Force Deque IBM ParaSoft University of Illinois Goals Develop Accessibility Validation rules for WCAG 2 compliance including WAI-ARIA Collaborate on techniques to produce highly efficient and scalable dynamic rules engines for handling RIAs Rule sets must be open source and consumable by major accessibility test tools. Develop Accessibility Reporting Best practices Target Developer IDEs, governance tools, and functional verification tools.

  6. Speaker: Mike Squillace – Accessibility Engineer, IBM Research • Simplifying WCAG2 as Rules • Expressing Validation Rules • Rulesets

  7. Simplifying WCAG 2.0 as Rules • Four layers of WCAG 2.0 • Principles – Perceivable, Operable, Understandable, Robust • Guidelines – next level of concreteness, primarily for organization within principles • Success criteria – actual measurement of compliance but not readily codifiable • Techniques – concrete examples of how to satisfy a given success criterion • What do I, the content author or web application developer, need to check? What did I do or what might I have done that breaks accessibility? • Examples: from success criteria to validation rules • SC 1.1.1 non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose… • alt attribute is missing from images that can be determine to be non-decorative or that are lacking WAI-ARIA role='presentation‘ • the longdesc attribute (if present) must point to a legitimate alternative resource (e.g. an .html file) • image is found with null alt text (i.e. either no alt attribute or alt="") but title attribute is present • WCAG 2.0 Validation Rules

  8. Simplifying WCAG 2.0 as Rules (cont.) • 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. • use of any stylistic, deprecated HTML markup (e.g. b (bold), blink, marquee, u (underlined text), i (italicize), etc. • an element with role="textbox" does not have an aria-labelledby property with an idref representing a label • Of course, includes non-WAI-ARIA version, which requires all form controls to be associated with a label via the ‘for’ attribute of the <label> element • 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set ; and notification of changes to these items is available to user agents including assistive technologies. • invalid or incorrect WAI-ARIA role given WAI-ARIA specification of roles • A container role (tree, grid, menu, etc.) must have at least one child with an applicable role as defined by WAI-ARIA • an assigned WAI-ARIA state or property is not compatible with the global or role-specific states and properties for a given WAI-ARIA role

  9. Expressing Validation Rules • Essential part of validation rule is rule logic – the test that must be passed or algorithm that must be completed to satisfy the rule • Permits rule reuse in different checklists • Simplifies checks as much as possible • Written in JavaScript • familiar to web developers and testers • portable via its support in a variety of browsers on multiple platforms • Also a number of stand-alone JavaScript engines (e.g. SpiderMonkey, Rhino) • Return to SC 1.1.1 non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose… • alt attribute is missing from images that can be determined to be non-decorative { id : "imgAltAttrMissing", context : "img[@role != 'presentation']", validateParams : { min_decorative_width : {value:8, type:"integer"}, min_decorative_height : {value:8, type:"integer"} }, validate : function (ruleContext) { var vparams = this.validateParams; var passed = (ruleContext.clientWidth <= vparams.min_decorative_width.value && ruleContext.clientHeight <=vparams.min_decorative_height.value) || ruleContext.hasAttribute("alt"); return new ValidationResult(passed, [ruleContext], '', '', []); } },

  10. Expressing Validation Rules (continued) • The longdesc attribute (if present) must point to a legitimate alternative resource (e.g. an .html file) { id : "imgAltLongdescInvalid", context : "img[@longdesc][@role != 'presentation']", validateParams : { valid_longdesc_url_pattern : {value:/.+\.[x]?htm[l]?$/i, type:"regexp"} }, validate : function (ruleContext) { var passed = this.validateParams.valid_longdesc_url_pattern.value.test(ruleContext.longDesc); return new ValidationResult(passed, [ruleContext], 'longdesc', '', []); } } • image is found with null alt text (i.e. either no alt attribute or alt="") but title attribute is present { id : "111.R02", label : "imgAltAttrEmptyTitleAttrPresent", context : "img[@role != 'presentation']", validate : function (ruleContext) { var passed = ruleContext.alt || !ruleContext.title; return new OpenAjax.a11y.ValidationResult(passed, [ruleContext]); } }

  11. Rulesets • Validation rules contain rule logic, everything else is defined by a ruleset • Container for validation rules • Holds metadata about ruleset (e.g. guidelines, checklist, etc.) and about each rule • All symbols are localizable codes • Again, coded in JavaScript, but format is simple enough to be coded by almost anyone • Rules discussed earlier are encoded in a WCAG2 ruleset as: { // basic info id : "WCAG_2_0", nameCode : "WCAG20.name", descriptionCode : "WCAG20.description", // rulesetUrl - URL of the checklist/ruleset as a whole rulesetUrl : "http://www.w3.org/TR/WCAG20/", // baseReqUrl - used to resolve relative urls of requirementUrls only baseReqUrl : "http://www.w3.org/TR/WCAG20/", requirements : [ { criterionNumber : '1.1.1', criterionLevel : 'WCAG20.level.A', criterionDesc : 'WCAG20.description.1_1_1', requirementUrl: '#text-equiv', rules : { 'imgAltAttrMissing' : {severityCode:'level.violation', messageCode:'images.msg.altmissing'}, 'imgAltLongdescInvalid' : {severityCode:'level.potentialViolation', messageCode:'images.msg.invalidLongdesc'}, 'imgPresentationalWithAltOrTitle' : {severityCode:'level.recommendation', messageCode:'images.msg.imgPresentationalWithAltOrTitle'} } }, // 1.1.1 : ] }

  12. Speaker: Nathan Jakubiak – Software Development Manager, Parasoft • Development Challenges to Accessible Applications • Policy-Based Approach • Enforcing Accessibility Policies • Support for Accessibility Standards • OAA Accessibility Tools Task Force

  13. Parasoft - Development Challenges to Accessible Applications • Inaccessible web applications • Developers don’t know they need to do it • Expectations around creating “accessible applications” not enforced • Manufacturing example • Automobile assembly line • Laser measures tolerance of spot-weld • If problem found, immediate alert sent • Questions asked • Can the weld be fixed/salvaged? (Fix actual problem) • Does the welder need to be adjusted? (Address process problem)

  14. Parasoft - Policy-Based Approach • Parasoft uses a policy-based approach to development and accessibility • Management defines expectations through Parasoft’s Policy Center • The process is continuously monitored with alerts sent when expectations not met

  15. Parasoft - Enforcing Accessibility Policies • Repeatable continuous (nightly) scans performed on the application • Problems found delivered to the responsible developer’s IDE • Non-intrusive process – developer does not have to run scans • Adjust policy as needed

  16. Parasoft - Support for Accessibility Standards • Crawling-type scans – low support for Rich Internet Applications • Functional testing of Rich Internet Applications • Automatic application to functional test scenarios • Application use cases can automatically be tested for accessibility • Some ability to test Rich Internet Applications – but static rules have limits • Support for Section 508, WCAG 1.0 and 2.0

  17. Parasoft - OAA Accessibility Tools Task Force • OAA Accessibility Tools Task Force a natural extension of commitment to accessibility and Rich Internet Applications • Addresses current shortcomings testing Rich Internet Applications for accessibility • Currently integrating support for rules and rulesets

  18. Speakers: Constantine Grancharov – Product Manager and Vio Onut – Accessibility Focal Point, Rational Policy Tester, IBM • What is Rational Policy Tester • A Single Solution • The Technology • Prototype • Prototype Grouping Issues • Prototype Accessibility Advisories and Education • OAA Participation

  19. Website IBM Rational Policy Tester – What is Rational Policy Tester • Web accessibility and compliance assessment platform • Identifies Web accessibility issues related to regulatory compliance standards • U.S. Section 508 • WCAG 1.0 (Priority 1, Priority 2, Priority 3) • WCAG 2.0 (A and AA) • AccessiWeb (France) • Can be customized for other standards • Provides Management with visibility of the accessibility status of their Web sites, and the regulatory compliance risk they present to their organization • Enables organizations to engage and educate their Development and QA teams, and implement accessibility controls throughoutthe SDLC to mitigate risk and reduce cost

  20. IBM Rational Policy Tester – A Single Solution • Enterprise visibility and scalability • Web portal style interface • Enterprise-class architecture designed to scale accessibility assessments • Central repository, which enables creating an inventory of your Web properties • User roles and access permissions • High-level dashboards displaying accessibility status and compliance risk • Engaging all stakeholders • Centralized test policies • Manual and automatic Web site explore • Detailed accessibility and compliance reports • Accessibility advisories and education • Issue management • Defect tracking systems integrations • REST-style API for integration with SDLC systems

  21. IBM Rational Policy Tester – The Technology • How the Technology Works • Phase 1 – Crawling the website as a regular user • Phase 2 – Analyze the content of the website for Accessibility issues • Phase 3 – Report the issues • Explore methods • Automatic – the engine crawls thewebsite until all pageshave been visited andtested • Manual explore – the user can specify aparticular path/sectionof the website to be tested

  22. IBM Rational Policy Tester – Prototype • Prototype

  23. IBM Rational Policy Tester – Prototype Grouping Issues • Prototype • Group issuesby compliancelevel (Fig 1): • Group issues by OAA rule (Fig 2):

  24. IBM Rational Policy Tester – Prototype Grouping Issues (continued) • Prototype • Group issuesby accessibilityseverity (Fig 1): • Group issues by HTMLelement (Fig 2):

  25. IBM Rational Policy Tester – Prototype Accessibility Advisories and Education • Prototype • Helping the customer to better understand the accessibility issue and provide possible solutions. Advisory: (Fig 1) Issue Details: (Fig 2)

  26. IBM Rational Policy Tester – OAA Participation • IBM is actively involved in the OAA effort, and Accessibility Tools Task Force comes as a natural fit for Rational Policy Tester. • Defining and shaping the challenges of Accessibility Testing • Defining accessibility rule format and semantics • Contributing to the ruleset • Leverage the OAA work and align the Rational Policy Tester solution with the OAA recommendations • It is our intent to actively participate to the OAA Accessibility Tools Task Force and to follow the standards of this group in the Policy Tester product.

  27. Speaker: Dylan Barrell – V.P. Product Development, Deque • Worldspace • Worldspace OAA Working group support • Worldspace Developer Workbench Preview

  28. Deque - Worldspace • About Deque • Provides software and services to help organizations with compliance in the areas of • Accessibility • Quality • Privacy, and • Security • Customers Include: • United States Department of Education, United States Mint, Federal Reserve System • Starbucks, Southwest Airlines, CVS/Caremark, Newegg.com, AOL • University of Texas at Austin • About Worldspace • A set of automated testing suites, developer tools and management reports to help organizations become and stay compliant • For Accessibility, Worldspace supports WCAG 1, WCAG 2, Section 508 out of the box as well as organizational standards and rules

  29. Deque – Worldspace OAA Working group support • The next release of our Worldspace Developer Workbench will support the existing OAA rule sets • We are actively involved in the working group and will continue to contribute know-how and content to the standardization effort • We have developed and will continue to maintain a web site that demonstrates the use of the OAA rule sets.

  30. Deque – Worldspace Developer Workbench Preview

  31. Deque – Worldspace Developer Workbench Preview (continued)

  32. Deque – Worldspace Developer Workbench Preview (continued)

  33. Deque – Worldspace Developer Workbench Preview (continued)

  34. Deque – Worldspace Developer Workbench Preview (continued)

  35. Speaker: Jon Gunderson, Ph.D. – Illinois Center for Information Technology Accessibility (iCITA), University of Illinois • Firebug Accessibility Extension

  36. University of Illinois – Firebug Accessibility Extension • Firebug Accessibility Inspector Video • Click logo to go to the video

  37. Backup slides

  38. Deque Extra Slides • Additional product information follows

  39. Deque - Worldspace

  40. Deque - Worldspace Flash CS4 Eclipse

More Related