The Ramp to Accessible Software:
Designing, Developing, and Testing for Online Accessibility

Presenter: Mike Paciello (TPG)

The text alternative to a PowerPoint presentation delivered by Mike Paciello of The Paciello Group, at the June 23, 2004 meeting of Boston-IA.

Quick Links:

• Slide 1
• Slide 5
• Slide 10
• Slide 15
• Slide 20
• Slide 24 (references)
• Slide 25 (last slide)
• Appendix

Slide 1: Overview

The Paciello Group (TPG) assumes that Information Technology (IT) vendors will develop and/or incorporate assistive technologies for one or more of the following reasons:

• To comply with existing regulations in markets where these regulations exist.
• To comply with anticipated regulations in markets where these regulations are expected.
• To exploit a market demand for these features, regardless of regulations.
• To generate goodwill and be perceived as good community citizens.

Government (Federal/State) vendors seek to assess the market opportunity for IT accessibility solutions, based on an analysis of:

• The current and future regulatory environment.
• Current and future buying behavior in the public and private sectors.
• Current and future competitive strategies and tactics.

Federal Agencies are on record and have publicly committed to Section 508:

• Social Security Administration (SSA), Department of Defense (DoD), Department of Education (DoED), Veterans Administration (VA), State Department, etc.

• Example: Department of Homeland Security

  • Access to the Web and IT for Department of Homeland Security (DHS) employees and U.S. citizens (Department of Homeland Security: Accessibility Policy).
  • Enforcing [Section] 508 compliance through request for proposals (RFP's), including the SPIRIT initiative.

This presentation serves as a foundation for IT vendors to make decisions on where to focus resources in the development and deployment of accessible products and solutions.

Back to Index

Slide 2: The Business & Technology Opportunity

Observations

• Federal Government is the single largest employer of people with disabilities.
• Federal laws including Section 508 & Section 255 mandate technology be accessible.
• Federal agencies are enforcing, requiring major shift in vendor product development and positioning.

Result = "Accessibility Gap"

• Technological advances in the field of accessibility lag behind greater advances in mainstream information technology.

• Disability demographics:

  • Estimated 54+ million Americans with disabilities.
  • Growing percentage using computers & Web resources.
• Combined with aging population of computer users demanding more services.

Net Effect

• People with disabilities & senior citizens lack mainstream technology inclusion.
• Section 508 is a new and fast growing "market maker".

Back to Index

Slide 3: Introduction

The Story of Brian...

[Story about a blind person visiting an accessible room in a hotel for the first time. Not only did he have to experiment with the orientation of the card-key to get into the room, he also had to explore an extra-large room designed to meet the needs of people with mobility impairments. One size does not necessarily fit all.]

Challenge for IT Vendors and Service Consultants

• Determine the accessibility state of Web & software user interfaces.
• Delivery of quantified recommendations that result in User Interface Enhancements (UIE) for people with disabilities.

• Incorporating accessibility into product development lifecycle.

  • Concept & design
  • Development & product management
  • Documentation, Training, & Help systems
  • Q/A & Usability testing
  • Marketing and sales

Issues

• Accessibility old/new dilemma.
• Limited in-house expertise at every level (management, development, sales).
• Industry standards are "thin" and infantile.
• Formulas for formal evaluation methods to calculate accessibility measurements do not exist.

Back to Index

Slide 4: Understanding IT Accessibility

Electronic & Information Technology (E&IT) must be accessible to a variety of users with disabilities without relying on a single sense or ability.

Examples:

• Systems that require "mouse"-only input are not accessible to blind or some with physical disabilities.
• Web sites containing images, media, and applications must be accessible to all users with disabilities.

Key Goal: Whole systems of technology that are inherently accessible.

• Example: Network operating systems with built in screen-readers, visual system alarms, on-screen keyboards.

Accessibility may be achieved by enhancing the system's ability to interact, co-exist, or be compatible with adaptive and assistive technology.

• Example: Web-based kiosks that are wheel-chair accessible.

The Point: There are alternative ways to accomplish the same objective.

• Do not strictly focus on web/software accessibility techniques, standards, and "doing it this way or that way".
• Give primary focus to user needs, user requirements, user testing process.
• This results in sites, applications, and services that are "coded" accessible and usable.
• Key = attitude and user inclusion.

Back to Index

Slide 5: Understanding Section 508

Federal agencies who develop, procure, maintain, or use electronic and information technology must ensure that it is accessible to people with disabilities including:

• Federal employees
• Members of the public who have access to and use Federal E&IT

Section 508 Technical Standards

Subpart B — Technical Standards

• 1194.21 Software applications and operating systems.
• 1194.22 Web-based intranet and internet information and applications.
• 1194.23 Telecommunications products.
• 1194.24 Video and multimedia products.
• 1194.25 Self contained, closed products.
• 1194.26 Desktop and portable computers.

Subpart C — Functional Performance Criteria

• 1194.31 Functional performance criteria.

Subpart D — Information, Documentation, and Support

• 1194.41 Information, documentation, and support.

Back to Index

Slide 6: Why Commit to Section 508?

Commitment to Section 508 and accessibility of information technologies to people with disabilities involves embracing accessibility and building Section 508 requirements into your products and services.

The subsequent ROI —

• Broadens your opportunity to reach an untapped market opportunity of approximately 54 million.
• Reduces the liability associated with legal repercussions.
• Enhances your corporate image.

Back to Index

Slide 7: Engineering Approach and Methodology

Development Strategy

Most Common Software/Web Accessibility Issues

• Content (structure/presentation, images, multimedia)
• User Interface (limited user preferences)

• Functionality is incompatible with Assistive Technologies

  • Lack of implementing Operating System/Application Library accessibility functions (Microsoft Active Accesssibily (MSAA)/Java)
  • Assistive technologies are behind technology curve
• Lack of documentation, robust Help systems
• Usability

Remember: Design usable and accessible software that accommodate people with disabilities by:

• Implementing corporate processes, policies, and standards that support accessible design.
• Positioning accessibility as a core competency.
• Educating internal resources.

Key Alerts:

• Current accessibility validation tools are not effective.
• Iterative user testing is the best way to ensure accessible user experience.

Back to Index

Slide 8: Checklist for Developing an Information Architecture

• Review requirements and task analysis.
• Evaluate your content.
• Develop a organizational development structure based on content, tasks, user personas, features, and market demand (test the structure via user testing, walkthroughs).
• Map your tasks and procedures to your site/application organizational structure.
• Build a navigational schema.
• Implement the architecture and test against design specification.

Back to Index

Slide 9: Usability Evaluation Methods

4 Basic Evaluation Methods

• Automatic (software tools)
• Formal (exact models/formulas to calculate measures)
• Informal (experienced evaluators conducting usability inspections)
• Empirical (usability testing involving users)

Best Practice Recommendation

• Combine informal inspections & empirical testing

Usability inspections result in immediate, accurate, and long term benefits to the user interface (UI).

Empirical studies ensure Accessible User Experience (AUE).

Back to Index

Slide 10: Usability Inspections

2 Simple Objectives

• Find usability problems within existing UI design.
• Make recommendations for improving & enhancing.

Usability Problems to Review

• Ease of Use — Error Seriousness
• Efficiency — UI "pleasantness"
• Error Frequency

Resulting Recommendation Report

• Identify problems and suggest redesign solutions.
• Prioritize list of usability problems based on rate of occurrence, severity level, & market/user impact.
• Where possible, estimate implementation cost & cost-benefit analysis.

Back to Index

Slide 11: Usability Inspection Methods

• Heuristic evaluations (expert reviews)
• Guideline & Standards reviews (conformance review)
• Walkthroughs (user/developer scenarios)
• Consistency (family of products review)
• Formal usability inspections (moderated & focused inspection)
• Feature inspections (function, utility review)

Back to Index

Slide 12: Heuristic Evaluations

Conducting Heuristic evaluations

• Form a team of 3-5** specialists to perform individual inspections against list of heuristics:

  • ** Studies show that use of 4 to 5 evaluators result in 80% identification of accessibility problems. More is better!
  • Evaluators require guidelines, standards, usability guidelines, and UI design experience.
  • Comparative analysis of collected data, formulate report.

Implement formal inspection process

• Appoint moderator to manage the team.
• Plan the inspection, conduct kick-off meeting, develop preparation phase for individual reviews, conduct main inspection, end with follow-up phase to assess effectiveness of the inspection.
• Plan user testing.

Back to Index

Slide 13: Accessibility UI Heuristics

• Simple & natural dialogue
• Familiarity (speak the user's language)
• Minimize the user's memory load
• Consistency
• Feedback
• Clearly marked exits
• Shortcuts
• Good error messages
• Prevent errors
• Help & Documentation

Back to Index

Slide 14: Usability Testing

Basis

• Automated testing rarely results in capturing true user experience.

• Heuristic evaluations cannot address all usability issues:

  • Not able to fully emulate user experience (unless inspector has a disability).
  • Task analysis is generally not part of the heuristic evaluation.

Benefits

• No preconceived notions, expectations, or application prejudices.
• Validates user requirements.
• Confirms heuristic evaluations.
• Builds client confidence.
• Assures AUE (accessible user experience).

Back to Index

Slide 15: Conducting User Testing

Setup

• Establish an accessibility center to perform user testing (Hint: Collaborate with disability organizations).

• Recruit sample users and ensure:

  • Cross-disability sampling
  • Multi-Assistive Technology (AT) configurations
  • Variable user experience level (novice, average, expert)
  • Involve client developers, engineers as observers

Reminders

• User testing is not beta testing!
• If permissible, video record sessions.
• Do not "lead" participants.
• Perform iterative studies.
• Pay participants and thank them!

Slide 16: Software Applications & Operating Systems:
Minimal Standards for Functional Performance

Section 508 Requires

At least one mode of operation and information retrieval shall be provided as follows:

• Does not require user vision OR includes support for assistive technology for people with visual disabilities.
• Does not require user hearing OR includes support for assistive technology for people who are deaf or hard of hearing.

If audio information is important, enhanced auditory support OR assistive hearing devices shall be provided. At least one mode of operation or information retrieval that:

• Does not require user speech OR provides appropriate assistive technology.
• Does not require fine motor control or simultaneous actions and is operable with limited reach and strength.

Back to Index

Slide 17: Keyboard Accessibility

For systems that include keyboards, product functions must be executable from the keyboard.

• Function itself or result of the function must be discerned textually.

Applications cannot disrupt or disable documented accessibility features including:

• Features made available through the operating system.
• Features made available through other products.

Windows, Macintosh, and Unix (Linux, too) support accessibility keyboard functions including:

• Mouse keys: Control pointer with numeric keypad.
• Bounce keys: Control rate of "taps" on keys.
• Serial keys: Allow serial devices access to keyboard and mouse functions.
• Sticky keys: Press 1 key for multiple key functions.
• Toggle keys: Emits tones for Caps, Num, and Scroll Locks.

For additional information, Select Control Panel — Accessibility Options

Back to Index

Slide 18: User Interface

Ensure that user focus is available through on screen indicators.

Ensure that user focus is exposed to assistive technology that tracks user focus and focus changes.

Expose sufficient information about user interface including identity, operation, and state of elements to assistive technology.

Provide textual information through operating system functions for displaying text.

Minimal requirements shall include:

• Text content
• Text input caret location
• Text attributes

Applications should not override selected contrast and/or color settings.

Do not use color coding as the only means for conveying vital system or application information.

Do not use blinking or flashing text, objects, or other elements that flash or blink at frequency rates greater than 2 Hz or lower than 55 Hz.

Animated information shall be available in at least one non-animated form that is optional to the user.

Back to Index

Slide 19: Images and Graphics

If the element is an image or graphic, the image information should be conveyed through text.

Assign consistent meaning to bitmap images used to identify controls, status indicators, or other programmatic elements.

Back to Index

Slide 20: Forms

Ensure that forms are fully accessible to people using assistive technology. Users should be able to access all form:

• Information
• Field elements

• Functionality for completion

  • Including directions and cues

Back to Index

Slide 21: Manual Tests

Unplug the mouse and make sure keyboard access is provided to all active objects such as buttons and scroll boxes.

Make sure tab elements such as links, tool bars, and form fields are loaded out in logical order.

Provide meaningful names in the application for all text and graphics based elements.

** Information taken from Sun's Guidelines for Software Accessibility.

Slide 22: Product Support Documentation & Customer Service

Section 508 includes provisions to ensure that users with disabilities have access to associated product support features, including the following minimal standards:

• Documentation available in alternative formats (examples: Braille, large type print, audio)
  • At no additional charge
• Product feature information available in alternative formats
  • Including accessibility features and compatibility information

Customer service support shall accommodate communication needs of end-users with disabilities. For example:

• TTY/TDD services for the deaf and hard of hearing

Slide 23: Multimedia — Larry Goldberg

[Larry Goldberg of WGBH and National Center for Accessible Media (NCAM) made his presentation on Making Multimedia Accessible at this point.]

Back to Index

Slide 24: Developer Resources & Tools

Microsoft

• Windows/MSAA Platforms:
  • Accessibility Home Page
• Microsoft Software Accessibility Guidelines
  • Microsoft Active Accessibility
  • Visual Studio: Designing Accessible Applications
  • Visual Studio: Accessibility Design Guidelines for Software
  • Guidelines for Keyboard User Interface Design

IBM

• Developer Guidelines
  • Software Accessibility
  • Java™ Accessibility

Sun

• Sun Microsystems, Inc.
  • Accessibility Quick Reference Guide

Others

• U.S. Department of Education
  • Requirements for Accessible Electronic and Information Technology Design
• Trace Research Software Guidelines and Resources
  • Desktop Software Standards
  • Application Software Design Guidelines

Back to Index

Slide 25: Summary and Conclusion

3 Key Words

• Clarity — Process/Plan/Standards
• Compatibility
• Usability

To achieve greater web access we need to focus on:

• Clarity of standards, guidelines (via standards initiatives)
• Compatibility with assistive/ adaptive technologies
• Infuse usability methods that engage individuals with disabilities into mainstream product design

Goal is "overall" accessibility of the whole technology system— you are encouraged go beyond what is minimally required.

Section 508 is about accessibility, and accessibility is about business opportunity— Go for it!

End of Slide Presentation

Back to Index

Appendix

About TPG

The Paciello Group (TPG) consults with commercial companies and government entities on designing systems for accessibility and Section 508 compliance. TPG offers professional consulting, technology solutions, and monthly monitoring services to ensure that our clients reach all of their audiences, meet governmental and international standards, and maintain the ongoing accessibility of their dynamic assets.

Additional background: The Paciello Group (www.paciellogroup.com) clients include Forrester, Fidelity, Cendant, Microsoft, Macromedia (Adobe), Hyperion, PTC, SkillSoft, and other well known companies. The founder and President, Mike Paciello, is an international authority on Web accessibility and assistive technology. He co-founded the Web Accessibility Initiative (WAI) for the World Wide Web Consortium (W3C) and is the author of the best selling book, "Web Accessibility for People with Disabilities."

Back to Index

© 2004 TPG, LLP. All rights reserved.

Back to top