CLF for the Internet - Accessibility

•  
• <
• Table of Contents
• >
• >>

Rationale

This standard is the key requirement for accessible design in the GoC. It points to an existing international standard: the Web Content Accessibility Guidelines 1.0 recommendation, from the World Wide Web Consortium (W3C).

The W3C checkpoints mentioned in the CLF standard are set out and defined in W3C's recommendation. That document explains the rationale behind each of fourteen basic guidelines for making Web sites universally accessible. Following each guideline are one or more actions that a page author must perform to meet the requirements of the guidelines. These actions are called "Checkpoints".

This CLF standard requires GoC Web sites to comply with Priority 1 and Priority 2 checkpoints.

Interpretation

[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 must 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.

1.1 Best Practices

Absolute Pixel Size (February 2003)
Primary References for Accessible Web Site Design
Accessible On-line Forms
Cascading Style Sheets
Design for all input devices
How to make pop-up windows accessible

Absolute Pixel Size

It is recognized that there are anomalies between the CLF Standards 6.1 and 6.2 and the W3C WAI Checkpoint 3.4. These CLF Standards dictate the use of absolute pixel measurement, while W3C WAI Checkpoint 3.4 does not recommend the use of absolute units.

The original and ongoing rationale for requiring GoC Internet Web sites to be designed using absolute units for the common and institutional menu bars was to ensure that there is a consistent look of the design as well as a consistent placement of the primary navigation aids across all GoC Internet Web sites.

Within the CLF structured look, there remains the flexibility for scalability of the textual elements making up these primary navigation aids, thereby achieving the accessibility objectives of the W3C WAI checkpoints as well as, to the greatest extent possible, the goals of the Common Look and Feel Standards.

Primary References for Accessible Web Site Design

Associated with, and considered an integral part of the W3C Web Content Accessibility guidelines are a set of supporting documents and tools.

These are the primary references for Accessible web site design:

• Techniques for Web Content Accessibility Guidelines 1.0
  The Techniques document is an invaluable source for examples, code and explanations of how to implement each of the checkpoints. Every checkpoint in the Guideline document links to a corresponding example in the Techniques document.
• The list of known errors in the Guidelines
  As the W3C recommendation is a published "standard", changes to the original work are not permitted. Any errors corrections or clarifications to the original that have been necessary are recorded in the Errata document.
• Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
  The checklist of checkpoints is a good tool for page designers or Web masters to use to identify problem areas in their design and record any actions taken. This document is presented in a tabular format, which may be inaccessible to some people. A more accessible version of the checklist is also available.
• Curriculum for Web Content Accessibility Guidelines 1.0
  The Curriculum is a self-study guide to the W3C Web Content material. Like the Techniques document, the Curriculum includes examples for many of the checkpoints, but the Curriculum attempts to make the examples easier to understand, and where possible, shows the results of using such techniques on a Web page.

Because of the scope and completeness of these resources, this CLF Web site will not duplicate or reinvent all of the examples found therein. However, there are certain aspects of the CLF design that will benefit from the application of specific techniques, and those are presented on the following pages.

The application of standards and consistent use of accessible design techniques will enable the GoC to achieve its goal of connecting all Canadians.

Accessible On-line Forms

HTML forms are not, in and of themselves, inaccessible. What the programmer / page author does with them determines the accessibility of the end product.

Elements of an inaccessible form:

• Complex visual layout and placement of controls and fields
• Badly explained requirements
• Field / control labels separated from and not clearly associated with their controls
• Client-side scripting to perform entry validation or completion
• No alternative method of posting information provided (e.g. no e-mail contact provide, no phone number to call for help, etc.)

Elements of an accessible form:

• Simple (e.g. single column) layout of controls and entry fields
• clear (meaningful) explanations or labels associated with fields and controls
• appropriate use of HTML markup specifically intended to enhance accessibility (e.g. LABEL, OPTGROUP, etc.)
• server-side verification and validation of data entry
• provision of alternate methods of contact / submission

All of the oldest assistive technologies can handle well designed HTML forms. The trick is to get page designers to keeps forms simple and to avoid client-side entry verification and processing.

Cascading Style Sheets

Most organizations are coding font effects using deprecated <FONT> codes, and worse, are fixing pixel or point sizes for text in the markup or in associated style sheets. This prevents text from scaling under user's control. Fixing font sizes with absolute units impacts persons with low vision and people who prefer to use screen resolutions other than the common 640x480 or 800x600.

Solution: Use Cascading Style Sheets

• Style sheets were designed to allow precise control - outside of markup - of character spacing, text alignment, object position on the page, audio and speech output, font characteristics, etc.
• By separating style from markup, authors can simplify and clean up the HTML in their documents, making the documents more accessible at the same time.
• CSS allows precise control over spacing, alignment and positioning. Authors can thereby avoid "tag misuse" - the practice of misusing a structural element for its expected stylistic effects. For example, while the <BLOCKQUOTE> and <TABLE> elements in HTML are meant to mark up quotations and tabular data respectively, they are frequently used to create visual effects instead such as indentation and alignment. When specialized browsing software such as a speech synthesizer encounters elements that are misused in this way, the results can be unintelligible to the user.
• In addition to preventing element misuse, style sheets can help reduce image misuse. For instance, authors sometimes use 1-pixel invisible images to position content. This not only bloats documents, making them slow to download, but can also confuse software agents looking for alternative text (the "alt" attribute) for these images. CSS positioning properties mean that invisible images are no longer required to control positioning.
• CSS provides precise control over font size, color, and style. Some authors have used images to represent text in a particular font when they are uncertain of the availability of the font on the client's machine. Text in images is not accessible to specialized software such as screen readers, nor can it be cataloged by search robots. To remedy this situation, the powerful WebFonts of CSS allows users much greater control of client-side font information. With WebFonts, authors can rely on fallback mechanisms on the client when the author's preferred fonts are not available. Fonts can be substituted with more accuracy, synthesized by client software, and even downloaded from the Web, all according to author specification.
• CSS allows users to override author styles. This is very important to users who cannot perceive a page with the author's chosen fonts and color. CSS allows users to view documents with their own preferred fonts, colors, etc. by specifying them in a user style sheet.
• CSS provides support for automatically generated numbers, markers, and other content that can help users stay oriented within a document. Long lists, tables, or documents are easier to navigate when numbers or other contextual clues are provided in an accessible manner.
• CSS supports aural style sheets, which specify how a document will sound when rendered as speech. Aural style sheets (or "ACSS" for short) allow authors and users to specify the volume of spoken content, background sounds, spatial properties for sound, and a host of other properties that can add effects to synthesized speech analogous to those achieved with styled fonts for visual output.
• CSS provides more precise control over the display of alternative content than HTML alone. CSS2 selectors give access to attribute values, often used to provide alternative content. In CSS2, attribute values may be rendered in a document along with an element's primary content.

This and more information regarding Style Sheets.

CSS Implementations

Widely deployed browsers do not implement CSS consistently. However, the latest generation of browsers from a number of vendors demonstrates solid implementations of most of CSS1 and much of CSS2, and implementations continue to improve.

Part of designing an accessible document with CSS involves ensuring that the document remains accessible when style sheets are turned off or not supported.

Until most browsers support CSS consistently, content developers may still create accessible documents that mix supported features of CSS with some presentation features of HTML. Documents that use HTML presentation features instead of CSS must transform gracefully. For example, tables used for layout must make sense when rendered serially.

Design for all input devices

Use features that enable activation of page elements via a variety of input

http://www.w3.org/WAI/wcag-curric/chk10-0.htm

Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device - mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form.

Note: Providing text equivalents for image maps or images used as links makes it easier for users to interact with them without a pointing device.

Generally pages that allow keyboard interaction are also accessible through speech input or a command line interface.

Design for Device-independence

W3C Checkpoint 9.3 - For scripts, specify logical event handlers rather than device-dependent event handlers.

An event-handler invokes a script when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.). In HTML, event handlers are attached to elements via event handler attributes (the attributes beginning with "on", as in "onkeyup").

What happens when an event occurs depends on the script the page author has created. Some produce purely decorative effects such as highlighting an image or changing the color of an element's text. Others produce much more substantial effects, such as carrying out a calculation, providing important information to the user, or submitting a form. For scripts that do more than just change the presentation of an element, content developers should do the following:

Use application-level event triggers rather than user interaction-level triggers. In HTML, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers.

Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):

• Use "onmousedown" with "onkeydown"
• Use "onmouseup" with "onkeyup"
• Use "onclick" with "onkeypress"
• Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML

Examples: http://www.w3.org/WAI/wcag-curric/sam71-0.htm

How to make pop-up windows accessible

To make your pop-up windows accessible to people who do not use a mouse to navigate, add the event triggers "onFocus" and "onBlur" to make the effect available to keyboard users.

Please note that client-side scripted pop-up windows may be partly or totally inaccessible to some users. Some users of screen-readers may be unaware that new windows have appeared, or may be confused by their sudden appearance. Also, people who have disabled script support or whose browsers do not support scripting will not "get the message". Where practical, use accessible server-side techniques to provide important messages.

•  
• <
• Table of Contents
• >
• >>