Designing

1
Designing Developing for Accessibility
Throughout the Life-CycleSession OTH-2055

• CSUN Conference Los Angeles, California,
  21-March-2009
• Olive Au - IBM Customer Facing Solutions
• Bill Curtis-Davidson - IBM Human Ability
  Accessibility Center

2
Agenda

• Purpose of this Paper
• Accessibility Governance Standards
• Integrating Accessibility into the Full Life
  Cycle
• Pre-Design
• Design
• Development
• Testing
• Conclusion References

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
• IBMs own integrated approach to accessibility
  transformation
• Experience with many other companies,
  organizations and government agencies

4
Agenda

• Purpose of this Paper
• Accessibility Governance Standards
• Integrating Accessibility into the Full Life
  Cycle
• Pre-Design
• Design
• Development
• Testing
• Conclusion References

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)

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

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

8
Agenda

• Purpose of this Paper
• Accessibility Governance Standards
• Integrating Accessibility into the Full Life
  Cycle
• Pre-Design
• Design
• Development
• Testing
• Conclusion References

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)

10
Goals for Integrating Accessibility into General
Life Cycle Phases
Pre-Design
Design
Development
Testing
Goal Accessibility strategy is defined.
Goal Designing to support the strategy.
Goal Accessibility strategy is implemented.
Goal Assure the quality of implementation of the
accessibility strategy.
11
Pre-Design Phase Introduction
Pre-Design

• 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

Goal Accessibility strategy is defined.
12
Pre-Design Phase Key Considerations
Pre-Design

• 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?

Goal Accessibility strategy is defined.
13
Technology Selection Example Creating Accessible
Widgets with Dojo
Pre-Design

• 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

Goal Accessibility strategy is defined.
14
Base Framework Example Creating Accessible
WebSphere Portals
Pre-Design

• 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 IBMs 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.

Goal Accessibility strategy is defined.
15
User Assistance Built-In Accessibility Example
BBC Web Site
Pre-Design

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

Goal Accessibility strategy is defined.
16
Design Phase Introduction
Design

• 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

Goal Designing to support the strategy.
17
Design Phase Key Considerations
Design

• 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)?

Goal Designing to support the strategy.
18
Team Collaboration Example Accessibility
Information Sharing
Design

• 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 technologys 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

Goal Designing to support the strategy.
19
User Interaction Design Example Content
Consistency
Design

• 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!

Goal Designing to support the strategy.
20
User Interaction Design Example Accessible UI
Patterns
Design

• 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)

Goal Designing to support the strategy.
21
Development Phase Introduction
Development

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

Goal Accessibility strategy is implemented.
22
Development Phase Key Considerations
Development

• 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

Goal Accessibility strategy is implemented.
23
Developer Training Example Routine IBM Project
Developer Training
Development

• 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)

Goal Accessibility strategy is implemented.
24
Unit Testing Example IBM Accessibility Unit
Testing Process
Development

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

Goal Accessibility strategy is implemented.
25
Unit Testing Example IBM Accessibility Unit
Testing Process
Development
Goal Accessibility strategy is implemented.
26
Testing Phase Overview
Testing

• 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

Goal Assure the quality of implementation of the
accessibility strategy.
27
Testing Phase Key Considerations
Testing

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

Goal Assure the quality of implementation of the
accessibility strategy.
28
Repeatable Test Example IBM Project with
Government Client
Testing

• 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

Goal Assure the quality of implementation of the
accessibility strategy.
29
Accessibility Defect Tracking Example Using
Rational ClearQuest
Testing

• 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

Goal Assure the quality of implementation of the
accessibility strategy.
30
Accessibility Defect Tracking Example Using
Rational ClearQuest
Testing
Goal Assure the quality of implementation of the
accessibility strategy.
31
Agenda

• Purpose of this Paper
• Accessibility Governance Standards
• Integrating Accessibility into the Full Life
  Cycle
• Pre-Design
• Design
• Development
• Testing
• Conclusion References

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.

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.

34
Contact Information

• Please email us if there are questions
• Olive Au, IBM Customer Facing Solutions
  (oau_at_ca.ibm.com)
• Bill Curtis-Davidson, IBM Human Ability
  Accessibility Center (wacurtis_at_us.ibm.com)

IBMs View of Accessibility To enable human
capability through innovative technology and
solutions so that all people can maximize their
capacity to contribute, regardless of age or
ability.
35
Accessing the Future A global collaborative
exploration for accessibility in the next decade
July 20-21, 2009 Boston, MA

• Conference tracks
• Universal Design and Accessibility Standards
• Patient-centered Collaborative Care
• Accessible Online Workplaces and Communities
• Travel Transportation

36
Legal Disclaimer

• IBM reserves the right to change specifications
  or other product information without notice. This
  publication could include technical inaccuracies
  or typographical errors. References herein to IBM
  products and services do not imply that IBM
  intends to make them available in other
  countries. IBM makes no representations or
  warranties regarding third-party products or
  services. IBM PROVIDES THIS PUBLICATION "AS IS"
  WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
  IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR
  PURPOSE. SOME JURISDICTIONS DO NOT ALLOW
  DISCLAIMER OF EXPRESS OR IMPLIED WARRANTIES IN
  CERTAIN TRANSACTIONS THEREFORE, THIS DISCLAIMER
  MAY NOT APPLY TO YOU.
• IBM, the IBM logo, WebSphere, and Rational
  ClearQuest are trademarks or registered
  trademarks of the IBM Corporation in the United
  States, other countries or both.
• Other company, product, or service names may be
  trademarks or service marks of others.