Common Look and Feel for the Internet

Accessibility Section

Overview

Internet technologies have provided many Canadians with an enhanced sense of intellectual and economic freedom. But for many people, gaining entry to Web content is more complicated than clicking mouse and operating a modem. Some Canadians rely on assistive technologies such as text readers, audio players and voice activated devices to overcome the barriers presented by standard technologies. Others may be limited by their own technology. But old browsers, non-standard operating systems, slow connections, small screens or text-only screens should not stand in the way of obtaining information that is available to others.

Thanks largely to the efforts of the World Wide Web Consortium (W3C), Internet accessibility has become a global issue that commands the attention of software and system designers during the development phase. The CLF standards are aligned with the W3C Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium (W3C).

World Wide Web Consortium (W3C)

In keeping with the client-centred approach of the CLF initiative, universal accessibility standards are directed toward ensuring equitable access to all content on GoC Web sites. While site design is an important element of the electronic media, universal accessibility guidelines have been developed to ensure anyone can obtain content, regardless of the technologies they use. The key to effective implementation of universal accessibility guidelines lies in designing sites to serve the widest possible audience and the broadest possible range of hardware and software platforms, from assistive devices to emerging technologies. W3C WAI working groups continually test WCA Guidelines against a full range of browsers and assistive devices before recommending widespread implementation.

There are many older, current and emerging display and control technologies that are not capable of rendering the full multimedia content that is becoming prevalent on the Web. Graphical, text-only or speciality browsers that pre-date current releases or low band-width connections present barriers to access, as do grey-scale or monochrome displays, enlarged monitors, and miniature display devices (such as pager displays, digital cellular phone displays, personal digital assistants, etc.). Web developers cannot assume that all end users can apply the full range of human physical and sensory ability, along with the standard suite of computer technology to Internet usage. Thus, they need to consider mobile communications technologies such as hands-free / eyes-free systems, speech synthesis and voice recognition technologies, one-button scanning and control features and mice-emulators, and alternative input systems (touch screens, eye-gaze systems, mouse or trackball devices).

Seamless transformations, context and orientation, and usability are all key factors in designing a Web site that is available to everyone, and can be interpreted by the technologies they use. WAI's Web Content Accessibility Guidelines, a comprehensive set of recommendations published in 1999, have already been recognized by the international standards community. On one hand, the guidelines aim to meet the needs of people with disabilities who rely on electronic devices to maximize the use of their computer systems. On the other hand, the guidelines will also assist individuals who are using advanced technologies: mobile and voice Web page viewing technologies, electronic agents such as indexing robots, etc. Like all standards, WAI guidelines will evolve over time, as developers and users become more proficient in applying new technologies to Internet usage.

Universal accessibility does not depend on minimal Web page design; it depends on thoughtful design. Along with WAI guidelines, the CLF standards provide direction for Web authors, particularly those using multimedia content, to ensure that all site content and functions are available to all users. Authors should not be discouraged from using multimedia, but rather should use it in a manner that ensures that the material they publish is functional for the widest possible audience. The GoC has adopted the W3C Web Content Accessibility Guidelines (WCAG) to ensure the majority of Canadians will find it relatively easy to use on-line information and services.

Web Content Accessibility Guidelines 1.0
For your information: Web Content Accessibility Guidelines 2.0 (Draft)

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.

W3C Checkpoints
Browser Testing

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
Accessible pop-up windows and menus
Accessibility across platforms

Absolute Pixel Size

It is recognized that there are anomalies between the CLF Standards 6.1 and 6.2 and the W3C WAI Checkpoints 3.4 and 5.3. These CLF Standards dictate the use of absolute pixel measurement and tables for layout, while W3C WAI Checkpoints 3.4 and 5.3 respectively do not recommend the use of absolute units and tables for layout.

The original and ongoing rationale for requiring GoC Internet Web sites to be designed using absolute units for the table cell attributes of 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 4.0, 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 4.0, 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 4.0

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.

Examples of how to create accessible menus

"Drop-down" or "rollover" menus created with client-side scripting can be made accessible to browsers that don't support client side scripting by adding a <NOSCRIPT> block that duplicates the content or functionality of the scripted menu. As well, you must ensure that the event-trigger you use is device independent.

In this example taken from a main English page, the code is extracted from the "Newsroom" button on the site. Additional event triggers were not added to provide an example of the use of the NOSCRIPT block. 

How to: The URL's and link-text are simply copied and pasted from the script declaration on the page, then added as plain HTML (UL list) to a NOSCRIPT block in the table cell containing the button:

<TD>

<A onmouseover="movepic('buttonNewsroom','/images.nsf/vLUImages/
WebHeaderEnglish/$file/top_nav_yellow_newsroom1.GIF'),popUp('elMenu6',event)" onmouseout="movepic('buttonNewsroom','/images.nsf/vLUImages/
WebHeaderEnglish/$file/top_nav_yellow_newsroom.GIF'),popDown('elMenu6')"
href="http://www.acdi-cida.gc.ca/newsro-e.htm">
<IMG alt=Newsroom src="Home_files/top_nav_yellow_newsroom.gif"
border="0" name=buttonNewsroom></A>

<noscript>
<ul>
<li><a href="/newsro-e.htm">Update-Main page</a><br></li>
<li><a href="/_ind.nsf/852562900065549d85256228006b10c0?
OpenView&Start=1&Count_00&Expand=1#1">News Releases</a><br></li>
<li><a href="/_ind.nsf/852562900065549f85256228006a0064?
OpenView&Start=1&Count_00&Expand=1#1">Speeches</a><br></li>

<li><a href="/publications-e.htm">Publications</a><br></li>
<li><a href="/newsflash.htm">News flash</a><br></li>
<li><a href="/comingevents.htm">Coming events</a><br></li>
<li><a href="/issues-e.htm">Major global issues</a><br></li>
<li><a href="/archives-e.htm">update archive</a><br></li>
<li><a href="/media-e.htm">Multimedia</a><br></li>
<li><a href="/_ind.nsf/subscribe-e">Subscribe</a><br></li></ul>
</noscript>

</TD>

• This was tested with a non-JavaScript browser (Lynx) and Netscape (4.6) with Javascript disabled and functions correctly.
• The page looks odd in Netscape with Javascript off, but the functionality is available to users.
• The <NOSCRIPT> block is ignored (and not displayed) by IE (5.5) and Netscape (4.6) with Javascript enabled.

Here is more information on how to implement accessible pop-up menus on your pages.

Accessibility across platforms

To ensure accessibility across platforms:

• make sure that a list of links similar to the one in the pull-down menu (or <NOSCRIPT> block) is available on the destination page of the main link.
• In other words, be sure that the pull-down menu (and <NOSCRIPT> block) is not THE ONLY way to get to the sub-links.

The reason: Graphical browsers that support scripting may never see the pulldown menu because assistive technologies do not recognize it and it may never see the <NOSCRIPT> alternative because it is not made available by script aware browsers.

Rationale

The W3C is an international industry consortium that develops many of the standard languages used by Web page designers and Web application programmers. As explained in the following quote, the W3C is committed to the concept of "Universal Access":

• "W3C defines the Web as the universe of network-accessible information (available through your computer, phone, television, or networked refrigerator...). Today this universe benefits society by enabling new forms of human communication and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability. W3C's Internationalization Activity, Device Independence Activity, Voice Browser Activity, and Web Accessibility Initiative all illustrate our commitment to universal access."

Source: W3C... in 7 points.

Through the working groups of the W3C's Web Accessibility Initiative, all W3C language specifications under development are looked at through an "accessibility lens" to ensure that the goals of interoperability and accessibility are met. To the best of our knowledge (at the time of writing), no other technology-standard setting bodies can make that claim.

The reason for inclusion of Standard 1.2 is to promote the use of standards that are known to include constructs and tools that make accessibility possible.

Interpretation

Primary Format for All Documents

HTML or other language recommendations* developed by the W3C must be the primary format for all documents on GoC Web sites.

Please note that simply using W3C languages for markup or application design does not mean that your products will be naturally accessible: using W3C languages does allow you to use standard methods to ensure the accessibility of your products.

Current W3C technologies

• MathML for mathematical equations
• HTML, XHTML, XML for structured documents
• RDF for meta data
• SMIL to create multimedia presentations
• CSS and XSL to define style sheets
• XSLT to create style transformations
• PNG for graphics (although some are best expressed in JPG, a non-W3C spec)

* Recommendation is the term the W3C currently uses instead of Standard

Alternate Versions

In cases where the document cannot be represented in HTML, users should be given information on how to obtain alternate versions, e.g., print, Braille, audio, etc.

First and foremost, be aware that this is a "last resort" measure. It was not included as a CLF Standard to give you a convenient method of avoiding the (often minimal) effort necessary to make your Web page or Web application accessible.

Most Web content can be made accessible, especially if you are using W3C recommended languages - see list. If, however, after your best effort you cannot make the content or application accessible, please refer to Techniques 1 - 6.

1.2 Best Practices

Technique 1: Include A Statement
Technique 2: Accessible Markup
Technique 3: Accessibility Notice
Technique 4: Converting Legacy And PDF Documents
Technique 5: Manager's Guide To Multiple Format Production
Technique 6: Guidelines And Specifications For Providing Information In Multiple Formats

Technique 1

Include a statement

If, in spite of your best efforts, you are unable to make any document or page accessible, the following is an example of explanatory text you can use to meet the requirements of Standard 1.2. Please note that this technique should be used only as a last-resort as it is contrary to the spirit of the policy that is intended to make all Web content widely accessible.

Include a statement on the same page and preceding the inaccessible element to this effect (some optional language is enclosed between square brackets):

• If the following [information, content, document, application, form, interactive questionnaire, animation, multimedia presentation or whatever it may be] is not accessible to you, please contact [name, e-mail, phone number, TTY number, mailing address or other appropriate contact information] for [assistance, explanations, alternate formats such as regular print, large print, braille, audio cassette or other appropriate format]

Technique 2

Accessible markup

Another way to provide similar information in a Web page is to include it as the content of the <OBJECT>, <APPLET> (deprecated), <NOSCRIPT>, or <NOEMBED> elements:

The following is an example of accessible markup you can use to meet Standard 1.2.

<OBJECT data="http://mysite.com/finance_calculator.class" type="application/java" >
Note: If your system cannot run this Financial Calculator program (a Java application) please contact the Financial Programme Office at (613) 555-5555 for assistance.
</OBJECT>

Note that <EMBED> and <NOEMBED> are not included the HTML standard, and <APPLET> is deprecated as of HTML 4.0.

The information placed between the start and end tags of the <OBJECT> element will be displayed on browsers that either don't support Java, or that don't support <OBJECT>.

Technique 3

Accessibility notice

Finally, if you resort to using such techniques, you should also place a note in the "Help" pages associated with your site. Something like this would be appropriate:

Accessibility Notice:

While every reasonable effort has been made to ensure the accessibility of this site, some content or services found here might be inaccessible to some visitors. In those circumstances, the contact information for someone who can assist you has been provided.

However, what you should first do in any case is make an effort to create an accessible alternative (using accessible markup) and include it as the content of the element - or less desirably, on a separate page - instead of resorting to the above disclaimers.

Technique 4

Converting legacy and PDF documents

For those concerned about vast legacy holdings of bitmapped or complex PDF documents, see alternative versions: Standard 1.2, for a possible solution.

Conversion of Legacy Documents to PDF

New files created in PDF must also be provided in an accessible format.

Legacy Documents already in PDF Format

Departments should start identifying the PDF documents that are most frequently accessed and develop a strategy for converting them to W3C accessible formats.

Technique 5

Manager's Guide to Multiple Format Production

Produced through the Assistive Devices Industry Office of Industry Canada for the Government of Canada. Financial support from the Treasury Board Employment Equity Positive Measures Program Intervention Fund.

http://www.collectionscanada.ca/accessinfo/s36-202.001-e.html

Technique 6

Guidelines and Specifications for Providing Information in Multiple Formats

Human Resources Development Canada Développement des ressources humaines Canada CA-406-12-99E

This document is available in multiple formats: large print, audio cassette, braille, and computer diskette in English and in French by calling 1 800 788‑8282.

Table of Contents

1. Providing Accessible Human Resources Development Canada Information to All Canadians
2. Preparing Information for Multiple Format Production
   Requirements for Developing the One Source Master
3. Guidelines and Specifications for Providing Information in Multiple Formats
   • Large Print
   • Audio Cassette
   • Braille
   • Computer Diskette
   • Packaging
   • Considerations for Multiple Format Production
4. Annex

I  Providing Accessible Human Resources Development Canada Information to All Canadians

As the lead department on disability issues, Human Resources Development Canada endorses the rights of all citizens to have equal access to our information, programs and services.

Providing accessibility to its information is important for Human Resources Development Canada. HRDC believes that the integration of people with disabilities into the mainstream will be instrumental in maintaining Canada's position as a world leader in the areas of human rights, disability, communications and technology.

Information is made available to Canadians through conventional print, via broadcast (radio / television) or through the Internet. However, there is a significant and growing portion of the population unable to access information through these methods.

Canadians provided with essential information and services through accessible communications methods such as large print, braille, audio recording, teletypewriter, listening systems, captioning and descriptive narration for film and video, and innovative electronic information delivery systems are more able to become active participants and contributors in the governance of their lives.

Accessibility requirements for such increasingly prevalent communications media such as the Internet and film and video are being developed. This document, however, will confine itself to the provision of large print, braille, audio cassette, and computer diskette.

II  Preparing Information for Multiple Format Production

When authors of HRDC documents work in consultation with producers of multiple formats at the planning stage, it becomes possible to synchronize the release date of publications so that all formats are available to Canadians at the same time.

Marketing, promotion and distribution strategies should ensure that, upon publication, Canadians are made aware of the availability of multiple formats. The conventional print publication should include this information.

Many documents prepared for conventional print publication contain elements that are not comprehensible in audio format (e.g., footnotes, charts, sidebars, etc.). For this reason, the first step in preparing text for production in multiple formats entails modifying the original electronic text version to ensure audio comprehension. This narrative script then becomes the one source master from which electronic multiple format masters are generated. This ensures consistency among all formats.

Requirements for Developing the One Source Master

• It is the responsibility of HRDC authors to contact the Depository Services Program (DSP), Public Works and Government Services Canada (PWGSC), to acquire a Government of Canada Catalogue Number and ISBN for each format. Consult dsp-psd.pwgsc.gc.ca
• A separate one source master is created for French, English and any other language
• The document provided to create the one source master must be the final, edited electronic copy
• Electronic masters are designed to be compatible with World Wide Web accessibility criteria. Consult www.w3.org/wai/
• A hard copy of the conventional print document is provided for reference purposes
• Logos are supplied in electronic format
• Visual elements are described in narrative form
• Footnotes and sidebar information are incorporated in body text
• Body text is formatted as a single column
• Table of contents is included, if the document is lengthy or if the text contains references to page numbers
• References to page numbers in text are replaced by references to table of contents
• Forms, applications, questionnaires, etc. are adapted for compatibility in all formats and for ease of use
• Sensitive and classified information is protected

III  Guidelines and Specifications for Providing Information in Multiple Formats

Large Print

Some partially sighted people can read print if the type is larger than that used for conventional material. For others, printed matter is accessible through the use of large print in conjunction with magnification devices such as closed-circuit television (CCTV).

Professional graphic designers ensure that layouts and typography provide optimum legibility. Paper qualities such as colour, texture, weight and finish are extremely important. Spiral binding allows pages to lie flat when opened and folded back for use with assistive reading devices.

Master:

• High density 3 1/2" IBM-formatted or Zip IBM-formatted computer diskette
• PostScript file as ASCII, formatted for 8 1/2"x11" paper formatting conforms to professional graphic design and typesetting standards
• Sans serif fonts (such as Arial, Univers, Geneva, Helvetica Regular)
• 16 point type for body text, 20% leading (standard default)
• Headings and subheadings proportionally larger and bold
• Upper and lower case for all text, including headings and subheadings body text (single column only), headings and subhead type set flush left, ragged right (left justified)
• One hard space only between sentences
• No hyphenation of single words at ends of lines; no italics, underline to represent italics
• Page margins: documents of 1-15 sheets; 1" top, bottom, outside, inside
• Documents of more than 15 sheets; 1" top, bottom, outside; 1 1/4" inside
• Black print on 24lb - white smooth opaque paper; no screens
• Binding: documents of 2-15 sheets stapled top left corner
• Documents of more than 15 sheets spiral binding

Audio Cassette

For blind or partially sighted people, and for some people with low literacy skills, as well as many new Canadians, listening may be the only access to the written word.

Information that is presented in point or list form is edited for audio comprehension. Listening instructions and audible tone indexing are incorporated to allow listeners to locate specific sections of the text.

Audio masters are recorded by professional narrators. Computer-generated synthesized voice files can be used for production of time-sensitive reference information subject to frequent re-listing such as: press releases, indexes, catalogues, bibliographies, etc.

Master:

• Digital audio tape (DAT) formatted for 2 track (1 7/8 per second) cassette
• Tone index: (50-60 Hz signals) audible in fast forward and rewind modes
• Single tone for section titles
• Two tones for illustrative material (figures, tables, charts, graphs, etc.)

Label:

• On side A - large print and grade II braille

Braille

Many blind, deaf-blind and partially sighted people gain access to the printed word through braille, a tactile reading system composed of embossed dots on paper. The system has three levels: grade I (basic) and grade II (contracted) are used for publishing braille documents in accordance with standards set by the Braille Authority of North America (BANA). Consult http://braille.brl.org/formats/. Grade III (shorthand) is not used for publication. Professional braille transcribers and proof readers ensure accuracy of transcription.

Master:

• High density 3 1/2" IBM-formatted computer diskette
• MS-DOS Grade II braille file formatted according to BANA standards for 8 1/2"x11"
• Braille paper
• 3/4" inside margins
• 30 characters maximum per line
• 25 lines maximum per page - page number only on line 25
• Double-sided (interpoint) printing

Binding:

• Documents of 2-10 sheets stapled top-left corner
• Documents of more than 10 sheets cerlox binding
• Large print and braille cover page

Computer Diskette

Some blind and partially sighted people use computer-based technology to gain access to printed information that is also available electronically. Information must be formatted as text-only and braille electronic files to ensure compatibilty with adaptive technologies such as large print screen display software, voice synthesizers and braille printers.

Master:

• High density 3 1/2" IBM-formatted or Zip IBM-formatted computer diskette
• ASCII file (MSDOS text)
• Body text is formatted as a single column
• 76 characters maximum per line
• Courier 10 point font (standard default)

Label:

• Large print and grade II braille

Packaging

• Large Print: 9"x 12" mailing envelopes or cardboard boxes for volume order
• Audio Cassette: bubble mailing envelope or cardboard packaging marked "Free Matter for the Blind"
• Braille: bubble mailing envelope or cardboard package marked; "Braille - Please Do Not Bend" and "Free Matter for the Blind"
• Computer Diskette: cardboard diskette mailing package or cardboard box

Considerations for Multiple Format Production

• Print copies should accompany the final electronic files to ensure consistency and cohesiveness across all formats
• Revisions to the final, edited electronic copy may result in increased costs to the document originator
• Documents submitted for multiple format production should be edited and proofread to ensure quality
• Nested numbering systems should be simplified where possible
• A brief description of the information contained in the document should be provided by the originator for catalogue purposes
• A summary of the information contained in the document should be provided by the originator if the document is lengthy

IV  Annex

Treasury Board of Canada Secretariat
140 O'Connor Street, Ottawa, Ontario, Canada K1A 0G5
General Inquiries, Distribution Centre
Tel: (613) 957-2400
Fax: (613) 996-0518
Policies & Publications Inquiries, Distribution Centre
Tel: (613) 995-2855
Fax: (613) 996-0518
Web: http://www.tbs-sct.gc.ca

How to Provide Alternative Formats (BT53-7/1993-L)
ISBN: 0-662-59900-4
Depository Services Program (DSP),
Public Works and Government Services Canada (PWGSC)
350 Albert Street, 4th Floor, Ottawa, Ontario, Canada
K1A 0F5
General Inquiries & Claims: (613) 990-5221
Web: dsp-psd.pwgsc.gc.ca

Braille Authority of North America (BANA)
Phyllis Campana, Chairperson
American Printing House for the Blind
P.O. Box 6085, Louisville, Kentucky, U.S.A. 40206
Tel: (502) 899-2302
Fax: (502) 899-2284
Email: pcampana@uph.org
Web: www.brailleauthority.org/

National Library Service for the Blind and Physically Handicapped
Library of Congress, Washington, DC, U.S.A. 20542
Tel: (202) 707-5100
Fax: (202) 707-0712
TDD: (202) 707-0744
Email: nls@loc.gov
Web: www.loc.gov/nls/

University of British Columbia Disability Resource Centre (Crane Library)
Room 1040, 1874 East Mall, UBC,
Vancouver, British Columbia, Canada V6T 1Z1
Crane Resource Centre: Tel: (604) 822-6111
Crane Production Unit: Tel: (604) 822-6114
Email: disability.resource@ubc.ca
Web: www.library.ubc.ca/home/access/crane.html

Web Content Accessibility Guidelines
Web accessibility initiatives are sponsored by many organizations
around the world including Industry Canada.
Web: http://www.w3.org/WAI/

Closed Captioning Web
Web: www.captions.org/

Rationale

Neither the CLF standards nor the W3C's Web Content Accessibility guidelines even suggest that a content provider cannot provide information in alternative formats. What they do suggest is that the first format encountered by a browser should be the most accessible version (usually, accessible HTML), and that if other formats are available, the content provider clearly indicates what those formats are and, if possible, include a link to a site where the visitor can download an appropriate viewer or "plug-in" application. If an accessible version of a plug-in is also known to be available, then a note and a link to that product should also be included.

1.3 Best Practices

The following is an example of one way to indicate the format of non-HTML documents on your site. Included is an example of explanatory text you might use to meet Standard 1.3.

Example links:

• The following documents are available for downloading or viewing:
  • Sustainable Development Bulletin, June 2001, vol2, no.5 (PDF Version)
  • Sustainable Development Bulletin, June 2001, vol2, no.5 (RTF Version)

Example explanatory text:

• Note: to read the PDF version you need Adobe Acrobat Reader on your system. If the Adobe download site is not accessible to you, you can download Acrobat Reader from an accessible page at: http://www.adobe.com/products/acrobat/alternate.html. If you choose not to use Acrobat Reader you can have the PDF file converted to HTML or ASCII text by using one of the conversion services offered by Adobe at http://www.adobe.com/products/acrobat/access_onlinetools.html.
• To view the RTF version, use the document conversion features available in most modern word processing software, or use a file viewer capable of reading RTF.

Rationale

The requirements for this standard are already clearly stated in the priority 1 checkpoints for W3C Web Content Accessibility Guideline 1 and would thus seem to make this standard redundant. The CLF working group was of the opinion that the sheer importance of marking up non-textual elements with text equivalents was reason enough to highlight this requirement in its own standard. Supplying appropriate textual-equivalents is a major enabler of device independence (the ability to serve content to any Web device) and accessibility for persons with disabilities who use assistive technology.

Accessibility standards are intended to make Web pages more functional for people with disabilities and to individuals using new Web page viewing technologies and electronic agents such as indexing robots. The standards outline procedures for Web authors to ensure that content and functions are equally accessible to all users. Authors need to be particularly aware of guidelines associated with the use of multimedia components and the application of text equivalents.

Federal Identity Program (FIP)

• FIP Signatures Text Equivalents

Web Accessibility Initiative (WAI)

• Examples of text equivalents for images and graphical buttons
• Provide equivalent alternatives to auditory and visual content

Guideline 1.1

Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively.

Best Practices

Browser Testing

Following these 6 steps should minimize the need for testing multiple platform / browser combinations.

1. Design to the W3C Priority 1 and 2 Checkpoints and CLF Standards.
2. Validate pages to HTML 4.01 Transitional as a minimum.
3. Choose colours from the 216 web-safe colours list.
4. Use style sheets.
5. Test pages in a browser with style sheets disabled.
6. When a client notifies you of an issue regarding access to content, then test against the specific issue and improve or solve it.

Guideline 1.2

Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively.

Best Practices

Media Attribute

CSS2 allows you to write different style sheets for different kinds of Web devices. These are known as media-specific style sheets.

e.g. @media screen { BODY { font-size: 16pt } H1 { font-size: 3em }

This works for style sheets that are media-specific. If an entire style sheet applies to one media type you can use the media attribute of the LINK element so browsers can find out what media types a style sheet applies to without downloading it.

e.g. Media attribute can define the following media options: (Please notice here sight, sound and touch output devices - this is why CSS2 is really great for ensuring access regardless of communication devices used by Canadians).

• Screen
• Print
• Aural (speech synthesizers)
• Braille (electronic braille readers)
• Embossed (braille printers)
• Handheld (small handheld devices with small screens and limited bandwidth; will not display graphics)
• Projection (transparencies; computers hooked up to projectors)
• TTY (text-based devices and other devices with fixed-pitch character grid)
• TV (television based presentations)
• All (all devices; will be ignored by browsers that don't support it)

Media can specify more than one output device. In this case: MEDIA="SCREEN, PRINT". This would signify that the style sheet could be applied to both screen and printouts. The aural style sheets are wonderful for speech synthesizers because they can provide, among many options, aural referencing. Aural referencing can be used to signify many things, such as links, headings, etc. It is important to provide page instruction to ensure that the online client understands what accessibility techniques the designer has provided and how to use the page or site.

Bugs relating to the attachment of style to pages

Media attribute bugs

Bug 1: Only screen supported
Only style sheets declared as media="screen" are used, those declared for 'print' or 'all' won't be read.

This means that you shouldn't declare media="all" if you want Netscape to read the style sheet.

Bug 2: Commas destroy
When the media attribute specifies a comma separated list of style sheets (e.g., media="screen, print") Netscape will ignore the style sheet.

Important Information

This is to advise you of the proposed procurement arrangements for accessibility testing to be implemented April 1, 2003. As you may be aware, the Web Accessibility Testing Services (WATS) have been contracted by the Treasury Board Secretariat and made available to departments and agencies for the last three years.

As of April 1, 2003, departments and agencies may procure their own accessibility testing services through PWGSC's Informatics Professional Services (IPS) Marketplace, or use the regular contracting services of their department / agency.

The PWGSC Informatics Professional Services Marketplace provides for:

1. Flexibility in the selection of a testing service provider based on the individual requirements of the department / agency
2. Flexibility in the level (degree) of accessibility testing required by the department / agency
3. Flexibility with the timing of testing to meet the specific needs of the department / agency
4. Flexibility of web services to be tested (Internet / Intranet / Extranet)
5. Flexibility with the duration of a contract with a service provider ranging from 1 day to a maximum of 100 days over a 12 month period

Departments / agencies are required to self-register in order to obtain access to the PWGSC procurement tool. Registration is completed through the IPS Web site under Info for Federal Departments.

Contact: Lucie Kealey, Supply Specialist
Email: lucie.kealey@pwgsc.gc.ca
Tel: (819) 956-1206
Fax: (819) 956-1432