Web Site Development Standards Header
Search This Site
 
Home | Province of Manitoba Internet Policy | Website Development Standards
Accessibility | Common Utilities | CSS | Electronic Forms | File Structure | HTML Forms | Images
Linking | Metadata | Site Operation | Quality Assurance | Search | Department Template


Accessibility, Usability and Access Key Guidelines

All government of Manitoba websites will be accessible by following W3C priority 1 and 2 standards, where technologies allow. All government of Manitoba websites will, in the normal course of business, be updated to

  • recognize the provisions of the government of Manitoba standards on accessibility
  • implement in a reasonable timeframe
  • be realistic and achievable
  • be technically feasible in the current environment
  • be financially responsible
  • be consistent with government of Manitoba existing policies and objectives
  • be consistent with improved customer service for all Manitobans

The following sections are guidelines to follow for creating web pages that are accessible to users with constraints due to physical, sensory or cognitive disabilities, work constraints, or technological barriers. Accessibility can be checked through validators.

For more on Accessibility in Manitoba please see The White Paper, Full Citizenship: A Manitoba Strategy on Disability - http://www.gov.mb.ca/access.

The accessibility guidelines describe the mandatory and suggested requirements for validating HTML code before publishing in a production environment. All contractors delivering HTML to the government of Manitoba must follow these standards. For content that is not created with the province's accessibility standards, departments are responsible for ensuring compliance by providing an alternative means of access, such as a telephone number or e-mail contact.

Acronyms, attributes and abbreviations can be difficult for screen-readers to interpret. Fortunately, the solution is easy: in your HTML, just mark up abbreviations and acronyms with ABBR and ACRONYM and use "title" to indicate the expansion. All sites should use attributes such as: LONGDESC, TABINDEX, ACCESSKEY, NOSCRIPT, HEADERS, ID, SCOPE and ABBR. New tags and attributes have been introduced into HTML to ease access to non-elements. While HTML does not require the use of these tags, they should be used to improve accessibility.

Alternative formats: If full access cannot be achieved, the department must provide alternative formats or means to access the information for all users.

  1. Build or rebuild the web page so it is fully accessible under the province of Manitoba standard.
  2. Include a link to a printable copy. This is an electronic copy suitable for printing.

Alternative formats for persons with visual disabilities include:

  • audio cassettes: a publication recorded on tape
  • braille: a reading system using raised dots read by touch
  • descriptive narration: the spoken word fully explains action scenes, charts and other visual components on film and video
  • diskettes: publications on computer diskettes, let the user access information through a computer connected to a Braille printer, voice synthesizer, large print monitor or any other access system
  • large print: publication using 14 point type or larger
  • modems: A modem transfers information between computers via the telephone line.

Formats for persons with hearing disabilities include:

  • captioned films and videos: the spoken word appears in written text on the bottom of the screen as in subtitles. Open captions can be seen by everyone, while closed captions are visible with a special decoder
  • signed films and videos: the spoken word is transferred to sign language on screen

Applications that contain forward and back buttons must be labeled so their function is understood. Radio buttons are preferred over drop-down menus for selections between one to three options. Drop down menus should be kept short enough not to require a scroll bar.

Cascading Style Sheets - Refer to the Cascading Style Sheet Guidelines

DOCTYPE: All HTML files must begin with a DOCTYPE tag to tell user agents (including validation tools) what version of HTML the page is written in. The DOCTYPE tag should be the first line of your file, preceding the opening <HTML> tag.

  • The HTML 4.01 Strict DTD consists of elements and attributes not being phased out or unlikely to become obsolete in the future HTML versions.
  • The HTML 4.01 Transitional DTD includes the Strict DTD along with elements and attributes (most of which concern visual presentation) being phased out or likely to become obsolete in future HTML versions.

Images and icons must be labeled with descriptive Alt tags to ensure image titles or explanations are provided for non-graphical viewers. Image maps must have Alt tag descriptions, and users must provide with a text-only version of the image. Images such as spacers or lines, used for fillers, require an Alt attribute but not an Alt description tag. Instead they should be left blank - Alt="". Screen readers still indicate the presence of the image, therefore, speaking browsers can be instructed to ignore these images by using a "null Alt text." All government web pages must be navigable with text-only browsers, or browsers with graphics turned off.

Ensure that images of charts and pie graphs provide a plain text description of all the information conveyed in the image.

Buttons and images must be legible. If text or a graphic is on a button, it must be readable. Ensure that any colour combination used does not prevent colour-blind people from reading content. For example, red type on a green background or blue type on a black background may be impossible for colour-blind people to read.

Flickering images and blinking text should be avoided.

Enhancements (multimedia, video, audio, VBScript, Flash, etc.)

Enhancements may have adverse effects on users with different browser settings and accessibility concerns. If a user is incapable of viewing the enhancement, or the enhancement prevents the user from viewing other information for any reason (technology, security, impairment, etc.), then the information contained in the enhancement must be made available by other means. Test your pages with these enhancements turned off to verify that the pages are still viewable.

Avoid any content that creates barriers for people who have visual or hearing impairments. If using audio or video, make sure to provide equivalent information in forms suited for other users. Provide captioning and transcripts of audio, and descriptions of video. All multimedia items should indicate what they are, as well as their version, size and format, so all users can choose not to miss content. Formats requiring users to purchase plug-ins are not permitted. Ensure there is a link to the government of Manitoba utilities page, which features some common plug-ins http://www.gov.mb.ca/example/utilities.html.

Video and audio files must be offered in more than one format such as a low-resolution format for users with a modem and a high-resolution format for users with high-speed connections. Accessibility must also be considered when using these formats. An alternative file or means of retrieving the file must be available.

Departments enhancing a site with sound or video should ensure the enhancements do not contain critical information that would be missed by a deaf or visually-impaired site visitor.

Use of animation, framed web pages, video, or audio is not recommended. Consult with ManWeb and CSM before developing any such content.

Script (JavaScript, VBScript, pull-down menus, applets, plug-ins, etc) - web developers working with JavaScript URLs should not use images inside of them without providing meaningful information about the image or the effect of the anchor link.

Replace all JavaScript SELECT menus with server-side SELECT menus. JavaScript pulldown menus are inaccessible via the keyboard and should be replaced by pulldown menus that use a submit button. Include a description of each applet that conveys important information or function and provide an equivalent for non-Java-enabled devices. Ensure there is a link to the government of Manitoba utilities page.

Make sure your pages are usable and functional in browsers that don't support scripts or that have scripts turned off. Include a description of each script that conveys important information or function and provide an equivalent for browsers that don't support scripts.

The user should be notified if websites are using browser-specific proprietary tags or scripts (ex: certain JavaScript, Java or ActiveX implementations). Sites should be designed to be viewable by current, commonly available and used browser software. Enhancements may have adverse effects on users with different browser settings and accessibility concerns.

The browser's status line (at the bottom of the screen) typically displays the URL of the link the mouse is currently pointing towards. In the case of JavaScript URLs, the status line can become filled with meaningless snips of script. Any additional content containing text rewritten into the status line is difficult or impossible to detect with a screen reader. Although rewriting the status line does not interfere with the accessibility or inaccessibility of the JavaScript URL, web developers should not add any additional information on the status bar.

JavaScript uses event handlers as triggers for certain actions or functions to occur. Web developers must exercise some caution when deciding which event handlers to use in their web pages, because different screen readers provide different degrees of support for different event handlers.

Tables - Tables can be used for data and layout. Developers can check in Lynx or Opera (browser) to see how they read.

  • Screen sizes: should not use absolute values (td width="500").
  • The more nested tables you use, the more potential problems you create for users of assisted technologies and the slower your pages will load for everyone.
  • Never use structural markup, such as the TH tag, to make your text bold and centered in layout tables. It will confuse screen readers. Use style sheets to control the appearance of your text.
  • Ensure that users can skip repetitive navigation menus.
  • Use style sheets to control your table elements (padding, colours, alignment, etc.) than loading up each TD tag with multiple attributes.
  • WYSIWYG - Web-authoring tools don't always give you enough control over your tables, and often insert a lot of junk HTML code automatically. It's easier to write the HTML for tables yourself and maintain full control over the code, than to go in and clean it up later.
  • Always check your pages to see whether your tables make sense when linearized.
  • Always test your pages on multiple browsers and platforms before launch.

Text - Use text that makes sense when read out of context. (For example avoid click here, more, etc.) Text (which can be re-sized by the user) is preferable to pictures of text which cannot. The World Wide Web Consortium recommends, "Avoid using images to represent text - use text and style sheets instead." [Note: using text rather than pictures of text also creates faster-loading sites that are easier to update and maintain, since changes do not require a graphic designer to create new images.]

Use the clearest, simplest language appropriate for your site's content. As your content is being developed, read it aloud, then simplify, clarify or break up the text as needed. Wherever possible, keep your paragraphs short and use bullets to highlight information.

Validators. All web developers shall apply HTML validators to existing sites and check for accessibility. Use tools, checklist, and standards at http://www.w3c.org/TR/WCAG   The following is a list of accessibility validators obtained from the Internet:

Online validators

  • Accessibility: Bobby http://webxact.watchfire.com/  (checks for certain features that make a site more accessible but does not check HTML syntax. See HTML Validation Service for this.)
  • Style sheets: CSS Validation Service http://jigsaw.w3.org/css-validator/
  • HTML: HTML Validation Service http://validator.w3.org/  (checks the HTML code to ensure a well-structured site. It should be used before to an accessibility check to catch any HTML errors. If you are having difficulties using an accessibility validator it may be because of HTML errors on your site.)

Accessibility Checklist

See W3C - Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10/full-checklist.html  for the Accessibility & Priority Checklist.

Accessibility Resources

The following is a list of resources on research, programs, information, data and useful tools for all users in many of the URLs below.

Screen readers

Usability

Format

  • Web pages should be usable with 640 by 480 line screen resolution.
  • All websites should be functional and viewable by Internet Explorer 5.0 and higher versions, as well as Netscape 4.73 and higher versions, PC and MAC.
  • Provide information in a downward compatible format and to the technology level common to most Internet users. Departments should periodically review their presentation of material in light of the tools used by the majority of their users.
  • Provide meaning paths and the ability to exit or quit at any time. Remember not every user is at the same skill level so make sure there are several exits or quits.

Graphics & colours

  • Graphics should be readable, meaningful and limited in size. Size should be kept to a minimum to reduce download time (20 seconds per page is the maximum reasonable download time).
  • Always remember less is more. Do not use too many colour components because they may compete for the viewer's attention and cause confusion. At no time should a background colour be used. Studies show the most easily read pages use a white background with black text.

PDF

  • HTML should be the primary format for all web documents. When PDF is used, wherever possible, the identical information should be available in another accessible format such as HTML or Word. There are instances, however, when PDF is the only viable option. When this occurs, consult with Manweb and CSM.
  • Some PDF files are accessible, but the access can be limited or unpredictable. Adobe 5.0 provides accessibility features, but they must be deliberately enabled by the document author. It is generally best to convert PDF files (from their original source) to HTML. There is a converter available on the government of Manitoba utilities page - www.gov.mb.ca/example/utilities.html .

Access Keys (keyboard commands)

Most browsers support jumping to specific links by typing keys defined on the website. On Microsoft Windows, you can press Alt + an access key; on Apple, you can press Control + an access key.

The government of Manitoba has adopted the following access keys:

  • access key 1 - header navigation
  • access key 2 - side bar navigation
  • access key 3 - main body navigation
  • access key 4 - footer navigation

Some access keys are already in use by accessibility software, please contact CSM and ManWeb prior to inserting additional access keys.

 

 
Manitoba Visual Identity