Common Look and Feel for the Internet

Note: This is a printable version of the core information available on the Common Look and Feel (CLF) Web site, including each CLF Standard, Guideline, Interpretation, Rationale and Best Practice. It does not contain the Self-Assessment Guide, Toolbox, FAQs, Internet Guide, CLF Background or Recommendations for Intranets / Extranets. Links to those documents can be found on the CLF home page.

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

Collaborative Arrangements Section

Overview

GoC institutions participating in collaborative arrangements with other levels of government or the private sector face additional challenges in ensuring federal identity, presence and visibility. Web sites are perhaps one of the most contentious applications as space for identification is often limited and the party hosting the Web site maintains creative control of the Web site.

As well, the GoC must be sure to avoid making or implying an endorsement of an individual, company, organization or product.

Rationale

These issues fall into areas of responsibility of both the Government Communications Policy and the Federal Identity Program. The TB Secretariat's Service and Innovation Sector has created an interdepartmental working group to examine all identity issues relating to collaborative arrangements and develop solutions for promulgation in the renewed Government Communications Policy.

Interpretation

Institutions of the Government of Canada may visually represent themselves using one of three following identifiers: The institutional signature, the Government of Canada signature, or the "Canada" wordmark. In collaborative arrangements involving more than one Government of Canada institution, the institutions are to be identified by a single Government of Canada signature or "Canada" wordmark. In collaborative arrangements involving many partners, it is advisable to create a separate page dedicated to identifying the participants in order to avoid a confusing presentation of many symbols and logos throughout a Web site.

The decision as to what degree to apply CLF standards to Web sites that involve collaborative arrangements is not straightforward. This is because the GoC is involved in many different types of collaborative arrangements with many different types of partners.

Sites with a gc.ca domain name must apply all CLF standards fully. The gc.ca domain is meant to apply to GoC institutional Internet Web sites, though it is not meant to necessarily apply to all possible Web sites with which a GoC institution is involved.

A GoC institution's primary site and any related sub-sites would be logically expected to use a gc.ca domain designation. This includes sites that could be described as primarily related to program delivery and / or the provision of corporate information.

Collaborative sites with others, such as provincial, territorial or municipal governments, the private sector, etc. should have a different domain designation than gc.ca, such as .ca, .org or .com (e.g. http://www.cbsc.org). On these sites, appropriate CLF standards as they relate to accessibility, collaborative arrangements, cybersquatting, important notices and official languages still apply to the GoC contribution.

Note that GoC institutions must display one of the FIP identifiers thereby achieving a visual presence and balance between the government and its partners. One example might be a portal or gateway site. In this circumstance, a Memorandum of Understanding (MOU) should be used to define how best to identify the partners' and their contributions. Note that it is the responsibility of the appropriate minister to determine whether or not a particular shared-cost program requires federal identity in its publicity. As and when directed by the minister, a federal institution entering into a contract or agreement with other levels of government or private institutions must include provisions in the contract that set out the terms for joint identification of the partners.

In other collaborative arrangements, the GoC institution may have a lead responsibility. The institution may have funded the design, development and implementation of the site and may host the site server. Other participants may play a minor or limited role, for example as information sources. For such sites, the gc.ca domain name should be used and the CLF standards should fully apply.

2.1 Best Practices

An example of collaborative arrangement: http://www.cbsc.org

A Treasury Board Secretariat publication entitled Stretching the Tax Dollar - The Federal Government As 'Partner' : Six Steps to Successful Collaboration (October 1995) is an excellent reference for public sector managers who find themselves faced with the challenge of providing Canadians with quality services using alternative service delivery mechanisms.

Additional information on collaborative arrangements can be found in the Communications Policy of the Government of Canada.

Rationale

Trade marks, logos, professional certifications, special file formats, and software plug-ins may be important to a specific audience; however, use of associated icons can be perceived to constitute an endorsement.

Interpretation

The use of symbols and logos is allowed in collaborative arrangements.

The President of the Treasury Board has approved a number of symbols for government-wide use, such as the Millennium Bureau symbol and the Year of the Elderly Person symbol. However, even approved government-wide symbols should be displayed with discretion. Any other symbol intended to be used government-wide is subject to prior approval by the President of the Treasury Board.

Any other third-party icons, symbols or logos that represent the products and services of private enterprises or individuals must not be displayed on GoC sites. Providing relevant information discretely in text format, rather than using symbols and logos, reduces the appearance of endorsement.

2.2 Best Practices

Hyperlinking to and from GoC Web sites (January 2003)

Through the work of the CLF Hyperlinking Working Group, the following best practices were developed to guide departments and agencies with the implementation of the Hyperlinking Notice and to provide a coding example for links to non-GoC sites. The best practices also include criteria for linking and standard replies to requests to be considered before implementing links to and from non-GoC sites.

It is recommended that departments and agencies use the following wording for their Hyperlinking Notice that has been vetted by TBS legal counsel for inclusion in their Important Notices statement.

With federal Internet sites now established as a viable and effective government communications and outreach medium, and the proliferation of the Web in general throughout Canadian society, there has been a marked increase in the number of requests received by the Government of Canada (GoC) from non-government organizations to establish links from GoC Web sites to non-GoC Web sites and vice versa. 

As a general rule, it is not necessary to have a linking agreement or to obtain permission when establishing a link to another site.  Also, as a general rule, the GoC reserves the right to refuse or to terminate links without notice.

These best practices should be applied to all links on Web sites, irrespective of the document format (e.g. HTML, PDF, RTF, etc.):

1. The Important Notices section of a GoC institution's Web site should use the following Hyperlinking Notice in the Important Notices section that informs users of the terms and conditions under which links may be made to non-GoC Web sites.
   
   Hyperlinking Notice
   
   For sites that use the "TITLE" attribute in the HTML link tag for the Important Notices, reference should be made to the Hyperlinking Notice.
2. Where appropriate, GoC institutions are encouraged to use lists of links rather than embedded or contextual links. This method of displaying information improves the overall accessibility of the page.
   A links page or page with a separate list of links should provide a link to the Hyperlinking Notice in the Important Notices section. It should be preceded by a statement such as: "For further information on the [name of institution]'s hyperlinking practices, please refer to the Hyperlinking Notice."
3. Links to non-GoC Web sites, particularly when they are interspersed throughout the site, should be referenced in a clear way to a directive or information that explains that the user is leaving a GoC Web site.  This can be accomplished by using the "TITLE" attribute in the HTML link tag.
   Example:
   <a href="http://www.nongovernmentofcanadasite.com" title="Link to a non-Government of Canada site - For more information on the [name of institution]'s hyperlinking practices, please refer to the Hyperlinking section of the Important Notices at the bottom of this page." >nongovernmentofcanadasite.com</a>
   Example: nongovernmentofcanadasite.com
   Note: The above solution does not work in Netscape. An alternative is currently being explored.
4. GoC institutions should develop a set of criteria for linking to and from their Web sites. Once established, these criteria should be applied consistently to all of the institution's Web sites and may be published for reference by the public. A sample set of Criteria for Hyperlinking has been developed, and GoC institutions are encouraged to adapt it for use on their Web sites in consultation with their legal counsel.
5. GoC institutions should verify the quality of links on their Web sites. This includes regular reviews to ensure that the link is not broken and that the content behind that link remains appropriate.  Please refer to the Communications Policy of the Government of Canada and the Government of Canada Internet Guide with respect to monitoring Web sites. It is recommended that this activity be undertaken on no less than an annual basis and/or if the institution receives a notice or becomes aware that links are not current or appropriate.
   For example, a site that may have been appropriate, through time, may become inactive or, in some cases, may be purchased by another third party. This third party may, in turn, choose to publish inappropriate materials to their site, making it critical to not only verify if links are broken but also to check the content of the sites to which the GoC institution is linking. 
6. According to Standard 6.6, GoC Web sites can use frames only as an alternative format and, as a general rule, GoC Web sites should not use framing.
   If frames are used as an alternative format, GoC institutions should not load the content of other Web sites, be they GoC or non-GoC, into the frames associated with their site unless a hyperlinking agreement exists. Since users are not necessarily aware that they have been linked to another site, framing in this manner may generate complaints of copyright and trademark infringement.
7. Deep linking refers to the practice of providing a link to internal pages of another Web site, bypassing the home or splash page of the site to which the link is created.
   As a general rule, an agreement is not required to create a deep link from a GoC to a non-GoC Web site; however, you should consider hyperlinking to home pages or obtaining permission before deep linking to private sector or commercial Web sites under the following circumstances:
   
   • When the site owner, by notice on the Web site, prohibits deep linking without permission; or
   • When bypassing the site's home page by navigating to a specific sub-page will result in a loss of advertising opportunities and revenue.
8. When establishing Collaborative Agreements or MOUs that involve or may involve linking, these agreements should address linking practices and procedures. These clauses should be drafted in consultation with departmental legal counsel.
   In establishing agreements that address linking, GoC institutions may also wish to confirm the date for renewal of the non-GoC site's domain, as well as any maintenance and linking standards; these will help to ensure that the site to which the GoC links remains appropriate and current.
9. As a general rule, establishing a link to another site without a linking agreement or permission in advance is not viewed as violating any rights; however, a sample set of Standard Replies to linking requests to assist you in responding to link requests has been developed. These replies can be adapted by GoC institutions.
10. Linking should be done in accordance with the Directive on the Use of Official Languages on Web Sites.

Cybersquatting Section

Overview

Some private sector organizations are misrepresenting themselves as Government of Canada institutions or making unauthorized use of Government of Canada titles by registering Internet addresses - known as domain names - that resemble Government of Canada institutional titles.

These organizations then use the false, but similar domain names, to direct unsuspecting Internet users to misleading and sometimes offensive material. Some organizations also offer to sell the domain names resembling institutional titles that they have registered to anyone who is prepared to pay, including government institutions.

This is known as "cybersquatting". The adverse consequence of "cybersquatting" is the hindrance of legitimate access to Government of Canada Web sites.

Rationale

Institutions are finding instances of Internet sites which clients may equate with their programs and services and may cause embarrassment to the government and the department. This situation is creating confusion for our clients and preventing legitimate access to federal government programs and services.

Interpretation

Institutions are encouraged to consult with the various business lines and regional and local offices to develop a list of names. The names should be considered from the legal and business perspective as well as from the perspective of your clients and the names they commonly associate with your services - perhaps the most important consideration.

For example, an organization may register domain names such as NRCanada, NRCan, RNCan, ResourcesCanada and RessourcesCanada under the following generic top level domain names - .com, .net and .org.

Institutions can consult the Netcraft Web site for the list of domain names already registered under .com, .net and .org.

Institutions can consult InterNic for the list of companies accredited as registrars for .com, .net and .org.

Institutions are reminded that only the gc.ca domain names are to be used as the official identification of the departmental Web site(s). All other registered domain names must act as aliases or pathways to your site(s). To register gc.ca domain names, please contact registry@gc.ca

3.1 Best Practices

• Guidelines for Registration of Top Level Domain Names (July 2001)
• Guidelines for .ca (October 2000)

Guidelines for Registration of Top Level Domain Names (July 2001)

Background

This summer marks the first introduction of new worldwide generic top level domains (TLDs) since dot.com was created in 1985. There are seven new top level domains which have been approved by the Internet Corporation for Assigned Names and Numbers (ICANN), they are dot.aero, dot.coop, dot.biz, dot.info, dot.name and dot.pro. The most anticipated of these, dot.biz and dot.info, have had their launch times approved and are ready to go. These new registries will add to the already familiar registries such as dot.com, dot.org, dot.edu and dot.gov.

Dot.info will be an unrestricted TLD, open to any business, person or agency to register for any purpose. Afilias, a consortium of eighteen domain names registrars, was awarded the right to operate the dot.info registry following its application and approval by ICANN.

Dot.biz will be a restricted TLD, open only for bona fide commercial or business purposes excluding using or intending to use the domain name exclusively for personal non-commercial purposes or for the expression of non-commercial ideas, e.g. thiscompanysucks.biz and registering the domain name for the sole purpose of selling, trading or leasing the domain name. It would appear from the registration restrictions outlined by NeuLevel, the dot.biz Registry operator chosen by ICANN, that some government sites would qualify for a dot.biz name. For further details on registration restrictions and procedures and a list of accredited dot.biz registrars, please refer to the NeuLevel Web site.

Dot.museum is to be sponsored by the Museum Domain Management Association, and restricted to museums. ICANN's negotiations on agreements with the sponsoring organization are still in a formative stage. Information will be posted on the ICANN Web site as the negotiations progress.

Dot.info registration process

On July 25, 2001 the "Sunrise Period" for the registration of dot.info domain names will open.

The "Sunrise Period" of 30 days is from July 25 - August 27, 2001 during which owners of trademarks and service marks (registered as of October 2, 2000) may register their marks in the dot.info domain. The Sunrise Period is intended to prevent some of the problems of cybersquatting and domain name speculation. Government institutions with trademarks, service marks and official marks - registered prior to October 2, 2000 - are therefore advised to register their marks in the dot.info domain during the sunrise period, e.g. environmentcanada.info. This can be done with any ICANN's - accredited registrar as soon as the sunrise period opens. Refer to information below that links you to a list of ICANN's-accredited registrars.

During the Sunrise Period, Afilias will accept registrations in 5 rounds from the accredited registrars. A randomized, round-robin processing system will limit any one registrant or registrar's ability to gain in domain name submissions. A more detailed description of the round robin process can be found on the Afilias Web site.

On September 12, 2001, the dot.info domain will be open for general registration during what is termed the "Start-Up Period". Domain registrations submitted during the Start-Up Period will be processed with the same randomization process used during the sunrise period.

The majority of government institutions, i.e., those that do not hold registered trademarks, service marks or official marks, should register the names of their applied titles, acronyms and programs during the Start-Up Period - which follows the sunrise period, in the same fashion that they previously registered in such domains as dot.com, dot.org, etc.

Disputes regarding conflicting marks may be raised according to Afilias' Sunrise Challenge policy, which will be administered exclusively by the WIPO Arbitration and Mediation Center. The challenge process begins August 28, 2001 for 120 days.

List of accredited domain name registries

ICANN's maintains a list of accredited registrars for dot.com, dot.net and dot.org on its Web site, and it lists where they are based. You can find it at: http://www.icann.org/registrars/accredited-list.html

Another reference of accredited domain name registrars can be found at the Web site operated by the .info registry Afilias.

The selection of a domain registrar will be on a case-by-case basis. Each institution has different requirements that will need to be matched with the services being offered by each of the accredited registrars.

Wholesale and retail costs for registering a domain name

According to the Afilias dot.info registry, and to whom the registrars must pay a fee for each dot.info domain name that they register, Afilias will charge US$5.75 for each domain name registration per year.

Registrars will be required to register each domain name for a minimum of two years and a maximum of ten years in one-year increments. As such, registrars will be billed US$11.50 for each two-year initial registration. Afilias will collect registration fees for the total term at the time of registration.

The retail costs for registering a domain name will depend upon the package of services that the registrar is bundling with the domain name registration service. This might be as low as $29US per year for your basic registration to over $200US per year for a full service that includes the maintenance of your Web site, redirecting your e-mail and the registration of your domain name(s).

Domain Name Renewal Fees

Similarly, for registration renewals, Afilias will charge registrars $5.75 for each renewal year. If a registrant wishes to renew a registration, the renewal must be for a term of between one and ten years. These revenues will begin during the third year of operations when the first round of two-year registrations become due for renewal. Afilias will collect renewal fees for the total renewal term at the onset of the renewal term.

Afilias has chosen a flat annual registration and renewal fee revenue structure for two primary reasons. First, registrars have become accustomed to the annual-fee pricing structure developed by Verisign Global Registry Services in its relationships with ICANN's-accredited registrars. Second, Afilias believes that Internet-based commerce is currently not well-suited for discrete micro-payments based on specific transactions performed by the registry.

Guidelines for Registering .ca domain names (October 2000)

Institutions should consider registering its domain names under .ca - the country code top level domain name. For example, NRCan.ca. A list of accredited registrars is available at CIRA.

Issue

The purpose of this e-mail is to inform departments and agencies (institutions) of the changes to the rules and procedures for registering Internet domain names under the .ca designation and indicate how these changes may impact their institution, whether or not they hold an Internet .ca domain name now.

Background

The current rules for registering in the .ca domain permit only federally incorporated corporations, corporations with offices in more than one province, or Canadian registered trademark holders to register .ca domain names, and limits them to one domain name in English and one in French. Departments and agencies do not, as a rule, register directly under the .ca domain name but register their domain names in the gc.ca sub-domain with the PWGSC GoC registry that is accessible at http://registry.srv.gc.ca/.

On November 1, 2000, when the Canadian Internet Registration Authority (CIRA), a not-for-profit, private sector corporation, assumes the responsibility for the administration of the .ca domain names from the University of British Columbia, these rules will be relaxed, and any individual or organization meeting certain Canadian requirements will be able to register any number of .ca domain names.

As a result, institutions will have to re-register any existing .ca domain names they want to maintain, and register any new institutional titles under .ca they want to protect against unauthorized use and cybersquatting.

New Registration Rules

By November 1, 2000, as part of this transition, all existing .ca institutional domain name holders who wish to keep their .ca domain name(s) must re-register the domain name with CIRA through one of CIRA's accredited registrars - a list can be found at: http://ro.cira.ca/re_choose_en.

After November 1, 2000, all institutions that want to protect their institutional titles against unauthorized use and cybersquatting must register new .ca domain names with CIRA through one of CIRA's accredited registrars - a list can be found at: http://ro.cira.ca/re_choose_en.

CIRA charges registrars $20 per domain name registration per year, and registrars are free to set their own prices for domain name registrants, subject to competitive marketplace forces. Departments and agencies are, therefore, encouraged to research the prices and other terms being offered by registrars and select the most appropriate and cost effective package for their needs.

Cybersquatting

These new registration rules will permit individuals and organizations to register .ca domain names that resemble Government of Canada institutional titles and then use the false but similar domain names to direct unsuspecting Internet users to misleading and sometimes offensive material. Some of these organizations also offer to sell the domain names resembling institutional titles that they have registered to anyone who is prepared to pay. This is known as "cybersquatting". The adverse consequence of "cybersquatting" is the hindrance of legitimate access to Government of Canada Web sites.

CIRA will also be implementing an on-line arbitration system that departments and agencies may wish to consider using for the recovery of .ca domain names that are registered by unauthorized parties. More information on this procedure will soon be available on the CIRA Web site at http://www.cira.ca.

Recommendations

Therefore, I encourage institutions, if they have not already done so, to re-register any .ca domain names they want to maintain, and to register the variations of their institutional title under .ca that could be registered and used by an unauthorized party to misrepresent the institution on the Internet, using the procedures mentioned above.

I would also ask you to advise us of the .ca domain names that the institution has registered by sending them to the Common Look and Feel Web site at clf-upe@tbs-sct.gc.ca.

This action is similar to that referenced in the letter of May 29, 2000 from the Secretary of the Treasury Board, Mr. Frank Claydon, to the head of your institution. This letter requested institutions to register its institutional titles under the .com, .net and .org domain names.

The preceding recommendations do not require institutions to re-register their gc.ca sub-domain names with the PWGSC GoC registry. However, institutions are reminded that domain names registered outside the gc.ca sub-domain are only to be used as aliases to direct your users to your bilingual Internet Welcome page in accordance with the Treasury Board Standards for Common Look and Feel on the Internet www.tbs-sct.gc.ca/clf-nsi/inter/inter-07-01_e.asp.

For further information on this registration process, please contact Ian Sinclair, Director, Chief Information Officer Branch at 613-957-2478 or by e-mail at sinclair.ian@tbs-sct.gc.ca.

Michelle d'Auray
Chief Information Officer
Treasury Board Secretariat
October 2000

Notes

• The organization now responsible for .ca is CIRA. Their Web site is: http://www.cira.ca
• You can do a search of all domains at Internic: http://www.internic.ca/. The cost per year would be approximately: $100+GST for .ca . Details at: https://www.internic.ca/payment.asp
• Web Hosting services: http://www.canadiandomain.ca/

E-Mail Section

Overview

Most government e-mail software now includes an "AutoSignature" function, which automatically attaches user-defined text to the bottom of every outgoing e-mail. Institutions that do not have the AutoSignature function in their e-mail software should develop other means of including appropriate identification information in all electronic correspondence. In situations in which e-mail is sent not by a specific individual, but rather by a service or program office (i.e. Webmaster@canada.gc.ca), full institutional contact information should still be made available.

Electronic mail is fast becoming a preferred communication tool for busy Canadians. By standardizing the look and feel (content and format) of electronic forms on all GoC Web sites, this initiative will make it easier for individuals using electronic media to make contact with public servants from any institution.

Rationale

While GoC Web sites are an excellent means of providing information to the Canadians at their convenience, it is important that individuals also be given the opportunity to contact a specific institution, operational area or individual when they need additional information or support. Electronic mail is an effective alternative to personal contact via the telephone or in-person visits, but it has inherent challenges.

Interpretation

The e-mail address supplied as a link from the 'Contact' button on the common menu bar is one means users have to contact the institutional Web site. Another means would be a feedback form provided under the 'Help' button located on the same common menu bar.

When personal information is being collected, users must be informed of their rights and responsibilities and the obligations of the institution regarding its protection. Although e-forms generally represent a separate page on Web sites, they are subject to the same CLF standards regarding the FIP identification of the institution, official languages and accessibility requirements.

4.1 Best Practices

Forms are another means of providing users with a means of contact.

To best serve the public, forms should include fields for the user's name, E‑mail address and mailing address, as well as a field where they can input comments, questions, or requests for information. As well, users should be given the opportunity to indicate their preferred method of receiving a response.

The use of mailto tools has become a widely used convention on the Web and is an excellent means of enabling end-users to make quick comments about specific Web pages or topics. These tools offer a number of benefits in that users do not have to input their personal information because the message header automatically includes their addressing information, a date stamp and various other pertinent information. They can also easily be tailored to include the URL of the originating Web page in the subject line.

Mailto tools also have several disadvantages. Firstly, the client's browser must be configured to send E-mail (most systems are configured in this manner), and because all text is free-text input, it cannot be validated. The tool lacks an automatic confirmation or acknowledgement function, meaning there is no way to inform users that their correspondence has been received. To facilitate universal accessibility, the Internet address that MAILTO responses will be delivered to should be made visible for users who can not utilize this function. Although this will open up that address to SPAM, the risk is unavoidable.

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 provided, 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

The oldest assistive technologies can handle well designed HTML forms. The trick is to get page designers to keep them simple and on the server-side.

Rationale

With the increased use of electronic mail as a communication tool for delivering GoC information, it is important to identify the source of the information at both institutional and individual levels. Public servants who provide information via e-mail can not make assumptions regarding the end-use of information. E-mail recipients may respond immediately, store the message indefinitely, forward it to other recipients, import it to other documents or print a hard copy record. Thus, all e-mail messages must contain enough information to identify the individual and the institution s/he represents, as well as sufficient contact information to facilitate further communication via various methods (i.e. telephone, fax, post, etc.).

Interpretation

Outgoing e-mail to which a signature block must be attached includes all correspondence being sent to institutional clients outside of the department. For example, these clients may be Canadian or international citizens or businesses, other levels of government - provincial, municipal, territorial, international, volunteer organizations or personnel in other federal government departments.

• FIP Signatures for E-mail
• Examples of e-mail signature blocks are provided for your use.

4.2 Best Practices

December 2002

1. It is important to remember to include the institution's applied title found at http://www.tbs-sct.gc.ca/Pubs_pol/sipubs/TB_FIP/titlesoffedorg1_e.asp in both official languages in the signature block of every employee. This applies to the signature block of employees whether they are providing information and services in a region designated bilingual or unilingual. For an example of a signature block, please refer to CLF Signature Blocks.
2. The inclusion of "Government of Canada / Gouvernement du Canada" is recommended for the signature blocks of all institutions for the following reasons:
   • It ensures the Government of Canada is identified where official graphic identifiers are not present or visible
   • It ensures the Government of Canada is identified in cases where institutions do not have an approved applied title
   • It supports TB minister's decisions on ensuring the primacy of the identity of the Government of Canada
   • It ensures that international audiences correctly identify an institution as part of the Government of Canada
3. A Teletype number (TTY) for the institution of the sender should also be included with the telephone and fax numbers as part of your signature block.

Example:

John Doe
613-123-4567 | facsimile / télécopieur 613-123-4567 | TTY/ATS 613-123-4567
doe.john@hc-sc.gc.ca
Health Canada | 123 Green St. Ottawa ON K2P 1B2
Santé Canada | 123 rue Green Ottawa ON K2P 1B2
Government of Canada | Gouvernement du Canada

July 2000

A good practice would be to include a signature block when e-mail is being sent within the department when the e-mail being sent has direct impact on the management of government and the various activities it carries out. For example, if the content of the e-mail is required by the institution to control, support or document the delivery of programs, to carry out operations, to make decisions, or to account for activities of government, then a signature block should be attached.

Rationale

The Federal Identity Program applies to all GoC corporate identity applications, such as institutional letterhead, business cards, complimentary cards, note paper, etc., and e-mail is no exception. With the evolution of graphic, windows-based e-mail software, the incorporation of the visual identifiers of the GoC is now possible. E-mail must be treated in the same manner as traditional business stationery applications to ensure proper identification through the institutional signature and the "Canada" wordmark.

4.3 Best Practices

June 2003

The Executive Summary of the e-mail assessment, completed by the CLF E‑mail Working Group, highlights the results of the assessment and their recommendations.

December 2002

An assessment by the CLF E-mail Working Group of various e-mail software applications in use across federal institutions has been undertaken. As a result, for those e-mail systems that cannot display the graphical elements ("Canada" wordmark and the institutional signature) in an accessible manner (e.g. HTML and alt text), it is important to include the institution's applied title in both official languages in the signature block of every employee. This applies to the signature block of employees of bilingual and unilingual designated regions. For a list of bilingual applied titles, please refer to http://www.tbs-sct.gc.ca/Pubs_pol/sipubs/TB_FIP/titlesoffedorg1_e.asp. For additional information on the use of applied titles and the use of the words "Government of Canada" in signature blocks, please refer to the Best Practice for CLF Standard 4.2.

July 2000

To ensure consistency in application, this initiative should be managed by mail and/or systems administrators rather than by individual GoC employees.

It should be noted that technological incompatibility between the sender and the recipient's e-mail systems might cause the institutional signature and the "Canada" wordmark to be stripped from e-mail messages.

Rationale

Auto-Acknowledgement:  Sample 1

Clients must be assured that their correspondence has been received and will be delivered to the appropriate place and that someone will respond to it. As a professional courtesy to GoC clients, an automatic electronic acknowledgement must be sent indicating that their correspondence has been received. The actual response to the e-mail will be prepared at the discretion of the institution.

From the client or citizen perspective, uncertainty can arise when sending an e-mail to a generic, or institutional or group mailbox, such as, for example, Department X@..., or Division Y@... or Webmaster@... These are used by some departments in the Contact Us or the Help section of the Web site. There is no individual contact, no person, no name to whom one might direct a query regarding the status of the question, comment or request. There can be a question raised in the client's mind - rightly or wrongly - "Will anyone in this nameless, faceless organization really pay attention to my message?" The automatic response in this case, at a minimum, indicates that the mail has been received and that someone will be attending to it. As mentioned, this is done as a courtesy and to inject a slightly "personal" touch into an automated procedure. It is these generic mailboxes to which the standard is addressed, and from which automatic responses must be generated.

In the case where an individual's e-mail address is used, there is no need to generate an automatic acknowledgement. Why?

From the client perspective, the situation is quite different. Here, there is a real person whom one can re-contact regarding any queries or status. If the client doesn't already have the telephone / fax number, it is easily obtainable by having the individual's name / organization, thereby opening other communications channels. If the e-mail, in fact, cannot be delivered for some technical reason, the system will so advise.   This situation is clearly much more service-oriented than is the generic case above. The client does not have same question arise when dealing with someone specific. The courtesy and the personal touch have already been applied. Someone "real" will be paying attention, and the client knows exactly who that is.

If the external address is a GoC site, with a gc.ca e-mail address, then the acknowledgement of receipt and the promise of action should take place. If it is not a gc.ca site, the handling of e-mail should be left to the external addressee to deal with as they see fit. We also want to make a clear distinction between generic or organizational mailboxes and personal ones.

4.4 Best Practices

If the individual is out of the office for an extended period, the Out of Office Auto-Reply should be used.

E-Mail loops best practices

1) Each corporate e-mail account will have two Internet addresses with one set-up as the default reply e-mail address. When a message is sent to the primary e-mail address (e.g. webmaster@tbs-sct.gc.ca), the auto-reply will be sent using the reply e-mail address (e.g. re-webmaster@tbs-sct.gc.ca). The reply e-mail address must have the auto-reply rule turned off. There is no possibility of a mail loop because any replies sent back to the corporate e-mail account will be addressed to the reply e-mail address (re-webmaster@tbs-sct.gc.ca) which does not have an auto-reply rule.

Example of Option 1:

-----Message d'origine-----
From: re-webmaster@tbs-sct.gc.ca
Date: March 1, 2001 2:43 PM
To: webmaster@tbs-sct.gc.ca
Subject: Looping address example

2) Another option is when a message is sent to a corporate e‑mail address (e.g. webmaster@tbs-sct.gc.ca), the auto-reply should incorporate a blank e‑mail in the "From" field. This will break the "Looping of auto-replies" because the system can't reply to the message because the "From" field is left blank.

Example of Option 2:

-----Message d'origine-----
From: THIS IS BLANK
Date: March 1, 2001 2:43 PM
To: webmaster@tbs-sct.gc.ca
Subject: Looping address example

About Option 2. Some mail systems refuse messages that do not have a valid addresses in the From field. The message would not be delivered and you wouldn't know it. They would never know you got their message.

Important Notices Section

Overview

In consideration of the fact that electronic media is relatively new, and that every day hundreds of Canadians use it for the first time, it is important that GoC institutions provide information about the rights, responsibilities and legal obligations of the information provider and the end-user. Without overburdening end-users, institutions should demonstrate their compliance with the many policies and procedures that govern information dissemination through electronic media.

This can best be achieved through a standard hyperlink, Important Notices, to be located at the bottom of each Web page on every GoC site. Generally, CLF takes the position that material on GoC Web sites have been posted to support information dissemination through free public access.

Rationale

Standard wording and placement for information about rights, responsibilities and legal obligations associated with using materials found on GoC Web sites lends credibility to the information source and further demonstrates that all GoC information is subject to the same rules and regulations. Adopting a plain language approach to such notices helps users understand their purpose and better identify how the conditions apply in specific circumstances.

The link to the Important Notices is included on each page so that users can access the information when and where they choose.

Interpretation

• The placement of the Important Notices link must be located in the lower right hand corner of each content page.
• The placement of the Important Notices link on the Welcome Page depends on the location of the office providing the service.  See Standard 7.3(b).

5.1 Best Practices

Official Languages Notice (January 2003)
Hyperlinking Notice (January 2003)
HTML "mouse-over" Coding for Important Notices link (January 2003)
Forms (July 2000)
Mailto Tools (July 2000)

Wording for Official Languages Notice (January 2003)

In her report "Official Language Requirements and Government On-Line", the Commissioner of Official Languages recommended that the Treasury Board Secretariat "find innovative and appropriate ways (slogan, icon, etc.) for federal institutions to inform members of the public, on the home page of their Web site, of their right to receive information and to interact with the federal government in the official language of their choice". In response, it is recommended that departments and agencies use the following wording that has been provided by TBS Official Languages Branch for inclusion in their Important Notices statement:

Official Languages Notice

• (Insert department / agency name) respects the Official Languages Act and the relevant Treasury Board policies, and is committed to ensuring all information and services on this site is available in both English and French (or in one language only if a unilingual office). However, users should be aware that some information from external sources that are not subject to the Official Languages Act is only provided as a convenience and is available only in the language in which it was provided.

(Option for inclusion by those departments / agencies that provide information / services in more than one language) Information and services that are provided on this site in language(s) other than English or French are only provided as a convenience to the user when available.

Hyperlinking Notice (January 2003)

For further information about Hyperlinking, see the Best Practices for Standard 2.2 - Hyperlinking to and from GoC Web sites (January 2003).

It is recommended that departments and agencies use the following wording for their Hyperlinking Notice that has been vetted by TBS legal counsel for inclusion in their Important Notices statement.

Hyperlinking Notice:

• Links to Web sites not under the control of the Government of Canada (GoC) are provided solely for the convenience of users. The GoC is not responsible for the accuracy, currency or the reliability of the content. The GoC does not offer any guarantee in that regard and is not responsible for the information found through these links, nor does it endorse the sites and their content.
  Users should be aware that information offered by non-GoC sites that are not subject to the Official Languages Act and to which the [name of institution] links, may be available only in the language(s) used by the sites in question.

HTML "mouse-over" Coding for Important Notices link (January 2003)

Because of the additional notices that are being recommended for inclusion in the Important Notices document, we encourage departments / agencies to include the HTML coding to enable a "mouse-over" feature. This will display informative text when an Internet user's mouse hovers over a link (e.g. a list of the notices that are included in the "Important Notices" link):

<a href="http://www.tbs-sct.gc.ca/cioscripts/in-ai_e.asp?Who=/clf-nsi/" title="Privacy Notice, Official Languages Notice, Hyperlinking Notice, Copyright Notice">Important Notices</a>
Example: Important Notices

Note: The above solution does not work in Netscape. An alternative is currently being explored.

Forms (July 2000)

Forms are another means of providing users with a means of contact.

To best serve the public, forms should include fields for the user's name, E-mail address and mailing address, as well as a field where they can input comments, questions, or requests for information. As well, users should be given the opportunity to indicate their preferred method of receiving a response.

When personal information is being collected, users should be informed of their rights and responsibilities and the obligations of the institution regarding its protection. Although e-forms generally represent a separate page on Web sites, they are subject to the same CLF standards regarding the FIP identification of the institution, official languages and accessibility requirements.

Mailto Tools (July 2000)

The use of mailto tools has become a widely used convention on the Web and is an excellent means of enabling end-users to make quick comments about specific Web pages or topics. These tools offer a number of benefits in that users do not have to input their personal information because the message header automatically includes their addressing information, a date stamp and various other pertinent information. They can also easily be tailored to include the URL of the originating Web page in the subject line.

Mailto tools also have several disadvantages. Firstly, the client's browser must be configured to send E-mail (most systems are configured in this manner), and because all text is free-text input, it cannot be validated. The tool lacks an automatic confirmation or acknowledgement function, meaning there is no way to inform users that their correspondence has been received. To facilitate universal accessibility, the Internet address that MAILTO responses will be delivered to should be made visible for users who can not utilize this function. Although this will open up that address to SPAM, the risk is unavoidable.

Rationale

Inclusion of a plain language Copyright / Permission to Reproduce notice on the Important Notices hyperlink from all Web pages provides direct access to information regarding content ownership and the conditions associated with reproduction of materials posted on GoC Web sites.

The Internet provides a tremendous vehicle for distributing an enormous range of information to Canadians, when and where they need it. One of the GoC's goals is to give Canadians information that is easily identified as having been created and/or distributed by the Government of Canada. Through the act of posting information on this medium, institutions are essentially indicating they want individuals to use, and to share, information found in this freely available format.

The absence of a copyright notice does not mean that copyright does not exist; anyone wishing to reproduce materials from an institutional Web site is therefore going to require permission. Instead of responding to individual requisitions for permission, institutions should make extensive use of permission notices on their Web sites, i.e., a notice to the public indicating the terms and conditions on which the materials on the site may be reproduced without further permission from the author institution. In fact, a copyright notice without a permission notice leaves the user in the position of not being able to reproduce the materials without infringement of copyright (subject to the fair dealing exceptions for private study and research).

In exceptional circumstances, institutions may wish to prohibit reproduction of some materials posted on their sites (i.e. priced publications that have been made available over the Internet). Such institutions should carefully examine their reasons for prohibiting the commercial redistribution of these materials. If the institution's primary interest is in facilitating the widest possible dissemination of its information, commercial redistribution should not be prohibited. Rather, commercial redistributors should be required to attach a notice to their reproductions to the effect that the materials are available in their original form from a GoC Web site.

Finally, it is important to consider adequate protection for third-party copyright materials and graphical elements on GoC Web sites. Generally, it is preferable for institutional Web sites to provide links to the third-party materials, rather than host them directly. An institution that hosts non-Crown copyright materials that are subject to prohibitions on reproduction really has no meaningful way of ensuring that the third-party copyright is respected. In such cases, a "third-party copyright" notice should be provided that indicates the conditions for reproduction of non-Crown copyrighted content.

Rationale

The Privacy Notice assures end-users that information automatically acquired through a visit to any GoC site will not be used other than for the express purposes of Web maintenance and security.

Interpretation

Each institution's Web site Privacy Notice should be developed as a co-operative effort of the areas responsible for information technology, computer security, privacy and protection of personal information, communications, legal services and information management.

Every institution's Privacy Notice must include the following elements:

• Identification of the organization and how it can be contacted, including the name or position title of the person to contact with any Web site privacy concerns (normally the Privacy Co-ordinator)
• A clear description of any personal information which is collected automatically, a statement that such information is protected under the Privacy Act, the purpose for which it is collected, who will have access to it, how long it is kept, where it is kept and how an individual can access and correct their own personal information
• A statement explaining that should the user choose to provide personal information through e-mail or other means, such information is protected under the Privacy Act and will only be used for the specific purposes for which it has been provided (e.g. to respond to a specific request), or where required by law, how long it is kept, where it is kept and how to obtain access and request corrections
• A statement that non-identifiable or statistical information may be collected for audit purposes, for use in maximising effectiveness, or for another purpose specified here, if this is the case
• An explanation of any security use of information for purposes such as tracking suspected intrusions or the source of a computer virus, or controlling access to the system
• A statement concerning whether cookies, or any other data, are placed on the user's machine, and how they are used
• A description of any privacy-enhancing technologies in use or available for use such as the Public Key Infrastructure (PKI) or Secure Socket layer (SSL)
• A statement that individuals may contact the Office of the Privacy Commissioner if they are dissatisfied with the response they receive from the institution privacy contact on a privacy concern with the Web site.

The Privacy Notice must provide enough detail to allow users to understand what information will be collected and when, and to make an informed decision concerning whether to remain at the site.

Two examples of Privacy Notices have been provided see www.tbs-sct.gc.ca/clf-nsi/5/5ex2_e.asp. Use the appropriate bullets from the 2 examples to build your own Privacy Notice.

Guidelines for Cookies on Government of Canada Web Sites (August 19, 2002)

5.3 Best Practices

An institution's Web site Privacy Notice should include a statement concerning:

• Links to other sites not covered by this privacy policy
• Any specific institutional policy on collecting information from children online

Institutions should also remind users that, unless specifically noted otherwise, neither electronic systems or e-mail are secure information transmission methods, and that it is not recommended that sensitive personal information be transmitted electronically.

In some circumstances institutions may use an outside service provider as a Webmaster, and may provide a link for sending a message to the Webmaster. In those circumstances, the outside service provider should be under a contractual obligation to treat any personal information as though it were covered by the Privacy Act. In addition, the institution must make it clear to users that they are sending information outside the institution.

Rationale

From any point at which GoC Web site users are given the opportunity to voluntarily provide personal information, they must be informed of the conditions under which their personal information will be protected.

Every institution which is subject to the Privacy Act must ensure that each collection of personal information conforms to the requirements of that Act. The requirements apply equally to electronic collections as they do to paper-based collections. Any time personal information is collected electronically, the individual must be properly informed of their rights, in the same way as if the collection was done via more traditional means.

One of the differences between electronic communications and paper-based communications is that it may not be obvious to the individuals involved whether or not personal information is being collected in the course of any specific interaction. For these reasons, every Web site must include a Privacy Notice, even if no personal information is collected through that site.

Interpretation

A statement must actually appear next to the text requiring the personal information, for example an application form or survey, etc. informing individuals how the personal information will be used, which parts of the form are discretionary or mandatory, how long the personal information will be kept, where it will be kept (which Personal Information Bank) and how they can obtain access to their information.

Notice and Consent Guidelines in an On-Line Environment (April 23, 2003)

5.4 Best Practices

Refer to the following checklist for a complete list of items to be considered:

Privacy Notice Statement Checklist

Indicate:

1.  That all personal information provided is protected under the Privacy Act
2.  Under what authority the personal information is being collected
3.  Why the personal information is being collected
4.  What personal information is collected automatically
5.  On input forms, which parts are mandatory and which are discretionary
6.  How the personal information is being collected automatically
7.  Where the personal information will be kept (i.e. PIB)
8.  How the personal information will be protected during transfer and storage
9.  How long the personal information will be kept
10. When the cookie will expire if cookies are used
11. Who will have access to the personal information
12. How users can gain access to their personal information
13. How users can correct their personal information
14. Contact information

Guideline 5.1

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

Rationale

Institutions that choose to host or make links to externally sourced information on their Web sites may want to protect themselves from liabilities associated with the accuracy or reliability of such information.

However, institutions are cautioned against the overuse of disclaimers as they have the tendency to discredit the product and the information source.

Best Practices

If a disclaimer is used it must be directly attached to the externally sourced information and must describe the information to which the disclaimer applies.

The following are examples of disclaimers:

• Third party information hosted on the institutional Web site
  This information has been provided by an external source. Although every effort has been made to ensure the accuracy, the currency and the reliability of the content, [name of department] does not offer any guaranty in that regard.

• For links to other Web sites not under the control of the institution
  This link is provided solely for the convenience of [department] Web site users. [Department] is not responsible for the information found through this link.

Guideline 5.2

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

Rationale

All works of substantive originality are covered by copyright protection, regardless of whether or not the Crown copyright symbol is applied © Her Majesty the Queen in Right of Canada, represented by the Minister of Public Works and Government Services, Year. Application of Crown copyright is most often intended as an assertion of ownership, rather than as a blanket prohibition on the reproduction or use of the materials. The use of the copyright tag is primarily an exercise in branding, thereby ensuring credit for the author institution. However, Web sites typically contain some examples of information that cannot sustain Crown copyright because they lack sufficient originality (i.e. databases,) or were produced jointly with organizations outside the GoC and are therefore subject to third-party copyright. In addition, much information remains useful to the public long after its original copyright has expired. For all of these reasons, it may be inappropriate to assert Crown copyright vis-à-vis individual GoC sites in their entirety.

If there is no legal basis or practical reason to affix Crown copyright legends with respect to GoC Web sites per se, the practice should be discouraged. That being said, it leaves the discretion to the individual institution to apply Crown copyright notices on elements of GoC Web sites that are capable of sustaining it.

Best Practices

The copyright-tagging practices have been updated and made more consistent with the hallmarks of the Federal Identity Program. Rather than identifying Her Majesty the Queen in Right of Canada as the copyright holder, the guideline suggests clear identification of the actual information provider, by naming of the institution in the copyright tag - © Department / Agency X, date or © Government of Canada, date.

Guideline 5.3

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

Rationale

While the vast majority of notices and disclaimers required on GoC Web sites serve to help users understand the roles, responsibilities and legal obligations of information providers and GoC Internet site users, the Exit Notice is distinct both in purpose and in placement. Unlike the elements included in the Important Notices hyperlink at the end of each GoC Web page, the Exit Notice should be an automatically generated message that pops up on the screen when users have chosen a link that takes them beyond the realm the gc.ca domain. The purpose of the Exit Notice is to clearly establish the boundaries at which GoC roles, responsibilities and legal obligations cease to apply. The Exit Notice will also minimize confusion resulting from inconsistencies that become evident when users transfer from GoC sites to privately developed sites.

Interpretation

There is no mandatory CLF Standard for Exit Notices to appear on GoC Internet Web sites. One of the underlying principles behind introducing a common look and feel for all GoC Internet sites is to provide our clients with a more unified visual and navigational approach that promotes immediate visual recognition of GoC information on our Web sites. Therefore, the use of Exit Notices may become somewhat redundant in that it should be obvious to users when they are leaving and/or no longer on a GoC Web site.

In general, departments may wish to use an Exit Notice to reinforce the fact that the user is leaving a GoC site. This could be to emphasize that GoC standards such as those related to Official Languages and Accessibility will not apply, or it could be to emphasize that the site definitely does not carry any GoC endorsement. However, these situations may not always be the case and it is left to the discretion of the institution under what circumstances and situations to use the Exit Notice.

Best Practices

The following is an example of an exit notice that could be used.

a) You are now leaving the (Title of the Institution) of Web site. Please be advised that the legislation and policy governing Government of Canada Web sites, including official language requirements do not apply beyond this point.

Navigation and Format Section

Overview

Electronic service delivery provides excellent opportunities for Canadians to obtain information on GoC programs and services when and where they need it. Given the enormous resources now available on-line at GoC sites, a logical and consistent system of navigation is key to improving access. Effective navigation is dependent on consistent application of standards that are both visible and invisible to the end-user. Well-designed and strategically placed menu bars give users visual cues to site navigation. Search functions help simplify the task of locating specific information. Placing all GoC sites under one domain and standardizing URLs will further enhance these elements.

Creating a 'common look and feel' for an extended family of related Web sites holds enormous challenges. The programs and services offered by GoC institutions are incredibly diverse and often serve a very specific purpose, for a very specific audience. In some cases, the purpose of a site may be strictly to provide information, in others it may facilitate delivery of a particular service. The Navigation and Format Standards and Guidelines are balanced so as to maintain an appropriate degree of consistency while giving institutions the freedom they need to develop Web pages that serve a variety of functions.

Developing a Web site is not a one-time effort: well-designed sites are continuously evolving. Revisions are prompted by user feedback, better understanding of usage patterns, clearer focus of communications objectives, development of new material, modifications to existing documentation, and new interactive options. In the same way, CLF Standards and Guidelines will continuously evolve.

Web-site design

The site must be designed and developed from a user's point of view and testing is a necessary part of the process. Coherent presentation of content is intrinsically linked to layout, typography, graphic standards, the use of symbols and measurement specifications that can be applied to all GoC Web pages, regardless of their function, to establish a standard framework.

Minimalism is a good practice in designing Web sites. Graphic files should be as small as possible to facilitate rapid delivery via any end-user technology and should include text equivalents to ensure all users can obtain a description of what the graphic contains and what purpose it serves. Users should be warned of large file sizes and non-standard formats, i.e., wider than 640 pixels. Navigational aids, such as buttons and links, should be well-designed and easy to use.

No specific procedural standard or guideline could adequately cover the use of imagery, but it is recommended that GoC Web sites minimize non-essential visual information. Where visual images are used, they must be accompanied by appropriate ALT Text tags to ensure that all users are provided with information about what the images represent and can identify the target (or destination) of images that act as links.

GoC institutions are free to use Web and multimedia technologies to enhance sites, on the condition that all elements are universally accessible. Web developers and content providers can maintain alternate versions of sites that offer demonstrations of advanced technologies, alternate formats or interactive multimedia components. These must be presented as secondary sites and must incorporate appropriate hyperlinks if users are expected to download software or plug-ins to operate multimedia components.

Imagery

Well-designed and carefully placed images can improve the visual appeal and information content of Web sites. However, the time it takes to display large images may drive users away from the site. Many users choose to turn off their display options; others, including individuals with certain disabilities or those with non-graphical browsers, can not view images at any time. Therefore, imagery should be kept to a minimum on GoC Web pages. In addition, all images (graphics, photographs, icons, etc.) should be accompanied by descriptive text equivalents to ensure all users can obtain the same information. It is critical to indicate when images act as links to other Web pages of the site or to other sites. Web developers may choose to use thumbnail images as a link to enable users to view larger versions, and should include information regarding the file size and format.

Animated or Scrolling Images and Text

Various simple mechanisms can be used to add an element of motion to either text or graphics, thereby enhancing the look, adding a degree of entertainment, or serving some other legitimate purpose within the context of a particular Web site. The World Wide Web Consortium (W3C) Web Content Accessibility Guidelines do not ban the use of animated or scrolling images and text, but do provide specific instructions on how they can be implemented without having a negative impact on accessibility. When used, these elements should not self-activate; rather, they should be user-controlled, meaning both activation and deactivation are dependent upon specific requests from the user. In addition, text equivalents must be provided via ALT text or LONGDESC tags. If there is any doubt as to the value of an animated or scrolling text or image, it should be removed from the site.

Text Elements

Like visual elements, Web site texts should be simple and concise. Content should fit within one or two screens, since users are reluctant to scroll endlessly through documents. All information must also be accessible in a text-only format. Font sizes are limited to a single size for headers, and a single size for body text. Hierarchical distinctions can then be made using other font features such as bold and italic. Users should be warned of large file sizes and non-standard formats. Developers should structure information so that it is relatively easy to update.

Typography

Typography choices can enhance or detract from the overall visual appeal of a site. Although user display preferences in individual browsers have ultimate control over text presentation and fonts are displayed as coded only when browsers are set to the default preference, there are benefits to be gained through consistent font presentation.

Layout

Web page layout is an integral part of Common Look and Feel. Some common styles of Web page design create barriers for individuals using assistive devices and non-graphical technologies. Such barriers to accessibility can be avoided through thoughtful Web page design in accordance with CLF and W3C guidelines.

Accessibility is not the only issue with respect to layout. Beyond the common menu bars and FIP identification, a common approach to organizing site content plays a major role in visually unifying the thousands of government Web sites. The simple fixed columnar arrangement provides for third level navigation requirements, creative themes, and a body text line-length that is easy to read on-screen. This layout anchors, in fixed space, the graphic elements which identify the site as a government site and ensures that the consistent presentation of the site content works together with the mandatory graphic elements. See FIP Toolbox for specifications.

It is the responsibility of individual Web developers with the Government of Canada to ensure Web sites are designed to be universally accessible. Information on how to use tables effectively for the layout of images or data presentation is provided from the World Wide Web Consortium Web site.

Standards 7.1, 7.2 and 7.3 have both Navigation and Format and Official Languages implications.

Version Histories

Rationale

Consistent use of a common menu facilitates navigation on GoC sites and consistently consolidates key common functions across all GoC Web sites.

Interpretation (Updated)

• Download and use the CLF page template
• Download and use the CLF Welcome Page template

To facilitate navigation within individual GoC sites and between multiple GoC sites, a Common Menu has been developed to provide specific service enhancements. Prominently placed at the top of every GoC Web page, the buttons on the Common Menu provide direct links to crucial navigation features. The Common Menu buttons are placed such that the most critical buttons hold the most prominent positions. For example, the language choice and 'Canada Site' buttons should be placed at the left and right extremes (respectively) of the bar itself. The Common Menu bar for unilingual sites is slightly different.

The width of Government of Canada Web pages must be no less than 600 pixels. The width dimensions for page components will be as follows:

• Header: Fixed, 600 pixels
• Footer: Fixed, 600 pixels
• First Column (left navigation): Fixed, 132 pixels
• Second column (vertical white space): Fixed, 18 pixels
• Third column (content area): Minimum column width of 450 pixels. 
  In exceptional cases where specific content (e.g. maps, large tables, charts, graphs, etc.) cannot adapt by way of wrapping or linearization to the standard 450 pixel width the content can extend to the right beyond the 450-pixel boundary. 
  When content does extend beyond the 450-pixel boundary a version suitable for printing on standard 8-1/2" x 11" (21.6 cm x 27.9 cm) paper must be provided.

The buttons in the common menu bar must have a black background with white text that is left justified and at least a 9 pixel font size. The dimensions of the buttons are 14 pixels high and 89 pixels wide with a 1 pixel space between the buttons. The common menu bar must appear on all html pages along with the other mandatory elements. See specifications.

• Tools and templates
• How to use skip navigation links

Web site vs Web document

CLF Standards are mandatory on all HTML navigation pages of GoC Web sites. In the case of downloadable versions of documents on your Web sites that are in non-HTML formats such as .doc, .rtf, .pdf, .txt, .wpd, the implementation of the menu bars is not required. However, the CLF Standards for Federal Identity, Official Languages, Important Notices, Collaborative Arrangements and Accessibility are required.

6.1 Best Practices

Common Menu Bar

The following are best practices to help institutions standardize the kinds of information that should be available behind each of the buttons on the Common Menu Bar.

English / Français Language button

Bilingual Web sites: This button provides a direct link to the page content in the other official language. Change language scripts

Unilingual Web sites: This button should read "Disclaimer" and take the user to the Unilingual Welcome page where a link to bilingual information on the department / agency is available. The Federal Identity Program Toolbox provides the specifications and guidance on building a unilingual Web site.

Multiple language Web sites: CLF Technical Working Group will provide guidance in the form of best practices on how to implement navigation of GoC content available in more than the two official languages.

"Contact Us" page

• GoC sites should provide relevant contact information, including information that could accommodate those with disabilities or special needs. The contact information provided should be in the context of where a user is on the Web site. An example of contact information can be found at the Canada site Contact Us page - http://canada.gc.ca/comments/form_e.html.
• Institutions should establish service standards or refer to existing institutional service standards. Service standards should be provided to the user up front so that they understand the process and know what to expect, i.e. response time for service delivery.
• Ensure proper implementation of Common Look and Feel Standard 4.4 - acknowledgements.
• Ensure proper implementation of Common Look and Feel Standard 5.4 - personal information.

"Help" page

• Provide a link to the site map or an alphabetical list of products that are available on your site.
• Provide an overview of any Accessibility features that are available on your site. e.g. Access Keys, personalization.
• Describe what formats are available throughout your site. Please see the Help page on this Web site for more information and examples.
• Provide a link to technical help for problems with the Web site or for users who are having problems accessing information on the Web site, i.e. link to webmaster's e-mail.
• Provide a link to the "Contact Us" page on the Web site.
• Provide site specific help information as well links to the institution's more general help.

"Search" page

• This button should link to search and retrieval systems that enable users to obtain information on a particular subject in any GoC Web site How to create an accessible Search page.
• Provide detailed help on how to search the information on your site with examples of how to conduct a simple and advanced search Information on how to search in other languages, and how to use other characters is encouraged when appropriate. Termium features, services and software could also be included.
• Provide links to the other levels of searching within your institution e.g. Department or Agency.
• Provide a link to the Canada Site AltaVista search page.

To ensure information on your site is found by users proper implementation of Common Look and Feel Standard 6.3 on metadata must be applied to html resources.

Canada Site button

• Provide a direct link to the Government of Canada Web site. When your site is a GoC intranet provide a link to the GoC Publiservice Web site.
• When linking from an English content page to the Canada Site / Publiservice Site always link to the index page of the site and never to the Splash page where the user is then forced to make their language selection again.

Rationale

Establishing a standard format and location for the primary institutional menu facilitates attainment of CLF navigation objectives and further enhances communication and identification objectives.

Interpretation

The institutional menu is a key feature in providing service delivery within an individual site. Each GoC site and sub-site will need to adopt terminology on the menu buttons that reflects its specific programs and services, yet some degree of standardization should be applied to enhance over CLF objectives. As it can be anticipated that some similarity in the content of institutional menus will occur from site to site, CLF suggests Web developers should consider including the following standard elements: What's New, Publications / Catalogue, Menu / Contents, Home / Previous / Next, Programs & Services, Index, Submit / Order.

The standard requires a consistent look and placement for the primary institutional menu. While institutions are free to choose the colour, number of buttons (up to 10) and content of their primary institutional menu, the size and design must match that of the Common Menu. In addition, the primary institutional menu must be placed directly below the Common Menu. The terminology used on menu buttons should be selected carefully to ensure choices are clear to end-users that may or may not understand the phrases or terminology used internally to reflect programs or services.

GoC institutions are free to develop additional secondary menu systems as required. Institutions with many Web sites or many levels of content may need this additional navigation assistance. Such secondary menus should be located in the left column of Content Pages. They may incorporate a more graphic or visually thematic approach to displaying navigation options than is used in the mandatory menu. Secondary menus should be designed with the appropriate attention to accessibility concerns and should visually complement overall Web page layout.

While the primary institutional menu should contain links to major subject areas that are institution-wide or major functions not included in the Common Menu, the secondary menu may contain links that are more content specific, such as institutional sub-sites, program and service areas, or lengthy content files.

• Side and Body Column

Common Look and Feel Metadata Standard Definitions and HTML Examples

TBITS 39: Treasury Board Information Management Standard, Part 1: Government On-Line Metadata Standard

META Tag Generator is a tool which accepts user input and will generate HTML code according to the standard which can be pasted into an HTML page.

These five metadata elements are part of the 15 element Dublin Core Metadata Element Set, the leading international metadata standard for on-line resource discovery.

Rationale

Metadata is a key tool in describing and managing information assets. It is particularly important to have an effective identification system for information assets since many are invisible, hidden in Web sites or databases, until a user initiates a search to find the assets relevant to a current need. Whether we in the public service or our clients in the Canadian public are the searchers, we need an effective way to use the labels on our information assets to find them when we need them. You can see that the chair you are sitting on is a chair without looking at the bar code label, but an electronic document is invisible until its label or its text is found by a search tool.

The benefits of using a systematic way of assigning and structuring metadata include:

• Relevance: Providing information that search engines can use to find relevant documents in large collections such as Web sites or document databases where text search alone brings up many irrelevant documents or lists of documents too long for users to look at.
• Identity: Providing descriptive information so that users can tell how old a document is, who wrote it, or how to get additional information. Most documents on government Web sites now cannot tell the user whether they are 5 days old or 5 years old. Sometimes the user wants one, sometimes the other. Metadata helps a user know if the information is reliable and current.
• Inventory: A list of what information the Government holds so that the information can be managed, tracked, updated, analyzed and used efficiently.
• Consistency: The Dublin core, an international metadata standard provides the framework and many of the rules for use so that metadata can be applied consistently in large and diverse organizations such as the Government of Canada. This creates an environment in which users can search for and find information without needing to know which department produced it or to which program it relates.
• Interoperability: An international metadata standard such as Dublin Core provides a way for information resources in electronic form to communicate their existence and their nature to other electronic applications (e.g. via HTML or XML) or search tools and to permit migration of information between applications or search systems.
• Policy compliance: A critical component of meeting the Management of Government Information Holdings (MGIH) policy requirement to know and be able to find the information Government holds.

For more information see: Selecting and Implementing a Metadata Standard for the Government of Canada

Interpretation

Essentially information about information, metadata is made up of elements that define standard descriptions of information holdings. This CLF standard is based on Dublin Core and requires GoC institutions to describe Internet resources using five mandatory metatags in document headers: Title, Originator, Language of Resource, Date and Controlled Subject. Link: Common Look and Feel Metadata Standard Definitions and HTML Examples

The Canada Site includes a Web crawler that indexes departmental sites to create a searchable central index. As departments create metatags to describe their information holdings, the Web crawler will incorporate these records in the central index. The Canada Site search index will be configured to recognize Dublin Core metatags and use them in ranking and displaying results.

6.3 Best Practices

To complement the use of these mandatory GoC metatags, Web developers should also ensure that the HTML Title element and two HTML meta elements, Description and Keywords are specified. Authors should use the Title element to identify the contents of a document. Since users often consult documents out of context, authors should provide context-rich titles. The content of the HTML Title tag is displayed as the window header in a Web browser, in bookmarks and in search results. Common search engines may use the contents of the Keywords tag to improve the quality of search results. The contents of the Description tag may be displayed as a summary in search results. The display of these elements is limited in length by browsers and search engines.

Departments or Web sites requiring additional metadata elements should use the additional Dublin Core elements as a starting point. In accordance with the Government of Canada Metadata Framework domain specific metadata element sets may be developed with the mandatory Common Look and Feel and additional Dublin Core metadata elements at their core.

Indexing Federal Government Web Pages: Guidelines for the Development of an Indexing Policy (November 2002)

These guidelines were developed by members of the GOL Metadata working Group during the summer of 2002 and approved at the September 17, 2002 meeting. This document targets departments developing indexing policies for the population of the Common Look and Feel mandatory element <dc.subject>.

Two user-friendly web-based guides are now available on the Council of Federal Libraries' site (September 2002)

An Implementation Guide for Metadata Developers offers practical assistance to those responsible for creating metadata content for federal government Web pages in accordance with the Common Look and Feel standard. It explains the tasks to be performed, demonstrates how the required information should be created and directs readers to other resources. It also provides instructions on how and where to insert the required source codes into a Web document.
An Implementation Guide for Metadata Managers offers assistance to managers responsible for meeting the CLF metadata standard.
The guides were created by an interdepartmental, cross-disciplinary team of metadata practitioners lead by the Council of Federal Libraries' Metadata Action Team.
The guides' home page is: http://www.collectionscanada.ca/6/37/s37-4016-e.html
The Council of Federal Libraries welcomes your comments on the guides. Please send them to: nippni@nlc-bnc.ca.

How to register a controlled vocabulary or thesaurus for use in dc.subject on federal government Web sites:

Registering a Standardized Vocabulary

Links

Search to select subject descriptors:
Government of Canada Core Subject Thesaurus Depository Services Program (Communication Canada)

Common Look and Feel Metadata Standard Definitions and HTML Examples

Treasury Board Secretariat Information Management Resource Centre References and Resources for Metadata

Training materials for applying Dublin Core metadata

Version Histories

Rationale

The date indicator informs the users of the date of the original posting (issuance or publication) to the Web site or the date of last update (modification) of the resource.  Because of its positioning at the bottom of the page, the date indicator can also signal to the users that they have reached the end of that page.

As GoC sites are increasingly used to obtain valid, accurate and up-to-date information for personal and professional use, it is vitally important that GoC institutions provide clear date indicators for the resources placed on their Web sites.

Including a currency indicator is recognized as an industry best practice that users have come to expect, and use of the ISO standard (YYYY-MM-DD) will enhance conformity among GoC sites.

Interpretation

The standard provides for two kinds of dates:  "Date published" and "Date modified". The dates must be represented in the ISO all-numeric date standard YYYY-MM-DD. The two dates are defined as follows:

"Date published" is the date of formal issuance (i.e., posting to the Web site) of the resource.

"Date modified" is the most recent date on which the document was substantially changed and re-posted to the Web site. "Last updated" is alternative wording. Use of "Date modified" is preferred.

Either 'Date published' or 'Date modified' must be used, as applicable in accordance with the definitions above.

These definitions are consistent with the Common Look and Feel Metadata Standard Definitions and HTML Examples used in Standard 6.3. Encoding for the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format.

6.4 Best Practices

It is useful to establish a standard marker that signifies users have reached the end of any given Web page.

CLF Footer Elements

Rationale

Only the 216 Web-safe colour options ensures compatibility with the full range of browsers and platforms available. It also makes good design sense to pick complementary colour schemes that display sufficient contrast for the average user.

Interpretation

In general, the standard requires the use of 216 Web-safe colours in all elements of site design to ensure the highest level of display accuracy across all platforms and systems. Web designers should also be aware that colour choices could seriously hamper the functioning of a Web site. While end-users can control colour elements to suit their needs, picking complementary colour schemes that display sufficient contrast such as black text on a white background, is the best way to avoid creating problems for people with visual and perceptual disabilities.

6.5 Best Practices

Black text on a white background provides high contrast and utility with respect to on-screen and printed information, and provides numerous accessibility advantages.

• 216 Web-safe colour options
• Effective Color Contrast http://www.lighthouse.org/color_contrast.htm
• Making Text Legible: http://www.lighthouse.org/print_leg.htm
• Vischeck : http://www.vischeck.com/
  Vischeck can show you what your image looks like to people who are color blind, people with glaucoma or macular degeneration, elders and children.

Rationale

Frames are an example of non-sequential text, which can create interpretation problems for individuals using assistive technologies and for advanced multi-modal systems. Frames present additional problems when trying to ensure that organizational identification and CLF elements remain attached to content when located via search engines. Frames can also prevent users from easily bookmarking specific Web site content.

Interpretation

It is the responsibility of individual Web developers to ensure Web sites are accessible to all citizens.

Web page layout is critical to universal accessibility in that some common styles of Web page design actually create barriers for individuals using assistive devices and non-graphical technologies. Such techniques can only be used as an alternative, where universal accessibility has been otherwise guaranteed.

Rationale

As corporate investment in Web site development and maintenance continues to rise, many organizations rely on statistics regarding site usage to measure associated costs and benefits. Some use simple counters, or others use more sophisticated Web analyzer tools to obtain data. Counters add little value to a site and often appear to be self-congratulatory. Web analyzer tools provide more information and are virtually transparent to the end user.

Rationale

All sites must be tested with a variety of browser software to ensure Web page layout remains intact regardless of what platforms end-users employ. These include graphic as well as character-based browsers. Testing should focus on ease of use, navigation, screen layout, comprehension and user satisfaction. Sites should also be tested with the graphics option turned off, as many users prefer this option as a means of accelerating document downloading. Web developers need to be aware that various hardware and software platforms can all significantly alter the appearance of a site, especially colour in graphics and backgrounds.

Validating HTML pages - on both existing and future sites - against a DTD will ensure they are syntactically correct. It should be noted that not all HTML editors are capable of performing this function, and that some are only effective in validating a vendor's proprietary DTD.

From: http://www.w3.org/TR/WAI-WEBCONTENT/#validation

Validation

Validate accessibility with automatic tools and human review. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and ease of navigation.

Begin using validation methods at the earliest stages of development. Accessibility issues identified early are easier to correct and avoid.

Following are some important validation methods, discussed in more detail in the section on validation in the Techniques Document.

1. Use an automated accessibility tool and browser validation tool. Please note that software tools do not address all accessibility issues, such as the meaningfulness of link text, the applicability of a text equivalent, etc.

2. Validate syntax (e.g., HTML, XML, etc.).

3. Validate style sheets (e.g., CSS).

4. Use a text-only browser or emulator.

5. Use multiple graphic browsers, with:

• Sounds and graphics loaded
• Graphics not loaded
• Sounds not loaded
• No mouse
• Frames, scripts, style sheets, and applets not loaded

6. Use several browsers, old and new.

7. Use a self-voicing browser, a screen reader, magnification software, a small display, etc.

8. Use spell and grammar checkers. A person reading a page with a speech synthesizer may not be able to decipher the synthesizer's best guess for a word with a spelling error. Eliminating grammar problems increases comprehension.

9. Review the document for clarity and simplicity. Readability statistics, such as those generated by some word processors may be useful indicators of clarity and simplicity. Better still, ask an experienced (human) editor to review written content for clarity. Editors can also improve the usability of documents by identifying potentially sensitive cultural issues that might arise due to language or icon usage.

10. Invite people with disabilities to review documents. Expert and novice users with disabilities will provide valuable feedback about accessibility or usability problems and their severity.

Guideline 6.1

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

Rationale

Effective design results from careful consideration of several elements: colour, space, imagery, typography and layout. While Web technologies offer new opportunities for creativity, there are distinct benefits to be gained in communication, identification, navigation and content through standardization of some design elements. When applied across a large group of related Web sites, design standards increase visual recognition by end-users and lead to stronger associations between various GoC institutions.

In keeping with good design principles, the common look and feel Web page layout guidelines observe practices developed to maintain consistent, professional and highly cognitive relationships between all elements on each Web page.

Interpretation

Effective use of space is crucial to good information design. Effective use of white space in the left-hand column, along with a fixed width for content space, reinforces visual recognition of GoC sites. Consistent use of labels, line width, Web page layout, etc., will further enhance visual recognition of GoC sites and make it easy for users to locate exactly what they are looking for. Carefully coded Cascading Style Sheets are the most efficient means of achieving this standard, but simply coded tables may also be used to establish placement of elements.

Best Practices

Layout and presentation

Once a majority of users use browsers that support CSS-2, the following style sheet techniques should be used to control layout and presentation.

1. Use style sheets for text formatting rather than converting text to images.
   For example, stylized text on a colored background can be created with style sheets instead of as an image. This provides flexibility for people to view the text in a form that is most readable to them including magnified, in a particular color combination such as white on black, or in a particular font.
2. Use style sheets rather than invisible or transparent images to force layout.
3. Use style sheets instead of deprecated presentation elements and attributes that control visual presentation (elements {BASEFONT, CENTER, FONT, S, STRIKE, and U}. attributes {"align," "background," "bgcolor," "color," and "face"}. Authors are encouraged to use elements (such as STRONG, EM, H1, H2, ABBR, etc.) that add structure to documents.

Until then tables (to control layout) and bit-mapped text (for special text effects) may be used with alternative pages as necessary. http://www.w3.org/WAI/GL/19980624txt.htm

Use Cascading Style Sheets only where the CSS techniques in question are known to have adequate browser support. Each new release of the major graphical browsers include more and better support for the CSS guideline. Many CSS commands especially for font effects, simple margins etc., have been well supported since level 4 graphical browsers. More advanced CSS support is being developed. CSS markup should be used to replace the deprecated <FONT> tag in any case.

Following these 6 steps should minimize the need for testing multiple platform / browser combinations and will ensure your content is served.

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.

The following CLF standards have both navigation and format and official languages implications. Their navigation and format characteristics are described below. The Official Languages considerations are fully described in Section 7, Official Languages.

Rationale

Just as government telephone numbers across the country are easily recognized by the '9' at the front of the prefix, the CLF standard to adopt a single domain name seeks to establish a similar identifier for GoC on the Internet. Domain names are vital to end-users. The domain name is the highest level reference to an individual site. If they know the exact domain name, users can effectively 'direct dial' to the information they want. In addition to acting as gateways to information and services, Web sites are key elements of marketing, promotional and information materials. A common domain name will further enhance federal identity, presence and visibility.

Bringing all GoC sites into a single domain will improve public recognition and make it easier for individuals to remember domain names they use on a regular basis. The standardization may also increase their chances of finding a site they have not previously visited. Informal surveys suggest Canadians are beginning to associate the gc.ca domain with the GoC.

Rationale

Welcome Pages are key to initial communication, identification and navigation on all GoC Web sites, and must therefore be designed to facilitate these functions. The standard single screen size ensures all necessary elements are viewable without scrolling and provides immediate access to the full content of any Welcome Page. While the centre area of any Welcome Page is left open for customisation to suit the needs of the institution (or its programs and services), standardization of the screen size and placement of mandatory elements will enhance visual consistency across all GoC sites.

Rationale

Standards for the size, placement and prominence of the "Canada" wordmark and FIP institutional signatures at the initial point of entry to GoC sites (the Welcome Page), and on all additional Web pages, foster visual recognition of individual institutions and increases the recognition of their links to the GoC. Consistent use of standard federal identifiers will ensure any area of any site can be easily identified as belonging to the Government of Canada, and will indicate that the information has been provided by a GoC institution. FIP identifiers also serve to assure users that the information is being appropriately used in the intended context.

Official Languages Section

Overview

All GoC Web sites must comply with relevant policies of the Official Languages Act (OLA). While publishing information in both official languages is nothing new, the use of electronic media calls for additional consideration of the linguistic aspects associated with Web technology and software interfaces. Web developers must ensure OLA requirements are met both in the content and the architecture of any given GoC site or sub-site, in accordance with Treasury Board's Directive on the Use of Official Languages on Web Sites.

The following standards related to the use official languages address particular aspects of Web site application. The rapid evolution of Web technologies and standards warrants a revision of current conventions to ensure they are up-to-date and precise.

Several other Web features require special attention to ensure OLA requirements are fully met, including server messages, text equivalents and metatags. Web servers have a number of automatic features such as instructions, e-mail redirection and error messages. Unless the server is able to recognize the language profile chosen by the user and respond accordingly, all messages generated automatically in response to user activity must be bilingual.

Because text equivalents e.g. title="  " or alt="  " are essentially tools through which site content can be obtained, they too, must be available in the end-user's language of choice.

Similarly, because metatags are designed to improve government-wide information searching through standardization of searchable criteria, metatag content must be included in the official language of the Content Page.

As the gateway to information on a particular program or service, the Welcome Page of any GoC institution is a key component of on-line communication. In the context of the common look and feel initiative, Welcome Pages can be said to serve three main functions. They help users identify the source institution, associate the site and the institution with the Government of Canada, and respect official languages requirements.

Rationale

Just as most government telephone numbers across the country are easily recognized by the '9' at the front of the NNX prefix, this initiative to adopt a domain name convention seeks to establish a similar identifier for GoC on the Internet. Domain names are vital to end-users for two reasons. First, the domain name is the specific reference to an individual site. If they know the exact domain name, users can effectively 'direct dial' to the information and services they want. Second, as the domain name appears in both Web addresses and in E-mail addresses, it increases user awareness that individuals they contact via e-mail are representatives of a GoC institution. In addition to acting as gateways to information and services and public service employees, Web sites and E-mail addresses are common elements of marketing, promotional and information materials. A common domain name convention will further enhance federal identity, presence and visibility. Bringing all GoC sites into a single domain will improve public recognition and make it easier for individuals to remember domain names they use on a regular basis. The standardization will also increase their chances of finding a site they have not previously visited. Informal surveys suggest Canadians are beginning to associate the gc.ca domain with the GoC.

At present, GoC institutions apply a wide range of approaches to indicating their identity within the gc.ca domain name: bilingual hyphenated acronyms, unilingual acronyms, selected keyword(s) from a title, truncated keyword, etc. While no solution is likely to meet the needs of all GoC institutions and provide an intuitive, memorable way for Canadians to locate individual sites in the language of their choice, there is a need for greater consistency in institution identification. The following options are available, all of which have been developed to meet the Official Languages Act requirements.

This Standard also has Navigation and Format implications.

Interpretation

If option (b) is adopted, the order of the two official languages is dictated by the location of the office providing the service through the site in question, i.e., English on the left for offices located outside of Quebec and French on the left for offices located inside Quebec. An example would be hrdc-drhc.gc.ca for offices located outside of Quebec and drhc-hrdc.gc.ca for offices located inside Quebec.

• Institutions may also register equivalent unilingual English and French versions of a name, or the acronym thereof, to be used as an alias as a means to facilitate faster access by the public to their sites when they are undertaking a promotional initiative for a given program.  These short forms could be used within announcements published in English and French magazines or on English and French television, or on the cover of equivalent unilingual versions in English and French of government brochures or appearing in alternation on the two sides of a bilingual brochure.

See following examples that illustrate the above principles.

For publications:

• See example below left to illustrate the English cover of a bilingual brochure: www.cfc.gc.ca
• See example below right to illustrate the French cover of a bilingual brochure: www.ccaf.gc.ca

English cover		French cover

• These unilingual versions of the domain name must be treated as short forms of the domain name for use within the context described above.  They would be of interest particularly to an institution whose hyphenated bilingual domain name contains several letters and the possibility of using the short forms in the contexts noted above will contribute to eliciting a better response by the public to a given initiative. They must, when either is selected by the user, lead back to the Welcome page, where the domain name will appear as in option (b).

• Should an institution wish to use the hyphenated bilingual version instead of the short form, the order conventions for the two official languages together would then have to be respected on the two sides of a brochure and in unilingual media.

• The unilingual English and French versions of the domain name may also be used on corresponding English and French content pages of the site, see below:

English content page		French content page

If geographic names are included as part of the domain name, the following principles apply:

• In the case of locations outside Canada, if a geographic name has different versions in English and French usage, both of these versions should be used (e.g. london-londres).
• In some cases, the English and French versions are identical (e.g. hongkong).
• In other cases, the name used is the same as the one within the country where the place in question is located and there is no established version in English or French.
• If Canadian place names need to be used, their use must conform to the principles of the Geographical Names Board of Canada (formerly known as the Canadian Permanent Committee on Geographical Names), see http://geonames.nrcan.gc.ca.

Vanity names as domain names

Many departments are registering so-called vanity or program specific names as sub-domains of gc.ca. These programs are often multi-departmental in nature and do not bear any FIP identity. For example, KidsCanSave.gc.ca, CanadaSavingsBonds.gc.ca, ConnectingCanadians.gc.ca. These are subject to the same rules described above under options (a) and (b) of Standard 7.1.

7.1 Best Practices

• URLs (August 2002)
• Domain Names (July 2000)

URLs (August 2002)

Another important issue related to CLF Standard 7.1 is the naming of folders and files that appear in URLs, and the language of the querystrings that may appear in URLs that are dynamically generated by such applications as ASP (Active Server Pages), e.g. http://www.goc-gdc.gc.ca/govscripts/docs/wn-qn_f.asp?who-qui=/abc-cba/forum/.

According to CLF Standard 7.1, the domain name portion of the URL, e.g. everything to the left of gc.ca, must be bilingual to comply with CLF Standard 7.1.

As a best practice, the names of folders and files, e.g. /govscripts/docs/wn-qn_f.asp, that appear in the full path should also comply with CLF Standard 7.1. This could be achieved in several ways such as naming with both official languages (links-liens), acronyms (faq_f.htm), one word spelled the same in both official languages (documents_e.htm), numbers (123_f.htm), alpha characters (abc_e.htm), etc.

It is acknowledged that the query language portion seen in some URL paths that are dynamically generated would require significant programming effort to comply with CLF Standard 7.1 but where it is feasible, this portion should also be bilingual (e.g. who-qui=/abc-cba/forum/), or should use parameter / value pairs that are not unilingual dictionary words (e.g. w=/abc-cba/forum and lang=fr).

Domain Names (July 2000)

The character string .ca is a top level domain name, and gc.ca is a sub-domain or "child" of the "parent" .ca. A name placed before the gc.ca references a sub-domain of the domain gc.ca. A "/name" after the dept.gc.ca references a directory within that domain. For example, canada.justice.gc.ca is a departmental domain name. justice.gc.ca/publications references the directory "publications" within the justice.gc.ca domain.

The network architecture selected by the department will dictate the format of specific sub-domain names and directories.

If a department advertises a host name or sub-domain within their domain for Web purposes, they must also show it as a bilingual name or acronym. For example, abc-eac.inac-ainc.gc.ca illustrates the bilingual acronym for the Aboriginal Canada sub-domain under the Indian and Northern Affairs Canada domain.

GTIS/PWGSC is responsible for registering all GoC sub-domain names under gc.ca but it does not register subdomains within a department. They are the responsibility of the department that has authority over its own departmental domain.

You can register on-line at http://registry.srv.gc.ca for a Domain Name under the gc.ca root, update an existing registered domain name (e.g., change contact information) and check the status of a new application, (e.g., received, pending approval, approved). This service is provided by the GoC DNS registry at GTIS/PWGSC.

GTIS/PWGSC also maintains a repository of institutional domain names registered under .ca, .com, .net and .org at http://registry.srv.gc.ca for your reference.

Rationale

Welcome Pages are key to initial communication, identification and navigation on all GoC Web sites, and must therefore be designed to facilitate these functions. The standard single screen size ensures all necessary elements are viewable without scrolling and provides immediate access to the full content of any Welcome Page. While the centre area of any Welcome Page is left open for customisation to suit the needs of the institution (or its programs and services), standardization of the screen size and placement of mandatory elements will enhance visual consistency across all GoC sites.

Interpretation

The official languages requirements applicable to welcome pages are located within the Treasury Board's Directive on the Use of Official Languages on Web Sites (Implementation Procedures). Specifically, for the welcome pages of sites of offices designated as bilingual, see section 6.1.1. b) and c) and Appendix A. For the welcome pages of sites of offices that are unilingual, see section 6.1.2 a) and Appendix B.

The sites of the offices of institutions subject to the Official Languages Act must reflect the official language obligations of the offices that use the sites. The standards ensure that these obligations are taken into account at the level of the Welcome page, which is, within the official languages perspective, an office's electronic service "wicket".

The standards set out above take into account the following factors:

• Offices designated as bilingual under the Official Languages Act are obligated to make an "active offer" in both official languages of their services and communications to the public. At a traditional service counter or wicket, or on the telephone, an active offer is normally achieved through the use of a bilingual greeting that lets members of the public know that at the office in question they have the right to be served in the official language of their choice.

• The English / Français buttons required on the Welcome page achieve the same purpose: they inform visitors to the site that it provides its services and communications in both official languages and offers them the choice of official language. Once the user has chosen the official language, the site gives access to content in that language.
  • For an office located outside Quebec
  • For an office located in Quebec

• The Web sites of unilingual offices or facilities are not required to post their content in both official languages as long as this is intended exclusively for the public served by that office or facility. That requirement may change if they post directly on their site content that is intended for the public in general; see Treasury Board's Directive on the Use of Official Languages on Web Sites.

In practice, it is highly recommended that a unilingual office wishing to post content which is intended for the public everywhere in Canada, to locate it on the institutional site, or on another bilingual site, and to refer to it via a hyperlink, rather than posting it directly on its own site.

Rationale

In accordance with Federal Identity Program (FIP) policies, every page of every GoC Web site must clearly identify the Government of Canada as the ultimate source. This is accomplished through the application of GoC identifiers, including the "Canada" wordmark and institutional signatures. To enhance visual recognition of GoC sites, standards for size, placement and prominence of these elements should be followed by all Web developers.

Standards for the size, placement and prominence of the "Canada" wordmark and FIP institutional signatures at the initial point of entry to GoC sites (the Welcome Page), and on all additional Web pages, foster visual recognition of individual institutions and increases the recognition of their links to the GoC. Consistent use of standard federal identifiers will ensure any area of any site can be easily identified as belonging to the Government of Canada, and will indicate that the information has been provided by a GoC institution. FIP identifiers also serve to assure users that the information is being appropriately used in the intended context.

Where the size and format of the content exceeds the 640 by 480 pixel size, a notice should be provided to the user telling them how they can adjust their screen size to accommodate the non-standard formats, e.g., tables, maps, etc.

This Standard also has Navigation and Format implications.

Rationale

The content of a site is allowed to be only in one official language when the office responsible for the site does not have the obligation to provide its content in both official languages under the Official Languages Act or its Regulations. This allows the office in question not to have to present its content in both official languages since it does not have to serve the public in its service area in both official languages. However, given the nature of the Internet, it is likely that many visitors to that site would be interested in obtaining information from a federal institution that goes beyond what the site offers to the public that is served by the office responsible for the site. The hyperlink from the unilingual site to a bilingual site (for example, the institutional site of the institution) make it possible for the official language minority population in the service area of the unilingual office to have access to other information from the institution in question in its preferred official language, even if this office is not required to serve the public in its service area.

Rationale

The sites of the offices of institutions subject to the Official Languages Act must reflect the official language obligations of the offices that use the sites. The standards ensure that these obligations are taken into account at the level of the Welcome page, which is, within the official languages perspective, an office's electronic service "wicket".

The standard for the use of the language buttons takes into account the requirements of the Official Languages Act, in particular, the obligation, pursuant to section 28 the Act, for offices required to serve the public in both official languages to make an "active offer" of those services and communications in both official languages. The language buttons on the Welcome page fulfill this purpose. The language button requirements for the Welcome pages of unilingual offices differ from those for the Welcome pages of bilingual offices. For these differences, see official languages Standard 7.2.

7.5 Best Practices

• Federal Identity Program On-line tool box

Example of common and institutional menu bars of bilingual Web sites.

English content page:

Button		Button		Button		Button		Button
Button		Button		Button		Button		Button

French content page:

Bouton		Bouton		Bouton		Bouton		Bouton
Bouton		Bouton		Bouton		Bouton		Bouton

• Change language Script

Example of common and institutional menu bars of unilingual Web sites.

English content page:

Button		Button		Button		Button		Button
Button		Button		Button		Button		Button

French content page:

Bouton		Bouton		Bouton		Bouton		Bouton
Bouton		Bouton		Bouton		Bouton		Bouton

Rationale

The principle set out under 7.6 is intended to ensure that, once a user has selected the official language for content, messages are generated in the official language of the Web page. This principle is therefore consistent with those found in other standards, see for example "Interpretation" under Standard 7.1 and Standard 7.5. When the technology available to an institution does not permit the selection of the language of Web server messages to match the language of the Web page, bilingual messages must be generated for both English Web pages and French Web pages. In bilingual messages, the order of the two official languages has to give priority to the language of the Web page. This principle is likewise consistent with those set out under 7.1.

Bilingual server notices

• error messages

Rationale

This principle is consistent with that set out under Standard 7.6.

Federal Identity Program (FIP)

• FIP Signatures text equivalents

Interpretation

In this standard the element of the metatag that makes up the content must be provided in the language of the page in which it is embedded.

Metadata

Complete Metatag = <meta name="Title" content="Important Notices">

Meta element name: "Title", "Originator", "Language of Resource", "Date" and " Controlled Subject"

These names are represented in English only.

Meta element content =  is name of the content within the Element Name

• The content of the name placed between quotation marks must reflect the language of the page in which it is embedded.

See example of metadata for a page:

<meta name="title" content="enter the title in English or French">
<meta name="originator" content="enter the Originator in English or French">
<meta name="language_of_resource" content="enter the language of resource" eng or fre">
<meta name="date_created" content="enter the date created date">
<meta name="controlled_subject_terms" content="enter the controlled subject terms" in English or French">

Metadata for an English content page:

<meta name="title" content="216 Web-safe Colours">
<meta name="originator" content="Government of Canada, Treasury Board Secretariat, Chief Information Officer Branch, Information Policy">
<meta name="controlled_subject_terms" content="CIO, IP, CLF, Common, Look, Feel, 216, colours, web-safe, websafe, safe">
<meta name="language_of_resource" content="eng">
<meta name="date_created" content="2001-07-04">

Metadata for a French content page:

<meta name="title" content="216 couleurs recommandées pour le Web>
<meta name="originator" content="Gouvernement du Canada, Secrétariat du Conseil du Trésor, Direction du dirigeant principal de l'information, Politique de l'information">
<meta name="controlled_subject_terms" content="DPI, PI, UPE, Uniformité, présentation, exploitation, 216, couleur, recommandées, RGB, HEX">
<meta name="language_of_resource" content="fre">
<meta name="date_created" content="2001-07-04">

Rationale

The content for which a federal office is responsible must be clearly identified for the public and must respect official languages requirements.

Interpretation

All offices in the National Capital Region as well as head or central offices of institutions are required to serve the public, or provide their information or communications to the public, in both official languages; the sites of these offices have the same obligation.

Offices not covered by the above must provide their communications in both official languages when they come under criteria in the Official Languages (Communications with and Services to the Public) Regulations. Both the legal text of the Regulations and a description of its provisions can be found at: http://www.hrma-agrh.gc.ca/ollo under the title "legislation".

Offices with the obligation to serve the public in both official languages are listed in Public Service Human Resources Management Agency's system known as Burolis.

There is also a Treasury Board Directive to complement the Official Languages Act, the Regulations and it's Policy on the Use of Official Languages for Communications with and Services to the Public entitled Directive on the Use of Official Languages on Web Sites.

Rationale

For the official languages, the requirements for domain names are the same as those set out under Standard 7.1. It is important that all domain name information to the right of the @ symbol reflect the same approach in complying with official language requirements as is employed at the institutional Web server level.

Thus, an institution that has registered a hyphenated name or acronym as its domain name (i.e., option (b) as discussed above under Standard 7.1) must observe the same rules for the order of the two official languages in the use of e-mail addresses. For example, English on the left for offices located outside of Quebec and French on the left for offices located inside Quebec.

Templates

E-mail templates - English

E-mail templates - French

This is for departments managing their own SMTP gateways and does not include the centralized X.400/SMTP gateway which has its own address mapping format.

Interpretation

Institutions may also register equivalent unilingual English and French versions of a domain name to be used for E-mail. However, these can be used only in the same circumstances as those outlined above with respect to unilingual forms of domain names in bilingual publications or publicity in separate unilingual magazines or other media (see "Interpretation" section of Standard 7.1). They can also be used on business cards where the official language in each unilingual version matches that of the language of the text, i.e., the unilingual English version as part of the English information on the card, and the unilingual French version as part of the French information. However, the use of these unilingual versions are once again to be seen as short forms to facilitate the public's contact with a government office. They are not to substitute for the bilingual versions used for the response to E-mails (as noted above).

Chief Information Officer Branch Direction du dirigeant principal de l'information John Doe Junior Technology Projects Officer Information Policy Division L'Esplanade Laurier, 10th Floor, East Tower 140 O'Connor Street, Ottawa, Canada  K1A 0R5 613 123-4567  Facsimile: 613 123-4567 Internet: doe.john@tbs-sct.gc.ca

Direction du dirigeant principal de l'information Chief Information Officer Branch Jean Doe Agent junior des projets en technologie Division de la politique de l'information L'Esplanade Laurier, 10e étage, tour Est 140 rue O'Connor, Ottawa, Canada  K1A 0R5 613 123-4567  Télécopieur : 613 123-4567 Internet : doe.jean@tbs-sct.gc.ca

Federal Identity Program