4 rules of WCAG 2.0, which you should know!

Some time ago, I had the opportunity to participate in very interesting training related to the application of the principles of WCAG 2.0 (Web Content Accessibility Guidelines), conducted by Oskar Michalski from the Chance for the Blind Foundation, as part of the “Bet on Accessibility! Action to Counteract Digital Exclusion of People with Disabilities and Seniors.”  According to the estimates of the National Population and Housing Census 2011, up to 12.2% of the country’s population consists of people with different types of disabilities. With this group in mind, the W3C has developed the WCAG 2.0 standard. The document sets out the extent to which a website should be adapted and accessible for people with disabilities (including the elderly and digitally excluded). Since 15 October 2012, these guidelines have the status of an international standard ISO/IEC 40500:2012. Although the document itself is quite concise, to avoid misinterpretation, it is accompanied by two documents: Understanding WCAG 2.0 and Techniques for WCAG 2.0. These documents after printing turn out to be close to a thousand-page long! Let’s not kid ourselves – no programmer can “absorb” the whole thing. Therefore, in this post I will present briefly the most important principles that will make it possible to meet the minimum requirements presented by this standard. Compliance with this minimum will give assurance that the website will be available not only for people with disabilities, but also for every citizen having difficulty in finding themselves in the cyberspace.

Where is the “minimum”?

The Journal of Laws of 16 May contains the Regulation of the Council of Ministers of 12 April 2012 on the National Interoperability Framework, the minimum requirements for public records and exchange of information in electronic form and minimum requirements for information and communication systems (Journal of Laws 2012, Item 526). This provision requires all entities performing public tasks to adapt their websites to the WCAG 2.0 and will come into force in May of 2015. Our minimum is precisely that what is defined by this law. Studies have shown that only 8% of public sector websites are adapted to the principles defines by this provision.

Each WCAG 2.0 recommendation has success criteria: A, AA or AAA. Adapting a website to all the recommendations is impossible, unless we want to disfigure it, therefore we will discuss the previously mentioned “minimum”, focusing on the technical side, related to administrators and developers. Issues related to content management will be discussed only in the most critical areas.

WCAG Principle No. 1: visibility

  • Graphic elements and other non-text elements must have a readable and understandable text alternative that allows blind people to understand an image, animation, applet. How many times do we encounter empty “alt” tags? Even if we fill them out, we do it too superficially. To a blind person, what does the description “path” say about a photo of a newly opened park? We should describe the pictures for those who cannot see them. For example, for the photo of the park, we can write: alt=”Central Park – main path and fountain. Perfect for walking if you like beautiful singing of birds.” Purely decorative elements, unrelated to the article, should have empty alt tags.
  • Audio content such as interviews, lectures and programs should have a text transcription, and films – subtitles for the deaf. In addition, player controls must be accessible from the keyboard – blind people do not use the mouse. Media files and SWFs should be made available in an alternative form.
  • Tables presenting data must have headers and be built in the easiest possible way. They cannot be a part of the site’s structure
  • Relevant information cannot rely solely on the senses – the heart of our article should contain the bare facts.
  • The color may not be the only way to highlight text and links must be clearly visible – instead of colored <span>, use <em> or <strong>. Links are presented so that they are clearly distinguishable from the background and surrounding text.
  • Avoid the use of music in the background of the website. If for some reason, however, you need to have it – be sure that it can be stopped or turned down from the keyboard. This applies to all the sounds longer than 3 seconds.
  • Contrast of all the elements on the website should be at least 4.5:1 for the success criterion A. For AAA, this value should be at least 7:1.
  • The information on the website should be fully visible after enlarging the page twice using the browser tools – text cannot overlap at any point. It is best if the whole page fits on the screen without having to scroll it horizontally.
  • The contents of PDF or DOC files should be accessible for blind people – creating a PDF containing the scanned document will not work, since the text in this case is not text but an image of text, thus – it is not visible to screen readers.

 

WCAG Principle No. 2: functionality

  • Go easy with animations – fast-moving texts, particularly in red, represent a serious threat to epileptics. If any elements change their position on the page dynamically – you need to make it possible to stop this process using the keyboard.
  • Every single element of the website should be accessible without the use of a mouse – keyboard traps (focus) are not acceptable. If the user enters a form using the keyboard, he must also be able to leave it.
  • Time – this is a very complicated rule, so it is worth it to spend a moment on it. This principle says that for every functionality that has a time limit, we must allow the user to control it. What does this mean in practice? No more than that in order to include criterion A, we must ensure that at least one of the following functionalities:
    • Ability to switch off – the user can turn off the countdown before the end of time; or
    • Adaptation – the user has the option to extend the duration of content availability by at least 10-fold; or
    • Extension – the user must be warned about the ending time at least 20 seconds before it expires, and must be able to react quickly (e.g. by pressing the corresponding key on the keyboard) resulting in an extension of the countdown.However, there are some exceptions to this rule:
    • When the time limit is crucial, because it concerns events taking place in real time and there is no possibility of its extension. This applies to, for example, an auction; or
    • When the time limit is crucial, because its extension or removal may result in cancellation of the fundamental functionality that cannot be provided by other means; or
    • The time limit is more than 20 hours.
  • When the time limit is crucial, because it concerns events taking place in real time and there is no possibility of its extension. This applies to, for example, an auction; or
  • When the time limit is crucial, because its extension or removal may result in cancellation of the fundamental functionality that cannot be provided by other means; or
  • The time limit is more than 20 hours.
  • Each function refreshing website content in a dynamic way, which takes place automatically, must have the option to stop it, hide it or adjust the frequency. The exception, as in the previous section, is a situation in which the refresh is crucial to the functionality.
  • For large sites, where there are a lot of links, it is recommended to use a link that allows to easily access the main content of the website.
  • The title of the page (<title> tag ) should be consistent, concise and unique and well reflect the contents of the page.
  • There should be at least two different ways to reach any content on the site – always use at least one additional way to navigate outside the main one. This can be a site map or search engine.
  • Sub-pages should be based on headers (h1 – h6), where h1 should be reserved for the title of the page and appear only once. Modern screen readers allow you to “jump” around the headers, which significantly helps to get to a particular piece of data, which interests us. Therefore, headers should be used in such a way that together with the rest of the article they form coherent content – obey the hierarchy and do not put h3 inside the article if two paragraphs earlier you used h4.
  • Navigation should be constructed in a coherent and logical way – focus should proceed sequentially through all the links, without skipping a single item.
  • Focus should be clearly visible – we often remove ugly default styles of pseudo :focus selectors. This is a big mistake, resulting in the fact that the website will not pass the audit (this item is criterion A). If you remove the default styles for no reason, or with the aim of unification in all browsers, you must remember to make available those that will be clear and visible for the visually impaired.

WCAG Principle No. 3: intelligibility

  • Language on a multilingual website or for downloadable documents in multiple languages ​​should be defined in a way that allows the blind to recognize it – placing flags in front of the file name using CSS background won’t work. We should at least throw in the language code in brackets. In addition, the language of the website, and each foreign language part of the content should be specified in the lang attribute.
  • We definitely should not automatically open any windows, tabs, pop-ups (including dynamic modals) without the user’s knowledge. In the case of modals, remember about the possibility of reaching their content using the keyboard.
  • The change of context on the website can take place only after approval by the user.
  • Forms:
    ◦ <label> is still needed – the “placeholder” attribute is not, in any case, an alternative to the description of the form field. Correct labels are essential for the forms.
    ◦ Required fields must be marked in a clear and understandable manner – the ideal solution is to simply add “(required)” behind the label.
    ◦ If you require a specific format of the data provided by the user, you should clearly define this format, preferably using text, e.g. for the date, you should add: “(dd-mm-yyyy)”.
    ◦ In the case of rejection of a form because of errors in the form,  suggestions on removing these errors are necessary- graphic validation is not enough. A blind person will not see a red frame or graphic exclamation point inserted using CSS. Also, do not just write “error” next to the field . If the user inserted an incorrect e-mail address, then you should inform him pointing to the e-mail field as the cause of the failure.
    ◦ You should give the user a chance to revise and modify the data provided prior to final approval. A good example is the order preview page during the online purchase process. After entering the address (or addresses if delivery address is different), selecting the method of delivery and payment, you usually see a summary page that gives you a chance for a quick return to a particular section of the form and editing individual fields.

 

WCAG Principle 4: reliability

  • The website (and all of its sub-pages) should not contain syntax errors – the reference point is the famous among programmers Front-End W3C validator (HTML and CSS).
  • All frames must have titles.

Well, most of the above-mentioned recommendations fit in the A success criterion, but that does not mean that AAA contains only “hardcore” ones. There are some items in this area that are technically very simple to implement, and even many of them have already been implemented earlier. As an example we can mention the “breadcrumbs” that many websites use because of SEO.

I hope that this long, but not fully exhaustive article will be useful for many people, and perhaps even serve as a kind of “checklist” before publishing a website.

 

pluswerk