Français | Contact Us | Help | Search | Canada Site | |||||
What's New | About Us | Policies | Documents | TBS Site |
Calendar | Links | FAQs | Presentations | Home |
|
CLF for the Internet - Accessibility
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. |
|||||||||||||||||||||||||
|
|
Top of Page |
Important Notices |