Content Availability Standard WAI-WCAG 1.0

The need for the introduction of standards for the availability of services and content is stated in the final resolution of the RIF-2008 , and in world practice such standards have existed and have been used for more than 10 years. Following the WAI-WCAG (Web Accessibility Initiative Web Content Access Guidelines) content accessibility 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 designing web pages on the Internet was developed in 1999 by the WAI unit of the W3C group. The purpose of the standard is to make the content of the Internet accessible to all users, including users with disabilities (for example, users who lack sight, use special programs that read the content of websites to work in 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 follow these provisions, otherwise some users will not be able to access the contents of the site.
• Priority 2. The site must follow these provisions, otherwise some users will experience significant difficulties in accessing the content of the site.
• Priority 3. It is desirable that the site follows these provisions, otherwise some users will experience some difficulties when accessing the content of the site.

Three priority levels correspond to three levels of compliance with the standard:

• Level A: All requirements that have priority 1 are met.
• Level "two A": all requirements having priority 1 or 2 are fulfilled.
• Level "three A": all requirements having priority 1, 2 or 3 are fulfilled.

')

Guideline 1. Provide alternatives to audio and visual content.

• 1.1 (priority 1) Provide a text equivalent for all non-textual elements, including img, map, applet, object, frame, script, audio and video files.

Perhaps this is 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 image is a diagram that cannot be described in the alt attribute, you must use the longdesc attribute, the value of which is a link to a separate page describing the image. Note that the alt attribute is mandatory for the img tag, so the html validator will indicate its absence. However, the validator will be satisfied with an empty alt attribute value, which may be a violation of the WCAG standard. If there is a significant amount of video or sound, this recommendation will significantly affect the process of placing new materials.

• 1.2 (priority 1) Provide alternate links to each active area on the server image map.
• 1.3 (priority 1) Until browsers learn to pronounce the text equivalent of a visual series, provide the audio equivalent of a visual series or multimedia presentation.
• 1.4 (priority 1) Synchronize text or audio equivalent with video over time. In case the video format used does not support subtitles, make 2 video options - with and without subtitles.
• 1.5 (priority 3) Until browsers learn to display textual equivalent areas on the client image map, provide duplicate links to each active area.

Guideline 2. Do not rely only on color.

• 2.1 (priority 1) Make sure that all information transmitted by color is also available without colors, for example, in the form of text or markup.
• 2.2 (priority 2 for pictures, priority 3 for text) Make sure that the foreground and background colors are sufficiently contrast when viewed on a black and white monitor, as well as by people with limited color perception.

Guideline 3. Use markup and style pages correctly.

• 3.1 (priority 2) If there is a suitable markup tool, use it, and not the image to transfer information.
• 3.2 (priority 2) Create documents that meet formal format requirements (for example, include a reference to the DTD at the beginning of the document to simply verify the correctness of the document format).
• 3.3 (priority 2) Use style pages.

To follow rules 3.2 and 3.3, you should regularly check the pages of the site for compliance with HTML and CSS standards, for example, with the help of validators provided by w3c.

• 3.4 (priority 2) Use relative, not absolute values ​​in CSS attributes. For example, use em or percentage values ​​instead of pt or cm. If absolute units are used, conduct detailed testing of the contents in various user environments.

This rule is probably quite difficult to follow. On many sites of the RuNet, the parameters are specified in pixels or in pt. Required testing in various environments should include testing in audio browsers and people with disabilities.

• 3.5 (priority 2) Use headers to structure the document.
• 3.6 (priority 2) Correctly draw up lists of elements (for example, using ol, ul and dl tags).
• 3.7 (priority 2) Correctly make out quotes. Do not use the q and blockquote elements to format non-quotation text.

Guideline 4. Correctly declare the language of the text.

• 4.1 (priority 1) Mark the change of language in the text (for example, in HTML use the lang attribute, in XML - xml: lang). 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 expanded equivalent of each abbreviation when first used in the text (in HTML, use the title attribute for the abbr and acronym elements).
• 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 the row and column headers in the data tables (in html - th elements).
• 5.2 (priority 1) For tables that have two or more levels of headings, use markup elements to associate headings with content (thead, tfoot, tbody to link rows, col, colgroup - to link columns, axis, scope attributes and headers 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 the tables, do not use structural markup elements for visual formatting purposes (for example, do not use th to select a non-title cell).
• 5.5 (priority 3) Set the table summary using the summary attribute.
• 5.6 (priority 3) Set the abbreviated table headings (the abbr attribute of the tr tag). Such headers can be useful to avoid repeating a long header when all the table cells are read in succession.

Guideline 6. Make sure that pages that use new technologies are available.

• 6.1 (priority 1) Make sure that the document can be read when style pages are disabled.

In order to test paragraph 6.1, we used the lynx text browser, included in most Linux distributions (windows versions are also available ). Looks quite readable, see the screenshot .

• 6.2 (priority 1) Ensure that the equivalent of dynamic content is updated when dynamic content is updated.

This requirement emphasizes that WAI-WCAG is not just a technical standard for which 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 content strategy of the site.

• 6.3 (priority 1) Make sure that pages can be used with scripts, applets or other program elements turned off.
• 6.4 (priority 2) Ensure that event handlers in scripts and applets are independent of the input device. Try to use application-level events such as onfocus, onblur, onselect. Device-specific event handlers use pairs: onmousedown along with onkeydown, onmounseup along with onkeyup, onclick along with onkeypress.
• 6.5 (priority 2) Make sure 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 that occur on a timer.

• 7.1 (priority 1) Avoid quick flickering of the screen until browsers learn to filter flicker (people with photosensitive epilepsy are contraindicated to look at flashes from 4 to 59 Hz).
• 7.2 (priority 2) Avoid flickering content (until browsers learn how to filter flicker).
• 7.3 (priority 2) Do not place moving content on pages (as long as browsers do not learn to stop movement). If you need to use traffic, provide a simple mechanism to disable traffic 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 client redirects, do not use it automatically. Use server redirection.

Guidelines 8-14 read the full version of the WCAG article on webew.ru .