Français | Contact Us | Help | Search | Canada Site | |||||
What's New | About Us | Policies | Documents | TBS Site |
Calendar | Links | FAQs | Presentations | Home |
|
Common Look and Feel for the InternetNote: 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 SectionOverviewInternet 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 Standard 1.1All GoC Web sites must comply with W3C Priority 1 and Priority 2 checkpoints to ensure sites can be easily accessed by the widest possible audience. RationaleThis 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 1.1 Best PracticesAbsolute Pixel Size (February 2003) Absolute Pixel SizeIt 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 DesignAssociated 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:
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 FormsHTML 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:
Elements of an accessible form:
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 SheetsMost 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
This and more information regarding Style Sheets. 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 devicesUse 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):
Examples: http://www.w3.org/WAI/wcag-curric/sam71-0.htm How to make pop-up windows accessibleTo 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/ <noscript> <li><a href="/publications-e.htm">Publications</a><br></li> </TD>
Here is more information on how to implement accessible pop-up menus on your pages. Accessibility across platformsTo ensure accessibility across platforms:
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. Standard 1.2 (Updated)HTML or similar formats that are W3C Recommendations (e.g. XHTML) must be the primary format for all documents on Government of Canada Web sites. In cases where a document cannot be represented in HTML, users will be given information on how to obtain alternate versions, e.g., print, Braille, audio, etc. Version Histories
RationaleThe 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":
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. InterpretationPrimary Format for All DocumentsHTML 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.
* Recommendation is the term the W3C currently uses instead of Standard Alternate VersionsIn 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 PracticesTechnique 1: Include A Statement Technique 1Include 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):
Technique 2Accessible 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 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 3Accessibility 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 4Converting 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 5Manager'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 6Guidelines 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
I Providing Accessible Human Resources Development Canada Information to All CanadiansAs 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 ProductionWhen 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
III Guidelines and Specifications for Providing Information in Multiple FormatsSome 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:
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:
Label:
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:
Binding:
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:
Label:
Considerations for Multiple Format Production
IV AnnexTreasury Board of Canada Secretariat How to Provide Alternative Formats (BT53-7/1993-L) Braille Authority of North America (BANA) National Library Service for the Blind and Physically Handicapped University of British Columbia Disability Resource Centre (Crane Library) Web Content Accessibility Guidelines Closed Captioning Web Standard 1.3To ensure universal accessibility, GoC Web pages that offer information in alternate formats must include a text indication of the file type that provides a hyperlink to a site where the necessary software can be obtained. RationaleNeither 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 PracticesThe 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:
Example explanatory text:
Standard 1.4All GoC Web sites and their pages must incorporate text equivalents for non-textual elements, such as graphics, images, navigational aids, sound tracks, to ensure universal accessibility goals are achieved. RationaleThe 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)Web Accessibility Initiative (WAI)
Guideline 1.1Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. If HTML is used, HTML 4.0 Strict or newer W3C adopted languages should be adopted
as the standard for new and revised Web pages.
Best PracticesBrowser TestingFollowing these 6 steps should minimize the need for testing multiple platform / browser combinations.
Guideline 1.2Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. If a page / site is explicitly designed to
provide information to alternate technologies such as hand-held, print, Braille,
and audio devices, such delivery should be handled with the "media"
element in Cascading Style Sheets.
Best PracticesMedia AttributeCSS2 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).
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 This means that you shouldn't declare media="all" if you want Netscape to read the style sheet. Bug 2: Commas destroy Important InformationThis 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:
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 Collaborative Arrangements SectionOverviewGoC 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. Standard 2.1GoC organizations must ensure that Web sites that represent a collaborative arrangement acknowledge their participation by prominently displaying one of the FIP identifiers thereby achieving a visual presence and balance between the government and its partners. RationaleThese 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. InterpretationInstitutions 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 PracticesAn 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. Standard 2.2Because the GoC clearly disallows the creation of unfair competitive advantage in the private sector through the endorsement of private interests, GoC Web sites must not display third-party icons, symbols or logos that represent the products and services of private enterprises or individuals apart from exemptions made within the context of collaborative arrangements and the use of TB approved symbols for government-wide use. RationaleTrade 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. InterpretationThe 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 PracticesHyperlinking 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.):
Cybersquatting SectionOverviewSome 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. Standard 3.1 (Updated)To help protect the unique identity and integrity of Government of Canada Web sites, GC organizations must register and maintain the registrations for any domain names that include their title in commonly used domains such as .com, .org, .net, .ca, etc. To help promote the unique identity of the Government of Canada online presence, GC institutions must register and maintain the registrations for their primary domain names, and any domain names supporting online services or products, in the ".gc.ca" domain. The domain names registered in the ".gc.ca" domain must be used for the purposes of advertising, marketing and promotion. Version Histories
RationaleInstitutions 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. InterpretationInstitutions 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 PracticesGuidelines for Registration of Top Level Domain Names (July 2001)BackgroundThis 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 processOn 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 registriesICANN'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 nameAccording 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 FeesSimilarly, 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. IssueThe 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. BackgroundThe 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 RulesBy 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. CybersquattingThese 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. RecommendationsTherefore, 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 Notes
E-Mail SectionOverviewMost 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. Standard 4.1All GoC Web sites must provide users with a means of contacting institutions / individuals via electronic mail options. RationaleWhile 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. InterpretationThe 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 PracticesForms 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.
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. Standard 4.2All outgoing e-mail messages sent by GoC employees must include the sender's name, institution, telephone and fax numbers with area code and extension numbers, postal and e-mail addresses. Where an e-mail address serves a program or service rather than an individual, contact information must include the institutional name, postal and e-mail address, telephone and fax numbers. RationaleWith 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.). InterpretationOutgoing 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.
4.2 Best PracticesDecember 2002
Example: John Doe 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. Standard 4.3All outgoing e-mail messages by GoC employees must demonstrate a consistent application of the "Canada" wordmark and institutional signature. RationaleThe 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 PracticesJune 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. Standard 4.4 (Updated)Institutions must ensure that legitimate electronic correspondence is acknowledged in a timely manner. Version Histories
RationaleAuto-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 PracticesIf 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----- 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----- 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 SectionOverviewIn 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. Standard 5.1All GoC Web pages must include direct access to plain language information regarding the rights, responsibilities and legal obligations of the information provider and the end-user, in the format of an Important Notices link. RationaleStandard 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
5.1 Best PracticesOfficial Languages Notice (January 2003) 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
(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:
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> Note: The above solution does not work in Netscape. An alternative is currently being explored. 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. 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. Standard 5.2The following Copyright / Permission to Reproduce text must be included within the Important Notices link at the bottom of all GoC Web pages. RationaleInclusion 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. Standard 5.3All GoC Web sites must adapt the following Privacy Notices within the Important Notices link at the bottom of all GoC Web pages. RationaleThe 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. InterpretationEach 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:
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 PracticesAn institution's Web site Privacy Notice should include a statement concerning:
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. Standard 5.4All GoC Web sites must include a Privacy Notice Statement, whenever Web pages provide an opportunity for users to input personal information. RationaleFrom 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. InterpretationA 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 PracticesRefer to the following checklist for a complete list of items to be considered: Privacy Notice Statement ChecklistIndicate: 1. That all personal information provided is protected under the Privacy
Act Guideline 5.1Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. Where externally sourced information,
i.e., third-party information, is hosted on the institutional Web site,
a liability disclaimer could be directly attached to the externally
sourced information and should describe the type of information to which
the disclaimer applies, i.e., databases, documents.
RationaleInstitutions 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 PracticesIf 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:
Guideline 5.2Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. Either of the following formats should
be used only in exceptional circumstances in which institutions believe
application of the Crown copyright symbol is necessary to protect
specific elements of their Web sites:
(a) © Government of Canada, date or (b) © Applied title of Institution, date RationaleAll 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 PracticesThe 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.3Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. All GoC
Web sites may want to incorporate Exit Notices in site architecture as a
means of informing users that they are about to leave a gc.ca domain.
RationaleWhile 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. InterpretationThere 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 PracticesThe 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 SectionOverviewElectronic 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. Standard 6.1All GoC Web pages must include the common menu bar, placed at the top of every Web page, to facilitate navigation through and between GoC sites. The GoC menu options must appear in this order and include: Language (English / French) for bilingual sites only, Contact Us, Help, Search and Canada Site. Version Histories
RationaleConsistent use of a common menu facilitates navigation on GoC sites and consistently consolidates key common functions across all GoC Web sites. Interpretation (Updated)
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:
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.
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 PracticesCommon Menu BarThe 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 buttonBilingual 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
"Help" page
"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
Standard 6.2All GoC Web pages must incorporate an institutional menu similar in design and placement to the common menu bar. The number of buttons and choice of terminology should represent plain language descriptors of the organization's program and services. Department, Branch / Sector, Division RationaleEstablishing a standard format and location for the primary institutional menu facilitates attainment of CLF navigation objectives and further enhances communication and identification objectives. InterpretationThe 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. Standard 6.3All GoC Web sites must adopt the following five metatags as a metadata standard for description of Web resources: Title, Originator, Language of Resource, Date and Controlled Subject. Metatag Generator Common Look and Feel Metadata Standard Definitions and HTML Examples 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. RationaleMetadata 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:
For more information see: Selecting and Implementing a Metadata Standard for the Government of Canada InterpretationEssentially 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 PracticesTo 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. 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. How to register a controlled vocabulary or thesaurus for use in dc.subject on federal government Web sites: Registering a Standardized Vocabulary LinksSearch to select subject descriptors: Common Look and Feel Metadata Standard Definitions and HTML Examples Training materials for applying Dublin Core metadata Standard 6.4 (Updated)All Government of Canada Web pages must have a date indicator to inform visitors of the currency of the content and signal that the end of that page has been reached. All currency indicators must use the ISO standard format for all-numeric date display (YYYY-MM-DD) and use at least one of the following date labels: "Date published:", "Date modified:", or "Last updated:". Version Histories
RationaleThe 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. InterpretationThe 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 PracticesIt is useful to establish a standard marker that signifies users have reached the end of any given Web page. Standard 6.5All GoC Web sites must use only standard 216 Web-safe colours for Web site elements, including menu bars and navigation aids, typography and background, and for simple graphic components. RationaleOnly 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. InterpretationIn 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 PracticesBlack text on a white background provides high contrast and utility with respect to on-screen and printed information, and provides numerous accessibility advantages.
Standard 6.6Frames must only be used on GoC sites as an alternative format. RationaleFrames 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. InterpretationIt 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. Standard 6.7Web analyzer tools must be the standard means of collecting site usage data. Counters must not be used to perform this function. RationaleAs 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. Standard 6.8All GoC institutions must apply HTML validators to existing Web sites to assess accessibility status and HTML validations must be applied to new GoC sites prior to posting. RationaleAll 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 ValidationValidate 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:
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.1Guidelines are not mandatory with respect to this policy but are provided to help institutions carry out government policy efficiently and effectively. All GoC
Web sites should incorporate Cascading Style Sheets
(CSS) or similarly sized tables to achieve consistent presentation of content.
W3C Cascading Style Sheets,
W3C CSS Validator
RationaleEffective 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. InterpretationEffective 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 PracticesLayout and presentationOnce a majority of users use browsers that support CSS-2, the following style sheet techniques should be used to control layout and presentation.
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.
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.Standard 7.1All GoC institutions must register their gc.ca domain names using at least one of the two following domain name conventions. (a) a name or acronym that represents the institution's primary purpose in both official languages, e.g. www.canada.justice.gc.ca, www.ic.gc.ca (b) 2 acronyms or names- one with the English first, the other giving prominence to the French, e.g. pco-bpc.gc.ca and bpc-pco.gc.ca and space-spatial.gc.ca spatial-space.gc.ca
Institutions may also register equivalent unilingual English and French versions of a name, or the acronym thereof, if they wish or need to use those on unilingual content pages (i.e., pco.gc.ca on English content pages and bcp.gc.ca on the French content pages) or when publishing information in unilingual media, e.g., in English or French magazines or newspapers. RationaleJust 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. Standard 7.2All GoC Web sites must incorporate Welcome Pages at the main point of entry to the site. Each Welcome Page must incorporate three key elements: the "Canada" wordmark, the institutional signature and the language choice buttons except on unilingual Web sites where a content button must be provided. See Policy on using the official languages on electronic networks, which sets out requirements for bilingual sites as well as for unilingual sites, with a special disclaimer and hyperlink requirement for the latter, see Standard 7.4. If Welcome Pages are used at a sub-site level, they must conform to the above requirements. All elements of each Welcome Page must be viewable without scrolling in a 640 by 480 pixel screen. RationaleWelcome 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. Standard 7.3All Web pages on all GoC Web sites must incorporate the "Canada" wordmark and the institutional signature using high quality reproductions in terms of accuracy, colour and resolution. (a) The "Canada" wordmark must appear in the lower right display area on Welcome Pages and in the upper right display area on Content Pages. (b) The institutional signature must appear in the upper left display on both Welcome and Content pages. On the Welcome page of a site, the order of the 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. RationaleStandards 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 SectionOverviewAll 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. Standard 7.17.1 All GoC institutions must register their gc.ca domain names using at least one of the two following domain name conventions. (a) a name or acronym that represents the institution's primary purpose in both official languages, e.g. www.canada.justice.gc.ca, www.ic.gc.ca (b) 2 acronyms or names- one with the English first, the other giving prominence to the French, e.g. pco-bcp.gc.ca and bcp-pco.gc.ca and space-spatial.gc.ca spatial-space.gc.ca
Institutions may also register equivalent unilingual English and French versions of a name, or the acronym thereof, if they wish or need to use those on unilingual content pages (i.e., pco.gc.ca on English content pages and bcp.gc.ca on the French content pages) or when publishing information in unilingual media, e.g., in English or French magazines or newspapers. RationaleJust 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. InterpretationIf 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.
See following examples that illustrate the above principles. For publications:
If geographic names are included as part of the domain name, the following principles apply:
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 PracticesURLs (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. Standard 7.2All GoC Web sites must incorporate Welcome
Pages at the main point of entry to the site. Each Welcome Page must incorporate three key
elements: the "Canada" wordmark, the institutional signature and the language choice buttons except on unilingual Web sites
where a content button must be provided. See Policy on using the official languages
on electronic networks, which sets out requirements for bilingual sites as well as for
unilingual sites, with a special disclaimer and hyperlink requirement for the latter, see
Standard 7.4. RationaleWelcome 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. InterpretationThe 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:
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. Standard 7.3All Web pages on all GoC Web sites must
incorporate the "Canada" wordmark and the institutional signature using high quality reproductions in terms of accuracy, colour and resolution. RationaleIn 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. Standard 7.4Unilingual GoC Welcome Pages must include a bilingual message indicating that under the Official Languages Act, the office provides services to its clientele in only one official language. This message must also inform users of a hyperlink to a site where users have access to general information in both official languages. Appendix B of the Policy on using the official languages on electronic networks contains a model Welcome Page showing the message that must be used. As well, the Policy indicates what disclaimer statements must be used in the case of bilingual sites that post unilingual content that belongs to entities not subject to the Official Languages Act. RationaleThe 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. Standard 7.5All Web pages on all GoC Web sites must
incorporate navigational buttons that allow users to proceed through the site in the
language of their choice or to access identical information in the alternate official
language, except where the office providing the Web site is not designated bilingual. RationaleThe 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 PracticesExample of common and institutional menu bars of bilingual Web sites.English content page:
French content page:
Example of common and institutional menu bars of unilingual Web sites.English content page:
French content page:
Standard 7.6 (Updated)Messages generated by Web servers and Web application servers must be presented in the official language preference indicated by the user. If this is not feasible, or if the language preference of the user is not known, the message must be presented completely in both official languages and in the prescribed order. For more information, refer to the Directive on the Use of Official Languages on Web Sites1. Version Histories
RationaleThe 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 noticesStandard 7.7All text equivalents must be given in the language of the Web page in which they are embedded. RationaleThis principle is consistent with that set out under Standard 7.6. Federal Identity Program (FIP)Standard 7.8The mandatory elements that make up the metatag for any given Web page must correspond to the page's official language. InterpretationIn 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. MetadataComplete 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
See example of metadata for a page: <meta name="title" content="enter the title in English
or French"> Metadata for an English content page: <meta name="title" content="216 Web-safe Colours"> Metadata for a French content page: <meta name="title" content="216 couleurs recommandées pour le Web> Standard 7.9Federal institutions must ensure that their content posted on a site that represents a collaborative arrangement complies with the official language requirements that would apply if the site were strictly the site of the office in question. RationaleThe content for which a federal office is responsible must be clearly identified for the public and must respect official languages requirements. InterpretationAll 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. Standard 7.10All GoC electronic mail administrators must provide all public servants with e-mail addresses that demonstrate compliance with official language requirements by applying the e-mail address format that reflects the institution's chosen domain name. See Standard 7.1 above regarding the order of the official languages in the domain name. RationaleFor 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. TemplatesE-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. InterpretationInstitutions 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).
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Top of Page |
Important Notices |