# Presentation: 476021

## Designing for Accessibility with HTML 4.0

- Larry G. Hull    NASA/GSFC
- larry.g.hull@gsfc.nasa.gov

## Learning HTML

- HTML 4.0 Specification
- http://www.w3.org/TR/REC-html40/
- Annual Calendar of On-Site Training
- Introduction to Web Publishing with HTML
- Introduction to Web Publishing with FrontPage
- Advanced Web Publishing with HTML

## Designing Web Pages

- HMTL Writers Guild
- http://www.hwg.org/
- Annual Calendar of On-Site Training
- Designing Information for the Web
- Writing HTML: A Tutorial for Creating Web Pages
- http://hakatai.mcli.dist.maricopa.edu/tut/index.html

## Web Accessibility

## Web Accessibility

- 	What does "Web accessibility" mean?

## Web Accessibility

- 	What does "Web accessibility" mean? To me, it means that anyone using any kind of Web browsing technology must be able to visit any site and get a full and complete understanding of the information as well as have the full and complete ability to interact with the site - if that is necessary.
- 			Chuck Letourneau, Starling Access Services © 1998

## Web Accessibility

- 	W3C's Web Accessibility Initiative uses the following definition in their Web Content Accessibility Guidelines:
- 	"Content is accessible when it may be used by someone with a disability.”
- 		http://www.w3.org/TR/WAI-WEBCONTENT/#glossary

## Web Users - Anyone

- Older Browser - IE or Navigator 3.X
- Alternate Browser - Lynx, Opera, iCab
- Low Bandwidth - 28.8/33.6/56 kbps
- Alternate Devices - WebTV
- New Devices - PDAs, Cell Phones, Car Computers (voice browser)

## Motivation

- Section 508
- Workforce Investment Act of 1998
- Federal agencies' electronic and information technology is to be accessible to people with disabilities
- Employees
- Members of the public

## Department of Justice                                               Section 508 Home Page

- http://www.usdoj.gov/crt/508/508home.html
- Section 508 in HTML
- http://www.usdoj.gov/crt/508/508law.html
- Section 508 in PDF
- http://www.usdoj.gov/crt/508/508law.pdf

## Architectural and Transportation Barriers Compliance Board

- Independent Federal Agency
- Created in 1973
- Primary mission is accessibility for people with disabilities
- Directed to publish Federal standards by February 7, 2000
- The Electronic and Information Technology Access Advisory Committee

## The Electronic and Information Technology Access Advisory Committee

- Develop set of recommended standards for achieving accessibility to technology and information by individuals with disabilities
- Final Report dated May 12
- http://www.access-board.gov/pubs/eitaacrpt.htm
-  Recommended standard likely to be adopted as Federal standard with little or no change (opinion)

## Final Report - Web Sites

-  Section 5.3, Technology Specific Standards
-   5.3.3.1 Web content shall conform with level 'Double-A', satisfying all Priority 1 and 2 checkpoints, of the World Wide Web Consortium (W3C) "Web Content Accessibility Guidelines 1.0"

## Final Report - Web Sites (Cont’d)

- 5.3.3.2 Tools for authoring Web page and sites
- Authoring Tool Accessibility Guidelines
-  5.3.3.3 User agents  (Browsers)
- User Agent Accessibility Guidelines
- 5.3.3.4 Navigation links or tool bars at the top and left side of your page
- 5.3.3.5 ASCII art

## Implementation

- Target date is August 7, 2000
- Section 508 exempts only national security systems
- E&IT hardware, software, and services will be phased in via procurement
- Web sites ??????

**Notes:**
Effective 2 years after the date of enactment of the Rehabilitation Act Amendments of 1998, any individual with a disability may file a complaint alleging that a Federal department or agency fails to comply with subsection (a)(1) in providing electronic and information technology. 

This subsection shall apply only to electronic and information technology that is procured by a Federal department or agency not less than 2 years after the date of enactment of the Rehabilitation Act Amendments of 1998. 

Date => August 7 1998

## Concerns

- Impact
- NASA directive that government-funded research be available to the public
- Scientists and engineers create Web pages for their particular projects
- Pages often “other duties as assigned”
- Pages are often not very accessible

**Notes:**
Federal standards are forthcoming, with little advance  warning, that may have a wide impact given scientists and engineers create Web pages for their particular projects to fulfill the NASA directive that government-funded research be available to the tax-paying public when such information is not classified.  
For many of these Web authors, the creation of web pages fall under  "other duties as assigned".  The scientists and engineers are focused on their projects and have little time to follow the activities of the W3C Web Accessibility Initiative or to become familiar with the recently published accessibility guidelines, if indeed they are aware that the guidelines exist.
Finally, application of these guidelines is not necessarily trivial. Several online debates are in progress concerning the exact actions required by several of the guidelines with a more generic debate over using guidelines (which nominally permit some interpretation) as standards (which conventually do not permit interpretation) and a related discussion concerning the accessibility of PDF documents.

## How You Can Make Your Site INACCESSIBLE(apologies to Chuck Letourneau)

- 	1. Use a lot of HTML "tricks" to enhance the visual display of your page (instead of using a style sheet)
- misuse HTML elements like H1-6, UL, OL, BLOCKQUOTE, CITE, etc.
- misuse alt-text, title (by hiding messages)
- misuse colors and fonts

**Notes:**

How to make your Web page less useful to browsers that understand what HTML is supposed to be used for, and probably confusing and possibly inaccessible to some people who have visual impairments.

## How You Can Make Your Site INACCESSIBLE

- 	2. Lay out your information in a highly complex manner
- create multiple columns of text using TABLES
- display large complex data tables (spreadsheets)
- use FRAMES to open a series of fixed or varying information windows
- include text in more than one language on a given page (or put text in an image)

**Notes:**
How to make your Web page very difficult to understand for many users of older technology (and there are still many), probably confusing to those of us who are not part of Gen-X or Gen-Next (a rapidly growing Web market), and quite likely inaccessible to many people with visual or cognitive impairments.

## How You Can Make Your Site INACCESSIBLE

- 	3. Provide information in a format that absolutely requires "something extra" from the user
- sight, hearing, mobility
- a particular browser
- an obscure plug-in
- a high speed connection
- prescience (omit basic page and site navigation)

**Notes:**
How to make your Web page inaccessible to a very large audience indeed, including people with many functional limitations (such as a disability, but also more mundane but potentially troublesome limitations like owning older technology, low bandwidth connections, etc.).

## Internet and HTML Accessibility

- W3C Web Accessibility Initiative  http://www.w3.org/WAI/
- W3C WAI Page Author Guidelines 1.0  http://www.w3.org/TR/WAI-WEBCONTENT/
- National Center for Accessible Media   http://www.wgbh.org/wgbh/pages/ncam/
- DO-IT Accessible Web Page Design http://www.washington.edu/doit/Resources/web-design.html
- WebABLE!               http://www.yuri.org/webable/

## Accessibility Exercise

- Disable Your Browser
- Disable Automatic Image Loading
- Disable Java
- Disable JavaScript
- Disable Style Sheets
- Unplug Mouse
- Tab Key is Your Friend

## Alternative Browsers

- Opera (Windows and BeOS new)
- http://www.operasoftware.com/
- iCab (Macintosh)
- http://www.icab.de/
- HotJava (Sun)
- http://java.sun.com/products/hotjava/3.0/

## Alternative Browsers lesson (to be) learned

- “I went to the WhatsHappenin.com web site and was greeted with this message:
- 	If you have reached this page it is not an error. WhatsHappenin.com has been using two version of it's site for some time. We have notice that there has been a significant decline in the number of users that have 3.0 version browsers. As a result WhatsHappenin.com has made the decision to discontinue the 3.0 version of the site. We would like to continue serving your needs and recommend that you upgrade your browser version to 4.0 or better with one of the links below. You will see drastic changes in the ability and functionality of your browsing, as well as, the content on the 4.0 version of WhatsHappenin.com
- Download Netscape
- Download Internet Explorer
- For the record, I use Opera 3.6, which is a newer release than either Netscape 4.0 or IE 4.0!”
- (extract from actual message to W3C WAI list)

## Text Browsers

- Lynx (Unix, Windows, Mac)
- http://lynx.browser.org/
- Primary browser of text-based universe
- Often used with a screen reader
- A “lowest common denominator”
- (yes, it is still supported)
- Lynx Viewer (next best thing to Lynx)
- http://www.delorie.com/web/lynxview.html

## Special Purpose Browsers

- Henter Joyce JAWS (Job Access With Speech) for Windows (JfW)
-  http://www.hj.com/JFW/JFW.html
- AI Squared ZoomText Extra
- http://www.aisquared.com/products/zx.htm
- Productivity Works pwWebSpeak
- http://www.prodworks.com/pww32.htm
- IBM's  Home Page Reader
- http://www.austin.ibm.com/sns/hpr.htm

**Notes:**
JAWS is a very popular general purpose screen reader which is both reasonably easy to use and powerful.  
The current version is fully compatibility with Microsoft Internet Explorer 4.01 and latter.  
Using the Windows operating system from the  keyboard ONLY is non-trivial. 
AI Squared ZoomText Extra is a screen magnification program, 
Mouse-oriented, it  is not quite vocal enough for a totally blind person, it can work well for people needing speech reinforcement. 
Productivity Works pwWebSpeak is a special purpose browser designed for the blind. 
Strips away all graphics from a HTML document.
IBM's  Home Page Reader is an add-on for Netscape Navigator that provides speech 

## Yahoo’s Browser Page

- 	http://dir.yahoo.com/Computers_and_Internet/Software/ Internet/World_Wide_Web/Browsers/
- Many platforms
- Wide variety of browsers
- 	Some seem to think there are only two  browsers in the world.  :)

## Test Your Site

- Bobby
- http://www.cast.org/bobby/
- W3C HTML Validation Service
- http://validator.w3.org/
- W3C CSS Validation Service
- http://jigsaw.w3.org/css-validator/

## Wireless Internet Access

- 3Com's Palm Computing and Symbian will create a de facto standard for wireless Internet access  (New York Times 14 Oct 99)
- Symbian is a joint venture of mobile phone manufacturers Nokia, Motorola, Ericsson, Psion and Matsushita
- Phone combining the Palm and Symbian operating systems will be introduced by Nokia in 2001.

## AOL Anywhere

- America Online signed a deal to offer instant messaging through Motorola's newest phones and pagers.
- (Washington Post 14 Oct 99)
- AOL subscribers can get their e-mail on Palm Pilots and use kiosks at Universal Studios for accessing AOL services.
- “We're trying to provide companion products across a variety of devices.”

## Cascading Style Sheets (CSS)

- Flexible
- Cross-platform
- Standards-based
- http://www.w3.org/TR/REC-CSS2/
- More Information
- http://www.w3.org/Style/css/
- CSS Pointers Group  at http://css.nu/index.html
- CSS Bugs and Workarounds at http://css.nu/pointers/bugs.html

**Notes:**
CSS is a flexible, cross-platform, standards-based language used to suggest stylistic or presentational features applied throughout entire websites. In their
         most elegant forms, CSS are specified in a separate file and called from within the HTML header area when documents loads into the CSS-enabled browser.
         Users can always turn off the author's styles and apply their own or mix their important styles with the authors. This points to the "cascading" aspect of CSS.
           The name CSS Pointers Group was given to us by a columnist who used some of our examples in an article on the difficulties of crafting cross browser
         CSS. 
         The newsgroup... 

         <comp.infosystems.www.authoring.stylesheets>

## Learning CSS

- Introduction
- http://wdvl.com/Authoring/Style/Sheets/Intro/
- Coupled with HTML, Style Sheets
- Add style
- Add color
- Position objects precisely
- Control the look of the website
- Tutorial
- http://WDVL.Internet.com/Authoring/Style/Sheets/Tutorial.html

## Accessibility Features of CSS W3C NOTE 4 August 1999 http://www.w3.org/TR/CSS-access/

- Separates document structure from presentation
- Precise control over spacing, alignment and positioning. Authors can thereby avoid "tag and/or image misuse”
- Provides precise control over font size, color, and style
- Allows user to override author styles

## W3C on Style Sheets

-  CSS2 Specification
- W3C Recommendation in May 1998
- http://www.w3.org/TR/REC-CSS2/
- CSS3 is currently under development.
- W3C Style Sheet Page
- 	  http://www.w3.org/Style/(This page uses CSS style sheets)

## Style Sheets Disabled http://www.w3.org/Style/

## Style Sheets Enabled http://www.w3.org/Style/

## Web Standards Project

- Coalition of web developers and users
- Mission to stop the fragmentation of the web, by persuading browser makers that standards are in everyone's best interest. “Together we can make the web accessible to everyone”
- http://webstandards.org/
- (This page uses CSS style sheets)
- Resources
- http://webstandards.org/general.html

## Style Sheets Disabledhttp://webstandards.org/

## Style Sheets Enabledhttp://webstandards.org/

## Six Web Accessibility Myths

- An accessible page is dull, boring plain text.
- Accessible web authoring is expensive and time-consuming.
- Accessibility is hard! Let's go shopping!
- Disabled people don't use the web!
- Good assistive technology can solve all accessibility problems.
- Web accessibility only helps people with disabilities.

## BREAK

## Myth # 1: Dull, boring plain text

- Threatening idea for graphic designers
- Web accessibility is NOT about making text-only pages or writing "down" to older browsers
- HTML 4.0 lets an author incorporate nearly any kind of "advanced technology"
- Web accessibility is never about restricting snazzy multimedia/graphical design; it's about enhancing it!

**Notes:**
MYTH #1: An accessible web page is dull, boring plain text. 
              This is a particularly threatening idea for the graphic designers out there -- luckily, it's a completely untrue myth. 
              Web accessibility is NOT about making text-only pages or writing "down" to older browsers. In general, the guidelines to accessible web authoring
              do not say "don't do that" -- rather, they say "here's how you can do that, accessibly." 
              The ALT attribute of the IMG tag is a good example. ALT allows you add text to substitute for an image; to make a page accessible, you add the ALT text, you don't throw away the IMG entirely! In the same way, the accessibility considerations of HTML 4.0 let you incorporate nearly any kind of "advanced technology" you want into your page while still preserving the ability to make your page completely accessible. 
              Web accessibility is never about restricting your snazzy multimedia/graphical design; it's about enhancing it! 

## MYTH #2: Expensive &       time-consuming.

- An HTML page that is not interoperable, not platform-independent, not accessible _does_ take less time than a correctly done web page
- Not bothering with trivialities such as grammar, spell-checking, or proofreading also shortens the time required
- If a page is not accessible, something is broken!

**Notes:**
MYTH #2: Accessible web authoring is expensive and time-consuming. 
              I've recently read someone's argument that creating an accessible web page has a great cost -- perhaps 10% to 50% more in the development phase -- in terms of money and time. I don't buy it. 
              In short, this person's argument boiled down to "if I create an HTML page that is not interoperable, not platform-independent, not accessible -- I can do it less time than a correctly done web page." Well, duh; if I'm writing a book and I don't bother with trivialities such as grammar, spell-checking, or proofreading, I could probably get it done quicker too. 
              But interoperability and platform-independence are the cornerstones of the web; if you've made a web page that is not accessible, you've just made it!
              By design, the web is meant to function for everyone; if your page is not accessible, something is broken! 
              So, when you're saying "I can make inaccessible pages quicker", you're really bragging about your skill at producing garbage. 

## MYTH #3: Accessibility is hard

- Some people are intimidated by accessibility
- A few easy principles
- Don't assume everyone has the same computer/browser that you do
- The web is an information medium, so make sure information is not getting lost
- Provide alternative ways to get information

**Notes:**
MYTH #3: Web accessibility is too difficult for the average web designer. 
              Some people are intimidated by accessibility requirements. Do I have to learn HTML 4? What's CSS? What in the world is an ABBR, a LONGDESC, or an OBJECT?? 
              In truth, accessible web authoring practices are not really that hard to learn. They can be boiled down to a few easy principles, such as "don't assume everyone has the same computer you do", "the web is an information medium, so make sure your information is not getting lost", and "provide alternative ways to get at that information". None of these is earthshakingly difficult to comprehend; the WAI's Web Content Accessibility Guidelines provide specifics on how to apply these principles when making your web page. 
              The best thing about learning accessible design practices is not just that you'll create more accessible web pages -- you'll learn more about the web itself, how it works, how it's meant to work, and the potential of the World Wide Web as a communications medium. To understand the web fully, you need to understand accessibility. 

## W3C WAI Web Content Accessibility Guidelines 1.0

- Guidelines on how to apply these principles
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
- Checklist
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/full-checklist
- Techniques
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-TECHS-19990505/
- Errata/Clarifications
-  http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA

## MYTH #4: Disabled people don't use the web!

- How do these page designers and authors know who is using their pages?
- HTTP_USER_DISABILITY is not a standard HTTP header
- Georgia Tech runs regular surveys
- 1 user in 12 (8%) has some disability
- Half (4%) have a visual impairment

**Notes:**
MYTH #4: Disabled people don't use the web! 
              Some web authors will go on at length about how they know their audience, and none of them are disabled, so they don't have to account for them in the design of their website. Now, the problems with this approach are: 
                    It's somewhat like the office on the 2nd floor with no elevator where the workers shrug and tell you, "No people in wheelchairs ever come to this office, so I don't see why we'd need to be wheelchair accessible..." Obviously, they can't get to the office, so they're never seen! Many times potential users of a website are turned away because they can't use the site at all! 
Secondly, how do these designers know who is using their pages? HTTP_USER_DISABILITY is not a standard HTTP header! Unless you specifically ask, and most people have not, you have no idea how many of your website's users may have special needs that you're unaware of! If you insist that you have no disabled users, you'll need to back that claim up. 
So, how many users do have disabilities? Georgia Tech asked this question in their regular surveys of Internet users, and the results were pretty high. One user in 12 (8%) has some kind of disability, and 4% of Internet users have visual impairments. More than you thought?

## MYTH #5: Assistive technology can solve accessibility problems

- In the last few years there have been some amazing advances in "assistive technology"
- Speech synthesis
- Voice recognition
- Braille terminals
- Specialized input devices
- Technology can only provide the given information; content must be accessible

**Notes:**
MYTH #5: Good assistive technology can solve all accessibility problems. 
              In the last few years there have been some amazing advances in "assistive technology" -- gadgets, hardware, and software that allow disabled folks to do many of the things that I take granted. Speech synthesis, voice recognition, Braille terminals, and a wide variety of specialized input devices. 
              Some people will tell you that all that's needed is simply to have better tech toys for the disabled, and the problem of web inaccessibility will be solved -- no need for the web author to do anything in particular since it's not her problem. 
              Unfortunately, though, this isn't the case, for one simple reason. Technology can only provide whatever information it's been given. A specialized web browser can't read the web author's mind and know what she "meant by" an image. That information MUST be supplied, and it's up to the author to diligently provide enough information to make the web page usage. 
              The neatest gizmo in the world can only do what it's been told to do; for this reason, web authors will always have to make sure they are providing accessible content. 

## MYTH #6: Accessibility only helps people with disabilities.

- Accessibility improves your web site
- Usable by the latest technology
- Hand-held computers
- Internet-enabled pagers
- Web telephones
- Easier to reach content
- Accessible sites are ahead of the curve when it comes to XML and other languages

**Notes:**
MYTH #6: Web accessibility only helps people with disabilities. 
              Is web accessibility just about making sure blind people can "see" your pictures or deaf people can "hear" your multimedia files? Not at all; although it is important to keep in mind that you are meeting the needs of particular groups, the benefits of accessible web authoring extend to everyone. 
              Some ways in which accessible web authoring practices will improve your web site: 
                    Your site can be used in the latest technology, such as hand-held computers, Internet-enabled pagers, and web telephones 
                    Search engines will index your site easier, because of your well-structured design and the text alternatives to your multimedia content 
                    Your navigation scheme will be easier for everyone to use so your content can be reached quickly 
                    New web applications that haven't yet been developed will be able to access your site, because it's designed to established standards 
                    You'll be ahead of the curve when it comes to understanding XML and other highly structured content languages 

## Web Content Accessibility Guidelines 1.0

- http://www.w3.org/TR/WAI-WEBCONTENT/
- Goals
- Promote accessibility
- Make Web content more available
- desktop browser
- voice browser
- mobile phone

**Notes:**
These guidelines explain how to make Web content accessible to people with disabilities. The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). 
Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience. 

## Web Content Accessibility Checkpoint List

- http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html
- Each checkpoint has one of three priority levels based on accessibility impact
- Priority 1
- A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document.

**Notes:**
Priorities
            Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility. 
            [Priority 1]  A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. 
            [Priority 2] A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. 
            [Priority 3] A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. 
Some checkpoints specify a priority level that may change under certain (indicated) conditions. 

## Web Content Accessibility Checkpoint List (Cont’d)

- Priority 2
- A Web content developer should satisfy this checkpoint. Otherwise, some will find it difficult to access information in the document.
- Priority 3
- A Web content developer may address this checkpoint. Otherwise, some will find it somewhat difficult to access.

**Notes:**
Priorities
            Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility. 
            [Priority 1]  A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents. 
            [Priority 2] A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents. 
            [Priority 3] A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents. 
Some checkpoints specify a priority level that may change under certain (indicated) conditions. 

## Web Content Accessibility Checkpoint List (Cont’d)

- Three levels of conformance
- Conformance Level "A": all Priority 1 checkpoints are satisfied
- Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied
- Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied

**Notes:**
5. Conformance

This section defines three levels of conformance to this document:

Conformance Level "A": all Priority 1 checkpoints are satisfied;
Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied; 
Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied; 

Note. Conformance levels are spelled out in text so they may be understood when rendered to speech.

## WAI Web Content Accessibility Guidelines Curriculum

- http://www.starlingweb.com/wai/wcag/
- Work in Progress - Updated October 6
- Curriculum
- Introductory Section
- Guidelines for Web Content Accessibility
- Checkpoints for Guideline Requirements
- Examples for Implementing Checkpoints

**Notes:**
Introduction
Appropriate use -- some cautions and disclaimers -- IMPORTANT! 
Your basic curriculum toolkit -- suggested software and hardware
 How to use the curriculum -- suggestions for classroom use or for self study 
Navigation -- a description of the curriculum design and navigation features 
Guidelines
Each W3C guideline presented separately. 
Explains why following the guideline is important for accessibility
Checkpoints
Each guideline links to one or more "checkpoints" to consider.
Each checkpoint then links to one or more examples. 
Examples
For each checkpoint, there are one or more examples. 
Examples show how to implement each checkpoint, and where possible demonstrate what the result will look like in common use.

## Curriculum Sample

- Guideline 1
- Provide equivalent alternatives to auditory and visual content.
- Checkpoint 1.1
- Provide a text equivalent for every non-text element.  Priority 1
- Example 1.1a
- text equivalent for images and graphical buttons.

**Notes:**
Guideline
1. Provide equivalent alternatives to auditory and visual content.
Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
1.1 - Provide a text equivalent for every non-text element.  Priority 1 
1.2 - Provide redundant text links for each active region of a server-side image map.  Priority 1 
1.3 - Until user agents can automatically read aloud the text equivalent of a visual track provide an auditory description of the important information of the visual track of a multimedia presentation.  Priority 1 
1.4 - For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.  Priority 1 
1.5 - Until user agents render text equivalents for client-side image map links provide redundant text links for each active region of a client-side image map.  Priority 3 

## Slide 54

## Guidelines Concern

- Concern often expressed is that a web site which follows the guidelines may not
- have a good appearance
- provide enough functionality
- Making a web page accessible should
- in no way affect the appearance
- enhance functionality not decrease it

**Notes:**
>One of the professors I've been talking with is interested in seeing
>a web site which follows the guidelines, preferably one which is
>science-based, housed at a university or highly interactive.  The
>concern is that a web site which follows the guidelines may not
>have a good appearance or may not provide enough functionality.

Hi, your very question shows that your professor is laboring under
one of the most common myths of accessible web design.  Making a
web page accessible _in no way should affect the appearance_, and
as for functionality, accessibility considerations _enhance_
functionality rather than decrease it.

## HWG Home Page

- http://www.hwg.org

## Enabling Technologies Links

- http://www.brailler.com/links.htm

## Bobby Approved Database

- http://dev.cast.org/bobby/approved_database.cfm

## Equal Employment Opportunity Commission Home Page

- http://www.eeoc.gov

**Notes:**
Alternative Approach

## EEOC Accessibility Alternatives

## Primary Accessibility Alternative

## W3C WAI Quick Tips

**Notes:**
Quick tips to make accessible Web sites 
       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 www.w3.org/TR/WAI-WEBCONTENT. 

## Inaccessible Page Example(features enabled)

## Inaccessible Page Example(features disabled)

- http://www.w3.org/Talks/1999/0512-wai-www8ij/ bad/index.html

## Make Your Web Site a TV Star

- Noncomputer browser markets are small
- Largest is WebTV
- Make 800,000 Web surfers happier with just a little extra effort
- Resource for developing Web pages for TV
-      http://www.builder.com/Authoring/WebTV/
- WebTV Development Checklist
-      http://developer.webtv.net/design/checklist/Default.htm

## Multiple Browsers & Devises

- HTML can work for almost all users
- Graceful degradation
- Lowest common denominator
- Multiple Web sites - static or dynamic
- Browser sniffer
- JavaScript code detects the browser
- Sniffer directs the browser to a specific page

## Microsoft Auto PC

- A plug-in replacement for your car radio
- Powered by Windows CE version 2.0
- Access to email
- Cellular phone service
- Global positioning system (GPS) support
- AM and FM music broadcasts
- Voice-controlled and capable of talking back.

**Notes:**
The idea is that as drivers speed between meetings, they can retrieve their email and have it read to them, compose verbal responses, engage in hands-free cell phone conversations, and otherwise make cruising the freeway even more dangerous than it already is. 

And did I mention that Auto PC will also support Web browsing?  

Dan Shafer is executive technical producer and editor at large for CNET's BUILDER.COM

## Noncomputer Browsers:        Alternate View?

- 	“It's just plain easier for the handful of manufacturers of these noncomputer browsers to fix them so they work with _standard_ Web pages than it is for the masses of Web builders to do their work for them. The manufacturers know the standards (HTML, JavaScript, XML, and Java) well enough to incorporate logic that will adapt the Web-for-PC to their particular product.”

**Notes:**
Until one or more of these platforms become so ubiquitous that they rival the PC in terms of market penetration, Web builders shouldn't have to adapt their sites to suit them. 

Finally, it's just plain easier for the handful of manufacturers of these noncomputer browsers to fix them so they work with standard Web pages than it is for the masses of Web builders to do their work for them. The manufacturers know the standards (HTML, JavaScript, XML, and Java) well enough to incorporate logic that will adapt the Web-for-PC to their particular products. 

Dan Shafer is executive technical producer and editor at large for CNET's BUILDER.COM

## Bobby from Center for Applied Special Technology (CAST)http://www.cast.org/bobby/index.html

- A web-based tool that analyzes web pages for accessibility offered as a free service
- Accessibility analysis based on W3C’s Web Content Accessibility Guidelines
- Analyzes pages for browser compatibility based on vendor documentation
- Automatic check for HTML 4.0 compatibility

## Bobby's Advanced Options 

## Bobby's Output - Interpretation

- Annotated Page (blue hats)
- Priority 1 Accessibility Errors
- Priority 2 Errors
- Priority 3 Errors
- Browser Compatibility
- Download Time

## Blue Bobby-Hats 

- Throughout the annotated version of the web page are blue Bobby hats with and without wheelchairs on them
- Blue hats with wheelchairs indicate that there is a disability access problem at that particular point in the web page
- If the blue hat does not have a wheelchair, it is a browser compatibility problem.

## Priority 1 Accessibility Errors

- Problems that seriously affect the page's usability by people with disabilities
- Clicking on any of the problems that Bobby reports will produce a more detailed description of how to fix the problem
- In addition, a number of items that require manual examination are presented here
- Bobby Approved status is equivalent to Web Content Guidelines Conformance Level A

## Priority 2 Access Errors

- Access problems which should be fixed
- Not as vital as Priority 1 access errors but considered important for access
- There are items presented here as well that require manual examination
- Page passing all items in this section meets Web Content Guidelines Conformance Level AA

## Priority 3 Access Errors

- Third-tier access problems
- There are items presented here as well that require manual examination
- Page passing all items in this section meets Web Content Guidelines Conformance Level AAA

## Browser Compatibility

- 	The section lists those HTML elements and element attributes that are used on the page which are not valid for particular browsers

## Download Time

- 	The section provides a summary of how long the web page and images would take to download on a slow modem line (assuming the server is not too busy)

## Usability Counts

- Site
- Inviting
- Easy to navigate
- Accessible
- Basic Principles
- Know your users
- Know your users’ tasks
- Know what performance means to users

**Notes:**
Most of us want our web sites to be as inviting and easy to
navigate as possible. Sometimes in the heat of design
battle, however, we forget to follow basic usability
guidelines. Here's a concise list of usability principles that
might prove useful.

## Usability Questions

- Is your site efficient?
- Is your site intuitive?
- Is your site supportive?
- Is your site engaging?

**Notes:**
Is it efficient?
   Can tasks be performed with keyboard strokes? (Important for power users.) 
   Does the site reflect a clear understanding of how users do their work? 
   Are response times fast enough to keep users in a flow state? 

Is it intuitive?
   Does it take advantage of users' mental models? 
   Does it behave consistently throughout? 
   Is it visually consistent? 

Is it supportive?
   Does it allow mistakes to be easily undone? 
   Does it provide advice? tools? reference materials? 

Is it engaging?
  Do users feel in control? 
   Do users enjoy their experience? 

## Usability Checklist

- Remember the eight-second rule (Loading)
- Show personality (Branding)
- Design with the user in mind
- Make your site easy to learn
- Remember, users never ask for directions
- Your content should have content
- Write well (Consistency)
- Enable visitor feedback
- Give people what they want
- Don't forget to test

**Notes:**
1.Remember the eight-second rule. Consumers have eight seconds worth of patience while waiting for your pages to load. This is especially true for home pages.
2.Show personality. Branding is the current term used to describe how a business or product distinguishes itself from the competition. 
3.Design with the user in mind. Usability should not constrain good design. Good design, on the other hand, should create a very usable site. 
4.Make your site easy to learn. A good site should be like good software—you
shouldn't need a manual to learn how to use it. Design your site so that people constantly "guess right." 
5.Don't let them lose the scent. Remember, users never ask for directions. 6.Your content should have content. What good is it to have a web site if the
content is useless? Write something worth reading. 
7.Write well. Consistency is key. And, don't forget to run spell check one last time before publishing. 
8.Enable visitor feedback. Make it easy for them to contact you—not only through the web site, but via phone, e-mail, fax, and snail mail. 
9.Give people what they want.  Sometimes we forget and give people what we want instead of what they want. 
10.Don't forget to test. Formulate your usability testing criteria, then test, test, test.
Strive for a quick-loading, well-designed, solidly written, easily maneuverable, thoroughly tested, pleasantly interactive, meaningful, and distinctive web site.