c/o Adaptive Technology Resource Centre 1st Floor, Robarts Library, University of Toronto 130 St. George St. Toronto, ON M5S 3H1 Tel: (416) 946-3225 | Fax: (416) 971- 2629

XXXXXXX XXXX XXXXX XXXXXX

March 11, 2002

This report first describes the Accessibility Conformance Rankings outlined by the W3C Web Accessibility Initiative (WAI). Comments that follow are based on the WAI "Web Content Accessibility Guidelines 1.0", and include techniques to remedy some of these barriers drawn from the "Techniques for Web Content Accessibility Guidelines 1.0". Developers should use this description along with the report that follows, to set a conformance goal for the accessibility of their Web site.

Secondly, this report includes general comments about overall features of the XXXXXXX XXXX XXXXX XXXXXX site that may create barriers for people with disabilities. These comments should be generalized to all pages on the site.

Refer to:
http://www.w3.org/TR/WAI-WEBCONTENT/
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/

Accessibility Conformance Ranking

Three levels of conformance are possible: A, AA, and AAA. Each level represents compliance with the Priority guidelines set out by the WAI. These are:

• [Priority 1] A conformance ranking (see items marked P1) 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] AA conformance ranking (see items marked P2) A Web content developer should 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.
• [Priority 3] AAA conformance ranking (see items marked P3) A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

Conformance Goals

A conformance ranking of AAA includes overcoming all access barriers associated with each of the priority levels. A ranking of AA includes overcoming all Priority 1 & 2 barriers, and a ranking of A includes overcoming all Priority 1 barriers. Developers should set realistic goals for attaining a given level of conformance. It would be realistic for the developers of the XXXXXXX XXXX XXXXX XXXXXX site to set a goal of A or AA conformance.

---

General Evaluation

http://www.somewhere.com/
P1 - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. For example, if Object is used, provide a text equivalent in the content of the element. If Applet is used, provide a text equivalent with the "alt" attribute and in the content of the Applet element. This enables the content to transform gracefully for those browsers that only support one of the two mechanisms ("alt" or content).

Comments:
Be aware that the dynamic content generated when a user moves a mouse pointer over the menu on the home page, or over the icons in the graphic header, will not be accessible to most assistive technology users. This is acceptable when the mouseover information is reproduced on the targeted page, or where the information displayed in the mouseover is not important to the functionality of the site or to understanding its content. In most cases it appears that mouseover content has been reproduced on the targeted page and does not affect functionality if a user is unable to access it. Note that the mouseover for the "Email your XXXXXXXX" (Your Feedback) icon in the header graphic produces jumbled content when viewed with Internet Explorer 5.0.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/#tech-scripts
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts
http://www.w3.org/WAI/wcag-curric/sam56-0.htm

P1 - A text equivalent must be provided for every non-text element on a web page. Examples of non-text elements include: images, graphical representations of text (including symbols), image map regions, animations (e.g. animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), standalone audio files, audio tracks accompanying video, and video presentations. The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people with various disabilities using a variety of technologies. Text is accessible to virtually all users because it can be output by screen readers, non-visual browsers, and braille readers. Text equivalents can be added to web documents via the "alt" or "longdesc" attributes.

Comments:
Though the site makes very good use of Alt text throughout, there are a number of instances where a longer description of images should be provided. For example, the information graphs linked from the opening page of the "XXXXXXXXXXX Report Card", should either include a longer description that summarized the key features in the graphs, or include the numbers associated with bars or lines within the graph in a separate table or list for users who are not able to see the graphs or are looking for a more exact measures than that discernable by viewing the graphs.
It is also important that relevant textual information within images be reflected in the Alt text associated with the image. In the image map that displays the faces of past Prime Ministers, names, but not dates, are associated with each of the Prime Ministers. Dates should also be included. Alternatively the content of the whole image could be duplicated in a table that displays names and dates as text, or a long description could be linked from the image (as a d-link, or a LONGDESC) that summarizes the content of the image.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/#tech-text-equivalent
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-text-equivalent
http://www.websavvy-access.org/resources/top_ten.shtml#alt_format
http://www.w3.org/WAI/wcag-curric/sam2-0.htm

P1 - Use the clearest and simplest language appropriate for a site's content. All users, whether they have disabilities or not, benefit from a site that includes easy to understand language, consistent page layout, and recognizable graphics. Adhering to a good writing style by avoiding jargon, overly complex sentences, and using active rather than passive verbs will help ensure that the content of your site remains accessible to most visitors, including those with reading and/or cognitive disabilities.

Comments:
On the Awards page links to the various award sites should use natural language instead of URLs as link text. URLs tend to be read as gibberish by assistive technologies. The titles associated with each award would work well here as link text.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-simple-and-straightforward
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-simple-and-straightforward
http://www.w3.org/WAI/wcag-curric/sam113-0.htm
http://www.w3.org/WAI/wcag-curric/sam114-0.htm

P1 - Ensure that information conveyed using colour is also available without colour (i.e. through context or markup). Individuals using screen readers, text-only browsers and those unable to differentiate between certain colours will not be able to access information conveyed by colour alone.

Comments:
On the site the underlining normally associate with links has been removed by using the "text-decoration: none" style. For users with low vision or colour blindness, finding blue links embedded in surrounding black text will be difficult. It is recommended that the underlining normally associated with links be maintained except where it is obvious to the user that the text is a link (e.g. in a navigation menu). Links embedded within surrounding text should always have some indicator other than colour that indicates the text is a link. In some cases throughout the site link underlining has been removed, but the text is presented in bold to indicate that it is a link. If this strategy is used in place of underlining, it should be used consistently through the whole site.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/#gl-color
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#gl-color
http://www.w3.org/WAI/wcag-curric/sam25-0.htm

P2 - For scripts and applets, ensure that event handlers are input device-independent. Use application-level event attributes such as "onfocus", "onblur", and "onselect". These attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers. To ensure a text equivalent of the script or applet is available on systems that do not support scripts and event-handlers, include equivalent content in a NOSCRIPT section.

Comments:
The "Quick Find" menu on the Home page will not be accessible to many assistive technology users. While it is possible for these users to use the menu with knowledge of the appropriate keystrokes required, the "Alt down arrow" key combination is relatively unknown to average Web users. As a result most keyboard users will not be able to get past the first item in the list without being directed to that page automatically. This problem can be corrected by removing the OnChange event handler and replacing it with a manual HTML submit button.
Pages must also function when scripting is disabled or not supported. When Javascript is disabled the Quick Find menu does not function. Using a standard HTML submit button would solve both the keyboard access and the script functionality problems.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-keyboard-operable-scripts
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-keyboard-operable-scripts
http://www.w3.org/WAI/wcag-curric/sam57-0.htm

P2 - Create documents that validate to published formal grammars. Validating web documents to a published formal grammar and declaring that validation at the beginning of a document informs the user that the document's structure is sound. Including a DOCTYPE with each web document identifies which version of HTML is being used should the document's syntax require verification.

Comments:
A DOCTYPE declaration should be included at the opening of every page to identify the version of HTML being used. This will help assistive technologies identify the appropriate version of the markup language used, and interpret pages accurately based on that version.
The W3 HTML validator reports a variety of markup errors, many of which would validate if the markup language were identified.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-identify-grammar
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-identify-grammar
http://www.w3.org/WAI/wcag-curric/sam29-0.htm
http://validator.w3.org/

P2 - When an appropriate markup language exists, use markup rather than images to convey information. For example, use MathML to markup mathematical equations, and style sheets to format text and control layout. Also, avoid using images to represent text, use text and style sheets instead. Using markup and style sheets in place of images promotes accessibility because text can be enlarged by low vision users and interpreted by speech synthesizers, braille and graphical displays. Style sheets also enable users to override author styles and change foreground/background colours in addition to font sizes and styles. In situations when images of text must be used (i.e. a company logo), providing a text equivalent with the "alt" attribute is an acceptable alternative but it is best to replace images of text with actual text wherever possible.

Comments:
The images used to create the navigation menu that appears down the left of most pages, and used to display page heading text, could be made more accessible if actual text were used instead of images of text. The navigation images on the left are of relatively low contrast and may be difficult for some low vision users to see. Without the option to increase the size of the text, possible for real text but often not possible for images of text, these users may find the menu difficult to use. Other advantages to using text instead of images of text include faster download times for remote users and users with slower Internet connections or older browsing technology, and increased usability for users accessing the site with text displays such as a cell phone or text browser.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-use-markup
http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup
http://www.w3.org/WAI/wcag-curric/sam28-0.htm

P2 - Ensure that foreground and background colour combinations offer sufficient contrast for all images when viewed using a monochromatic monitor or by someone with a colour deficiency (i.e. colour blindness). Example: A light green image presented on a yellow background would be very difficult to see for someone with a colour deficiency or on a monochromatic monitor.

Comments:
Instances where foreground/background colour combinations may not provide sufficient contrast include the URL displayed in the header graphic and between gray text and gray background in the navigation menu on the homepage.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-color-contrast
http://www.w3.org/TR/WCAG10-HTML-TECHS/#color-images
http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-color-contrast
http://www.w3.org/WAI/wcag-curric/sam26-0.htm

P2 - Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. Explicit labelling is necessary when form labels risk being separated from their associated fields. Placing labels immediately before or above a form field is usually sufficient. However, it is good practice to explicitly associate form labels using the LABEL element, along with the "for" or "id" attributes, to ensure labels remain associated with their related form fields should the viewing window be resized.

Comments:
On the Search page the label associated with the search field is separated from the field by a table cell. As a result some assistive technologies will not associate the field with "Enter your query", but instead identify the field with the word "edit". As a result some users many not understand what content should be entered into the field. Explicit labeling is advised for the search field. Alternatively, the accessibility of the form could be improved by removing the search field and label from the table they are currently laid out in so that label and input field appear immediately next to each other.
The same is true for the form found on the "Email the XXXXXX" page. Because labels are currently separated from their respective form fields by table cells, some assistive technology users will only hear that the fields exist, without any indication of what is to be entered into each one. All labels on this page should be explicitly associated with their fields using the LABEL element.
In a form such as the Quiz for Kids, labels appear immediately adjacent to their associated fields so explicit labeling with the LABEL element is not required. However, it is always good practice to use the LABEL element on all form fields so in the event the labels become dislocated from their fields (e.g. when the screen size is reduced), the explicit association between fields and labels is maintained. Using the LABEL element also allows a user to click on the label itself to activate the field (e.g. to select the radio button) allowing users who might have difficult targeting a tiny radio button (those with gross motor impairments), to click on a larger target area.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/#tech-associate-labels
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-associate-labels
http://www.websavvy-access.org/resources/top_ten.html#labels
http://www.w3.org/WAI/wcag-curric/sam78-0.htm

P2 - Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. If pop-up windows are used, their usage should be described on an "Accessibility Tips" page. Users should also be warned that external links to other sites open in a new window. Where possible provide a scripted link/button at the top of the pop-up window that will close that window. Content developers should also avoid specifying a new window as the target of a frame (i.e. target="_blank").

Comments:
In some instances new windows are opened for displaying external sites. Users should be warned when new windows are opened. If multiple windows are opened, it easy for some assistive technology users to become lost, and have difficulty finding their way back to the main window. For example, the link to the "Parliament of Australia Web site" (/aust_focus/stats/index.htm) opens into a new window without warning.
Each link on the links page opens into a new window without warning, and it is possible to have many new windows open. A general notice at the top of the page should warn users about new windows opening, and the target of each link should be the same window, rather than opening a new window for each one.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-pop-ups
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-pop-ups
http://www.w3.org/WAI/wcag-curric/sam77-0.htm

P2 - Clearly identify the target of each link. Link text should remain meaningful even when read out of context, either on its own or as part of a sequence of links. The key to creating meaningful link text is to clearly identify the purpose or target of each link (i.e. describe the destination of the link). In addition, it is also important to keep link text concise. Screen reader users will often use the tab key to cycle through the links on a page in order to gather the gist of its content. Ambiguous link text such as "click here" fails to convey any useful information to visitors. In addition, the term "click" suggests the link is only accessible via a mouse or other similar pointing device. Excessively long text links are unnecessary and can be confusing to visitors, especially if the link wraps on the screen.

Comments:
On the Links page (/links/index.htm) the word "here" being used as link text should be replace with more meaningful text such as "My Personal Favourites" or "All Government Web Sites".

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-meaningful-links
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-meaningful-links
http://www.websavvy-access.org/resources/top_ten.shtml#link_context
http://www.w3.org/WAI/wcag-curric/sam97-0.htm

P3 - When links are grouped into logical sets (in a navigation bar, for example) they should be marked up as a unit. Navigation bars are often the first item a visitor encounters on a web page. For those using speech synthesizers, this means having to listen to a list of links repeated before being able to access the main contents of a page. There are several ways to allow users to bypass groups of links. They include: creating a skip over link that allows users to bypass the set of navigational links; providing a style sheet that enables users to hide the link set; and, using the MAP element to group links, then identifying the group with the "title" attribute.

One method of creating a skip-over link is to place an invisible 1 pixel x 1 pixel gif immediately before the navigation links. This invisible link is anchored to the main content of the page and includes "alt" text indicating that its purpose is to bypass the navigational array. This invisible gif can also be used to direct visitors to alternative navigational tools. For example, if images are used as navigation links at the top of a page, text equivalent alternatives could be included at the bottom of the document and linked to the invisible gif by an anchor element.

The MAP element can also be used to create a grouping. (Although most developers use MAP for creating image maps, links contained between opening and closing MAP elements are not required to be part of an image map.) The "title" attribute is then used to identify the series of links as a navigational array and a skip-over text link allows visitors to bypass the grouping.

Comments:
Since many assistive technology users will have to listen to 10-15 links at the beginning of every page before reaching the content of the page, a means to bypass those links should be provided. An invisible gif as the first link on each page, with the Alt text "skip navigation" or something to that effect, would greatly improve navigation through the site for these users. The bypass link should anchor to just above the header text in the content area of each page.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-group-links
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-group-link
http://www.websavvy-access.org/resources/top_ten.shtml#bypass
http://www.w3.org/WAI/wcag-curric/sam104-0.htm
http://www.w3.org/WAI/wcag-curric/sam105-0.htm
http://www.w3.org/WAI/wcag-curric/sam106-0.htm

P3 - Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns. For some screen reader and text-to-speech users, text presented in table columns can create a significant barrier to accessibility. Older screen readers, for example, read tables in a linear fashion across the entire screen from left to right and from top to bottom. Sentences along the same row but from different columns are interpreted as one sentence. To gain a better understanding of how a screen reader might interpret a table, run a piece of paper down the page and read the table line by line across each column. The resulting output is often unintelligible. Use Tablin, linked below, to linearize columnar content.

Comments:
Though most current assistive technologies will read tabular content cell-by-cell, most older technologies read across the entire page one line at a time. As a result columns of text will be inaccessible to some users.
The "XXXXXXXXXXXXXX Portfolio List"is an instance where older technology users will have great difficult interpreting the page because of the wrapping of text in adjacent tables cells. This table could be made more accessible to assistive technology users, and more readable to other users, by laying out content in a linear manner, perhaps in a list format.
If the table format is used content would be easier to comprehend if the table had borders, also coinciding with the instruction above "Each box represents a portfolio." Enclosures such as brackets, boxes, or table cells, make content easier to comprehend for most people.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-linear-tables
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-linear-tables
http://www.w3.org/TR/WCAG10-HTML-TECHS/#wrapped-text
http://www.websavvy-access.org/resources/top_ten.php#tab_lin
http://www.w3.org/WAI/wcag-curric/sam79-0.htm
http://www.w3.org/WAI/Resources/Tablin

P3 - Provide keyboard shortcuts to important links including those in client-side image maps, form controls, and groups of form controls. In HTML documents, these shortcuts should be specified using the "accesskey" attribute. ACCESSKEYS are commonly included with navigational arrays to add direct keyboard accessibility to links. To activate an Accesskey, users must depress "Alt" simultaneously with the key designated by the "accesskey" attribute. It is important to make sure that the shortcut designated by the "accesskey" attribute does not conflict with shortcut keys used to control browser functions. For example, the number "1" can be designated as an Accesskey, but the letter "F" cannot because that opens a browser's file menu.

Comments:
A set of ACCESSKEYS could be defined for key navigation link, such as those immediately below the header graphic. Tabindexes might also be used to guide users to the first field in a page that contains a form. This strategy can conflict with the bypass links if users expect the first tab into a page to be a bypass. One strategy to avoid this conflict is to bring focus to the first form field using a javascript onload event handler that sets the mouse cursor into the first form field.

Refer to:

http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-keyboard-shortcuts
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-keyboard-shortcuts
http://www.websavvy-access.org/resources/top_ten.shtml#independence
http://www.w3.org/WAI/wcag-curric/sam76-0.htm

---

Notes:

Once the accessibility of a site has been addressed, access features should be described so users who require them can take advantage of them. This page might describe the use of alternative text for images and other non-text elements, describe the layout of page so users can develop a mental picture, or describe the key combinations require to activate ACCESSKEYS.