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: AccessIT)

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?

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

• 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, so...
• We need support from knowledgeable people.