WEST VIRGINIA WEB PAGE GUIDELINES

Getting the most of this document:

Through the summer of 2001, members of the Statewide Internet Group, which includes state webmasters, technical administrators, and policy-makers, created the following guidelines and recommendations to reflect changes in legislation, technology, and style which affect state websites and its users.

The committee, which is a subcommittee reporting to the Information Technology Council (ITC), also voted to have state web sites meet Level One standards of Section 508; West Virginia's state web sites will be accessible by January 1, 2002.

Like any publication, the greatest benefit can be gained from this document by reading it in its entirety. The most important thing, of course, is that these guidelines be treated as suggestions to help, not inhibit, the creativity necessary to effectively communicate your message.

(This document can also be found on the WV Office of Technology¹ website)

CONTENT

Agency-Controlled Content

Statement of Purpose
Use of the WWW should be incorporated into the agency's strategic planning process and should support an identifiable business purpose. The content of all pages on agency WWW servers should be related to the function and mission of the organization. Each organization's Web site should include, or link to, a specific statement describing the purpose and content of the WWW site.

Approvals
Each organization within an agency should designate responsible parties for reviewing and approving WWW content. Given the dynamic nature of the Web, it may be appropriate for an agency to establish a policy that delegates the release of WWW content to individual Webmasters. When data is made available to the public through a web site, release procedures and/or authorizations comparable to those for any external publication should be considered.

Responsible Party/Contact
Every Web site should list an e-mail address, or include a form, which can be used to contact a responsible party regarding the content of the page(s). The e-mail address should not necessarily be that of an agency employee and may be that of the Webmaster for the WWW server on which the document resides. Where personal service is not important, it is acceptable to establish generic e-mail addresses for agency public points of contact instead of using personal addresses (e.g., library@agency.gov rather than john_doe@agency.gov). However, many people prefer responding to real people rather than impersonal mail locations.

Accuracy/Timeliness
Effective customer service and the credibility of an agency's public access Internet sites depend on providing up-to-date information. Information, particularly time-sensitive information, such as grant announcements and press releases, must be posted as promptly as possible. Out-of-date information must be removed or updated promptly. It is recommended that agencies provide dates within Web sites so users are aware of the currency. The party responsible for the document or collection should determine whether to retain an electronic version corresponding to the outdated version. Because accuracy of all on-line information is an important goal, care should be exercised in the following areas:

• Information on which users may base important decisions (e.g., grant application deadlines, policy guidance, etc.).
• Inaccuracies, which may compromise meaning (e.g., missing text, misaligned table cells, etc.).
• Cosmetic flaws (e.g., titles not italicized, missing dashes, etc.). Before releasing an HTML document to a public server, the syntax and spelling should be checked and all links verified. The formatting adjustments that are required to present information in HTML are not considered to compromise accuracy if they faithfully convey the information in a document. Further, user controlled browser preferences may also alter the document format. If the document format is important, consider delivering the content in Adobe's Portable Document Format (PDF) or in Postscript files.

Content Summary

• The content of a Web site should be directly related to the organization's function and mission.
• WWW content should be reviewed before release.
• Each Web site should identify and display a responsible party and provide contact information.
• Information within a document should be accurate and current. Spelling and grammar should be correct.· Document content or data should comply with security and privacy policies.
• External links should be denoted with a disclaimer, stating that the agency is not responsible for the content.

Style/Markup

• Every site page should have a unique title. This helps visitors save web pages based on content.
• The title and top level heading for a Web site should be the same.
• Include appropriate header comments, such as HTML version.
• Every title/heading should reference the theme of the Web site.
• Paragraphs should be clear and concise.
• Horizontal rules can be used to separate dissimilar paragraphs.
• Text highlighting (italics, bold, underline) should be used sparingly.
• Footers should be separated from the body by a horizontal rule.
• Footers should provide logical navigational aids, consistently throughout the site
• The Web site footer should include the 'contact link' for the responsible party, the last date the document was updated, and text navigation links, if possible.
• Agency logos should be used where appropriate.
• Large documents should be divided logically.
• Every page should be tested with multiple viewers (e.g. Lynx, Mosaic, Netscape, Microsoft Internet Explorer).
• Write to the current HTML standard.
• Proprietary markup should be avoided.
• Consider "file inclusion" for standard page elements, such as footers, headers, images, etc. to ensure easier maintenance and consistency of pages.

Images and Backgrounds

• Images should be in soft/muted tones that are "easy on the eyes"
• Background images should be small enough to load quickly
• Avoid black background with white text
• Limit graphics on pages that will be printed or offer an alternative page for printing
• Try to always use a background color even if you are using a background image
• WV Standard Colors & Images (For Web and Print)
• MIME types should be restricted to GIF, TIFF, JPEG, MPEG, AU, and SND.
• Thumbnail images should be used to link to large images.
• Images should not be wider than 472 pixels.
• Avoid long, thin images such as specialty horizontal rules.
• The width and height of each image should be specified in the HTML tag.
• Every graphic should have an associated and meaningful (ALT) text.
• Image maps should have alternate text-based selection mechanisms.

Organizational or Agency Web Sites
Each organization within an agency, that has both the authority and responsibility to serve WWW pages, should maintain a Web site describing the organization, its structure and its activities. The organizational Web site should include appropriate links up the organizational hierarchy. It should also include appropriate links to subordinate Web sites (e.g., other organizations, programs, projects, etc.). Organizational entities that maintain Web sites should retain ownership of and responsibility for their information content.

Agency Sponsored Web Sites
Information on WWW servers operated under agency funding, but outside of direct agency control, should be related to the purpose of the award under which the project is funded. The sponsoring agency should be identified prominently and a link should be provided to the sponsoring office or program's Web site. In the case of organizational servers where agency-sponsored information co-resides with other information, agency-sponsored information should be clearly identified and distinguished from non-agency-funded information.

Program and Project Web Sites
Program and project Web sites allow organizations to highlight specific efforts or functions within an organization. These collections are optional, but highly recommended. If appropriate, they should link to the sponsoring organization's Web site. Links from appropriate topical forums and a program/project index should be maintained on the main agency WWW server to guide users to these special interest pages..

Individual Employee Web Sites (Bios)
Any individual website hosted on a state server is subject to these guidelines. Individual employee Web sites can be very useful for those who deal directly with a specific user community, the public, or hold high profile positions. Employee Web sites should not be viewed as 'personal' Web sites. Content and external linkages should relate to the employee's role as they support the agency's mission.

The following is one possible approach to establishing agency policy:
Individual employee Web sites are permitted if they relate to and support the functions the individual performs at this agency. All information and external links on an individual Web site should support this purpose. A link to the standard disclaimer must be included near the top of the page. Individuals are responsible for making sure the content of their Web sites and related documents are appropriate and approved by organizational management. An individual Web site should not be considered as an "electronic office" or "electronic desktop". Information that might be harmlessly posted on an office wall or bulletin board is not necessarily appropriate to the purpose of an individual employee Web site.

Links to External Content or Sites
The decision to include a link to an external source should be consistent with sound public policy, in support of the agency's mission, and based on the WWW site's "Statement ofPurpose"

NAVIGATION/ORGANIZATION

Presenting a Unified Picture - An important goal for each agency's collective World Wide Web services is to offer each user full access to the entire expanse of the distributed collection, regardless of the point at which the user enters the system. Reaching the goal of providing the convenience of "one-stop shopping" in a widely distributed system may require that each server sponsored by the agency, in addition to serving its own particular constituency, provide links to other organizational servers. In some cases it is useful for 'virtual servers' or servers which knit together disparate resources, to make a strong attempt to appear integrated, through common styles, buttons, environments, tools for the user, etc.

Agency websites should be designed to:

• Include links to each organization and agency program.
• Accommodate cross-links among organizations, programs, projects, and individuals.
• Provide a comprehensive catalog of the agency's publications and products.
• Host links to agency-sponsored Internet sites and related external resources.
• Sponsor topical forums on important agency initiatives through online discussion groups and provide collections of documents or resources.
• Help users identify agency resources and services available to them by subject, role, or geographical location.
• Provide a key-word searching capability on large sites.
• Organization and agency-sponsored WWW materials should be coordinated with the main agency site for consistency and navigational ease.
• Be compatible with version 4.0 browsers as a minimum - Recommendation based on an average provided by http://state.wv.us web statistics
• Avoid (at all times if possible) browser specific code.
• Site Map - recommended because it allows people to find information they might not for whatever reason be able to locate via provided links or a search capability.
• Provide a Search box - recommended, but if unavailable, please provide a Site Map.
• Site should maintain a consistent look and feel.

Navigation/Organization

• Each agency page within a Web site should have a link to the agency's default/index page, and the agency's default/index page should have a link to the State's default/index page.
• Staff should be assigned to check periodically to avoid 'dead links'· When the Web site is moved to a new location, leave for visitors a forwarding URL or utilize a redirect to point to the new site.
• Use graphical references, such as color, icons, wallpaper, consistency of fonts, etc., to give Web visitors a sense of location or local environment.
• Provide search capabilities for large or complex WWW sites.
• Page design: plan for 800x600 as a standard screen resolution.
• Fonts: use only cross-browser, cross-platform compatible fonts.
• Editorial style: each agency has its own identity and should have its own style.
• Shockwave and Flash should be avoided due to accessibility issues - if used, layout and/or text alternatives must be provided.
• Site design structure needs to allow for entry from any page. Visitors may arrive at any page via search engines - don't expect users to arrive only through default or top-level pages.
• Keep navigational choices simple. Categorize or group site links to help your visitor navigate through the site.
• Don't use the organization chart to organize site - use the top 10 services provided by your agency. Determine the list of tasks a user might do on your site
• Use current stats on web site access, most visited pages, and non-working pages.
• An "About the agency" link that's prominent and informative.
• FAQ, site map, and/or site search are all useful.
• Don't make user go more than 5 clicks deep to find something.
• Language denoting an official West Virginia state agency web site

Page Design

• Forms: Make sure forms are accessible. Strive to have all forms "submittable" online. This increases ease of use of filling out applications for people with disabilities as well as making it much more convenient for general users.
• Meta Tags should be used to assist in the site's searchability. Use page headings to let your visitor know where they are.
• Name your graphics! - 'alt' tags are very important.
• Use universal fonts if not using CSS.
• Screen Size: Make sure it is not too big - so much so that the user needs to scroll a lot - for a minimum of 640 x 480 pixel resolution. (Right now the average screen resolution is 800 x 600 pixels, so we recommend designing for 800 x 600, but checking it in 640 x 480 to determine if it is acceptable.) One way to avoid any such problem is to create a "scalable" design that expands and contracts with screen size.
• Page lengths - We would avoid setting limitations on page lengths unless the download time exceed the 7 second download time rule. (Webmaster discretion)
• Pages should be compliant with HTML 4.0.
• WWW pages should be usable by all major clients to ensure equitable access to the information.· Browser-specific HTML should be avoided. For browser compatibility, pages should be designed for a minimum of browser versions of 4.0 and up and a resolution of 600 by 750 max on web pages.

Web Site Links
Documents should be designed to minimize users' reliance on the navigational aids in WWW clients (e.g., back and forward buttons, history lists). The browser back button, particularly, tends to retrace a path through every page the user has visited rather than logically backing out of a website. Therefore, it is recommended that each page have a navigational area, including a link back to a main page, to help users navigate throughout the site easily. The Web site for each document or collection should include an explicit link back to the sponsoring organization or program. Each organization's Web site should include an explicit link back to the agency homepage. It is recommended that each agency's Web site contain a link to the state Web site at http://www.state.wv.us. Also the webmaster for http://www.state.wv.us should be contacted to provide a link from the state Web site to each agency's Web site. This will make it easier for web browsers to find state government information for West Virginia.

Restricted Access
Sensitive, confidential, or privacy information should not be placed in publicly available directories. In some instances, there may be a need to place documents that are not officially public (i.e., discussion drafts, prototypes, content which is in development, etc.) in a non-private directory for access by a geographically distributed workgroup, test group, or team. The sponsoring organization is responsible for determining whether to have the Webmaster password-protect the materials to prevent access by unauthorized individuals. Documents and collections that are not public (i.e., not yet published, not fully marked up or tested, internal working group notes, etc.) should not be linked to publicly accessible documents or placed in publicly available directories without information on the restrictions and an explicit notice such as: "Coming soon expanded information about..." or "Internal working documents..." Pre-release information that is available on the open Internet should be restricted by domain, IP address, or password. Postings to agency WWW sites are official agency disclosures and must be consistent with other agency Information disclosures of the same or similar information. For example, if requests for draft agency documents are routinely denied from Freedom of Information Act requesters as pre-decisional to protect the integrity of the agency's deliberative process, then it would be more appropriate to post draft documents on the agency intranet server rather than on the public WWW site. It may be necessary to coordinate with the Webmaster to explicitly exclude restricted access documents from site-wide full-text indexes.

STYLE/MARKUP

Titles
Every page should have a title, which displays in the title bar of the browser, and is used by visitors when saving or "bookmarking" pages. The title should be as short as possible but fully informative and specific (e.g., "FY 1996 Agency Budget" is preferable to "Budget").

Headers
Every Web site should have a top-level header near the top of the first screen which clearly identifies the theme of the page. A header should be used for continuation pages. Like the title, the header should be as short as possible but fully informative and specific. By convention, the top-level header and the title for each page should be the same. Lower-level headers may be used if appropriate to the document. Header markup should not be used to emphasize entire paragraphs.

Multiple page sections should reference the section's theme in the header of each continuation page. This will help identify the document to users who may arrive at the page without knowing its context, (e.g., as the result of a full-text search) and will make the saved pages more identifiable.

Body
Paragraphs within the body of a document should be clear and concise. Where the audience has a limited knowledge of the subject being addressed, it is often desirable to hyperlink explanatory information. Hyperlinks to a glossary, footnotes, and external documents provide additional information to less informed readers. Other effective uses of hyperlinks include graphics, tables, surveys, and indexes.

Care should be taken in separating and emphasizing content within a page. Horizontal rules can often be used effectively to separate themes within a page. However, the overuse of italics, all capital letters, and bold text can make web pages difficult to read.

Standard Footer
At a minimum, most Web sites have footers which are separated from the body (sometimes by a horizontal rule) and contain the following information:

• The last date the document was updated.
• Copyright information
• Privacy and Usage Information
• An e-mail address of a responsible party for the Web site.
• Navigational aids such as a mapped bar or buttons

File Formats
The choice of file formats used should be based on the following considerations: (1) the intended use of the files by the target audience, (2) the accessibility of the format to the target audience, and (3) the level of effort required to convert the material to the format.

In the interest of making information readily available to as wide an audience as possible, WWW servers should avoid making information available only in proprietary file formats (e.g., WordPerfect, Microsoft Word, Microsoft PowerPoint, SAS, Adobe Acrobat Portable Document Format, etc.), except in cases where the target audience commonly has access to such formats. Links to files in proprietary or unusual formats should be explicitly noted. Material intended to be 'viewed', read, or browsed online should be prepared in HTML format (for text and tables) and GIF (for graphics). JPEG format may be used instead of GIF for photographic material where there is a need to preserve a large number of colors.

Portable document formats, such as Adobe Acrobat, should not be used as the primary format unless converting the material to HTML is not feasible. Although it is easier in many instances to create PDF than HTML, there are drawbacks: the contents of PDF files are not included in site-wide full-text search indexes, PDF viewers are not embedded in most WWW browsers, and PDF viewers require more powerful hardware for on-line viewing than a WWW browser alone.

Material intended to be downloaded for off-line print or display should be prepared in one of the following formats, which are listed in descending order of preference:

1. HTML and GIF or JPEG -- Same as materials for on-line viewing.

2. Adobe Acrobat (.PDF), etc. -- Include link to downloadable free viewer.

3. Rich Text Format (.RTF) -- RTF is easily created from most word processors and is more widely usable than native word processor formats such as Microsoft Word or WordPerfect. However, its reproduction of fonts and page layout can vary depending on the user's font set.

4. Proprietary formats (e.g., WordPerfect, Microsoft Word, Excel, PowerPoint, etc.) should only be used if: (a) conversion to one of the above formats is not feasible; (b) the intended audience is known to have ready access to software which can handle the proprietary format; or © the intended use is data analysis or manipulation (see below). If use of a proprietary format is unavoidable, use an earlier, more widely available version if possible.

Material in formats other than HTML should be linked to an HTML page which describes the material in such a way that users of site-wide full-text search facilities can find material of interest.

PDF's

Requirements for the Use of PDF as Sole Online Source of State Information. 1. The reader is available free for all platforms2. It can be used both online and offline (standalone) 3. PDF files can be read online, or downloaded and saved to the user's computer. 4. PDF technology is constantly advancing, has a good history of development, and is used by more companies than other technologiesNext, when should a PDF be used as the ONLY online source of the information or material?1. When State Law requires that the material be available in an un-editable format 2. When the material must look like the paper document 3. When the document is a form that must be filled out a certain way For images used in PDFs - convert to .jpg to avoid pixilationThere may be certain situations when an agency wants to post a file in a specific software format. For instance, if an agency wants to make available a spreadsheet file with formulas embedded, so that the user can download the file and make calculations offline, the agency will want to post that file. If possible, it should save the file in a format one generation back from the latest version. In the above example, aQuattro Pro 8 file should be saved as version 7, so that it can be opened by the latest versions of Quattro, Excel and Lotus. If the file makes use of features only available in the latest version, then availability of the file takes precedence over maximum accessibility.

Text Format
In the interest of maximum accessibility to state government information, documents posted to West Virginia state government web sites should be in plain text or HTML-formatted text (including HTML-formatted forms) whenever possible. When exceptions occur, the favored text document format is Adobe Acrobat Portable Document Format (PDF). (see PDF)

EXCEPTIONS:

1. When State Law requires that the material be available in an un-editable format

2. When the material must be a facsimile of the paper document

3. When the document is a form that must be filled out a certain way

Large or Complex Documents
Large documents (greater than five pages) should be organized into sections or chapters and linked together. If the material is to be read consecutively, then a table of contents and division by chapter may be most appropriate. If the material is to be accessed randomly, then a division by section with key word links to appropriate sections may be best. To assist users in navigating sectioned documents, each page should include a navigation menu that allows the user to logically progress through the document. Links to files larger than 100 kilobytes should include an explicit note of the file size.

Web Graphics
The appropriate use of images is to help convey information or to create a consistent and recognizable "look and feel" for a collection as well as to convey meaningful information which is not easily conveyed by words. The judicious use of images will help users remember your Web sites and will attract frequent usage by the community. We recommend that a page should in most cases load in less than 7 seconds on a 56kb connection. Pages with graphics larger than 100k, should have a warning for the user that the page has a huge image and may take some time to load.

The following hints will help make pages effective:

• Images should be as small as possible. Use thumbnail images or text to link to pages with large images. Image resolution may often be reduced without compromising the information conveyed.
• Images should be no wider than 472 pixels, in order to display on the typical WWW browser's 500 pixel wide viewing window on a 640 by 480 monitor.
• Reducing the color depth, especially for non-photographic material such as charts and graphs, can often reduce image file size.
• Limit the number of images to less than three per page and keep the total size of the images to less than 15 Kbytes.
• Avoid long, thin images such as specialty horizontal rules. These are not effective for users who do not have image capabilities.
• Specify the width and height of each image within the HTML "image" tag. This will speed up document formatting on many browsers.
• When image maps are used, there should be an alternate method of selection options.
• Provide text transcriptions or descriptions for all audio clips.
• Make link text descriptive but not verbose.
• File formats other than HTML should be used only as alternatives to rather than replacements for HTML.
• Provide alternate mechanisms for on-line forms.
• All pages should be tested using multiple viewers.
• Do not use proprietary procedural format markup.
• For simple images, such as icons performing the function of bullets, use simple ALT attributes (e.g. "*" or "-"). It should be noted that many users find the use of image bullets annoying, since they take up space and time, and add very little to functionality.

Tables
Tables, like images, can be an extremely effective way to present information. However, like images, they can hamper access to information by visually impaired individuals or those with character-only browsers. TABLE markup should be used when it significantly enhances the effectiveness of information presentation. It should be accompanied by an alternative presentation for those whose browsers or disabilities prevent them from using table markup. An appropriate use of "TABLE" markup would be to present a statistical table, accompanied by a version of the same information as formatted "PRE" that is eighty (80) or fewer characters in width.

ADDITIONAL POINTS

Cookies
Cookies are used to track user information across several WWW pages or WWW sessions. WWW site users should be notified of the use of Cookies and the purpose for their use. An example where cookies might be used to track usage is an end user training service. Cookies can be used to track student progress and automatically connect them to the next lesson. There should be a notification to the user that the application utilizes a cookie - for privacy and in case the user has "cookies" turned off in their browser settings. It is recommended that the cookie should die at the end of the browser session and there should be a built-in session time-out.

Cookies Notice - This site uses a technique known as cookies to provide better services to our users. If you object to this use of cookies, you may wish to exit the WWW site at this time.

User Information Collection
Organizations should be careful in collecting information from users. WWW site users should be notified of any user information collection activities and the purpose for its use.

Usage Monitoring
Webmasters should review and analyze the usage reports generated by the server for their documents and collections, and use this information to improve their services and public information access. WWW site users should be notified of usage monitoring and the purpose for its use. Information containing individual identifiers such as e-mail addresses should not be retained for long periods.

Copyright and Multimedia Documents
A copyright is the 'rights' of an author or publisher to the 'copy' (text of an article) that author or publisher produced. This has come to mean the right of intellectual property, whereby authors obtain, for a specific time, certain exclusive rights to their work.

In the United States, copyright protections are exclusively granted under federal law, which derive from Article 1, Section 8, Clause 8 of the U.S. Constitution which provides Congress with the power "to promote science and the useful arts, by securing for a limited times to authors ...the exclusive right to their...writings".

In the United States, and most other countries, a work is copyrighted automatically upon creation. No notice is required nor is registration required with a government agency. Works that do not enjoy copyright privileges are considered to be in the public domain. Common examples of public domain works are:

• Works for which the copyright has expired. Expiration of a copyright depends on a number of criteria and can run from 28 to 100 years.
• Works of the U.S. Government. These works cannot be copyrighted. However, it appears that works, which have been created for the Government by a commercial entity, may have some copyright protection from commercial use.
• Non-copyrightable works such as titles, names, short phrases and slogans. (However, these may be trademarks.)
• Works for which the copyright has been forfeited or abandoned. The most common form of copyright forfeiture is the lack of specific copyright notice on materials published before March 1,1988. (After that date posting of notice was no longer required for a copyright.) Abandonment requires specific language and intent to place copyrighted works in the public domain by the author.

"Fair Use" of a Copyrighted Work.
Copyrighted works can be "fairly used" without fear of copyright infringement for such purposes as criticism, comment, news reporting, teaching, scholarship, or research. Whether the use of a work is fair is determined by balancing these factors:

• The purpose and character of the use.
• The nature of the copyrighted work.
• The amount and substantiality of the portion used in relation to the work as a whole.
• The effect of the use on the potential market for, or value of, the copyrighted work.

Copyright issue: The Attorney General's office needs to develop standard language for web sites covering images, data, design and content Contracts for web design need to include copyright ownership language, giving the state the right to alter as they wish, and not permitting private contractors to place copyright notice on state web pages. Suggestion: Standard copyright notice on web site pages with a link to a more explanatory statement on the state's home web site. Same for privacy statements and standard disclaimers.

• Extreme caution should be exercised in using digital material downloaded from the Internet because there is a mix of works protected by copyright and works in the public domain on the Internet. Access to these works on the Internet does not automatically mean that these works can be reproduced and reused without permission and/or royalty payment.
• Please note that proper credit should be given for all copyrighted material. When in doubt, credit should be given as if the material was copyrighted.
• In general no more than 10% of copyrighted textual, motion, music, or collections of illustrations or photographs should be included. In the case of independent illustrations or collections, no more than 5 images of an artist or photographer should be included. If there is a possibility that multimedia content (e.g. image, movie) may become part of a commercial product in the future or will become widely disseminated, then permissions should be sought before publication of the product.
• If any alterations are made to copyrighted material, then care should be taken to explain the specific changes. Copyright Status: The West Virginia State Government retains a nonexclusive, royalty-free license to publish or reproduce these documents, or allow others to do so, for West Virginia State Government purposes. These documents may be freely distributed and used for non-commercial, scientific and educational purposes. Commercial use of the documents available from this server may be protected under the U.S. and Foreign Copyright Laws. Individual documents on this server may have different copyright conditions, and that will be noted in those documents.

Disclaimers
Agency servers and most agency multimedia documents should carry a Disclaimer of Endorsement and a Disclaimer of Liability. These disclaimers address references to commercial products and services, as well as merchantability and fitness for purpose.

Disclaimer of Endorsement: Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the West Virginia State Government. The views and opinions of authors expressed herein do not necessarily state or reflect those of the West Virginia State Government, and shall not be used for advertising or product endorsement purposes.

Disclaimer of Liability: With respect to documents available from this server, neither the West Virginia State Government nor any of its employees, makes any warranty, express or implied, including the warranties of merchantability and fitness for a particular purpose; nor assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed; nor represents that its use would not infringe privately owned rights.

Notice: Information from this server resides on a computer system funded by a West Virginia Government agency. The use of this system may be monitored for computer security purposes.

Electronic Public Disclosure
Postings to agency WWW sites are official agency disclosures and must be consistent with other agency disclosures of the same or similar information. To facilitate release of information, agencies may want to develop a WWW statement of responsibility that reminds webmaster4s of release criteria and then rely on the professionalism of content developers. An example of this statement of responsibility can be found at [http://www.cise.nsf.gov/pub/responsibility.html].

Accessibility Issues
All State web sites should be as accessible as possible within the guidelines of the latest HTML standard as published by the W3C. Exceptions should use good judgment, such as: Online educational activities using non-accessible technology, such as Shockwave; Paper documents that require a PDF; Audio or video streams for which alternate text is not available or not meaningful. It is important that all information that the state provides on its web sites, which are necessary to state residents, be as accessible as possible. This means easily accessible for 'abled' people as well as disabled. Top level and informational pages should load in a reasonable time. They should also not require special tools or the absolute latest browser versions, or a particular brand of browser. Special use pages (such as those supporting media) may require longer download times, tools or the newest browsers, but visitors should be warned, and if at all possible, the information should be available by alternate means. Any special tools required to access a page should have links to where the tools can be obtained, and easy instructions should be provided for their installation. The use of accessibility guideline tools, like Bobby, are encouraged; however, state web sites do not have to receive the Bobby seal of approval.

---

The following information was extracted from http://www.w3.org/TR/WCAG10-TECHS/ . [Please visit that site for clarification and updates in Accessibility Guidelines. After reviewing, the Internet Users Group committee voted to follow Level One guidelines to make all state websites accessible.

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee, W3C Director and inventor of the World Wide Web

²

Techniques for Web Content Accessibility Guidelines 1.0

W3C Note 6 November 2000

This version:

http://www.w3.org/TR/2000/NOTE-WCAG10-TECHS-20001106/³

(plain text⁴, PostScript⁵, PDF⁶, gzip tar file of HTML⁷, zip archive of HTML⁸)

Latest version:

http://www.w3.org/TR/WCAG10-TECHS/⁹

Previous version:

http://www.w3.org/TR/2000/NOTE-WCAG10-TECHS-20000920/¹⁰

Editors:

Wendy Chisholm, W3C²;
Gregg Vanderheiden, Trace R & D Center¹¹, University of Wisconsin -- Madison;
Ian Jacobs, W3C²

Copyright¹² ©1999 - 2000 W3C^2® (MIT¹³, INRIA¹⁴, Keio¹⁵), All Rights Reserved. W3C liability¹⁶, trademark¹⁷, document use¹⁸ and software licensing¹⁹ rules apply.

Abstract
This document is the gateway to a series of related documents that provide techniques for satisfying the requirements defined in "Web Content Accessibility Guidelines 1.0" [WCAG10]. This series includes:
1. "Techniques for Web Content Accessibility Guidelines 1.0", the current document, which is the gateway to the other documents.
2. "Core Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CORE-TECHNIQUES]), which discusses the accessibility themes and general techniques that apply across technologies (e.g., validation, testing, etc.).
3. "HTML Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-HTML-TECHNIQUES]), which provides examples and strategies for authoring accessible Hypertext Markup Language (HTML) content.
4. "CSS Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CSS-TECHNIQUES]), which provides examples and strategies to help authors write Cascading Style Sheets (CSS) as part of accessible content design.

Status of this document
This version has been published to correct some broken links in the previous version. The 6 November 2000 version of this document is a Note in a series of Notes produced and endorsed by the Web Content Accessibility Guidelines Working Group. This Note has not been reviewed or endorsed by W3C Members. The series of documents supersedes the 5 May 1999 W3C Note "Techniques for Web Content Accessibility Guidelines 1.0". That single document has been divided into technology-specific documents that may evolve independently. Smaller technology-specific documents also allow authors to focus on a particular technology. While the "Web Content Accessibility Guidelines 1.0" Recommendation [WCAG10] is a stable document, this series of companion documents is expected to evolve as technologies change and content developers discover more effective techniques for designing accessible Web sites and pages. In the near future, the Working Group intends to incorporate techniques for the Synchronized Multimedia Integration Language (SMIL) [SMIL] described in "Accessibility Features of SMIL" ([SMIL-ACCESS]) and techniques for Scalable Vector Graphics (SVG) [SVG] described in "Accessibility Features of SVG" ([SVG-ACCESS]). The Working Group also intends to incorporate techniques for non-W3C technologies such as ECMAScript, PDF and Flash.

The history of changes to the series of documents as well as the list of open and closed issues are available. Readers are encouraged to comment on the document and propose resolutions to current issues. Please send detailed comments on this document to the Working Group at w3c-wai-gl@w3.org; public archives are available.

The English version of this document is the only normative version. However, for translations in other languages see "http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS".
The list of known errors in this document is available at "Errata in Web Content Accessibility Guidelines." Please report errors in this document to wai-wcag-editor@w3.org.

The Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) makes available a variety of resources on Web accessibility. WAI Accessibility Guidelines are produced as part of the WAI Technical Activity. The goals of the WCAG WG are described in the charter.
A list of current W3C Recommendations and other technical documents is available.

Table of Contents
· Abstract
· Status of this document
· 1 How this Document is Organized
o 1.1 Priorities
· 2 Techniques for Web Content Accessibility Guidelines
o 1. Provide equivalent alternatives to auditory and visual content.
o 2. Don't rely on color alone.
o 3. Use markup and style sheets and do so properly.
o 4. Clarify natural language usage
o 5. Create tables that transform gracefully.
o 6. Ensure that pages featuring new technologies transform gracefully.
o 7. Ensure user control of time-sensitive content changes.
o 8. Ensure direct accessibility of embedded user interfaces.
o 9. Design for device-independence.
o 10. Use interim solutions.
o 11. Use W3C technologies and guidelines.
o 12. Provide context and orientation information.
o 13. Provide clear navigation mechanisms.
o 14. Ensure that documents are clear and simple.
· 3 Glossary
· 4 References
· 5 Resources
o 5.1 Other Guidelines
o 5.2 User agents and other tools
· 6 Acknowledgments

1 How this Document is Organized
Section 2 of this document reproduces the guidelines and checkpoints of the "Web Content Accessibility Guidelines 1.0" [WCAG10]. Each guideline includes:
· The guideline number.
· The statement of the guideline.
· A list of checkpoint definitions. Checkpoints are ordered according to their priority, e.g., Priority 1 before Priority 2.
Each checkpoint definition includes:
· The checkpoint number.
· The statement of the checkpoint.
· The priority of the checkpoint.
· A link back to the definition of the checkpoint in "Web Content Accessibility Guidelines 1.0" [WCAG10]. Definitions may also include informative notes, examples, cross references, and commentary to help readers understand the scope of the checkpoint.
Each checkpoint is followed by one or more links to techniques in the following documents:
· "Core Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CORE-TECHNIQUES]), which discusses the accessibility themes and general techniques that apply across technologies.
· "HTML Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-HTML-TECHNIQUES]), which provides examples and strategies for authoring accessible Hypertext Markup Language (HTML) content.
· "CSS Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CSS-TECHNIQUES]), which provides examples and strategies to help authors write Cascading Style Sheets (CSS) as part of accessible content design.

1.1 Priorities
Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.
[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 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]
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.
Some checkpoints specify a priority level that may change under certain (indicated) conditions.

2 Techniques for Web Content Accessibility Guidelines

Guideline 1. Provide equivalent alternatives to auditory and visual content.
Checkpoints:
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: 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), stand-alone audio files, audio tracks of video, and video. [Priority 1] (Checkpoint 1.1)
· Core Techniques: Text equivalents
· HTML Techniques: Images used as bullets
· HTML Techniques: Text for images used as links
· HTML Techniques: Short text equivalents for images ("alt-text")
· HTML Techniques: Long descriptions of images
· HTML Techniques: Text equivalents for client-side image maps
· HTML Techniques: Text and non-text equivalents for applets and programmatic objects
· HTML Techniques: Text equivalents for multimedia
· HTML Techniques: Describing frame relationships
· HTML Techniques: Writing for browsers that do not support FRAME
· HTML Techniques: Graphical buttons
· HTML Techniques: Alternative presentation of scripts
1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1] (Checkpoint 1.2)
Refer also to checkpoint 1.5 and checkpoint 9.1.
· Core Techniques: Text equivalents
· HTML Techniques: Server-side image maps
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1] (Checkpoint 1.3)
· Core Techniques: Visual information and motion
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1] (Checkpoint 1.4)
· Core Techniques: Audio information
· HTML Techniques: Directly accessible applets
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3] (Checkpoint 1.5)
Refer also to checkpoint 1.2 and checkpoint 9.1.
· Core Techniques: Text equivalents
· HTML Techniques: Redundant text links for client-side image maps

Guideline 2. Don't rely on color alone.
Checkpoints:
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1] (Checkpoint 2.1)
· Core Techniques: Structure vs. Presentation
· CSS Techniques: Ensuring information is not in color alone
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]. (Checkpoint 2.2)
· HTML Techniques: Color in images
· CSS Techniques: Color Contrast

Guideline 3. Use markup and style sheets and do so properly.
Checkpoints:
3.1 When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2] (Checkpoint 3.1)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Markup and style sheets rather than images: The example of math
· CSS Techniques: Generated content
3.2 Create documents that validate to published formal grammars. [Priority 2] (Checkpoint 3.2)
· HTML Techniques: The !DOCTYPE statement
3.3 Use style sheets to control layout and presentation. [Priority 2] (Checkpoint 3.3)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Emphasis
· CSS Techniques: Text instead of images
· CSS Techniques: Text formatting and position
· CSS Techniques: Layout, positioning, layering, and alignment
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2] (Checkpoint 3.4)
· HTML Techniques: Directly accessible applets
· HTML Techniques: Sizing frames with relative units
· CSS Techniques: Units of measure
3.5 Use header elements to convey document structure and use them according to specification. [Priority 2] (Checkpoint 3.5)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Section headings
3.6 Mark up lists and list items properly. [Priority 2] (Checkpoint 3.6)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Lists
· CSS Techniques: Providing contextual clues in HTML lists
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2] (Checkpoint 3.7)
· HTML Techniques: Quotations

Guideline 4. Clarify natural language usage
Checkpoints:
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1] (Checkpoint 4.1)
· HTML Techniques: Identifying changes in language
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3] (Checkpoint 4.2)
· HTML Techniques: Acronyms and abbreviations
4.3 Identify the primary natural language of a document. [Priority 3] (Checkpoint 4.3)
· HTML Techniques: Identifying the primary language

Guideline 5. Create tables that transform gracefully.
Checkpoints:
5.1 For data tables, identify row and column headers. [Priority 1] (Checkpoint 5.1)
· HTML Techniques: Identifying rows and column information
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1] (Checkpoint 5.2)
· HTML Techniques: Identifying rows and column information
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2] (Checkpoint 5.3)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Tables for layout
· CSS Techniques: Layout, positioning, layering, and alignment
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2] (Checkpoint 5.4)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Tables for layout
5.5 Provide summaries for tables. [Priority 3] (Checkpoint 5.5)
· HTML Techniques: Providing summary information
5.6 Provide abbreviations for header labels. [Priority 3] (Checkpoint 5.6)
· HTML Techniques: Providing summary information
Refer also to checkpoint 10.3.

Guideline 6. Ensure that pages featuring new technologies transform gracefully.
Checkpoints:
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1] (Checkpoint 6.1)
· CSS Techniques: Generated content
· CSS Techniques: Rules and borders
· CSS Techniques: Using style sheet positioning and markup to transform gracefully
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1] (Checkpoint 6.2)
· HTML Techniques: Text and non-text equivalents for applets and programmatic objects
· HTML Techniques: Frame sources
· HTML Techniques: Alternative presentation of scripts
6.3 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. [Priority 1] (Checkpoint 6.3)
· HTML Techniques: Text and non-text equivalents for applets and programmatic objects
· HTML Techniques: Directly accessible scripts
6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2] (Checkpoint 6.4)
· Core Techniques: Structure vs. Presentation
· HTML Techniques: Directly accessible applets
· HTML Techniques: Directly accessible scripts
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2] (Checkpoint 6.5)
· Core Techniques: Alternative pages
· Core Techniques: Audio information
· HTML Techniques: The LINK element and alternative documents
· HTML Techniques: Directly accessible applets
· HTML Techniques: Writing for browsers that do not support FRAME
· HTML Techniques: Graceful transformation of scripts
Refer also to checkpoint 11.4.

Guideline 7. Ensure user control of time-sensitive content changes.
Checkpoints:
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1] (Checkpoint 7.1)
· Core Techniques: Screen flicker
· Core Techniques: Visual information and motion
· HTML Techniques: Directly accessible applets
· HTML Techniques: Scripts that cause flickering
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2] (Checkpoint 7.2)
· HTML Techniques: Directly accessible applets
· HTML Techniques: Scripts that cause movement and blinking
· CSS Techniques: Text style effects
7.3 Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2] (Checkpoint 7.3)
· Core Techniques: Visual information and motion
· HTML Techniques: Animated images
· HTML Techniques: Directly accessible applets
· HTML Techniques: Scripts that cause movement and blinking
· CSS Techniques: Creating movement with style sheets and scripts
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2] (Checkpoint 7.4)
· Core Techniques: Automatic page refresh
· HTML Techniques: The META element
· HTML Techniques: Directly accessible applets
· HTML Techniques: Page updates and new windows
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. [Priority 2] (Checkpoint 7.5)
· Core Techniques: Automatic page refresh
· HTML Techniques: The META element
· HTML Techniques: Page updates and new windows
Note. The BLINK and MARQUEE elements are not defined in any W3C HTML specification and should not be used. Refer also to guideline 11.

Guideline 8. Ensure direct accessibility of embedded user interfaces.
Checkpoint:
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] (Checkpoint 8.1)
Refer also to guideline 6.
· HTML Techniques: Directly accessible applets
· HTML Techniques: Directly accessible scripts

Guideline 9. Design for device-independence.
Checkpoints:
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1] (Checkpoint 9.1)
Refer also to checkpoint 1.1, checkpoint 1.2, and checkpoint 1.5.
· HTML Techniques: Client-side versus server-side image maps
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2] (Checkpoint 9.2)
Refer to the definition of device independence.
Refer also to guideline 8.
· Core Techniques: Alternative pages
· HTML Techniques: Directly accessible applets
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2] (Checkpoint 9.3)
· Core Techniques: Alternative pages
· HTML Techniques: Directly accessible scripts
9.4 Create a logical tab order through links, form controls, and objects. [Priority 3] (Checkpoint 9.4)
· Core Techniques: Alternative pages
· HTML Techniques: Keyboard access
· HTML Techniques: Keyboard access to forms
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3] (Checkpoint 9.5)
· Core Techniques: Alternative pages
· HTML Techniques: Keyboard access
· HTML Techniques: Keyboard access to forms

Guideline 10. Use interim solutions.
Checkpoints:
10.1 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. [Priority 2] (Checkpoint 10.1)
· HTML Techniques: Anchors and targets
· HTML Techniques: Directly accessible applets
· HTML Techniques: Using FRAME targets
· HTML Techniques: Page updates and new windows
10.2 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. [Priority 2] (Checkpoint 10.2)
· HTML Techniques: Labeling form controls
10.3 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. [Priority 3] (Checkpoint 10.3)
· HTML Techniques: Linearizing tables
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] (Checkpoint 10.4)
· HTML Techniques: Techniques for specific controls
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3] (Checkpoint 10.5)
· HTML Techniques: Grouping and bypassing links

Guideline 11. Use W3C technologies and guidelines.
Checkpoints:
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported. [Priority 2] (Checkpoint 11.1)
· Core Techniques: Technologies Reviewed for Accessibility
11.2 Avoid deprecated features of W3C technologies. [Priority 2] (Checkpoint 11.2)
· HTML Techniques: Index of HTML elements and attributes
· CSS Techniques: User override of styles
· CSS Techniques: Fonts
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3] (Checkpoint 11.3)
Note. Use content negotiation where possible.
· Core Techniques: Content negotiation
· CSS Techniques: Aural Cascading Style Sheets
· CSS Techniques: Access to alternative representations of content
· CSS Techniques: Media types
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1] (Checkpoint 11.4)
· Core Techniques: Alternative pages
Note. Content developers should only resort to alternative pages when other solutions fail because alternative pages are generally updated less often than "primary" pages. An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. Automatically generating alternative pages may lead to more frequent updates, but content developers must still be careful to ensure that generated pages always make sense, and that users are able to navigate a site by following links on primary pages, alternative pages, or both. Before resorting to an alternative page, reconsider the design of the original page; making it accessible is likely to improve it for all users.

Guideline 12. Provide context and orientation information.
Checkpoints:
12.1 Title each frame to facilitate frame identification and navigation. [Priority 1] (Checkpoint 12.1)
· HTML Techniques: Providing a frame title
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2] (Checkpoint 12.2)
· Core Techniques: Text equivalents
· HTML Techniques: Describing frame relationships
12.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2] (Checkpoint 12.3)
· HTML Techniques: Structural grouping
· HTML Techniques: Grouping form controls
12.4 Associate labels explicitly with their controls. [Priority 2] (Checkpoint 12.4)
· HTML Techniques: Labeling form controls

Guideline 13. Provide clear navigation mechanisms.
Checkpoints:
13.1 Clearly identify the target of each link. [Priority 2] (Checkpoint 13.1)
· HTML Techniques: Link text
13.2 Provide metadata to add semantic information to pages and sites. [Priority 2] (Checkpoint 13.2)
· Core Techniques: Navigation
· HTML Techniques: Metadata
· CSS Techniques: Providing contextual clues in HTML lists
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents). [Priority 2] (Checkpoint 13.3)
· Core Techniques: Navigation
13.4 Use navigation mechanisms in a consistent manner. [Priority 2] (Checkpoint 13.4)
· Core Techniques: Navigation
13.5 Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3] (Checkpoint 13.5)
· Core Techniques: Navigation
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3] (Checkpoint 13.6)
· HTML Techniques: Grouping and bypassing links
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences. [Priority 3] (Checkpoint 13.7)
· Core Techniques: Navigation
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3] (Checkpoint 13.8)
· Core Techniques: Comprehension
13.9 Provide information about document collections (i.e., documents comprising multiple pages.). [Priority 3] (Checkpoint 13.9)
For example, in HTML specify document collections with the LINK element and the "rel" and "rev" attributes. Another way to create a collection is by building an archive (e.g., with zip, tar and gzip, stuffit, etc.) of the multiple pages.
· Core Techniques: Bundled documents
· HTML Techniques: The LINK element and navigation tools
13.10 Provide a means to skip over multi-line ASCII art. [Priority 3] (Checkpoint 13.10)
· HTML Techniques: Ascii art

Guideline 14. Ensure that documents are clear and simple.
Checkpoints:
14.1 Use the clearest and simplest language appropriate for a site's content. [Priority 1] (Checkpoint 14.1)
· Core Techniques: Comprehension
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. [Priority 3] (Checkpoint 14.2)
· Core Techniques: Comprehension
14.3 Create a style of presentation that is consistent across pages. [Priority 3] (Checkpoint 14.3)
· Core Techniques: Navigation
· CSS Techniques: Decrease maintenance and increase consistency

3 Glossary

Accessible
Content is accessible when it may be used by someone with a disability.

Applet
A program inserted into a Web page.

Assistive technology
Software or hardware that has been specifically designed to assist people with disabilities in carrying out daily activities. Assistive technology includes wheelchairs, reading machines, devices for grasping, etc. In the area of Web Accessibility, common software-based assistive technologies include screen readers, screen magnifiers, speech synthesizers, and voice input software that operate in conjunction with graphical desktop browsers (among other user agents). Hardware assistive technologies include alternative keyboards and pointing devices.

ASCII art
ASCII art refers to text characters and symbols that are combined to create an image. For example ";-)" is the smiley emoticon. The following is an ASCII figure showing the relationship between flash frequency and photoconvulsive response in patients with eyes open and closed [skip over ASCII figure or consult a description of chart]:

% __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 | * |
90 | * * |
80 | * * |
70 | @ * |
60 | @ * |
50 | * @ * |
40 | @ * |
30 | * @ @ @ * |
20 | |
10 | @ @ @ @ @ |
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Flash frequency (Hertz)

Authoring tool
HTML editors, document conversion tools, tools that generate Web content from databases are all authoring tools. Refer to the "Authoring Tool Accessibility Guidelines 1.0" ([ATAG10]) for information about developing accessible tools.

Backward compatible
Design that continues to work with earlier versions of a language, program, etc.

Braille
Braille uses six raised dots in different patterns to represent letters and numbers to be read by people who are blind with their fingertips. A braille display, commonly referred to as a "dynamic braille display," raises or lowers dot patterns on command from an electronic device, usually a computer. The result is a line of braille that can change from moment to moment. Current dynamic braille displays range in size from one cell (six or eight dots) to an eighty-cell line, most having between twelve and twenty cells per line.

Content developer
Someone who authors Web pages or designs Web sites.

Deprecated
A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements may become obsolete in future versions of HTML. The index of HTML elements and attributes in the Techniques Document indicates which elements and attributes are deprecated in HTML 4.01.

Authors should avoid using deprecated elements and attributes. User agents should continue to support them for reasons of backward compatibility.

Device independent
Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and braille devices.

Please note that "device-independent support" does not mean that user agents must support every input or output device. User agents should offer redundant input and output mechanisms for those devices that are supported. For example, if a user agent supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.

Document Content, Structure, and Presentation
The content of a document refers to what it says to the user through natural language, images, sounds, movies, animations, etc. The structure of a document is how it is organized logically (e.g., by chapter, with an introduction and table of contents, etc.). An element (e.g., P, STRONG, BLOCKQUOTE in HTML) that specifies document structure is called a structural element. The presentation of a document is how the document is rendered (e.g., as print, as a two-dimensional graphical presentation, as an text-only presentation, as synthesized speech, as braille, etc.) An element that specifies document presentation (e.g., B, FONT, CENTER) is called a presentation element.

Consider a document heading, for example. The content of the heading is what the heading says (e.g., "Sailboats"). In HTML, the heading is a structural element marked up with, for example, an H2 element. Finally, the presentation of the heading might be a bold block text in the margin, a centered line of text, a title spoken with a certain voice style (like an aural font), etc.

Dynamic HTML (DHTML)
DHTML is the marketing term applied to a mixture of standards including HTML, style sheets, the Document Object Model [DOM1] and scripting. However, there is no W3C specification that formally defines DHTML. Most guidelines may be applicable to applications using DHTML, however the following guidelines focus on issues related to scripting and style sheets: guideline 1, guideline 3, guideline 6, guideline 7, and guideline 9.

Element
This document uses the term "element" both in the strict SGML sense (an element is a syntactic construct) and more generally to mean a type of content (such as video or sound) or a logical construct (such as a heading or list). The second sense emphasizes that a guideline inspired by HTML could easily apply to another markup language.

Note that some (SGML) elements have content that is rendered (e.g., the P, LI, or TABLE elements in HTML), some are replaced by external content (e.g., IMG), and some affect processing (e.g., STYLE and SCRIPT cause information to be processed by a style sheet or script engine). An element that causes text characters to be part of the document is called a text element.

Equivalent
Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. In the context of this document, the equivalent must fulfill essentially the same function for the person with a disability (at least insofar as is feasible, given the nature of the disability and the state of technology), as the primary content does for the person without any disability. For example, the text "The Full Moon" might convey the same information as an image of a full moon when presented to users. Note that equivalent information focuses on fulfilling the same function. If the image is part of a link and understanding the image is crucial to guessing the link target, an equivalent must also give users an idea of the link target. Providing equivalent information for inaccessible content is one of the primary ways authors can make their documents accessible to people with disabilities.

As part of fulfilling the same function of content an equivalent may involve a description of that content (i.e., what the content looks like or sounds like). For example, in order for users to understand the information conveyed by a complex chart, authors should describe the visual information in the chart.

Since text content can be presented to the user as synthesized speech, braille, and visually-displayed text, these guidelines require text equivalents for graphic and audio information. Text equivalents must be written so that they convey all essential content. Non-text equivalents (e.g., an auditory description of a visual presentation, a video of a person telling a story using sign language as an equivalent for a written story, etc.) also improve accessibility for people who cannot access visual information or written text, including many individuals with blindness, cognitive disabilities, learning disabilities, and deafness.

Equivalent information may be provided in a number of ways, including through attributes (e.g., a text value for the "alt" attribute in HTML and SMIL), as part of element content (e.g., the OBJECT in HTML), as part of the document's prose, or via a linked document (e.g., designated by the "longdesc" attribute in HTML or a description link). Depending on the complexity of the equivalent, it may be necessary to combine techniques (e.g., use "alt" for an abbreviated equivalent, useful to familiar readers, in addition to "longdesc" for a link to more complete information, useful to first-time readers).

A text transcript is a text equivalent of audio information that includes spoken words and non-spoken sounds such as sound effects. A caption is a text transcript for the audio track of a video presentation that is synchronized with the video and audio tracks. Captions are generally rendered visually by being superimposed over the video, which benefits people who are deaf and hard-of-hearing, and anyone who cannot hear the audio (e.g., when in a crowded room). A collated text transcript combines (collates) captions with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the video track). These text equivalents make presentations accessible to people who are deaf-blind and to people who cannot play movies, animations, etc. It also makes the information available to search engines.

One example of a non-text equivalent is an auditory description of the key visual elements of a presentation. The description is either a prerecorded human voice or a synthesized voice (recorded or generated on the fly). The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.

Image
A graphical presentation.

Image map
An image that has been divided into regions with associated actions. Clicking on an active region causes an action to occur.

When a user clicks on an active region of a client-side image map, the user agent calculates in which region the click occurred and follows the link associated with that region. Clicking on an active region of a server-side image map causes the coordinates of the click to be sent to a server, which then performs some action.

Content developers can make client-side image maps accessible by providing device-independent access to the same links associated with the image map's regions. Client-side image maps allow the user agent to provide immediate feedback as to whether or not the user's pointer is over an active region.

Important
Information in a document is important if understanding that information is crucial to understanding the document.

Linearized table
A table rendering process where the contents of the cells become a series of paragraphs (e.g., down the page) one after another. The paragraphs will occur in the same order as the cells are defined in the document source. Cells should make sense when read in order and should include structural elements (that create paragraphs, headings, lists, etc.) so the page makes sense after linearization.

Link text
The rendered text content of a link.

Natural Language
Spoken, written, or signed human languages such as French, Japanese, American Sign Language, and braille. The natural language of content may be indicated with the "lang" attribute in HTML ([HTML4], section 8.1) and the "xml:lang" attribute in XML ([XML], section 2.12).

Navigation Mechanism
A navigation mechanism is any means by which a user can navigate a page or site. Some typical mechanisms include:

• navigation bars
  A navigation bar is a collection of links to the most important parts of a document or site.

• site maps
  A site map provides a global view of the organization of a page or site.

• tables of contents
  A table of contents generally lists (and links to) the most important sections of a document.
  

Personal Digital Assistant (PDA)
A PDA is a small, portable computing device. Most PDAs are used to track personal data such as calendars, contacts, and electronic mail. A PDA is generally a handheld device with a small screen that allows input from various sources.

Screen magnifier
A software program that magnifies a portion of the screen, so that it can be more easily viewed. Screen magnifiers are used primarily by individuals with low vision.

Screen reader
A software program that reads the contents of the screen aloud to a user. Screen readers are used primarily by individuals who are blind. Screen readers can usually only read text that is printed, not painted, to the screen.

Style sheets
A style sheet is a set of statements that specify presentation of a document. Style sheets may have three different origins: they may be written by content providers, created by users, or built into user agents. In CSS ([CSS2]), the interaction of content provider, user, and user agent style sheets is called the cascade.

Presentation markup is markup that achieves a stylistic (rather than structuring) effect such as the B or I elements in HTML. Note that the STRONG and EM elements are not considered presentation markup since they convey information that is independent of a particular font style.

Tabular information
When tables are used to represent logical relationships among data -- text, numbers, images, etc., that information is called "tabular information" and the tables are called "data tables". The relationships expressed by a table may be rendered visually (usually on a two-dimensional grid), aurally (often preceding cells with header information), or in other formats.

Until user agents ...
In most of the checkpoints, content developers are asked to ensure the accessibility of their pages and sites. However, there are accessibility needs that would be more appropriately met by user agents (including assistive technologies). As of the publication of this document, not all user agents or assistive technologies provide the accessibility control users require (e.g., some user agents may not allow users to turn off blinking content, or some screen readers may not handle tables well). Checkpoints that contain the phrase "until user agents ..." require content developers to provide additional support for accessibility until most user agents readily available to their audience include the necessary accessibility features.

Note. The WAI Web site (refer to [WAI-UA-SUPPORT]) provides information about user agent support for accessibility features. Content developers are encouraged to consult this page regularly for updated information.

User agent
Software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software. Refer to the "User Agent Accessibility Guidelines 1.0" ([UAAG10]) for information about developing accessible tools.

4 References
For the latest version of any W3C specification please consult the list of W3C Technical Reports.
[ATAG10]
"Authoring Tool Accessibility Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs, and J. Richards, eds., 3 February 2000. This ATAG 1.0 Recommendation is http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512/. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. This DOM Level 1 Recommendation is http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001. The latest version of DOM Level 1 is available at http://www.w3.org/TR/REC-DOM-Level-1.
[HTML4]
"HTML 4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224/.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. This SMIL 1.0 Recommendation is http://www.w3.org/TR/1998/REC-smil-19980615/. The latest version of SMIL 1.0 is available at http://www.w3.org/TR/REC-smil.
[SMIL-ACCESS]
"Accessibility Features of SMIL", M. Koivunen and I. Jacobs, eds., 21 September 1999. This W3C Note is http://www.w3.org/TR/1999/NOTE-SMIL-access-19990921/.
[SVG]
"Scalable Vector Graphics (SVG) 1.0 Specification", J. Ferraiolo, ed., 2 August 2000. This W3C Candidate Recommendation is http://www.w3.org/TR/2000/CR-SVG-20000802/.
[SVG-ACCESS]
"Accessibility Features of SVG", C. McCathieNevile and M. Koivunen, eds., 7 August 2000. This W3C Note is http://www.w3.org/TR/2000/NOTE-SVG-access-20000807.
[UAAG10]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest version of the User Agent Accessibility Guidelines is available at http://www.w3.org/TR/UAAG10/.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG10-CORE-TECHNIQUES]
"Core Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-CORE-TECHS/.
[WCAG10-CSS-TECHNIQUES]
"CSS Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-CSS-TECHS/.
[WCAG10-HTML-TECHNIQUES]
"HTML Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WCAG10-HTML-TECHS/.
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. This XML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml²⁰.

5 Resources
Note: W3C does not guarantee the stability of any of the following references outside of its control. These references are included for convenience. References to products are not endorsements of those products.

5.1 Other Guidelines
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education.

5.2 User agents and other tools
A list of alternative Web browsers (assistive technologies and other user agents designed for accessibility) is maintained at the WAI Web site.
[WAI-UA-SUPPORT]
User Agent Support for Accessibility

6 Acknowledgments
Web Content Guidelines Working Group Co-Chairs:
Jason White, University of Melbourne
Gregg Vanderheiden, Trace Research and Development
W3C Team contact:
Wendy Chisholm
We wish to thank the following people who have contributed their time and valuable comments to shaping these guidelines:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Chuck Letourneau, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, and Jaap van Lelieveld