Select photo for a larger view and description

Proceedings
Web Accessibility Capacity Building Institute

November 29 - December 1, 2006
Hotel Andra, Seattle

The Web Accessibility Capacity Building Institute (CBI) was funded by the National Science Foundation (cooperative agreement #HRD-0227995) through The Northwest Alliance for Access to Science, Technology, Engineering, and Mathematics (AccessSTEM), which is directed by DO-IT at the University of Washington. The purpose of the CBI was to identify accessibility problems and solutions related to emerging web applications and the technologies used to create them as well as strategies that lead to systemic change.

The ultimate goal of AccessSTEM is to increase the successful participation of people with disabilities in STEM careers. To reach this goal, it is critical that students with disabilities have full access to the software and information used in their educational programs. Higher education institutions are exploring and beginning to utilize rich media technologies to improve functionality and usability of both academic and administrative web services, but by doing so they may risk excluding students and employees with disabilities. It is critical that accessibility be addressed early in the development and deployment of web applications, including those that utilize emerging technologies such as AJAX, Flex, and Flash.

Participants at the CBI included representatives from the World Wide Consortium (W3C), IBM, Google, Yahoo, Adobe, and GW Micro, as well as 27 web managers and programmers from 11 colleges and universities, primarily from the Northwest region of the United States.

Agenda

The agenda for the CBI was as follows:

Tuesday, 11-28-06

7-9:00pm
Evening Social and Time to Get Reacquainted
The Loft at the Hotel Andra (floor above the registration counter)

Wednesday, 11-29-06

8 - 9:00am
Buffet Breakfast and Networking
Hotel Andra Mezzanine and Ballroom

9:00 am
Welcome and Introductions
Sheryl Burgstahler, DO-IT, University of Washington

9:40am
Web Apps - The Next Generation: Access Opportunity or Challenge?
TV Raman, Google

10:30am
Break

10:45am
Assistive Technology Vendor Panel
TV Raman, Google
Doug Geoffray, GW Micro

11:45
Introduction to Small Group Discussion Format
Sheryl Burgstahler, DO-IT, University of Washington

12:00pm
Working Lunch
Hotel Andra Mezzanine and Ballroom
Working group discussions: What are the most important issues in maintaining accessibility of the web as we use rich media?

1:30pm
Working group reports

2:00pm
W3C Roadmap for Accessible Rich Internet Applications
Rich Schwerdtfeger, IBM and W3C Web Accessibility Initiative

3:00
Break

3:15
Working group discussions:

4:15
Working group reports

4:45
Preview of tonight's activity and tomorrow's agenda
Daily feedback

5:00
Adjourn

6:30 - 8:30
Network and discuss future collaborations
Cutters Bayhouse Restaurant, 2001 Western Avenue
(Meet in the hotel lobby at 6:10 to walk together (less than half a mile). If you need a ride please arrange this with CBI staff.)

Thursday, 11-30-06

8 - 9:00 am
Working Buffet Breakfast, Networking, and Discussion
Hotel Andra Mezzanine and Ballroom

8:45
Overview of Agenda
Sheryl Burgstahler, DO-IT, University of Washington

9:00
Management Panel: Policies, Practices, and Processes for Maintaining Accessibility

10:00
Break

10:15
Working group discussions:

11:00
Working group report

11:30
Accessibility of Rich Adobe Applications
Bob Regan, Adobe

12:30 pm
Working Lunch
Hotel Andra Mezzanine and Ballroom
Working group discussions: How do we support emerging technologies without sacrificing accessibility?

1:30pm
Working group report

2:00
Programming Web Interfaces: A Live Interactive Problem Solving Session
Todd Kloots, Yahoo!
Doug Geoffray, GW Micro

3:00
Break

3:15
Working group discussions: What do you need to efficiently and reliably create web interfaces?

4:15
Working group reports

4:45
Preview of tomorrow's agenda
Daily feedback

5:00
Adjourn

5:00+
Dinner on Your Own

Friday, 12-1-06

8-9:00 am
Working Buffet Breakfast, Networking, and Discussion
Hotel Andra Mezzanine and Ballroom

9:00 - Noon

11:30
CBI Evaluation
Box lunch and further discussion

CBI Participants

Speakers

Participants

Planning Team

Presentations

The following are summaries of the presentations based on meeting notes, recordings, and edits of presenters.

Web Apps - The Next Generation: Access Opportunity or Challenge

Select photo for a larger view and description

Summary: In this presentation, T.V. Raman asserts that new technologies should be seen as new opportunities, rather than as obstacles and complications. Through coordinated development of content, the user interface, and assistive technology, the reach of people using assistive technology can be increased. Newer light-weight components even make it possible to quickly create custom interfaces, delivering useful information in a wide range of contexts and usable by a variety of technologies.

Speaker: TV Raman, Google

Hosted Web applications offer the promise of easy deployment, light-weight user interaction, ubiquitous access to data, and easy upgrades, but a shift in approach will be needed before they work with assistive technologies (AT). To an extent, the blind community has put itself in a bind by saying something is accessible if it works with a screen reader. A better approach is to view accessibility as usability done properly, with graceful degradation for less capable technologies.

Access goals with Web applications are to:

The building blocks of access are the following:

To build speech access, we need to be able to identify what to speak, determine how to speak it, and decide when to speak.

The Web application model provides an opportunity for AT to extend and embrace the Web model.

The Web browser becomes a container for the Web application, functioning as a universal client.

Custom interfaces are doable in the Web world, providing new opportunities for access.

New adaptive technologies can be built from the growing arsenal of light-weight components.

Separation of content from interaction is laying the foundation for mashups. What is the accessible equivalent of a mashup?

Inspiration for innovative AT could come from audio games. Games often lead to UI innovation.

In conclusion, it is important to build on what we have, but thinking only in terms of current AT is too limiting.

Assistive Technology Vendor Panel

Select photo for a larger view and description

Summary: Early AT software simply captured text, but as pages and interfaces became more complex, accessibility aids such as Microsoft Active Accessibility were needed. Now, with the appearance of dynamic HTML content, new approaches must be developed. IBM is working with W3C, FireFox, and others to address this need. A key challenge is the lack of coordination among AT developers.

Panelists: TV Raman, Google; Doug Geoffray, GW Micro

Doug Geoffray: With early AT software, content could be read by capturing the text output, but as pages became more complex, that approach could yield gibberish. Microsoft Active Accessibility (MSAA) gave AT a way to get at content within, but still pages could have much more complexity that was indicated by MSAA. GW Micro's Window-Eyes screen reading software is designed to use MSAA and the Windows Document Object Model (DOM) to move through content, but is still basically designed for reading static pages. Users can move back and forth between a virtual mode, which navigates a copy of the page, and a browse mode which interacts directly with the page, such as when doing forms. GW Micro is working with IBM to find ways to handle dynamic HTML elements.

As Web applications move into the browser, one challenge is that virtual mode is becoming useless because it does not know about dynamic changes in page content between page loads. A standard method is needed for AT to communicate with the Web applications. How can menu items be presented to the blind user? How can Web applications have the consistency of method AT needs when there are so many different authors and applets?

TV Raman: Early text browsers, such as Emacspeak, demonstrated the advantages of formatting text in terms of its type (from, to, subject). How can we bring the content out of the prison of the screen reader? Why can't the user community build its own set of tools using tools such as GreaseMonkey scripts?

Among assistive technologies, a key problem is that there are too many control key combinations. Every possible combination has been taken and getting AT software developers to coordinate is very difficult. Also, people writing self-voicing applications do not necessarily know what people who are blind need. Not every blind person wants audio. Some just want Braille. Other problems are that the infrastructure in Windows is inconsistent and there are a huge number of APIs AT must be designed to deal with. The result of this confusion is that innovation with respect to the blind has come to a standstill.

Publishing and sharing knowledge about these challenges is the way to get things moving. IBM has focused on open standards:

With the growth of cell phones and MP3 players, are we seeing a shift to aural delivery? Not necessarily. Quality is the key. What a blind user needs to hear is different from what a sighted person needs. You need to have a fairly high threshold of pain to deal with current voice software. The general user has a lower pain threshold and expects higher sound quality. An interesting aspect of the aural delivery idea is how the interaction and aural content might be managed to produce a distinct sound and feel, such as of a Nike shoes commercial site.

W3C Roadmap for Accessible Rich Internet Applications

Select photo for a larger view and description

Summary: The wide variety of ways data in pages are organized is a major obstacle in writing AT for rich Internet applications. A standard interoperativity contract between the Web application and AT is needed. The Roadmap for Accessible Rich Internet Applications identifies gaps that need to be filled. A review and update of guidelines, standards, and laws relating to accessibility will be needed as these new methods are developed and implemented.

Speaker: Rich Schwerdtfeger, IBM and W3C Web Accessibility Initiative

We are moving from the static document into the rich desktop experience. The Roadmap for Accessible Rich Internet Applications (ARIA) is a gap analysis aimed at providing plans and guidelines we can use to addressing the holes.

Accessibility of a graphical user interface (GUI) is about getting to the data, but everyone's data is organized differently. We need an accessibility application programming interface (API) that defines a standard contract between the Web application and the assistive technology which should include the following:

Keyboard accessibility is an example of the problems we face:

Work is underway to develop new standards for XHTML:

The goal is to provide information to map the content to the accessibility API, even as the content changes. As we see more distributed development of mashups, these standards could be built into the tools used to build them. The Dojo AJAX library (http://dojotoolkit.org/) is already including many of these ideas.

Part of the effort is to clarify best methods, such as in menus utilizing tabs only for the highest level and using arrow keys within the menu tree.

We need to address legislation relating to accessibility. Most of the legislation (WCAG1, 508) is based on 1998 browser technology and is rapidly becoming an obstacle to finding solutions. We need to focus on interoperability and usability, rather than try to exclude technologies. The IMS Global Learning Consortium accessibility specifications (http://www.imsglobal.org/accessibility/) are an example of what could done.

Resources on this topic include the following:

Management Panel: Policies, Practices, and Processes for Maintaining Accessibility

Select photo for a larger view and description

Summary: Recognizing the importance of accessibility in online education, process and procedures addressing it were built into course design, quality assurance, and instructor training. Instructors want to use more rich media. Evaluating sites is challenging as content is built with more technologies. Developers, excited about new technologies such as AJAX, can easily forget about accessibility.

Panelists:

Bill Corrigan, Director, Distance Learning Design, University of Washington Educational Outreach

Cheryl Hammond, Senior Applications Systems Engineer, Administrative Information Systems (AIS) Development, University of Washington

Wei-zhong Wang, Senior Information Processing Consultant, Division of Information Technology, University of Wisconsin-Madison

Bill Corrigan: When developing independent study programs, the question of accessibility came up. If someone identified a specific problem we would fix it. Then Sheryl Burgstahler gave us a presentation on accessibility, making it clear it was a lot easier to build Web sites that are accessible from the start, rather than go back and retrofit sites. As a result, Educational Outreach set up processes and procedures including improved Web skills, incorporating checking for accessibility features into the Quality Assurance process, and incorporating accessibility into the design process so that everyone would be talking about it, including the instructors.

A system of indicators was developed for evaluating distance learning education sites.

Wei-zhong Wang: University of Wisconsin-Madison, which has a resource center for students with special needs, has had a Web accessibility policy since 2001.

Cheryl Hammond: As a lead technical analyst for electronic research administration systems at the University of Washington, Cheryl has become passionate about accessibility.

Developers, enthusiastic about trying new technologies like AJAX, are frequently an obstacle to accessible design. Developers want to provide more interactive interfaces and quicker response time. What roadblocks are in the way between us and using new technologies?

Developers who work on internal and faculty applications can develop a false sense of security of only dealing with a limited audience. As we make ourselves more dependent on electronic technology, we are going to need to insure that our technology works for everyone now and for any people we may hire in the future.

Discussion: How can you evaluate accessibility?

When there are legal requirements, it is worth doing more work to fully understand why the requirements are the way they are. When federal money is involved, you should be 508 compliant.

How accessible is AJAX? .Net developers will be using Microsoft libraries, including ATLAS. Open source libraries are way ahead in terms of accessibility. The Dojo Toolkit (http://dojotoolkit.org/) is available and includes many accessibility features. Saying technology is not available is a punt.

Accessibility of Rich Adobe Applications

Select photo for a larger view and description

Summary: Current accessibility standards tend to push us toward text oriented content, but for many people, interactivity addresses how they learn. In rich media, label, role, state, and structure need to be provided for for good interaction between AT and content. Evaluating usability of rich media presents some puzzles, including control the time axis and notifying the user of content changes.

Speaker: Bob Regan, Adobe

The techniques for making rich Adobe applications accessible are easy. The hard part is getting developers to use the techniques.

In Web applications, single screen updates, diverse controls (buttons, sliders), and live data updates (constantly streaming data to the browser) can be difficult for someone using AT to follow.

When developing Web applications with technologies like AJAX and Flash (including Flex, a structured language for creating Flash content), we have a number of standards we can work with.

We be able to evaluate designs, we need a base set of assistive technology to test against. The disabled are not the only community we have to address, but designs must work for the blind community - that is a baseline requirement. Needs of the blind can be addressed with both audio and tactile interfaces.

Usability is an important question. A design feature can work in AT, but will anyone use it? Associating usability and accessibility is tricky. One site with 37 frames, each fed by a different data stream, followed standards, but will it make sense and be meaningful to the user?

One approach to accessible design is disability use cases:

Needs can be conflicting. For someone who is blind, the most accessible form of content is text. For a person with a cognitive disability, the least accessible form of content may be text.

If we prohibit interactive media such as Flash, we will be leaving a large group of people behind. Interactivity addresses how many of us learn.

Training developers about accessibility is challenging:

Successful development of accessible Web applications must address four characteristics of elements and objects:

Rich applications present some puzzles:

Designing RIA Accessibility: A Yahoo UI (YUI) Menu Case Study

Select photo for a larger view and description
Select photo for a larger view and description

Summary: Preserving opportunity and availability can be approached with three techniques; (1) standards based development, (2) redundant interfaces offering multiple approaches to content, and (3) designs that mimic functionality the user is already comfortable with. Menus can be built from unordered lists with display controlled by CSS or scripts, for example. AT that does not use the CSS or scripts can still access the information because its of simple, semantic structure.

Speakers:

Todd Kloots, Yahoo!

Doug Geoffray, GW Micro

Todd has been working on the menu bar in the YUI library. Menus are a basic way people navigate a site. The menu mechanism needs to be accessible for the site to work.

Doug is developing AT software and often gets calls from developers who want to do the right thing.

Libraries of tools provide a means to provide and support well thought-out methods of design. Yahoo! wanted to move to CSS layout but did not always have people with CSS layout skills. The solution was to develop a grid kit, available in the Yahoo! UI Library (http://developer.yahoo.com/yui/grids/).

Web 2.0 is about getting it right the second time. Now we have browsers that can support a range of standardized technologies (CSS, XHTML, XML, JavaScript). If we use the technology as designed (such as avoiding non-semantic class names) we can create evolvable platforms that preserve opportunity and availability.

One definition for accessibility is "a general term used to describe the degree to which a system is usable by as many people as possible without modification."

We can approach that kind of accessibility by using three techniques:

A bad practice is to think that Web 2.0 means you can throw out all we have learned about accessibility.

With these techniques in mind we can look at how menus should be made in Web technology.

The list approach goes "with the grain" of web technologies and results in pages that are truly available to all. What we create is likely to be out there a long time. It is important to do things right from the beginning.

Redundant interfaces offering multiple means of input make possible flexible interactions. A user can have the choice of GUI or command line input, text fields can have the option of auto complete, and support can be provided for tab and arrow keys. This an example of progressive enhancement:

Semantic markup makes content portable. Progressive enhancement allows for the development of redundant interfaces that give users a choice.

Redundant interfaces are better for everybody. The keyboard is as important as the mouse. Users can choose among multiple task flows. The approach is limited by insufficient communication with accessibility APIs on the desktop at present. While it can require development of two experiences, it does not necessarily require twice the effort and can benefit the development process.

Design that is faithful and predictable to the desktop experience has greater learnability and discoverability. Completeness is critical to preserve the illusion of consistency between the desktop and the Web application.

The WAI-ARIA roles and states utilize a powerful and well-understood desktop accessibility API, providing a standard and predictable enrichment of markup.

The benefits of this approach are more options, better discoverability, better usability, and support of many working styles. Drawbacks are that it is not easy, seems heavier and more complex, and is not the path of least resistance.

Group Discussion Summaries

Throughout the CBI, participants met in small groups of up to 8 people and engaged in discussion surrounding particular questions posed by CBI organizers. The following is a summary of the key ideas generated by these discussions.

Select photo for a larger view and description

Question #1: What are the most important issues in maintaining accessibility of the web as we use rich media?

First, what do we mean by rich media? One group listed examples, including Adobe Flash, DHTML, AJAX, video, audio, and essentially anything non-static. Another paraphrased the AccessIT article "What is rich media and how can I learn more about its accessibility?":

...a broad range of digital interactive media ... can be downloadable or embedded ... exhibits dynamic motion ... may occur over time or in response to user interaction, e.g., streaming media, stock ticker, slide show with user control, animated interactive presentation file.

(Derived from : http://www.washington.edu/accessit/articles?146 )

The following are key concepts that emerged as important issues:

Graceful Degradation

A website can be designed with contemporary features for those users whose technologies support these features, but the site should still work - and content should be accessible - to users with non-supporting technologies. "Backwards compatibility" is a related concept.

This can be accomplished in part by:

Reusable, Accessible Content

This was a common theme throughout the CBI, and was the focus of multiple presenters as well as group discussions. The emerging web may require less hand-coding, and may instead be built by assembling applications from libraries of plug-and-play widgets. It is therefore critical that these widgets be developed with accessibility in mind.

Overall Design Approach

Suggestions made by participants include the following:

Accessibility Standards

Discussion about standards focused on support for existing standards, as well as the need to continue work toward creating new standards. Some points brought up by participants are:

Evolving Assistive Technology

Comments by participants included the following:


Developer Tools

Comments by participants included the following:

Education, Motivation and Incentives

Comments by participants included the following:

Select photo for a larger view and description

Question #2: What are the first steps to take and what are specific roles (for webmasters, educators, administrators, institutions, vendors, government entities, standards organizations, consumers, etc.) in assuring the accessibility of the emerging web?

Comments by participants included those listed below.

Educators

Web Developers

Web Managers

Higher Education Administrators and Institutions

Standards Organizations

Web Authoring Tool Developers

Assistive Technology Vendors

Browser and Operating Systems Vendors

Advocacy Agencies

Consumers

Government

DO-IT

Anyone Who is Interested

Everyone

Select photo for a larger view and description

Question #3: What are policies, practices, and processes for assuring accessibility of web resources within an institution, department, or other organization?


In this discussion, groups recommended a variety of approaches to influencing web accessibility in higher education institutions. Some favored a directive top-down approach such as an institutional policy, but the majority seemed to favor an approach that stresses encouragement, engagement, and education. Comments by participants included those listed below. Ideas are organized by area of emphasis.

Emphasis on Policy

Emphasis on Encouragement and Engagement

Emphasis on Accessibility as a Service

Emphasis on Commitment of Resources

Emphasis on Universal Design

Emphasis on Departmentalization of Accessibility Efforts

Overall process

One group offered the following four steps in developing and implementing web accessibility policy:

  1. Create: get the policies in place.
  2. Expand awareness: Have emissaries. Attain buy-in among deans, other department heads, institutional leadership.
  3. Make accessibility a marketing/branding requirement, i.e., in order to use the logo or official seal, accessibility policies must be satisfied.
  4. Enforcement: Ultimate authority to pull a non-accessible page.
Select photo for a larger view and description

Question #4: What are some mechanisms for enforcing web accessibility?

Comments by participants included those listed below.

Select photo for a larger view and description

Question #5: How do we support emerging technologies without sacrificing accessibility?

Comments by participants included those listed below.

Multiple parties expressed frustration that a lack of education, time, and money make creating accessible technologies particularly challenging.

Regarding education: Web developers need help. They need access to knowledgeable accessibility experts, available to troubleshoot.

Regarding time: Web developers only have time for client demands. They need tools that will create accessible content automatically, and well-designed reusable content libraries with documentation and examples. They also need tools that will efficiently and effectively check accessibility.

Regarding money: They need support from their administrations to hire sufficient staff, and to purchase multiple assistive technology tools for testing.

Select photo for a larger view and description

Question #6: What do you need to efficiently and reliably create web interfaces?

Group responses to this question tended to fall into one of two categories: Intrinsic needs over which they (individuals or teams) had some direct control, and extrinsic needs which require action on the part of some other party. Comments by participants included those listed below.

Intrinsic Needs

Extrinsic Needs

Educational
Standards
Libraries, Tools and Resources
Support

Conclusion

As higher education institutions begin to utilize rich media technologies (Web 2.0), accessibility is simply one of many issues to consider in ensuring that content and services are deliverable to the full range of audience members. There is considerable promise for accessible rich media, but there is also much work to be done. Methods are currently being developed to allow assistive technology to work well with Web applications, and assistive technology is being improved to utilize and support these new methods. Full support by all players (operating systems, browsers and other user agents, authoring tools, and assistive technologies) is critical. Web designers and developers also play a critical role, and in order to develop accessible applications, they need training and support, authoring tools and reusable code libraries that support accessibility, and objective methods for evaluating the accessibility of rich media. Improved standardization among assistive technology products would also make full accessibility more attainable.

This CBI is an example of the kind of "bringing together" of perspectives that will be needed to orchestrate the many aspects of this challenge into effective, reliable, accessible Web applications we can all use.

Further Communication and Discussion

CBI participants are encouraged to continue collaborating with one another through the AccessWeb discussion list (http://www.washington.edu/doit/Resources/accessweb.html). To subscribe, enter your email address and name in the appropriate fields on the AccessWeb Info Page. This list fosters ongoing discussion about accessible website design, management, policy, and practice. It is open to anyone with an interest, but was particularly established as a means of fostering communication and collaboration on web accessibility among higher education entities in the Northwest region of the United States. The list is supported by the Northwest Alliance for Access to Science, Technology, Engineering and Math (AccessSTEM) at the University of Washington.

More information about encouraging people with disabilities in STEM fields, consult http://www.washington.edu/doit/Stem.

DO-IT
University of Washington
Box 355670
3737 Brooklyn Ave. N. E.
Seattle, WA 98105
doit@u.washington.edu
http://www.washington.edu/doit/
206-221-4171 (FAX)
206-685-DOIT (3648) (voice/TTY)
888-972-DOIT (3648) (toll free voice/TTY)
509-328-9331 (voice/TTY) Spokane
Director: Sheryl Burgstahler, Ph.D.

Acknowledgement

This capacity-building institute was funded by the National Science Foundation through AccessSTEM (cooperative agreement #0227995). The opinions expressed in this document are those of the authors and do not necessarily reflect those of the National Science Foundation.