©2009 ibm corporation * * * designing & developing for accessibility throughout the life-cycle...

©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


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


Agenda




– Pre-Design

– Design

– Development

– Testing



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)


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


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


Agenda




– Pre-Design

– Design

– Development

– Testing



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)


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.


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



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



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



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



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



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



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



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



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



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



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



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



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



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


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

+


Unit Testing Example: IBM Accessibility Unit Testing Process Development


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


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



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



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


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


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


+


Accessibility Defect Tracking Example: Using Rational® ClearQuest® Testing



Agenda




– Pre-Design

– Design

– Development

– Testing



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.


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.


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….


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

©2009 ibm corporation * * * designing & developing for accessibility throughout the life-cycle...

Documents

ibm corporation slide

limitations of standards

accessible application

specific phases of development

disabilities act adaamericans

olive au ibm customer

disabilities decisions

agenda purpose