Technical Requirements and Recommendations, version 5.0

1. Markup
2. Scripting
3. Layout and Design
4. Browsers and Input Devices
5. Content Types and Formats
6. Metadata
7. Databases
8. Performance Measurement
Contact Information

Note: In this document, requirements are mandatory, while recommendations, although optional, are strongly recommended. CIF-funded projects will be evaluated against the requirements listed below. Following this technical evaluation, fund recipients will be asked to revise their website to comply with any requirement that has not been followed.

1. Markup

1.1 Markup Language

Requirement

All Web page content must be marked up using the "Strict" or "Transitional" Document Type Definition (DTD) for either HTML 4.01 or XHTML 1.0.

Note: Frames must not be used, and therefore the use of the "Frameset" DTD is not permitted.

Recommendations

Fund recipients are encouraged to implement proper semantic markup in their Web pages. Semantic markup describes the content, as opposed to how the content is to be presented or displayed.

For example, a site menu is normally just a list of links. As such, it should be marked up as a list (e.g., <ul>) because the list element describes the semantic structure of that content. If the site's design calls for the menu to be displayed as a horizontal menu bar, some developers might be tempted to mark up the menu as a horizontal row in a <table> element, but this mixes the content's semantic structure with its presentation. More importantly, it assigns the menu the wrong semantic structure: the <table> element is for marking up tabular data, but the site menu is a list of links. Instead, the menu should rightly maintain its proper semantic structure as a list element, while also being displayed horizontally through the use of appropriate Cascading Style Sheets (CSS) (see 3.1 Cascading Style Sheets).

Similarly, a paragraph should be marked up as a paragraph, as opposed to, say, text separated by <br /> elements within a generic <div> element. A document that includes several levels of hierarchical headings should make use of the different (X)HTML heading elements (i.e., <h1> to <h6>) in order to add the appropriate hierarchical semantic structure to the document and its sections. The heading elements can then be styled using CSS.

1.2 Code Validation

Requirement

a) All (X)HTML code must be completely error-free and validate against the chosen W3C-published DTD for either HTML 4.01 or XHTML 1.0, whichever is used.

Note: The one exception to this requirement is the proprietary <embed> element. While the <embed> element must not appear in the raw (X)HTML document that is served to the browser, it may be dynamically added to the (X)HTML page via client-side scripting.

The W3C provides access to an online HTML validator^[1].

1.3 Character Encoding

Requirement

a) All Web pages must use and declare either UTF-8 or ISO-8859-1 character encoding.

Note: For languages that use characters not available in UTF-8 or ISO-8859-1, see requirement 3.6b.

Top of Page

2. Scripting

2.1 Client-side Scripts

Requirement

a) All client-side scripts must be compliant with ECMAScript, version 3, also known as ECMA-262.

b) Key features of the site must function if client-side scripting is disabled or not supported.

Recommendations

Following the progressive enhancement approach (see Recommendations under 4.1 Browser Compatibility) and the best practice of separating presentation (CSS - see 3.1 Cascading Style Sheets) from content ((X)HTML), fund recipients are strongly encouraged to also separate behaviour (JavaScript) from content in the same way. This is known as unobtrusive JavaScript, as all JavaScript is loaded from external files and the basic (X)HTML page code includes no JavaScript at all, including inline event handlers such as onclick or onmouseover.

By linking to external JavaScript files that dynamically alter the (X)HTML Document Object Model (DOM), desired modifications or additions to the Web page can be made, leaving the original (X)HTML content served to the browser untouched. Unobtrusive JavaScript is an approach that improves the maintainability of the website, since, for instance, updates to JavaScript functions associated with event handlers can be made from within the JavaScript code itself, as opposed to having to modify all of the Web pages had the JavaScript functions and event handlers been written inline in the (X)HTML source code.

CIF recommends that fund recipients develop client-side scripts using either JavaScript version 1.5 or JScript version 5.5, which most closely comply with ECMAScript, version 3.

Top of Page

3. Layout and Design

3.1 Cascading Style Sheets

Requirements

a) Cascading Style Sheets (CSS) levels 1 and/or 2 must be used to establish the presentation of Web page content.

b) All CSS must be valid (i.e., completely error-free).

Note: The W3C provides an online CSS validator^[2].

c) All core website content and functionality must be available without CSS.

Recommendations

It is strongly recommended that the website's presentation be entirely separated from its content by making all style (CSS) declarations in external files that are loaded from within a page's <head> element using either the <link> or the <style> @import methods, or both.

Fund recipients are strongly urged to implement a print style sheet that provides a printer-friendly page layout that, for example, prevents certain elements and features (e.g., decorative images, site menu, colour) extraneous to the page's content from being printed. Print style sheets can be distinguished from other style sheets that a page loads by setting the relevant <link> or <style> element's media attribute to "print" (i.e., media="print").

3.2 Tables

Requirements

a) Tables can only be used for numerical data presentation. The use of layout tables is not permitted.

b) Numerical data tables must incorporate row and/or column headers.

c) Numerical data tables must incorporate the scope attribute.

d) A descriptive name or title for each numerical data table must be provided using the <caption> element.

3.3 Pop-up Windows

Requirement

a) The use of pop-up windows is not permitted.

3.4 Image Maps

Requirements

a) The use of server-side image maps is not permitted.

b) While CIF discourages their use, client-side image maps must be made accessible by including appropriate alt attributes for both the <img> and <area> elements used by the image map.

3.5 Screen Resolution

Requirement

a) The website must be effectively viewable at every screen resolutions (including 800x600 with no horizontal scroll bar at the bottom of the page).

3.6 Font

Requirements

a) The font-size of text must be established in a way that allows it to be increased and decreased using the built-in functions of popular browsers. In other words, font-size must not be declared in pixels (px), or in absolute units such as points (pt), but rather as relative units such as percentages (%) or "ems" (em).

b) If the website employs a language that uses characters not available in the UTF-8 or ISO-8859-1 character encodings, users must be provided free access to download the required font that will allow them to view the content. (See also >requirement 1.3a.)

3.7 Visual Contrast

Requirement

a) Web pages must be developed with sufficient visual contrast between text and background colours in order to be legible to all users.

Note: Various online tools for checking the visual contrast between text and background colours are available, for example, the Colour Contrast Check Tool^[3].

Top of Page

4. Browsers and Input Devices

4.1 Browser Compatibility

Requirement

a) All core website content and functionality must be accessible in any browser, although its presentation may vary.

Note: While the site's presentation or behaviours may not be consistent across all browsers or devices, all users, regardless of their browser, must have access to the site's basic content and functionality.

Recommendations

It is strongly recommended that fund recipients develop their sites following the progressive enhancement approach, a Web development strategy that produces, at the most basic level, a website whose core content and functionality are available to all users, no matter what browser or device is used. By progressively adding CSS presentational and JavaScript behavioural effects in a layered fashion, the site provides an increasingly enhanced experience for those with browsers that can take advantage of the added features. However, the site's core content and functionality remain available to everyone, regardless of browser or device.

For example, a timeline of major historical events might be developed using Adobe Flash, and require that users have at least version 8 of the Flash Player installed in their browser. In this case, the information in the timeline is probably not accessible to those using assistive technologies such as a screen reader, and certainly not to those using a Mac with MacOS 9.1, which can only run up to version 7 of the Flash Player. Instead, by creating a simple (X)HTML text version of the timeline and including this as the default content in the (X)HTML page, it is guaranteed that all users will be able to use the timeline. By additionally linking this page to an external JavaScript file that checks if the browser has the appropriate version of the Flash plug-in, the page's (X)HTML code could be dynamically modified by the JavaScript (assuming that the browser is capable of implementing the required JavaScript methods) to load a Flash version of the timeline. Users of suitably capable browsers would thereby receive an enhanced Flash version of the timeline, with no loss of accessibility for those using browsers that are not so capable.

4.2 Input Device Independence

Requirement

a) All core website content and functionality must be accessible, at a minimum, to both mouse and keyboard input.

Top of Page

5. Content Types and Formats

5.1 Plug-ins and Specialized Software

Requirements

If a plug-in or specialized software is required to view, listen to, or use certain content (e.g., audio, video, animation, text):

a)The plug-in or software must be freely available to users and platform-independent.

b) A link to a page that allows users to download the plug-in or software must be provided on those pages where the plug-in or software is required, and before the content is presented.

c) A sentence alerting users that a plug-in or specialized software is required to access the content must appear on those pages where the plug-in or software is needed, and before the content is presented.

5.2 Text (See also 5.1 Plug-ins and specialized software)

Requirement

a) All text-based content must be displayed primarily in (X)HTML format.

Note: Text-based content can additionally be developed in a proprietary format, for viewing or printing, with the use of a freely available and platform-independent plug-in or software (e.g., Adobe's PDF^[4], which requires the use of the Adobe PDF viewer, Adobe Reader^[5]).

Text-based content can also be delivered in formats such as RTF or ASCII, or as a delimited text file. Content produced in such formats is acceptable if the files are intended for download, or for storage or manipulation by users outside of the browser environment, and if they are not meant to be a substitute for content created in (X)HTML.

Recommendations

To promote the long-term viability of text-based content, CIF recommends that fund recipients create and manage content in a structured format suitable for delivery as (X)HTML files. In most cases, storing text-based content as (X)HTML, XML or ASCII text will be the most appropriate option. This will reduce the dependency on any content creation or management software and on the server environment where it is stored.

Text-based content can also be developed and managed in a database or content management system (CMS). CIF recommends that fund recipients choose a system that will allow the content to be exported in a standardized format. A CMS must produce valid (X)HTML pages. This will ensure that the content managed in such environments is not completely dependent on a single application or platform and, at a minimum, that it can be migrated to new environments with greater ease.

5.3 Still Images

Requirements

a) JPEG, GIF, or PNG formats must be used for photographs and graphics in Web pages.

Note: CIF may grant an exemption to the above requirement in certain situations where the use of proprietary solutions is needed to meet project objectives. This could be the case, for example, for geographic maps. In such cases, specialized solutions could be chosen to provide users with greater flexibility in viewing the digitized objects. In order to obtain an exemption, fund recipients must request permission from CIF at the start of the project, with a justification for the use of such solutions.

b) All images, including graphical representations of text (including symbols), images used as list bullets, spacers, and graphical buttons, must be accompanied by text-equivalents in the form of <alt> attributes.

c) All large images and large graphic files must first be presented to users through thumbnail or other smaller image previews. The thumbnail or image preview must be hyperlinked so that when users click on it, they are directed to the larger version of the same image.

d) Original, high-resolution (e.g., TIFF or PNG) versions of images used in the website must be properly stored and backed-up in an environment such that fund recipients can access them at a future date.

Recommendations

<Alt> attributes are intended for those users who, for whatever reasons, cannot view the images in a Web page. Following requirement 5.3b, every <img> element must include an appropriate <alt> attribute, though what counts as appropriate depends on the image and its use or function in the page, from a user's perspective. An image's <alt> attribute, like any text-equivalent for video or audio, should be understood as a replacement for the image. When determining an image's <alt> attribute content, ask yourself how you would describe that image, in its specific context, over the telephone or in an email to someone who cannot see it. Remember that most users who cannot view images will usually either see the <alt> attributes' content as text, or hear it in the case that they are using a screen reader.

For example, an image of a map showing directions from one location to another should have an <alt> attribute that textually reproduces the directions indicated visually in the image. The <alt> attribute for an image of a sculpture should describe the image in a way that captures the intended meaning of the image as it is used in the page, perhaps as an example of a particular sculpting technique.

On the other hand, many images are purely presentational, such as stock photos in corporate banners, or custom images for list item bullets. In most cases, these images provide no meaningful content or information to users, and are simply there for presentational effect. While, as images, they require <alt> attributes, these <alt> attributes should be empty or null, i.e., <alt>="". This way, those who cannot view the images are not asked to pay them any notice, since there is no <alt> attribute content to direct their attention. Similarly, while blank images (e.g., "spacer gifs") included in (X)HTML content to help position elements on the page should in fact be replaced by proper CSS positioning, such images should equally take an empty <alt> attribute as they do not impart any meaningful content or information.

Sometimes, a content image will be accompanied by (X)HTML text that serves as a description of the image. If this text, through both its position in the source code as well as on the page, is clearly associated with the image, there is usually no need to repeat it in the image's <alt> attribute. Unless there is meaningful information in or about the image that is not found in its description, and which could rightly be added to the image's <alt> attribute, the <alt> attribute should remain empty, since the description will act as the image's text-equivalent. Often, though, developers, in a best effort to provide <alt> attributes, will reuse the image's textual description for this purpose. Unfortunately, this causes needless repetition for those users who, relying on <alt> attributes, will see and/or hear the same text twice, once from the <img> element's <alt> attribute, and once from the image's regular text description on the page.

<Alt> attributes should not be longer than 100 characters, spaces included. Should an image's <alt> attribute be longer than 100 chartacters, it is better to provide the complete text-equivalent as (X)HTML text next to the image, while giving the image itself an empty <alt> attribute.

5.4 Video (See also 5.1 Plug-ins and specialized software)

Requirements

a) All video files must be accompanied by (X)HTML text-based summaries or transcripts that allow any user to understand the essential content of the individual video clips without having to view them.

b) Video files that are loaded into a browser-embedded player must not start automatically, and the player must include controls for starting and stopping the video.

c) All links to large video files (i.e., files greater than 50 KB) must be accompanied by a label indicating the file's size and duration.

d) Where a codec is used to produce video files, it must be included in a common platform (such as the Apple, Real or Microsoft platforms) or freely-available for installation by users. A link to the codec must be provided for users who need to download and install it.

e) If video files are prepared for delivery in a high-bandwidth environment, a low-bandwidth version must also be prepared and provided to users.

Note: Some streaming systems allow producers to prepare a single video file that can be played at various streaming speeds corresponding to multiple Internet access speeds. In cases where such systems are used, a single version of a video file is sufficient.

5.5 Audio (See also 5.1 Plug-ins and specialized software)

Requirements

a) All audio files must be accompanied by (X)HTML text-based summaries or transcripts that allow any user to understand the essential content of the individual audio clips without having to listen to them.

b) Audio files that are loaded into a browser-embedded player must not start automatically, and the player must include controls for starting and stopping the audio.

c) All links to large audio files (i.e., files greater than 50 KB) must be accompanied by a label indicating the file's size and duration.

d) Where a codec is used to produce audio files, it must be included in a common platform (such as the Apple, Real or Microsoft platforms) or freely-available for installation by users. A link to the codec must be provided for users who need to download and install it.

e) If audio files are prepared for delivery in a high-bandwidth environment, an alternate low-bandwidth version must also be prepared and provided to users.

Note: Some streaming systems allow producers to prepare a single audio file than can be played at various streaming speeds corresponding to multiple Internet access speeds. In cases where such systems are used, a single version of an audio file is sufficient.

5.6 Animation and Flash (See also 5.1 Plug-ins and specialized software)

Requirements

a) All animation (e.g., Flash) files must be accompanied by (X)HTML text-based summaries or versions that allow any user to understand the essential content of the individual animation files without having to view them.

Note: Interactive features such as slide shows or photo galleries must be provided through standard (X)HTML interfaces, to which an animated or Flash interface is an alternate version.

When it is not possible to produce a standard (X)HTML version of a Flash animation, such as is the case for most interactive games, an (X)HTML text-based summary describing the function and purpose of the game will be acceptable. The (X)HTML version of the site is the one which will undergo a full technical evaluation by CIF before final funding is released.

b) All links to large animation files (i.e., files greater than 50 KB) must be accompanied by a label indicating the file's size.

Recommendations

It is strongly recommended that Flash files be added to Web pages using a client-side scripting solution such as UFO^[6], or SWFObject 2.0^[7]. For one, this will help the site where its progressive enhancement (see Recommendations under 4.1 Browser Compatibility) is concerned, as a Flash movie can dynamically replace the default and accessible version of the same content already in the page if the browser is appropriately JavaScript-enbabled and Flash-capable. Otherwise, the user will remain with the accessible and default version of the content. Secondly, such a solution serves to overcome the Microsoft ActiveX feature in Internet Explorer 6.x and above that forces users to first click on a Flash movie before interacting with it. (See also the note under requirement 1.2a.)

Fund recipients should be aware that a Web page presenting only Flash content contains no search engine indexable text. Therefore, content presented solely in Flash will not be indexed by search engine spiders. Additionally, since the majority of Flash content cannot be read by screen readers, the use of Flash involves rather serious accessibility issues that should inform any decision to implement Flash content.

Top of Page

6. Metadata

6.1 Dublin Core Metadata

Requirements

The following six mandatory Dublin Core elements must be applied to describe the most important pages of the website, such as the home page, each section's main page, and pages featuring resources for which there is sufficient context and meaning and are also worth listing in a search engine:

Title
Creator
Subject
Date Created
Language (where applicable)
Identifier

b) Metadata must be embedded in the <head> section of the (X)HTML page.

Each page described must feature a unique set of metadata content.

Note: Copying and pasting the same metadata content is bad practice as it makes pages compete among themselves to be retrieved. At the very least, no two pages should have the same identifier, title and list of subjects.

d) Metadata content must be in the language of the page.

Note: This means that a page in English must include metadata content in English, and a page in French, metadata content in French. The syntax (e.g., <meta name="dc.title" content="" /> is never translated. In cases where a page is bilingual or multilingual, metadata elements Creator, Title, Subject and Language must be repeated to reflect all languages; however, in such cases, it is not needed to repeat the Date Created and Identifier elements.

Recommendations

To facilitate compliance with the above requirements, the template below can be directly embedded in the (X)HTML code, within the <head> element. Fund recipients simply have to fill it out with the appropriate metadata content that best describes the given Web page.

Note: The template above is provided for XHTML. In HTML, the trailing slash (" /") is not required before the closing bracket (" >"), as in this example:

Top of Page

7. Databases

7.1 Database Interoperability

Requirement

a) If the website employs a database, the database must support open standards such as SQL and XML. The database solution must allow fund recipients to import and export the data into a range of commonly used formats that are independent of any particular platform and software rather than dependent on a proprietary one.

Recommendations

It is strongly recommended that fund recipients document their database designs and structures. Documentation about the design, the rationale behind it, and decisions behind normalization, etc., will serve several purposes. These include facilitating possible migrations, data recovery and preservation, not to mention allowing others to better understand the database itself in cases of future maintenance and software updates.

Fund recipients building databases to store large amounts of metadata are encouraged to follow the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)^[8]. "Open" means that the specifications are freely available. "Archives" refers to repositories. As the OAI mission statement indicates, "the Open Archives Initiative develops and promotes interoperability standards that aim to facilitate the efficient dissemination of content." The goal is essentially to enable access to Web content through interoperable repositories for metadata sharing, publishing and archiving.

The Protocol for Metadata Harvesting is a mechanism for interoperability between repositories. It gives data providers (for example, CIF fund recipients) technical options to make their metadata available to others, based on the open standards, HTTP (Hypertext Transfer Protocol) and XML (Extensible Markup Language). Metadata harvesters, such as cultural information portals and metadata repositories, can then harvest those metadata. Access to content is ensured through the metadata. In the OAI-PMH, the basic level of interoperability is provided by the Dublin Core metadata standard (either by using or mapping to it).

For more information, fund recipients can consult the Open Archives Initiative website^[9].

8. Performance Measurement

8.1 Web Metrics

Requirements

a) It is required that you implement the WebTrends / Smart Data Collection (SDC) automated system to collect, store, and analyze user traffic statistics on each page and for each Flash object within an (X)HTML page

Note:

Step 1. Open the supplied JavaScript source file and update it with your domain address information.

Step 2. Insert the updated JavaScript source file in a folder of your choice on your Web site server.

Step 3. Update the supplied SDC code according to the JavaScript file location.

Step 4. For the Beta version, the WebTrend / Smart Data Collection (SDC) code must be implemented on each of the main section pages and on at least one Flash object for testing and to verify that results are coming through.

Step 5. Once you have ensured that you have met all your performance measurement requirements and we have informed you that everything is working properly, the JavaScript code must be implemented on all Web pages and on all Flash objects within an (X)HTML page. This must be done before the final version is launched.

b) The SDC code must be located just before the closing body tag </body> of each (X)HTML page.

Recommendation

To help compliance with the above requirements, templates and examples are provided below. Fund recipients simply have to fill out the template or to follow the examples below with the appropriate JavaScript code and add it in the proper location of each Web page.

It is important to ensure the safeguard of the code so that it continues to track results over time, as indicated in the reporting requirements of the contribution agreement.

1) Keep the data the CIF has sent you (JavaScript source file, Filename, SDC code) in a safe location.

2) Include Web site/Web page update procedures that will ensure that the SDC code and JavaScript source file always remain in all your Web site pages during Web page update and/or new Web page creation.

The template and examples below will enable implementation of the SDC in (X)HTML pages.

1) The JavaScript source file is located in a directory that it is accessible to every page of your website.

2) The SDC code which appears below is placed just before the closing body tag, i.e. </body>, of each Web page.

3) Also remember to update the “relativePath”, “filename.js”, and “SDC code” fields, and if necessary, correct the “this.fpcdom”.

Example of the information you will receive in an email from the CIF:

this.fpcdom: .mywebsite.com
JavaScript- filename.js: dcs2xu4wocmeqpe8amn952g7r_7z9d.js
SDC code: dcs2xu4wocmeqpe8amn952g7r_7z9d
relativePath: Depend where you will place the filename.js file

This is the JavaScript source file to be updated and to insert in a folder of your choice on your Web site server. See example below:

this.fpcdom=".xyz.com"; Replace by domain name (URL) i.e., “.mywebsite.com”

This is the SDC code template to be updated (section highlighted in yellow only) and to cut and paste it before the closing body tag of each Web page. The relativePath is to be replaced by the URL related to the directory where the JavaScript source file is placed.

<script src="relativePath/filename.js" type="text/javascript"></script>


<script type="text/javascript">
//<![CDATA[
var _tag=new WebTrends();
_tag.dcsGetId();
//]]>>
</script>
<script type="text/javascript">
//<![CDATA[
// Add custom parameters here.
//_tag.DCSext.param_name=param_value;
_tag.dcsCollect();
//]]>>
</script>
<noscript>
<div><img alt="DCSIMG" id="DCSIMG" width="1" height="1" src="http://rabbit.pch.gc.ca/SDCcode/njs.gif?dcsuri=/nojavascript&WT.js=No&WT.tv=8.6.2"/></div>
</noscript>

The examples below will help with the insertion of the JavaScript code for all Flash objects within a Web page.

Using Flash with getURL. To log a virtual page view whenever a visitor plays a particular Flash movie embedded in your page, you can activate the dcsMultiTrack function from within the ActionScript for the Flash object using getURL.

getURL("JavaScript:dcsMultiTrack('DCS.dcsuri',
'/Support/movie.html/',
'WT.ti', 'Support%20and%20Services%20Movie', 'DCSext.WT.type1', 'Flash')");

Note that in ActionScript, this code must appear on a single line without a line break. This code does not need its own layer.

You can track other Flash events in addition to plays. To capture data when a button is clicked within a Flash application, use the dcsMultiTrack function from within the event handler for that button. For example, if you have a button that plays an additional piece of video, your event handler syntax may look similar to the following example:

on (release) {
getURL("JavaScript:dcsMultiTrack('DCS.dcsuri', '/Support/ws.html/'
'WT.ti', 'Training%20Info%20Button', 'DCSext.WT.type1', 'Flash')");
gotoAndPlay(2315);
}

Using this implementation, any visitor interaction that triggers a Flash event can be reported to SDC as a virtual page view.

Using Flash with ExternalInterface. Since the getURL function was removed from the ActionScript language in version 3, calling the dcsMultiTrack JavaScript function is slightly more complex in the newer version of Flash. Adobe recommends using the ExternalInterface object to call external JavaScript functions.

if (ExternalInterface.available) {
try {
ExternalInterface.call("dcsMultiTrack", "DCS.dcsuri",
"/flash/support_tab.html", "WT.ti", "Support%20Tab, 'DCSext.WT.type1', 'Flash'");
} catch (error:Error) {
// error handling here
} catch (error:SecurityError) {
// error handling here
}
}

As in the getURL examples in the previous section, this code can be embedded either in the first frame of a movie, or in an event handler.

Contact Information

For further information concerning the technical requirements presented in this document, please communicate directly with your CIF program officer, or contact CIF.