Making The Web Accessible

Leading the Web to its full potential.

Good design is accessible design

This talk will be available online from next week:

http://www.w3.org/Talks

Overview

• Why accessibility?
• W3C and WAI
• Principles of accessible design
• Quick Tips, Guidelines and more
• Fix this! - a sample site
• Resources to get started
• Questions.

I. Why Accessibility?

1. People
2. Design
3. Market
4. Law

People: Doors opened by the Web

• Web is fastest-adopted technology in history
• Displacing traditional sources of information and interaction
• Web is becoming a key resource for:
  • news, information, commerce
  • classroom education, distance learning
  • job searching, workplace interaction
  • civic participation

People: Access for all

People: Barriers to Access

Many users may be operating in contexts very different from your own:

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
• They may have difficulty reading or comprehending text.
• They may not have or be able to use a keyboard or mouse.
• They may not speak or understand fluently the language in which content is written or spoken.

Design: Functional Requirements

Similar functional requirements for able-bodied users in other environments:

• Eyes-busy/Hands-busy environment: voice output
• Noisy/Silent environment: captioning.
• Low bandwidth: alternatives to images, video, etc.
• Voice browsing: voice input/output
• They may have a text-only screen, a small screen, or a slow Internet connection.
• They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.).
• Mobile access: limited screen area, screen magnifier

Design: Device Independence

• Device-independent design is accessible/universal design.
• Separate structure from presentation and reach mobile devices, Web-TV, kiosks, search engines, etc.
• Different learning styles; low literacy levels; second-language access
• Easier site maintenance (e.g., style sheets shared, caching).

Design: Graceful Transformation

Market

• 10-20% of the population in most countries have disabilities. Some affect Web access.
• Temporary disabilities such as RSI, holiday accidents can affect a very small company.
• Aging populations (lower vision, hearing, mobility).
• Lots of mobile access users to come!

Law

Refer to WAI Policies Reference list.

• Australia
• Canada
• Denmark
• France
• Ireland
• Portugal
• United Kingdom
• United States

II. W3C and WAI

• World Wide Web Consortium (W3C)
  • an international, vendor-neutral consortium, 400+ Members
  • promotes evolution & interoperability of the Web
  • hosted by MIT, INRIA, Keio
• W3C hosts the Web Accessibility Initiative (WAI)
  • partnership of industry, disability organizations, access research centers, government
  • major sponsors include: US, European and Canadian governments, IBM/Lotus, Microsoft, Bell Atlantic

What WAI does

1. Accessibility Guidelines:
   • Web Content: What is accessible content?
   • User Agent : What is accessible user agent?
   • Authoring Tool: What authoring tool is accessible and produces accessible content?
2. Review W3C specifications for accessibility
3. Evaluation and Repair Tools
4. Education and outreach: Quick Tips, Movie, ...
5. Coordination of Research

III. Principles of Accessible Design

Principles that appear in all three Guidelines:

• Device independence (input and output)
• Graceful transformation
• Alternative equivalent and Metadata
• Context, Orientation, and Notification
• Navigation
• Documentation

Techniques are implementation suggestions, issues, and language-specific details

Standards and conventions:

• Allow assistive technologies access
• Interoperability promotes accessibility
• Validate or Crash-and-Burn: Don't ignore important information (ecommerce, contracts, medical decisions).
• Credible design: Well-written pages build confidence in content.
• Innovate new functionalities, but use standard channels since people and tools rely on them.

IV. Quick Tips, Guidelines and more

WAI produces a range of materials

W3C Recommendations

"Technical standards". The Guidelines

Reference Notes

Discussion papers on specific technologies - CSS, SMIL, ...

Education materials

Quick Tips, flyers, Curriculum ...

Education resources

Getting started, Policy reference, ...

The Quick Tips

• Images & animations. Use the alt attribute to describe the function of each visual.
• Image maps. Use client-side MAP and text for hotspots.
• Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
• Hypertext links. Use text that makes sense when read out of context. For example, avoid "click here."
• Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
• Graphs & charts. Summarize or use the longdesc attribute.
• Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
• Frames. Use NOFRAMES and meaningful titles.
• Tables. Make line by line reading sensible. Summarize.
• Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WAI-WEBCONTENT.

Web Content Accessibility Guidelines

http://www.w3.org/TR/WAI-WEBCONTENT

• W3C Recommendation, WCAG 1.0
• Has a companion Techniques document.
• Explains to Web site designers how to make accessible Web sites
• Nearly one year old
• Foundation for Authoring Tool & User Agent Accessibility Guidelines
• Has 14 guidelines, 60+ checkpoints
• Priority/conformance model re-used in ATAG & UAAG
• Comprehensive document, but with simplified checklist

WCAG - hit and myth

Web Content Guidelines are...

• Techniques document in current development
  • Modularised by technology (HTML, SVG, SMIL, etc)
  • Updating according to deployment
  • Browser support increasing
• Guidelines will also evolve
  • Generalise for wider range of use - XML, Graphics, etc
  • Increase the amount of information in Techniques document
  • Using the same process - collaboration of industry, users, expert research

WCAG hit and myth

Web Content Guidelines are not...

• Requiring text only
• Prohibiting colourful, media-rich pages
• Written solely for english in the USA
• Based on what is easy. (They are based on what is necessary.)

Authoring Tool Accessibility Guidelines

http://www.w3.org/TR/WAI-AUTOOLS

• All tools for Web Content - images, HTML, database systems, word processors...
• Both: generation of accessible content and accessibility of the environment.
• Same Priority, Guidelines, Checkpoints, organization as Web Content
• Companion Techniques document with examples, references, etc
• Evaluations of Authoring software
• W3C Recommendation February 2000

The Authoring Tool Guidelines

1. Support all accessibility features of W3C recommendations
2. Generate standard markup
3. Make sure that no accessibility content is missing
4. Provide Methods of checking and correcting inaccessible content
5. Integrate accessibility solutions into the overall "look and feel"
6. Promote accessibility in help and documentation
7. Make the Tool Accessible

Authoring Tools - building the future

• Working with developers
• Have begun evaluating tools
• Building tools, templates, techniques

User Agent Accessibility Guidelines

http://www.w3.org/TR/WAI-USERAGENT

• Emphasis for version 1.0 on common graphic browsers, HTML
• Some focus on mobile devices, multimedia players, ...
• Same Priority, Guidelines, Checkpoints, and Techniques organization
• Looking at:
  • Accessible UI, control over style
  • Orientation and access to document structure
  • Visibility of accessibility information and controls
  • Compatibility with assistive technology
• Final release: early Summer 2000 (now a Proposed Recommendation)

V. Fix this!

While fictional, this page accurately illustrates common practices.

• Inaccessible page example

Some things to think about generally:

• Illustrate with images
• Validate!!
• Make large groups of links "skippable"

Fix 1: Ensure Scripts are accessible

• Content must not rely on scripts to provide information.
• Use markup instead of scripts when possible.
• Don't prevent access through browser-sniffing.

Make other scripts accessible:

   <a href="javascript:popout('miles')" onmouseover="highlight()">
         <img src="blood.gif" alt="earn miles - donate blood"></a>

Becomes

   <a href="miles" target="_blank" onfocus="highlight()"
      onmouseover="highlight()"><img src="blood.gif" alt="earn miles - donate blood"></a>

Related Checkpoints: WCAG 6.3, 6.4, UAAG 9.1

Improved example

Fix 2: Provide equivalent alternatives

Since text can be rendered visually, as speech, or as braille it helps many users.

In HTML, provide short functional equivalent text with the "alt" attribute:

   <IMG ... alt="Navigation Bar..." >
   <IMG ... alt="Advertising Information" >

   <AREA ... alt="More Articles" >
   <AREA ... alt="Health Topics" >

Provide content for applets:

   <applet code="Lake.class">
     <param name="image" content="lh.gif">
     <img src="lh.gif" alt="Latest News">
   </applet>

Provide long descriptions for complex content (charts, graphs, etc.)

Related Checkpoints: WCAG 1.1, 6.3 ATAG 3.1, 3.3, 3.5

Improved example

Fix 3: Make frames accessible

To provide navigation alternatives, assign titles to frames and add a "noframes" alternative:

   <FRAME ... name="TOC"
              title="Table of Contents" >
   <FRAME ... name="Home"
              title="Home Page" >
   <NOFRAMES>
      <BODY>
      <P><a href="a"><img src="vnav.gif" border=0 usemap="#map" alt="Navigation Bar..."></a>
      ...
      </BODY>
   </NOFRAMES>

Related checkpoint: WCAG 12.1

Improved example

Fix 4: Specify colours appropriately

Specify all colours for a colour scheme. If only a background is given it might be the same as user-specified defaults for a foreground.

Ensure specified colours have sufficient contrast to be read.

  body background=bg.gif

becomes

  body background="bg.gif" bgcolor="#8e0851" text="white" link="3fa" vlink="5f5"

Don't forget images!

Related Checkpoint: WCAG 2.2

Improved example

Fix 5: Use meaningful link text

To provide information about link targets to users who surf link text only, write:

  <A href="a">
    Coping With Asthma's Relentless Attacks</A> 

instead of:

  Coping With Asthma's Relentless 
  Attacks:<A HREF="a">Click Here</A> 

Related checkpoint: WCAG 13.1

Improved example

Fix 6: Add structure

To convey a logical model other than visually, use markup correctly. For example:

  <B>9 May 1999</B> <IMG src="l1.gif">

becomes:

  <H1>9 May 1999 
      <IMG src="l1.gif" alt="Latest News"></H1>

Related checkpoints: WCAG 3.5, 3.6, ATAG 3.2

Improved example

Fix 7: Use style sheets

• Use CSS instead of background image as color
• Replace text in images with real text.
• Use a style sheet instead of FONT element / inline styles

Related checkpoints: WCAG 3.1, 3.3, UAAG 4.17

A much more accessible version

• Accessible page example [Inaccessible page example]

VI. Resources to Get Started

• W3C Technical Reports
• Web Accessibility Initiative home page
  • Guidelines
  • Education and Outreach materials
• Quick Tips
• For feedback on accessibility of pages:
  • Sinica's Schematron
  • CAST's "Bobby"
  • And many others... WAI-ER's list of tools
• Key resources at other organizations

Get Involved!

• Ensure that your Web sites are accessible
• Promote your commitment to accessibility
• Partner with W3C/WAI in promoting awareness
• Demand tools that support accessibility
• Distribute Quick Tips and other accessibility information
• Participate in development of guidelines
• Join the Protocols and Formats Working Group

VI. Questions and discussion

W3C presentations are archived online at http://www.w3.org/Talks