Proceedings:
Web Accessibility Capacity Building Institute

November 29 - December 1, 2006
Hotel Andra, Seattle

• Contents
• Agenda
• CBI Participants
• Presentations
• Group Discussion Summaries
• Conclusion
• Further Communication and Discussion

The Web Accessibility Capacity Building Institute (CBI) was funded by the National Science Foundation (cooperative agreement #0227995) through The Northwest Alliance for Access to Science, Technology, Engineering, and Mathematics (AccessSTEM), which is directed 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:

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

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

• 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

10:00
Break

10:15
Working group discussions:

• What are policies, practices, and processes for assuring accessibility of web resources within an institution, department, or other organization?
• What are some mechanisms for enforcing web accessibility?

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

• Facilitated discussion
• Action planning
• Moving forward
• Future collaborations

11:30
CBI Evaluation
Box lunch and further discussion

CBI Participants

Speakers

• Bill Corrigan, University of Washington Educational Outreach
• Bob Regan, Adobe
• Cheryl Hammond, University of Washington
• Doug Geoffray, GW Micro
• Richard Schwerdtfeger, IBM/World Wide Web Consortium (W3C)
• Todd Kloots, Yahoo!
• TV Raman, Google
• Wei-zhong Wang, University of Wisconsin-Madison

Particiants

• Adam Graffunder, University of Washington
• Bill Corrigan, University of Washington Educational Outreach
• Bob Regan, Adobe
• Brendan Sweeney, University of Washington
• Carolyn Gardner, ViewPlus
• Charles Munat, University of Washington
• Cheryl Hammond, University of Washington
• Chris Concannon, Clark College
• Cecilia Kremer, University of Washington
• Dan Comden, University of Washington
• Doug Geoffray, GW Micro
• Erin Tidwell, University of Washington
• Gina Hills, University of Washington
• Kerstin Goldsmith, Adobe
• Jeffrey Bigham, University of Washington
• Jeffrey Burnett, Washington State University
• Jelena Curless, University of Washington
• Jill Yetman, University of Washington
• Joe Winton, Washington State University Vancouver
• John French, University of Alaska Southeast
• John Gardner, ViewPlus
• Juan Ulloa, Bellevue Community College
• Kei Wakabayashi, Bellevue Community College
• Kevin Pittman, University of Washington
• Luis Menchu, Portland Community College
• Marie Raney, Western Washington University
• Mark Bilodeau, Green River Community College
• May Zhang, University of Washington
• Michael Richardson, University of Washington
• Patrick Michaud, University of Washington
• Richard Schwerdtfeger, IBM/World Wide Web Consortium (W3C)
• Rick Ells, University of Washington
• Rita Johnson, University of Washington
• Sangyun Hahn, University of Washington
• Sheryl Burgstahler, University of Washington
• Terry Thompson, University of Washington
• Todd Kloots, Yahoo!
• TV Raman, Google
• Wei-zhong Wang, University of Wisconsin-Madison
• William Washington, University of Washington

Planning Team

• Ashley Ingersoll
• Dan Comden
• Doug Hayman
• Lisa Stewart
• Marvin Crippen
• Michael Richardson
• Rick Ells
• Sheryl Burgstahler
• Terry Thompson

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

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:

• Retain at least the present level of access to functionality for people using AT
• Increase the reach of people using AT by enabling a wider range of forms of access
• Enable access in more user contexts
• Enable people with disabilities to use any machine with access to the network, not just the machine with their AT on it.

The building blocks of access are the following:

• Content: Content includes adequate semantics
• User Interface (UI): The UI degrades gracefully for less capable technologies.
• Assistive Technology (AT): AT is designed to bridge the gap between the Web application and the user.

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

• What to speak can be addressed by rich markup of Web content so that every chunk of text has a role. Separating content from presentation helps to better management content and to structure content to reflect its role.
• How to speak can be controlled through aural styles.
• When to speak can be addressed with event handlers, which will hear the event and respond accordingly.

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

• Data resides on the network.
• Interaction resides in the client.
• HTTP operations can be done any time to synchronize data.
• Browser widgets create the user interface (UI).
• Applications, instead of being single monolithic programs on the local computer, can be chopped into pieces, some on the servers, some on the client.
• AT dynamics are no different from mainstream Web technologies.
  

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

• The UI is realized through Web pages.
• HTML for creating content.
• CSS for styling.
• DOM eventing for adding behavior
• Exposes client-side interaction logic.

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

• Interfaces no longer need to be "one size fits all."
• User interactions can be optimized to user's needs.
• Multiple UIs can collaborate.
• APIs made available by services like Google can be used to place the service in a wide range of contexts.

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

• A new market is appearing for consumer applications.
• Custom services can be tailored to end-user needs.
• Task-driven access tools can be built.
• The new AT will be so light-weight and simple it can be quickly built and easily changed.
  

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

• Light-weight Web APIs.
• Atom/RSS based syndication
• AJAX APIs for hosting services (Google Maps, Google Calendars)
• Syndication of data sources to customer UI

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

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:

• Took design issues to the World Wide Web Consortium (W3C).
• Worked with FireFox, including donating code.
• Worked with Linux.
• Avoiding working with any one company.

W3C Roadmap for Accessible Rich Internet Applications

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:

• role
• state
• actions
• caret
• selection
• text
• hypertext
• value
• name
• description

• In current XHTML, only anchors and form fields accept focus.
• We need better ways to manage tabbing.
• Pop-ups are often not keyboard accessible.
• It is hard to know what a link is for.
• Navigating to items within a page often requires navigating through the entire page.
• AT companies like GW Micro have to guess what contract elements are being used and how they are defined.
  

Work is underway to develop new standards for XHTML:

• Extending XHTML through namespaces to define new states and properties.
  • Checked, expandable, selected, does this object control another object
  • Tabindex property that can apply to all elements in a document
  • Typical widget states
  • Relationships (describedby, controls, flowto)
  • AJAX properties ( live, relevant, atomic)
• Provide a role attribute in the XHTML namespace for identifying roles of elements.
• An ARIA role model including common landmarks (navigation, search, main, secondary, note, seealso)

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:

• W3C Protocols and Formats Working Group - ARIA Roadmap (http://www.w3.org/WAI/PF)
• University of Illinois Accessibility Extensions (http://firefox.cita.uiuc.edu/dhtml/download.php)
• WAI Role Taxonomy Extension Tool (http://test2.ubapps.com/RolesWebApp/roles/start)

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

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.

• The site should communicate about accessibility, stating the intention to make it accessible.
• Accessibility is worked into the checklist for developing courses to ensure that everyone knows that accessibility is a goal of the department.
• Accessibility is addressed in the guidelines to instructors, stating the accessibility is a priority.
  • Making HTML pages accessible is the easiest.
  • Course developers are moving toward using less HTML and more rich media like Flash. Instructors are creating content themselves using tools they are familiar with.
  • Everyone involved is trying to reduce the time it takes to produce material.

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.

• A Web doctor evaluates Web sites before they are finalized. Common situations are database driven pages with tables layouts, missing labels in electronic forms, frames and iframes with no labels, and complex Javascript. Many sites do not meet campus policy but work with screen readers.
• Every application must be accessible
  • Accessibility testing is required.
  • Working to move it to the top of the list of checkpoints.
  • Language about accessibility is being added to the software procurement process and documents.
• Updates and upgrades can be a problem. The original design may be accessible, but updates add complexity that may break accessibility.
• It is hard to ensure accessibility of imported content.
• Streaming media service has been offered for several years, but explaining how to make 508 compliant videos can be a problem. The current system uses MagPie to do captioning and can be time-consuming.
• Podcasting use in teaching and learning is growing. To get grant money, a plan on how you will make your content accessible is required. Services are provided on and off campus to do captioning.
• eTeach, a rich media authoring environment, is being used to do online courses. In eTeach, slides and TOC links automatically synchronize. Control buttons work with Home Page Reader and JAWS.
• Library electronic resources include a large number of PDF files, both images and text readable. A quick scanning service makes possible timely availability. If requests for better accessibility to a file are received, the instructor deals with it.
• Wisconsin Historical Society has joined the Google Book Project, but so far it is not very accessible. Meetings are underway with the University of Wisconsin-Madison, the National Federation for the Blind, the Daisy Consortium, and others on the topic.
• Spam getting in through Web forms has been a problem. Some sites are using a simple "add two integers" task to test whether a page visitor is a person or a robot. So far no robots have gotten through the task.
• Page authors are encouraged to ensure screen shots and images are enhancements and that the text makes complete sense by itself.
• Database driven content is being done in ways that allow multiple modes of output for different access devices.

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?

• At UW-M, evaluation is based on the 508 standard. Initially, online tools were used, although most applications are behind an authentication mechanism. Pages are also manually checked, tested by persons with disabilities, and the page code examined. If possible, the developer shadows the tester during the tests.
• At UW Educational Outreach, evaluation tools are used but are not relied on exclusively. It is necessary to go through the pages conducting tests, such as of tab keys. When new designs are developed, time is scheduled at the Adaptive Technology Lab to test them on AT software. Videos are difficult. Efforts are being made to build captioning into the budget when getting grants for videos. Requiring a script be created before doing voiceover provides that can then be offered as alternative text.

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

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.

• The World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) are getting old and tend to push us toward approaches like graceful degradation.
• Interoperability standards from several sources. These are all in motion:
  • Microsoft Active Accessibility (renamed UI Automation in Vista)
  • DOM-based mapping to MSAA
  • ATK-Linux
  • MacAccessibility API
  You can follow these standards and still be inaccessible.

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:

• A person who is blind.
• A person with a mobility impairment (someone who can use the mouse but who has trouble with small targets).
• A person with low vision (requires a screen magnifier).
• A person who is color blind.
• A person who is deaf (need captioning for audio and video).
• A person with a cognitive disability. This may be the largest and most complicated group and we have no checklist on how to address cognitive disabilities.

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:

• Many developers have been groomed to think visually. When asked to step outside the visual approach, they are lost.
• Ask developers to use a screen reader an hour a day. Leave the monitor on so they can track what the voice browser is reading. Most people take about six weeks to develop an intuition of what is usable and accessible.
• Include people with disabilities in the process of designing and evaluating designs. Be sure to budget money to pay them. You cannot just exploit the blind to make your applications better.

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

• Label: What is this thing? The label differentiates repeated instances of the same control. Every control should have an associated label. Labelling puts the user in charge.
• Role: What does this thing do? The screen reader user should know what every control does, including correct identification of buttons, and identification of controls emulating standard Windows controls. Unusual controls should provide cues to users as to their identification, operation, and state.
  • For a standard set of roles to work, you need many developers to use them. Developers often do not want to stick to standards, but without the standards there is no way to make a predictable experience for AT. Managers need to tell developers to stick to the provided options. The Roadmap now defines 43 roles.
  • As roles become standard and common, we want to include them and figure how they will work for AT.
• State: Is this thing on or off? Managing state is easier in more structured languages, such as in Flex. Flash can manipulate the time axis, which presents some interesting problems dealing with information changing over time.
• Structure: How are things connected? How do things relate to one another? With RIAs, often changing something in one part of the application can changes in another part of the application.

Rich applications present some puzzles:

• Managing a list: A list can be visually presented with Flash as a series of graphical objects and the means made available to manipulate the objects, but how much information should be made available to the screen reader? WCAG2 is weak on the notion of the relationship between controls. The responsibility for saying what has changed belongs to the object that has been changed - it is the only one that knows of the change.
• Screen updates: How do you let someone know a change has occurred on the screen? Does the user want to be interrupted and notified of an event even when doing something else?
• Time access: A blind user will want to be able to take control of the time axis, such as by tabbing to the next time increment. When you are interacting with video or audio, such as in a game, you want control of time.

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

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:

• Standards based development.
• Redundant interfaces (giving the user options).
• Faithful and predictable ports. When developing something new, mimic things in the user's comfort zone.

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.

• Menus are lists and are often hierarchical. Menus can easily be implemented as unordered lists.
• The list may have separators within it indicating sets within the list. The separator can be a style property used in the list.
• Headings can be hx elements between lists

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:

• For browsers with no Javascript support, or where users have turned off Javascript, the YUI content, based on semantic markup, is still meaningful and the menu hierarchy is still well represented.
• Browsers with support of CSS and Javascript transform the experience without sacrificing the content. Functionality such as skipping steps in menu hierarchies becomes possible.

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

• Keyboard navigable DHTML widgets can be built using tabindex (see Key-navigable custom DHTML Widgets at http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets)

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.

• In constructing menus, pressing Esc should hide the menu, up and down arrow keys should move you up and down menu items, right arrow should expand a submenu or move you down the menu (if no submenu), and the left arrow should collapse a submenu or move you up the menu (if not in a submenu).
• Use relative font sizes to ensure created and inserted text matches its surroundings.
• Position menus within the viewport to avoid the need for scrolling.

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.

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:

• Assuring that navigation and other critical content is left out of rich media.
• Start with a standards-compliant document, and assure that long-standing accessibility standards are followed, such as providing text alternatives to video content, providing alternate text for visual elements, assuring proper tab order, providing labels on form elements, providing a good heading structure, etc. If needed, supplement this core, well-structured document with rich media as a non-critical enhancement to the user interface.
• Separation of content and structure from presentation: If content is made accessible through proper design that encodes semantics within the visual design of the page, where elements are not wasted just to be pretty, then the design may be accessible by default. Content should still be accessible without the presentation layer.

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:

• Don't let technology dictate content. Design should happen the other way around.
• Focus on true core goals. What is the function of the website? What are you trying to accomplish? What message is being communicated? Who are the target users? Only after answering these questions, then determine which tools and technologies are needed to accomplish the site's goals for the target audience.
• Regarding target audience: Consider whether content needs to be accessible to all users. For example, some content may be purely visual in nature, and it may not be necessary to make it accessible to a blind user. However, be careful to avoid using this as an excuse. Some applications (e.g., maps) may seem to be purely visual in nature, but if created well these applications might have plenty of good information to offer non-visual users.
• Design for accessibility at the start of the project. Even if you don't put in all accessible features, design so you can add them easily later
• Conduct usability testing. Developers need access to screen reader users and other users with disabilities to include in usability tests.
• "Keep it simple". This is challenging given that emerging rich technologies are inherently not simple. Reusable code may simplify the design process, but as mentioned above the reusable code needs to be accessible.

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:

• Browsers need to do a better job of supporting existing standards.
  

• Browsers need to be more timely in their support of new standards.
  
• Standards are needed for indicating relative importance of specific content. For example, in most applications it is unimportant for a digital clock to communicate each time a second changes. This is the type of problem that is being addressed by Rich Schwerdtfeger and the W3C WAI Protocols and Formats Working Group (e.g., in the "Roadmap for Accessible Rich Internet Applications"). However, the fact that only Firefox currently supports these efforts reinforces the previous bullet regarding timely support from browsers.
• There needs to be improved standardization among screen readers (perhaps assistive technology industry standards?), or at least better/more consistent support for existing W3C standards.
• Designers would benefit from having guidelines for developing style sheets specifically for certain populations, such as low vision users, seniors, or users with learning or cognitive disabilities. This would be challenging since there are many individual differences within these categories, but is worthy of consideration.

Evolving Assistive Technology

Comments by participants included the following:

• The economics of assistive technology companies is an important issue. AT developers are faced with difficult challenges supporting a web environment that is becoming more and more complex. How will they get paid for doing so?
• Perhaps it's more practical for mainstream technology to become more universally multi-modal. How do we develop AT so it is useable by the masses? Or, how do we develop mainstream user interfaces that are fully usable by everyone, including those with specialized needs?
• Improving handling is needed of graphically displayed information, such as math, diagrams, and charts. For example, tactile interfaces should be usable in conjunction with graphical displays

Developer Tools

Comments by participants included the following:

• Software tools used in developing websites must do a better job of supporting accessibility. Designers should be able to create accessible content without prior skills or knowledge about the process. This should either happen automatically, or users should be prompted and/or guided in creating accessible content.
• Better, more accessible remote collaboration tools are needed. This would allow accessibility experts to better collaborate on developing accessible tools and content.
• Better tools for objectively evaluating accessibility are needed.

Education, Motivation and Incentives

Comments by participants included the following:

• We need to improve awareness of accessibility among developers, and increase training opportunities.
• We need to promote best practices
• We need to come up with ways to encourage users to caption videos in near or real time, perhaps by providing rewards or incentives for those who take the time to do so. Hopefully someday technology will be able to do this automatically, but we're not there yet.

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

• Work with Webmasters to keep their sites up with current technology and accessibility standards.
• Educate their students regarding accessibility, and how accessibility fits within design processes
• Get up to speed with compliance requirements.

Web Developers

• Get up-to-date with current technology for web publishing and work with administrators and educators to assure that sites are accessible.
• Recognize the variety of user characteristics that comprise their audience, and design with these differences in mind, rather than with some limiting view of "normal" in mind.
• Begin immediately to practice accessible design techniques:
  • Follow standards
  • Use semantic markup
  • Start with a solid document structure
  • Avoid events that require the mouse
  • Be sure functionality is available from the keyboard (without using the mouse)
  • Avoid use of proprietary technologies such as Flash for presenting essential content
• Take the initiative and help make sure that policies are followed.
• Clean up existing structure so when new stuff comes on board, it can plug in to an accessible framework. This will also make the old stuff closer to being compliant.
• Start developing accessible reusable widgets and plug-ins. Contribute to existing open source libraries. Get involved.
• Choose the right technology for the job. Don't use a specific technology just for the heck of it as it may hinder accessibility.

Web Managers

• Provide guidance, constructs and support tools that help with accessible design.
• Give accessibility priority.
• Define the level of accessibility we are shooting for. Is Section 508 compliance enough, or do we need or want to go beyond?
• Create policies, procedures and guidelines for developers to follow.
• Review existing procedures to be sure they include accessibility as forethought, rather than afterthought.
• Meet with team or workgroup and articulate goals and methods with respect to accessible web design. If policies, procedures, and guidelines have been developed, educate my team on these policies, procedures and guidelines.
• Gather current information on efficient methods for evaluating web accessibility. Figure out how to test for our target level of accessibility compliance.
• Evaluate and recommend tools (editors, QA applications) to help content developers improve accessibility, and to automate the process of testing for accessibility.
• Adopt procedures for usability /accessibility testing — even if this can be implemented in a small way, with one or two users, it's better than no testing at all.
• Work with my developers to help them to:
  • Begin to think of their audience as including users other than "standard" users (i.e., mouse and monitor users).
  • Better understand the role of semantic markup in accessible web design
• Encourage accessibility by establishing a policy whereby help and other services are provided in exchange for clients' transitioning to new standards.
• Continue to work with administrators in pursuit of sufficient time and resources to get the job done right.

Higher Education Administrators and Institutions

• Make accessibility a priority and hold their team(s) accountable.
• Commit resources to accessibility.
• Commit resources to raising awareness.
• Develop a policy and/or guidelines related to web accessibility
• Provide tools to support creation of standards-compliant and accessible sites for those not interested in technical side of web publishing.

Standards Organizations

• Create clear consistent and timely standards.
  
• Get the job done more quickly (not just developing standards, but seeing through to their adoption and support). Court or influence vendors to help them standardize.
• Anticipate new technologies by creating standards BEFORE tons of content is created.
• Offer more tutorials and more outreach to get the word out. Specifically, build curriculum for educators to use in educate their students (and themselves)

Web Authoring Tool Developers

• Embed guaranteed accessibility into web development tools, with more documentation and examples.
• Integrate stricter accessibility requirements without sacrificing ease-of-use.
• Make accessibility a priority and supply well-tested components that help lower the barrier to entry.
• Develop according to standards, and produce content that complies with standards.
  
• Adobe: Flash and Flex need to better support accessibility for custom widgets. The ARIA specifications can help FLEX but the Flash player and tooling must be more amenable to support custom accessible widgets. Most people who use Flash create custom UI components.

Assistive Technology Vendors

• Work together to push for AT industry standards. AT vendors should not have to create specialized product-specific environments, which is problematic and timely. Set aside competition and work together to attain a common underlying framework. Competition can occur at higher levels (user interface, support, etc.)

Browser and Operating Systems Vendors

• Increase market share by working with standards organizations (i.e., build a better, more reliable, standards-compliant product), rather than by trying to kill competitors.
• Microsoft: Provide a rich Windows accessibility API to help Flash and other technologies to more fully support accessibility.

Advocacy Agencies

• Set aside differences and work together. Competition and politics between these agencies ultimately harm progress.
• Help vendors to see that accessibility has mainstream marketing benefits.

Consumers

• Put more pressure on web developers etc. In most cases consumers with disabilities don't speak up and just live with the inaccessibility or put the burden on the AT company.

Government

• Section 508 is great for federal government purchases but doesn't help other applications. However, more legislation isn't realistic. Tools must be provided before demands can be made.
• Provide funding or incentives in addition to mandates.

DO-IT

• Continue to develop lists of promising practices

Anyone Who is Interested

• Hold a brown bag luncheon on where we are now with regards to accessibility, and raise questions about where we need to be and how we're going to get there
• Create "Captipedia" (or something similar) - an online community of people dedicated to captioning multimedia. Let the masses address the problem of uncaptioned multimedia resources. The community will make the decision of which resources are highest priority.

Everyone

• Continue the struggle to shift the dominant culture in the direction of awareness.
• Encourage end users to complain or advocate with stronger voices for accessibility
• Raise the level of accessibility awareness among administrators. Establish a procedure for getting the ear of top administration.

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

Emphasis on Policy

• Projects should be required to include accessibility in their design process.
• Pick a standard and follow it. Code to standards, Follow usability guidelines, but be aware that is all they are.

Emphasis on Encouragement and Engagement

• The POV of Enforcement of Law creates adversaries and an approach of encouragement and engagement creates good will.
• Start with the assumption that people inherently want to do the right thing, and use education to help them do it. Telling people if they don't implement web accessibility then they are bad people doesn't seem to work.
• Attract people by making accessibility fun. Offer awards for best accessible designs, organize inter-collegiate accessible design competitions, such as those organized by Knowbility.org.

Emphasis on Accessibility as a Service

• Providing an infrastructure of services may be the best way to address accessibility practices. For example, making a good, rapid-turnaround captioning service available may achieve much higher compliance that hassling people for not having captions.
• Institutions may benefit from a centralized accessibility testing program, staffed by accessibility experts who test web sites and applications, and provide help and consultation to web developers.

Emphasis on Commitment of Resources

• Accessibility is a manpower/implementation issue. Administrations may say accessibility is important, but there are no resources dedicated to having this happen. It is a question of priority.

Emphasis on Universal Design

• When campaigning for improved accessibility, stress the benefits for everyone - it isn't just about people with disabilities. For example, reducing use of graphics through CSS reduces download time; using good heading structure improves search engine placement; adding closed captions makes videos searchable. However, it's equally important that these benefits don't trump accessibility considerations. For example, speech recognition may already be accurate enough to produce searchable text for videos, but the accuracy isn't high enough to meet the needs of people who are deaf or hard of hearing.

Emphasis on Departmentalization of Accessibility Efforts

• For large organizations it might be more successful to focus on web accessibility at a departmental level or small groups. Trying to change a large campus would be very difficult.

• Start with awareness. Each division could be responsible for evangelizing accessibility in their own areas. Computing & Communications at University of Washington has done work in this fashion with unit mission statements - could do the same with accessibility.

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.

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

Comments by participants included those listed below.

• A policy must have a mechanism for enforcement. Otherwise, it carries no weight.
• Education must proceed enforcement, and accessibility must be defined in a way that is objectively measurable, and tools/services for accessibility testing must be readily available. Otherwise, how do you enforce a policy if departments don't know if they are compliant?
• It might take a lawsuit before campus administrators take accessibility seriously. Perhaps a ripple affect from the Target lawsuit (depending on how it is decided). Administrators must be convinced that it is not cheaper or better to wait until that happens.
• An administration with an accessibility policy must be willing to enforce it. Provide ample opportunity for web developer or author to address accessibility concerns, then maybe pull the page? Maybe rebuild the page?

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

Comments by participants included those listed below.

• By developing with well-established industry standards. In addition to supporting accessibility, this also helps to bring down the learning curve of new staff.
• By developing and using standards-based templates.
• By building ongoing testing into the process.
• By reaching consensus on what the projects goals are
• By determining where the responsibility lies, and get past the "finger-pointing" stage

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.

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

• We need to include accessibility in the design process. It is not necessarily expensive or time consuming to address accessibility when designing an interface. However, retrofitting an existing one is another story.
• We need a structured, yet flexible process for developing accessible applications, with milestones that ensure all the necessary steps are taken.
• We need a consistent "big picture" view or strategy for incorporating accessibility into the design and development process.
• We need consensus within teams about what we want, with clear goals.
• We need skilled people, a good team.
• We need to have access to expertise when needed.
• We need to provide education and promote awareness

Extrinsic Needs

Educational

• We need education, time and money. Events like this CBI give us the knowledge needed to give us the leg up.
• We need education on how the browser works; how screen readers work; and how the various web technologies render in different platforms, operating systems, and versions of each.

Standards

• We need attainable accessibility standards, and we need support for those standards by all players. Where is the responsibility? Browsers? AT software? Even operating systems all have an impact. Not being able to count on a single solution working across the variety of browsers is frustrating.
• We need assistive technology industry standards. Lack of consistency across AT software, and across different versions of any one AT product, will always be an accessibility challenge due to the exorbitant price new versions demand. An enormous variety of AT tools are being used, and they all behave differently.

Libraries, Tools and Resources

• We need well-designed libraries that can be reused, and that will help us to avoid common pitfalls and redundant development efforts.
• We need libraries that include documentation so developers know how to use them, and guidelines with examples
• We need web authoring tools that automate accessibility to whatever degree this is possible

Support

• We need support from our administrations, in order to implement many of the ideas listed above. Sometimes we won't get that.
• We need support from knowledgeable people.

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.edi/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