Introduction


The Knowbility Accessibility Internet Rally (AIR) is a one-day web site development competition that provides web professionals with the opportunity to learn accessibility skills from recognized experts. After a free, accessibility training session (a value of hundreds of dollars), web developers test their newly acquired design tools and techniques in the context of one rollicking, high energy work day. Each team creates a site for a local non-profit organization and prizes and wide recognition are awarded to winners in three categories.

Advanced Developer Training 2003

This advanced developer training is provided as a supplemental course for AIR participants. It is expected that all attendees have attended the prerequisite “Accessibility Basics” course. It is also assumed that all attendees have at least a basic understanding of web development and HTML.

Instructors

Permanent link to this training material: http://cookiecrook.com/AIR/2003/train/

Agenda


  1. Accessibility refreshers

    This section briefly discusses material from the AIR-Austin “Accessibility Basics” course and serves as a refresher for previous AIR participants. There are several topics covered in this section:

    • web accessibility challenges faced by people with disabilities,
    • text alternatives,
    • creating a logical tab order with tabindex,
    • accesskey or other navigation methods,
    • form accessibility,
    • data table accessibility, and
    • laws and standards for web accessibility.
  2. Importance of valid code and semantic markup

    This section discusses the benefits of markup and CSS validation, and tools for partial accessibility validation. Beware that while HTML and CSS validation require only scripts, accessibility validation requires extensive human analysis (The “Bobby Approved” graphic does not mean accessible. It means, “The script couldn’t find any errors, but keep looking.”).

    This section also discusses semantics and metadata, and how using semantic markup can benefit you and your site’s audience.

  3. Cascading Style Sheets

    This section discusses the basics of CSS, benefits of CSS, and how to use CSS in an accessible way. CSS resources, examples, and a demonstration of User Style Sheets are also provided.

  4. JavaScript/ECMAScript

    This section discusses the ability to provide rich usability benefits to a majority of your audience without negatively affecting the accessibility of your site to the disabled minority. This material dismisses the myth that accessible means “a separate plain-text site” and demonstrates how most common uses for JavaScript can be executed in an accessible manner.

  5. Accessibility testing

    This section discusses quality assurance techniques to ensure your site is accessible to as wide an audience as possible. DHTML requires additional accessibility testing, so several testing techniques are covered. The term, DHTML, simply refers to the creative combination of HTML, CSS, and JavaScript.

  6. Flash MX

    This section briefly discusses the new accessibility features of Flash MX and how to overcome accessibiity challenges while providing a rich user experience.

  7. Audio/video

    This section discusses how to make other forms of media accessible: captioning video, descriptive audio tracks, etc.

  8. Conclusion

    This sections concludes the course with a compiled list of resources, contact information for the instructors, and time for questions.

Accessibility Challenges


The following challenges are faced by groups historically overlooked in quality assurance for web sites. Steps taken to ensure access to these groups can provide benefits for everyone. Sharron Rush refers to these benefits as virtual curbcuts.

Physical Disabilities

Technical Disabilities

HTML Accessibility Basics Refreshers


The following is a list of some of the technical (HTML) accessibility options discussed in the AIR “Accessibility Basics” course.

Forms Refresher


These elements can be unsupported in older browsers like Netscape 4, but add accessibility and usability features to newer browsers and screen readers.

See an example of label, fieldset, and optgroup in use.

Tables Refresher


Note: The following applies to data tables, not layout tables. Data is the only semantic use for tables, but if you must use them for layout, the following may not apply.

For more on data tables, view a list of accessible table resources, compiled by Matthias Gutfeldt, a member of the Web Standards Project.

Laws and Standards


Validation


Validation means verifying that the site you produce meets and complies with published guidelines to ensure a quality experience for all users. Some validation (like HTML and CSS validation) can be done automatically, however full accessibility validation requires a large amount of human interaction.

Semantic Markup


Semantics:
The study of meanings.
  1. The historical and psychological study and the classification of changes in the signification of words or forms viewed as factors in linguistic development.
  2. A branch of semiotic dealing with the relations between signs and what they refer to and including theories of denotation, extension, naming, and truth.

Meaningless HTML can validate; make sure your site is semantically pure. Think about what your content means, not just how it is going to look.

CSS Basics


For a great CSS reference tool, install the Netscape DevEdge sidebar for Mozilla or other Gecko-based browsers.

CSS Benefits


...important to note that while CSS allows good document structure, it does not enforce good structure.

Mark Pilgrim

User Style Sheets


A user style sheet is saved on a web user’s computer and maintains their display preferences for browsing the internet. A user style sheet can override an author style sheet by use of the !important construct.

Benefits of User Style Sheets

All of these examples are assuming the author style sheet has not been set up in an inaccessible manner — that is, without the !important construct on key selectors like these and with all font-sizes relative to the body size. If an author has defined a style rule as !important, it cannot be overridden by a user style sheet (without a more specific rule also utilizing !important). It has been brought to my attention that the previous statement does not apply to modern standards-compliant browsers. I had previously written it because of a browser bug that I can no longer verify. I think it may have been a version of Internet Explorer for Windows, but all tests now appear to work correctly.

Accessible CSS


CSS Examples


JavaScript Basics


Accessible JavaScript Guidelines


(Nathan) Shedroff pointed to the continuing lack of integration between design skills and programming knowledge as a reason why most sites were still functioning primarily as brochures.

David Womack, AIGA Director of New Media

Event Handlers


Accessible event handlers
Mouse event Equivalent keyboard event
onmouseover onfocus (1)
onmouseout onblur (1)
onmousedown onkeydown (2)
onmouseup onkeyup (2)
onclick onkeypress (3)

Never use the onchange event for automatic form submissions!

Only use onchange rarely and don’t alert users of format errors until time for submission. For example, you may want to use it for slight formatting changes of input data. If a user has typed in (555)555-1212 for a phone number format instead of the requested format, you could change it to 555-555-1212 safely without alerting the user. However, since this type of data manipulation could easily be done at the time of submission or on the server-side, it may still be a good idea not to use onchange.

Keyboard events

  1. onfocus and onblur

    The onmouseover and onmouseout events are most commonly used with image rollovers. While adding the onfocus and onblur events for rollovers is not necessary for screen reader accessibility, it can add usability benefits for sighted users accessing your site with a keyboard. For example, although a mobility-impaired user may not need to see a rollover, he could still benefit from the visual feedback of the effect.

    You may also wish to consider using CSS for rollover effects. The CSS image replacement techniques are not fully accessible (and probably won’t be until CSS3 generated content is widely supported), but for text effects it is more than adequate.

    a:link { /* normal state */ }
    a:visited { /* visited state */ }
    a:hover, a:active, a:focus { /* rollover state */ }

    The :active and :focus psuedo-classes mimic the :hover state for keyboard events. Ideally, :active would mimic an onmousedown or onkeydown event, but Internet Explorer incorrectly treats this as :focus so we double-up the psuedo-classes to get a consistent effect across multiple browsers.

    See an example of CSS rollovers versus JavaScript rollovers.

    Because newer browsers (like Mozilla) can implement :hover on arbitrary elements (not just links), you may want to double-up your pseudo-classes. Combining :hover with :link and :visited can ensure the special effects won’t appear on non-link anchors.

    a:link { /* normal state */ }
    a:visited { /* visited state */ }
    a:link:hover, a:visited:hover, a:active, a:focus { /* rollover state */ }
  2. onkeydown and onkeyup

    In a few DHTML cases, these events may need to be used instead of onkeypress. For example, the arrow keys do not consistently activate the the onkeypress event, but they usually do activate the onkeydown and onkeyup events.

    However knowing that many users do not have arrow keys (laptops for example), consider rethinking your need for these keys if the functionality provides a essential information. Also consider how difficult it may be to use this type of interface with a screen reader.

  3. onkeypress

    Most browsers activate the onclick event when a user presses the Enter key, however certain browsers do not. To ensure full support, you may wish to use the onkeypress event.

    You could use this example HTML code:

    <input
      type="button"
      onclick="foo();"
      onkeypress="verifyKey(this,event);"
      />

    With this JavaScript function:

    // With onkeypress event, this verifies “Enter” key
    function verifyKey(oElement,oEvent){
      if(oEvent.keyCode==13 && oElement.onclick){
        oElement.onclick();
      }
    }

    Note: The verify key function is usually not necessary, but it was written to account for an bug in some older versions of Mozilla. The bug has been fixed in the latest releases, but it previously activated the onkeypress event when a user hit the Tab key, making it impossible to tab past the link without activating the event.

Accessible JavaScript Examples


Testing Accessibility


My motivation is the pursuit of perfection. Although I am aware that perfection is impossible, the strive towards perfection is not.

Gregory Evans

Flash MX


As of this writing, Flash cannot be made as accessible as an HTML document.

This information is provided because Flash developers will continue to use Flash whether it is accessible or not. Until Flash can be made as accessible as HTML, please use all the accessiblity techniques available in the most current version of Flash. It’s not there yet, but it keeps getting better.

I’ve learned almost everything I know about Flash accessibility from Bob Regan, head of the Macromedia Accessibility team. Unfortunately, he no longer updates his blog, but you can still find the achives on Bob Regan’s Flash Accessibility web log.

Audio / Video


Using the following tools and techniques, you can provide most multimedia presentations in an accessible format.

Resources


This list will continue to grow/evolve as I have time to update it.

Contact Information


URL for Presentation

http://cookiecrook.com/AIR/2003/train/

Author / Instructor Information