WAI-WCAG 1.0 Content Accessibility Standard
The need to implement standards for accessibility of services and content is mentioned in the final resolution of RIF-2008 , and in world practice such standards have existed and have been used for more than 10 years. Following WAI-WCAG (Web Accessibility Initiative Web Content Accessibility Guidelines) guidelines is one of the requirements of the WebHiTech contest . In this article I will try to list the recommendations of the standard.
WCAG 1.0 - a standard that describes the general rules for the design of pages on the Internet was developed in 1999 by the WAI division of W3C. The purpose of the standard is to make Internet content accessible to all users, including users with disabilities (for example, impaired users use special programs to read the contents of sites to work on the Internet). The standard is described in the form of guidelines containing a list of control points, divided into three groups according to priority:
Three priority groups correspond to three levels of compliance with the standard:
This is perhaps the most important requirement. If there are no sounds and videos on the site, then you need to make sure that all pictures have an alt attribute that describes the contents of the picture. If the picture is a chart that cannot be described in the alt attribute, you must use the longdesc attribute, whose value is a link to a separate page that describes the picture. Note that the alt attribute is required for the img tag, so the html validator will indicate its absence . However, the validator will also be satisfied with an empty alt attribute, which may be a violation of the WCAG standard. If there are a significant number of videos or sounds, this recommendation will significantly affect the process of posting new materials.
To follow the rules 3.2 and 3.3, you should regularly check the site pages for compliance with HTML and CSS standards, for example, using the validators provided by w3c.
This rule is perhaps quite difficult to follow. On many sites, Runet parameters are set in pixels or in pt. Required verification in various environments should include testing in sound browsers and people with disabilities.
Recommendation 4.1 should be taken into account, for example, on tourist or language sites containing fragments in other languages.
In order to test point 6.1, we used the lynx text browser, which is included in most Linux distributions (windows versions are also available ). It looks quite readable, see the screenshot .
This requirement emphasizes that WAI-WCAG is not just a technical standard for which the site developers are responsible. The standard is equally addressed to content authors, editors and content managers, and the provisions of the standard should be enshrined in the site’s content strategy.
Guidelines 8-14 read in the full version of the article about WCAG on webew.ru .
WCAG 1.0 - a standard that describes the general rules for the design of pages on the Internet was developed in 1999 by the WAI division of W3C. The purpose of the standard is to make Internet content accessible to all users, including users with disabilities (for example, impaired users use special programs to read the contents of sites to work on the Internet). The standard is described in the form of guidelines containing a list of control points, divided into three groups according to priority:
- Priority 1. The site must comply with these provisions, otherwise some users will not be able to access the content of the site.
- Priority 2. The site must follow these provisions, otherwise some users will experience significant difficulties in accessing the contents of the site.
- Priority 3. It is desirable that the site follows these provisions, otherwise some users will experience some difficulties when accessing the contents of the site.
Three priority groups correspond to three levels of compliance with the standard:
- Level A: All requirements with priority 1 are met.
- Level Two A: All requirements having priority 1 or 2 are met.
- Level Three A: All requirements with priority 1, 2, or 3 are met.
Guideline 1. Provide alternatives to audio and visual content.
- 1.1 (priority 1) Provide the text equivalent for all non-text elements, including img, map, applet, object, frame, script, audio and video files.
This is perhaps the most important requirement. If there are no sounds and videos on the site, then you need to make sure that all pictures have an alt attribute that describes the contents of the picture. If the picture is a chart that cannot be described in the alt attribute, you must use the longdesc attribute, whose value is a link to a separate page that describes the picture. Note that the alt attribute is required for the img tag, so the html validator will indicate its absence . However, the validator will also be satisfied with an empty alt attribute, which may be a violation of the WCAG standard. If there are a significant number of videos or sounds, this recommendation will significantly affect the process of posting new materials.
- 1.2 (priority 1) Provide alternative links to each active area on the server image map.
- 1.3 (priority 1) Until browsers learn to pronounce the text equivalent of the visuals, provide the audio equivalent of the visuals or multimedia presentations.
- 1.4 (priority 1) Synchronize the text or audio equivalent with the video in time. In case the used video format does not support subtitles, make 2 video options - with and without subtitles.
- 1.5 (priority 3) Until browsers learn to display the text equivalents of areas on the client image map, provide duplicate links for each active area.
Guideline 2. Do not rely only on color.
- 2.1 (priority 1) Make sure that all information transmitted using color is also available without colors, for example, in the form of text or markup.
- 2.2 (priority 2 for drawings, priority 3 for text) Make sure that the foreground and background colors are sufficiently contrasted when viewed on a black and white monitor, as well as people with limited color perception.
Guideline 3. Use layout and style pages correctly.
- 3.1 (priority 2) If a suitable markup tool exists, use it and not an image to convey information.
- 3.2 (priority 2) Create documents that meet formal format requirements (for example, include a link to the DTD at the beginning of the document to easily verify the correctness of the document format).
- 3.3 (priority 2) Use style pages.
To follow the rules 3.2 and 3.3, you should regularly check the site pages for compliance with HTML and CSS standards, for example, using the validators provided by w3c.
- 3.4 (priority 2) Use relative rather than absolute values in CSS attributes. For example, use em or percentages instead of pt or cm. If absolute units are used, do detailed testing of the content in various user environments.
This rule is perhaps quite difficult to follow. On many sites, Runet parameters are set in pixels or in pt. Required verification in various environments should include testing in sound browsers and people with disabilities.
- 3.5 (priority 2) Use headings to style the structure of the document.
- 3.6 (priority 2) Correctly list the elements (for example, using the ol, ul, and dl tags).
- 3.7 (priority 2) Make quotes correctly. Do not use the q and blockquote elements to style non-quote text.
Guideline 4. Correctly declare the language of the text.
- 4.1 (priority 1) Note the language change in the text (for example, use the lang attribute in HTML, xml: lang in XML). If the document contains parts of text in other languages, an explicit indication of the language will allow the sound browser to switch to another language when reading these fragments.
Recommendation 4.1 should be taken into account, for example, on tourist or language sites containing fragments in other languages.
- 4.2 (priority 3) Give the detailed equivalent of each abbreviation for the first use in the text (in HTML, use the title attribute for the elements abbr and acronym).
- 4.3 (priority 3) Declare the main language of the document (in HTML using the lang attribute of the html tag, in XHTML using the xml: lang attribute).
Guideline 5. Create accessible tables.
- 5.1 (priority 1) Select row and column headings in data tables (in html - th elements).
- 5.2 (priority 1) For tables that have two or more heading levels, use markup elements to associate headings with content (thead, tfoot, tbody to link rows, col, colgroup to link columns, axis, scope and headers attributes to describe more complex relationships).
- 5.3 (priority 2) Do not use tables if the table does not make sense in a linearized form or provide an alternative view to such tables.
- 5.4 (priority 2) Inside tables, do not use markup structural elements for visual formatting purposes (for example, do not use th to highlight a cell that is not a header).
- 5.5 (priority 3) Define a table summary using the summary attribute.
- 5.6 (priority 3) Specify abbreviated table headers (abbr attribute of the tr tag). Such headers can be useful to avoid repeating a long header when sequentially reading all the cells in a table.
Guideline 6. Make sure that pages using new technologies are accessible.
- 6.1 (priority 1) Make sure that the document can be read with the style pages turned off.
In order to test point 6.1, we used the lynx text browser, which is included in most Linux distributions (windows versions are also available ). It looks quite readable, see the screenshot .
- 6.2 (priority 1) Ensure that the equivalent of dynamic content is updated when updating dynamic content.
This requirement emphasizes that WAI-WCAG is not just a technical standard for which the site developers are responsible. The standard is equally addressed to content authors, editors and content managers, and the provisions of the standard should be enshrined in the site’s content strategy.
- 6.3 (priority 1) Make sure that pages can be used when scripts, applets or other program elements are turned off.
- 6.4 (priority 2) Make sure that the event handlers in scripts and applets are independent of the input device. Try to use application level events such as onfocus, onblur, onselect. Use device-specific event handlers in pairs: onmousedown with onkeydown, onmounseup with onkeyup, onclick with onkeypress.
- 6.5 (priority 2) Ensure that dynamic content is available in different client environments or provide an alternative page view. For example, in many cases, server-side scripts provide higher availability than client-side scripts.
Guideline 7. Give the user control over page changes occurring on a timer.
- 7.1 (priority 1) Avoid fast flickering of the screen until browsers learn how to filter flicker (people with photosensitive epilepsy are contraindicated to look at flashes with a frequency from 4 to 59 Hz).
- 7.2 (priority 2) Avoid flickering content (until browsers learn how to filter flickering).
- 7.3 (priority 2) Do not place moving content on pages (until browsers learn to stop moving). If you need to use movement, provide a simple mechanism to disable movement on the page.
- 7.4 (priority 2) Do not create pages with automatic periodic page refresh (until browsers learn to block auto-refresh).
- 7.5 (priority 2) Until browsers learn to block a client redirect, do not use it automatically. Use a server redirect.
Guidelines 8-14 read in the full version of the article about WCAG on webew.ru .