©2009 IBM Corporation
*** Designing & Developing for
Accessibility Throughout the Life-CycleSession OTH-2055
CSUN Conference – Los Angeles, California, 21-March-2009Olive Au - IBM Customer Facing SolutionsBill Curtis-Davidson - IBM Human Ability & Accessibility Center
©2009 IBM CorporationSlide 2
Agenda
Purpose of this Paper
Accessibility Governance & Standards
Integrating Accessibility into the Full Life Cycle
– Pre-Design
– Design
– Development
– Testing
Conclusion & References
©2009 IBM CorporationSlide 3
Purpose of this Paper Offers activities that should occur
throughout the development life cycle– Guidelines and standards are often referred to
only in specific phases
– There are many considerations that complement use of guidelines/standards
Targeted to practitioners such as architects, designers and developers
This is a pragmatic insertion of accessibility that adopts a software engineering approach via process methodology
Offer many good practice examples– IBM’s own integrated approach to accessibility
transformation
– Experience with many other companies, organizations and government agencies
©2009 IBM CorporationSlide 4
Agenda
Purpose of this Paper
Accessibility Governance & Standards
Integrating Accessibility into the Full Life Cycle
– Pre-Design
– Design
– Development
– Testing
Conclusion & References
©2009 IBM CorporationSlide 5
The Importance of Accessibility Standards Established accessibility standards are
becoming more well known:
– US Section 508
– W3C Web Content Accessibility Guidelines (WCAG)
Other legislation may be applicable in certain markets:
– Accessibility for Ontarians with Disabilities Act (AODA)
– Americans with Disabilities Act (ADA)
– UK Disability Discrimination Act (DDA)
©2009 IBM CorporationSlide 6
The Advantages of Standards Standards offer many advantages by outlining:
– Basic design principles
– Development (coding) guidelines
– Some “pass/fail” test criteria
Multiple vendors now provide accessibility standards compliance testing tools
However, standards and testing tools only address “compliance” at specific phases of development:
– Often provide no guidance on how to address “compliance” at all stages of development (governance)
– This can give developers a false sense of having developed an “accessible” application
©2009 IBM CorporationSlide 7
The Limitations of Standards However, standards and testing tools only address
“compliance” at specific phases of development:– Often provide no guidance on how to address
“compliance” at all stages of development (governance)
– This can give developers a false sense of having developed an “accessible” application
Issues not usually addressed by standards:– Can abide by all the guidelines but still be inaccessible (alt
text that is inconsistent, wrong alt text)
– Usability for people with disabilities
– Decisions made by developers, architects before the application is even designed that affect the ability to implement some of the standards
– Accessibility support/strategy for application once it is deployed to production
©2009 IBM CorporationSlide 8
Agenda
Purpose of this Paper
Accessibility Governance & Standards
Integrating Accessibility into the Full Life Cycle
– Pre-Design
– Design
– Development
– Testing
Conclusion & References
©2009 IBM CorporationSlide 9
Reasons for Integrating Accessibility into the Full Development Life Cycle Decisions made in each development phase
will affect the accessibility of the application
Level of effort (and associated cost) to address accessibility increases if issues not addressed until late in the life cycle
Regardless of development method used, guidance presented herein can be applied by teams (we are not advocating any specific software process methodology)
©2009 IBM CorporationSlide 10
Goals for Integrating Accessibility into General Life Cycle Phases
Pre-Design
Goal: Accessibility strategy is defined.
Design
Goal: Designing to support the strategy.
Development
Goal: Accessibility strategy is implemented.
Testing
Goal: Assure the quality of implementation of the accessibility strategy.
©2009 IBM CorporationSlide 11
Pre-Design Phase: Introduction Decisions here will have the largest impact:
– On ability of the application to be truly accessible, or create a barrier to full accessibility
Decisions once made are often irreversible once development begins
– Technology and framework are huge
– Any attempt at changing key technologies and framework will often be major surgery.
Good decisions made will cut down on cost of addressing accessibility / remediating
– Maximizing accessibility
– Minimizing defects and exceptions
Pre-Design
Goal: Accessibility strategy is defined.
©2009 IBM CorporationSlide 12
Pre-Design Phase: Key Considerations Does the technology selection or base
framework have an impact on accessibility? – Some platforms may have accessibility modes that
can be enabled/disabled that can have positive or negative effects on AT. These are constraints that the developers will need to work with.
Is there a certain demographic of users that will be using this particular application?
What kind of assistance will be provided to the assistive technology user beyond any built-in accessibility features or functions of the application?
Which accessibility standards are applicable and how will they be followed?
Pre-Design
Goal: Accessibility strategy is defined.
©2009 IBM CorporationSlide 13
Technology Selection Example: Creating Accessible Widgets with Dojo A key open source Javascript toolkit for
developing Web 2.0 applications
The Book of Dojo describes the strategies Dojo uses to support accessibility:
– High contrast settings
– Images off settings
– Device-independent interaction
– ARIA specification support
Key browsers and assistive technologies are improving support for ARIA
An excellent article by IBM Dojo Accessibility leader Becky Gibson is a great starting place
Pre-Design
Goal: Accessibility strategy is defined.
©2009 IBM CorporationSlide 14
Base Framework Example: Creating Accessible WebSphere® Portals Many vendors such as IBM offer product
accessibility statements for many products upon request (http://www.ibm.com/able/). These should be looked at as basic statements of accessibility of the framework.
IBM WebSphere® Portal is used for IBM’s own award-winning “w3” intranet, to implement enhanced accessibility features:– Hidden “Landmarks” are used in core view
layouts (e.g., masthead, global navigation, start of main content area, footers) using HTML heading elements that are hidden from most users using CSS classes.
– Portlet page indexes that are dynamically rendered (and hidden using CSS classes) to offer blind users a quick way to understand complex pages and navigate.
– “Skip to Main Content” links that allow users to jump over the masthead and repetitive navigation elements.
Pre-Design
Goal: Accessibility strategy is defined.
©2009 IBM CorporationSlide 15
User Assistance & Built-In Accessibility Example: BBC Web Site BBC Web site offers comprehensive
accessibility support for end users from a prominent link at the top of each page.
Help is more exhaustive than most Web sites’ accessibility assistance.
Offers some good guidance for users who use different kinds of operating systems and who have different kinds of access needs.
Pre-Design
Goal: Accessibility strategy is defined.
©2009 IBM CorporationSlide 16
Design Phase: Introduction Defining an accessibility strategy during Pre-
Design maximizes the possibility of the application being accessible
But in Design Phase, proper technical and usability design decisions need to be made which will affect accessibility.
If accessibility not addressed during Design, cost for resolving any issues will be higher
Design
Goal: Designing to support the strategy.
©2009 IBM CorporationSlide 17
Design Phase: Key Considerations Accessible Design & Technology
– How is the accessibility strategy supported in use cases and other technology, functional and non-functional requirements?
– How do the selected accessibility standards impact technical aspects of design?
– How will technical team members be trained and share knowledge related to accessibility?
Accessible Design & Usability
– How is the accessibility strategy supported in interaction design work products (e.g. wireframes, templates, visual style, tables, forms, sorting etc.)?
– Have the special needs of people with disabilities been taken into account in specific work products (e.g. personas)?
Design
Goal: Designing to support the strategy.
©2009 IBM CorporationSlide 18
Team Collaboration Example: Accessibility Information Sharing Accessibility information discovered during
pre-design of chosen technologies should be shared among user experience designers and developers
This information should include:
– Accessibility constraints and/or accessibility attributes of a technology’s API
– List of widgets/components that are accessible and can be used by the team and list of widgets/components that are inaccessible and should be avoided
In sharing this information, developers and user experience designers can be more able to produce an accessible solution
Design
Goal: Designing to support the strategy.
©2009 IBM CorporationSlide 19
User Interaction Design Example: Content & Consistency Many sites have images that require ALT text.
Surprisingly, the responsibility of defining ALT text to developers whose strength may not be communication!
In addition, the same images may appear on multiple pages where each page is developed by a different developer.
– Accessibility specialist working with an IA can define a list of images and the ALT text that should be associated with a particular image. This will solve both problems: proper wording AND consistency!
Design
Goal: Designing to support the strategy.
©2009 IBM CorporationSlide 20
User Interaction Design Example: Accessible UI Patterns User interaction designers are often not trained
to look for accessibility issues such as:– Color and contrast
– Dynamic content including error messages
– Keyboard access
– Tables
– Forms
– Cursor focus (for screen readers, other AT)
These issues should be thought about so that UI designers can incorporate accessible UI patterns in wireframes.
The accessible UI patterns should be shared among the design & development team (e.g. using a wiki)
Design
Goal: Designing to support the strategy.
©2009 IBM CorporationSlide 21
Development Phase: Introduction During Development, many practices can be
employed to help make sure developers are enabled to produce accessibility standards conforming code in a collaborative manner.
By doing so, a level of consistency can be maintained.
The number of accessibility defects found in the Testing Phase can be minimized.
Development
Goal: Accessibility strategy is implemented.
©2009 IBM CorporationSlide 22
Development Phase: Key Considerations Which accessibility testing tools will be used
to perform “unit testing” of developed code?
– To help ensure that it conforms to the given standards as early in development as possible
How will designers and developers be trained to use these tools?
– And understand the rationale and importance of accessibility standards conformance and usable access
What processes will developers use to manage their code builds?
– Checking units into the repository after they have performed accessibility unit testing to minimize the need for retroactive bug fixes
Development
Goal: Accessibility strategy is implemented.
©2009 IBM CorporationSlide 23
Developer Training Example: Routine IBM Project Developer Training Quick “accessibility lunch & learn” sessions
are used on IBM projects to provide invaluable initial training on topics such as:
– Accessibility Rationale: Why accessibility is important
– IBM Accessibility Resources/Portal: Intranet portal offering resources for developers and testers
– Checklist & Testing Tools: Outlining specific tools being used for design and testing
– Usability & Accessibility: Usable Access, Design Methods, Testing Methods
Specific guidance is often also included in Development Guides (core reference for team)
Development
Goal: Accessibility strategy is implemented.
©2009 IBM CorporationSlide 24
Unit Testing Example: IBM Accessibility Unit Testing Process Code can be ‘unit tested’ for accessibility
(along with functional unit testing) before it is checked into the repository.
– Can be as simple as running a browser add-on or plug-in such as the AIS Web Accessibility Toolbar.
– Helps ensure a certain level of conformance to the selected accessibility standard.
– Consistent with Agile development practices.
Will not eliminate all potential accessibility defects:
– But will likely minimize the number of retroactive bug fixes that are required for defects not discovered until the Testing Phase.
Development
Goal: Accessibility strategy is implemented.
Unit Testing & Development Cycle
Check out code from repository
Make changes to
code
Run development unit test and
fix bugs
Run accessibility unit test and
fix bugs
Check code into
repository
+
©2009 IBM CorporationSlide 25
Unit Testing Example: IBM Accessibility Unit Testing Process Development
Goal: Accessibility strategy is implemented.
Unit Testing & Development Cycle
Check out code from repository
Make changes to
code
Run development unit test and
fix bugs
Run accessibility unit test and
fix bugs
Check code into
repository
©2009 IBM CorporationSlide 26
Testing Phase: Overview Accessibility tests conducted during a
Testing Phase are one of the most familiar activities related to accessibility:
– Many developer resources exist for how to perform accessibility tests (methods, tools, techniques)
However, the process of testing itself as a project activity is not frequently discussed.
Successful accessibility test require not only test execution, but consideration of a number of factors…
Testing
Goal: Assure the quality of implementation of the accessibility strategy.
©2009 IBM CorporationSlide 27
Testing Phase: Key Considerations How thorough will the testing be? What types of tests will be performed? What methods will be used to document the
tests so they can be repeated exactly the same way by another developer assigned to fix the defect?
What methods will be used to document and communicate accessibility defects:– To the developers such that defects are effectively
tracked to resolution?
– Communicating general information about defects at a higher level to garner management support for additional resources to fix the defects, or to generalize issues being found for the whole team.
Testing
Goal: Assure the quality of implementation of the accessibility strategy.
©2009 IBM CorporationSlide 28
Repeatable Test Example: IBM Project with Government Client List of key information from pre-design phase
– In this case, US Section 508 Web Standards conformance is required, and JAWS® compatibility
Standards-aligned checklist outlining test tools and methods for specific checkpoints
– Includes use of syntax-checking tools, code inspectors/plug-ins and assistive technologies
Creation of step-by-step accessibility test scripts that can be repeated by team members
Testing
Goal: Assure the quality of implementation of the accessibility strategy.
Elements used in application
Section 508 Checkpoint
Accessibility Requirement Testing Method
1.4.2.7 – Images & Non-Text Elements
§1194.22 a Images & Text Equivalents
AccVerify, Manual Inspect/AIS, JAWS
N/A §1194.22 j Screen Flicker / Moving Content
AccVerify, Manual Inspect
N/A §1194.22 f Image Maps AccVerify, Manual Inspect/AIS
N/A §1194.22 I Frames AccVerify, Manual Inspect, JAWS
1.4.2.10 –Scripting §1194.22 l and m Scripts and Applets AccVerify, Manual Inspect, JAWS
N/A §1194.22 k Alternative Page Link
AccVerify, Manual Inspect
N/A §1194.22 e Image Maps Manual Inspect/AIS
1.4.2.8 – Simple Tables §1194.22 g Data Tables Manual Inspect/AIS
1.4.2.9 – Complex Tables §1194.22 h Data Tables Manual Inspect/AIS, JAWS
N/A §1194.22 b Multimedia Manual Inspect
1.4.2.11 – Electronic Forms §1194.22 n Forms AccVerify, Manual Inspect
©2009 IBM CorporationSlide 29
Accessibility Defect Tracking Example: Using Rational® ClearQuest® Determining and agreeing to detailed test
scope (sample set to be tested)– For example, key screens/templates, portlets or
sub-applications, user assistance, etc.
Documenting detailed test results– Spreadsheets are excellent tool to summarize the
defects found in the tested component
– Also summarize the details of test (date, build ID, test ID, file names, etc.)
– Severity assigned for prioritization
Entering defect records into Rational® ClearQuest® for tracking to resolution– Defect record created for each component tested
– Spreadsheet attached to each defect record
Testing
Goal: Assure the quality of implementation of the accessibility strategy.
+
©2009 IBM CorporationSlide 30
Accessibility Defect Tracking Example: Using Rational® ClearQuest® Testing
Goal: Assure the quality of implementation of the accessibility strategy.
©2009 IBM CorporationSlide 31
Agenda
Purpose of this Paper
Accessibility Governance & Standards
Integrating Accessibility into the Full Life Cycle
– Pre-Design
– Design
– Development
– Testing
Conclusion & References
©2009 IBM CorporationSlide 32
Conclusion Project team members have the same overall goal, which is to
develop an application:
– However, each team within the project has a different goal.
Developers need training to understand accessibility standards, development techniques and testing methods.
Application architects, interaction designers and project managers also need training in order to know:
– What questions to ask and how to plan for accessibility activities.
– How to engage in a rational succession of accessibility activities that will hopefully result in development of an accessible solution.
When teams implement the accessibility practices described herein, there can be better communication that can lead to more efficient development of a truly accessible application.
©2009 IBM CorporationSlide 33
References From the Full Paper Government of Alberta, Canada; Alberta Website Accessibility, 2008. Apple, Inc. Introduction to Accessibility Programming Guidelines for Cocoa, 2008. British Broadcasting Corporation (BBC), “My Web My Way” Site, 2008. Dojo Foundation, The Dojo Toolkit: Dojo Accessibility Strategy, 2008. GNOME Project, GNOME Accessibility Toolkit (ATK), 2008. IBM Corporation, IBM Human Ability & Accessibility Center Web site, 2008. IBM Corporation, “Dojo: an accessible JavaScript toolkit,” 2007. IBM Corporation, “Usable Access: Conducting User Evaluations with People with
Disabilities,” 2005. IBM Corporation, Developing accessible portals and portlets with IBM WebSphere
Portal, 2006. Keates, Simeon. Designing for Accessibility: A Business Guide to Countering Design
Exclusion. Routledge, 2006. Linux Foundation, iAccessible2 API, 2008. Microsoft Corporation, Microsoft Active Accessibility (MSAA) v2.0, 2008. Quantcast, Quantcast Audience Profile: GlobeAndMail.com, 2008. Sun Microsystems, Inc. Java SE Desktop Accessibility, 2008. United States Internal Revenue Service (IRS), IRS Web site: Accessibility, 2008. United States Access Board, US Section 508 Website, 2008. WebAIM, Articles on Training Others, 2008. World Wide Web Consortium (W3C), Web Content Accessibility Guidelines, 2008. World Wide Web Consortium (W3C), Accessible Rich Internet Applications (ARIA)
specification, 2008.
©2009 IBM CorporationSlide 34
Contact Information
Please email us if there are questions:
Olive Au, IBM Customer Facing Solutions ([email protected])
Bill Curtis-Davidson, IBM Human Ability & Accessibility Center ([email protected])
IBM’s View of AccessibilityTo enable human capability through innovative technology and solutions so that all people can maximize their capacity to contribute, regardless of age or ability….
©2009 IBM CorporationSlide 35
Accessing the Future:A global collaborative exploration for accessibility in the next decade
July 20-21, 2009Boston, MA
Conference tracks: Universal Design and Accessibility Standards Patient-centered Collaborative Care Accessible Online Workplaces and Communities Travel & Transportation