January 14, 2013 at 12:04Adapting a site for users with disabilities is not difficult
Web developers to adapt sites for the visually impaired (and other categories of people with disabilities) are ambivalent. On the one hand, I have not yet met a person who would say “there are too few of them to spend time on them”; on the other, in the context of fixed budgets and tight deadlines, this is exactly what happens. In addition, the fact that for this you need to learn some rules, recommendations, is often simply scary. Meanwhile, most of the recommendations WCAG 2.0 of the consortium W3C (Web Content Accessibility Guidelines, Guidelines for Web Content Accessibility) upon closer examination, they corny coincide with the rules of good form, recommendations for adapting sites for mobile devices, and it’s just not so difficult to implement. At the same time, following these recommendations will simplify the work with the site not only for users with disabilities, but also for users with limited technical capabilities (low-speed Internet; no mouse, like on smartphones; small screen), as well as older people. Therefore, I decided to write a free summary of all twelve provisions of WCAG 2.0, which I bring to your attention.
The simplest and most universal way of perceiving information for any person is printed text. It is not always optimal for conditionally healthy people (there are no completely healthy ones, as we know): it is better to listen to songs, watch videos. But the text format is good in that its perceptibility can easily be improved: visually impaired with a magnifying glass or a font enlargement using the operating system, blind - with the help of programs for computer scoring of text or displaying it on the Braille display. Therefore, all content that lends itself to presentation in textual form must be presented in the same way (or offered a textual presentation as an alternative way of conveying information). Exceptions to this rule are special forms of content:
Have you ever had a situation where you need to quickly understand what exactly a long video contains in order to decide whether to watch it? Or find the fragment you want, which is "somewhere in the middle"? Or is the person speaking the audio recording doing it too fast or inaudible? Agree, it is always useful to have a textual analogue of the contents of an audio or video clip. Or at least a description of what is written there.
It should be understood that the decoding of the audio series does not fully describe the contents of the video. A textual analogue should also include a description of what is important shown on the screen in order to convey to the reader the full meaning of the video. In addition to the text version of the video clips, they also create audio versions according to the same principles.
And the usefulness of subtitles in the video has not been canceled.
Assistive technologies designed for computer-based text scoring perceive an HTML page as a sequence of text, and not as a collection of blocks geometrically arranged on a page. Therefore, it is very important in the source code of the page to observe the same sequence of blocks that is implied in the display. For example, with absolute positioning of divs, they should be shown in the same sequence as shown on the page. It also imposes limitations on the sensory characteristics of content (color, location, etc.). An example of instructions that can create problems for users with disabilities: “if you are an individual, fill out the form in the second column of the table” or “click the green button if you agree to the terms of the offer”.
It is also useful to provide the user with a page with a lightweight design (for example, a print version).
And, of course, it is important to use semantically correct layout. Not only for assistive technologies, but also for other cases of automatic extraction of content, for example, search engines.
Let's start with the color. Color coding is a useful thing. For example, the save button / icon may be green and the delete button may be red. Or the user is prompted to select a color for some task: it’s much more obvious to display the colored squares and offer to click on the color you like than to select “green”, “red”, etc. from the drop-down list.
But you cannot use color as the only way to convey information or designate an action. The red button should clearly say “delete” (or it should have the corresponding attribute title), the same applies to colored squares. Another example, which, unfortunately, is very common: highlighting the form fields with incorrectly filled red borders. Color coding is not enough here: you must at least list all the wrong fields and indicate exactly what the error is (there are few digits in the phone number, email does not match the format).
This provision also applies to audio content played automatically. Surely you, like me, met obsessive banners or other page elements that not only show, but also tell their message out loud. And for sure you, like me, in most cases it annoys. Personally, I believe that such elements on pages cannot be used (except in rare cases, such as browser games or online broadcasts), but if they do exist, you must provide a means to turn off the sound or reduce its volume directly on the page, and not by the operating system or speaker off buttons.
It is also advisable to abandon the background sound or, if you really want to, make it quiet and mute.
The following simple rules also apply to this provision:
When I first sat down at the computer, the most popular work environment was the text Norton Commander. Without exception, all operations in it were convenient to do on the keyboard, and we used the mouse much less often than now in graphic operating systems. It is understandable: try without a mouse, with one Tab, get to the eighty-third icon on the desktop or to the link in the footer of your site.
However, from the old memory I often use the keyboard not only for entering text: the down key in the input fields or drop-down lists, ctrl-c / ctrl-v, Tab, Enter, etc. And although I feel mild, I am dissatisfied if pressing Enter does not send the form, and after entering the login key Tab does not move the cursor to the password field.
So the WCAG clause also talks about providing control over the functionality of content using the keyboard. This primarily relates to forms. A separate problem is single-page websites that are fashionable today (when switching to subsections of a site without reloading the page: a new page either creeps to the right or bottom, or pops up over the old one), parallax effects, a drop-down menu on mouseover, etc.
Check if your page matches this position very simple: move the mouse and try to perform all significant actions with the page only using the keyboard.
This provision refers to time-limited content. For example, it can be changing frames of special offers or new products, online tests, online board games with a time limit for a game or a party, automatic leaflets for presentation slides, etc. Such restrictions can create a problem not only for the visually impaired, but also for older people for which the language of the content is not native. If possible, it is better to avoid time limits, and if it does not work out at all, give the user the option to manually pause or extend the validity period of the content by warning it in advance of the time.
Of course, there are times when it is impossible to extend the validity period, for example, online auctions, real-time selection of seats on the plane. For such cases, there are also tricks: to give more time to the auction step, to block the place chosen by the user, to give him excess time to confirm the choice, etc.
If the time limit is related to security issues (for example, the client-bank interrupts the session if the user is idle for a long time), then in addition to the warning about an imminent break of the session, if such a break did occur, you need to return the user to the place where he was before after re-authorization, without forcing to go all the way from the beginning a.
This is about flashing or blinking too often on the page or its elements. (Here I would add sharp unexpected sounds.) I think the undesirability of such methods for conditionally healthy people is quite obvious. If for some reason you can’t do without such outbreaks, at least make them not very frequent.
And again, an experienced web developer will not find anything in this position that would contradict the logic when designing a site without taking into account the audience of people with disabilities:
Also, during layout, it should be borne in mind that when moving around the page using the keyboard, the sequence of movement should be the same as when using the mouse; the meaning of the page should not be violated.
If the main content of the page is preceded by a large amount of secondary information (heading, advertising, navigation elements, secondary elements), then there should be an element as high as possible on the page, when clicked, the visitor will see the main content. However, using massive caps and hiding content for the second scroll of the screen - and so bad taste.
First, the language (or main language) of the page must be defined in the HTML code of the page. If the page contains blocks of text in another language (for example, quotes), their container must have the xml: lang attribute that defines the language. Secondly, if the text contains rare words, abbreviations or specific meanings of words, it makes sense to explain them immediately.
If the content is too specialized (for example, it uses formulas, scientific, medical or financial vocabulary), but is focused not only on a professional audience, it would be nice to provide alternative content content that is simpler both in meaning and in reading possibilities.
When developing, you should avoid the non-standard behavior of the page or its elements, which can confuse the user. Examples of erroneous page behavior:
In other words, changing the context of the page (opening a new window, switching to another page, dynamically replacing a tangible amount of content) should be predictable for the user; its action that caused this change (submitting a form, moving focus, hovering over an element, scrolling) should, in the understanding of the user, be clearly associated with the consequences.
Surely you have repeatedly seen error messages in the spirit of "Error No. 355" or "Stack Overflow" or "The form is incorrectly filled." You will see a window with such an inscription and look at it like a new gate, each time thinking: well, was it really difficult to write so that it was clear what should I do with this ?! But these inscriptions were not written by secretaries, but by programmers, and, moreover, good programmers. Have you noticed that with the growth of the professional level, developers are moving away from the "common people"? We know that the field with an asterisk is mandatory, that the date in Russia is filled in the format “dd.mm.yyyy”, that if the field “password” is followed by the same field without a signature, then this is a password replay, and the field next to the numbers is captcha.
If we take the place of a person whose perception of our form is difficult for one reason or another (non-native language, poor eyesight, age, lack of experience on the Internet), it will be much easier for us to compose the forms so that they are understandable for any category of users. By compiling a form, I mean not only its layout itself, but also a reaction to incorrect completion: the output location and contents of error messages, tips and templates.
The principles of confirmation and reversibility are also very important, especially in cases when it comes to legal or financial transactions (acceptance of the offer, sending the payment, etc.): the user needs, firstly, to provide the opportunity to verify the entered data and correct errors before sending, and secondly, if possible, the ability to recall the information sent (cancellation).
Sometimes, for the purpose of decorating, developers replace standard HTML elements with alternative means. For example, instead of a drop-down list - an invisible layer that appears when you click on an element; instead of radio batons - pictures with the image of turned on / off circles, instead of the submit button - a picture with onclick. It’s better to avoid such techniques, fortunately, the HTML / CSS capabilities are powerful enough for such visual effects, and if it doesn’t work at all, check for compatibility with assistive technologies.
And here again: semantically correct layout is very important!
As you can see, the developer doesn’t require anything exotic. Of course, the document itself is more complex and detailed, with levels of conformity, a glossary, etc. Unfortunately, the main part of the accompanying content (explanations, examples) has not yet been translated into Russian, but it is in abundance in the original .
In Russia, more than 13 million people with disabilities are registered, that is 10% of the country's population. That is, with certain assumptions, we can assume that every tenth visitor to your sites has any health restrictions. And if you take into account users of various gadgets for which the described principles are also applicable, as well as older people, their share in the audience of the site can grow up to 30-40%. Agree, even ten (not to mention forty) percent of visitors is more than a tangible figure in order to make sure that it is convenient for them to read your site, write, make purchases on it.
Personally, I believe that it is not necessary to follow the letter of the Guide exactly in each project: in some cases this may be too time-consuming. But if you keep in mind the basic principles and take them into account in your work, your projects will be much more friendly to a variety of users.
PS Thank you for your help in preparing the article by the experts of the Russian office of W3C Alexey Lyubimov and Daniel Novichkov .
Provide a text version of any non-text content for possible conversion to alternative forms suitable for various users
The simplest and most universal way of perceiving information for any person is printed text. It is not always optimal for conditionally healthy people (there are no completely healthy ones, as we know): it is better to listen to songs, watch videos. But the text format is good in that its perceptibility can easily be improved: visually impaired with a magnifying glass or a font enlargement using the operating system, blind - with the help of programs for computer scoring of text or displaying it on the Braille display. Therefore, all content that lends itself to presentation in textual form must be presented in the same way (or offered a textual presentation as an alternative way of conveying information). Exceptions to this rule are special forms of content:
- Controls and information input (input fields, drop-down lists, radio buttons). Such elements cannot be represented in the form of text, for them you must use the label tag and the attributes alt, title. This will help programmatically associate the input field with an explanatory inscription and, as a result, convey the meaning of the element to the user.
- Tests or exercises that cannot be represented as text. In this case, at least a brief text explanation of this exercise is needed. The same applies to content that creates a specific sensory perception (paintings, music without words).
- CAPTCHA. Firstly, you need a clear explanation of why you need this input field and how to enter it there (you must have seen an “ascetic” captcha, consisting only of a picture and input field, without textual explanations?). Secondly, captcha should have an alternative output of information (audio captcha).
- Non-text elements designed for decoration, formatting or not visible at all. Such elements must be described in such a way that auxiliary (assistive) technologies (for example, scoring of the text) ignore them. That is, for example, to render design in CSS or not to register alt and title attributes.
Provide an alternative version of time-limited media content
Have you ever had a situation where you need to quickly understand what exactly a long video contains in order to decide whether to watch it? Or find the fragment you want, which is "somewhere in the middle"? Or is the person speaking the audio recording doing it too fast or inaudible? Agree, it is always useful to have a textual analogue of the contents of an audio or video clip. Or at least a description of what is written there.
It should be understood that the decoding of the audio series does not fully describe the contents of the video. A textual analogue should also include a description of what is important shown on the screen in order to convey to the reader the full meaning of the video. In addition to the text version of the video clips, they also create audio versions according to the same principles.
And the usefulness of subtitles in the video has not been canceled.
Create content that can be presented in various forms without losing data or structure (for example, with a simpler page layout)
Assistive technologies designed for computer-based text scoring perceive an HTML page as a sequence of text, and not as a collection of blocks geometrically arranged on a page. Therefore, it is very important in the source code of the page to observe the same sequence of blocks that is implied in the display. For example, with absolute positioning of divs, they should be shown in the same sequence as shown on the page. It also imposes limitations on the sensory characteristics of content (color, location, etc.). An example of instructions that can create problems for users with disabilities: “if you are an individual, fill out the form in the second column of the table” or “click the green button if you agree to the terms of the offer”.
It is also useful to provide the user with a page with a lightweight design (for example, a print version).
And, of course, it is important to use semantically correct layout. Not only for assistive technologies, but also for other cases of automatic extraction of content, for example, search engines.
Simplify viewing and listening to content, separating important parts from minor ones
Let's start with the color. Color coding is a useful thing. For example, the save button / icon may be green and the delete button may be red. Or the user is prompted to select a color for some task: it’s much more obvious to display the colored squares and offer to click on the color you like than to select “green”, “red”, etc. from the drop-down list.
But you cannot use color as the only way to convey information or designate an action. The red button should clearly say “delete” (or it should have the corresponding attribute title), the same applies to colored squares. Another example, which, unfortunately, is very common: highlighting the form fields with incorrectly filled red borders. Color coding is not enough here: you must at least list all the wrong fields and indicate exactly what the error is (there are few digits in the phone number, email does not match the format).
This provision also applies to audio content played automatically. Surely you, like me, met obsessive banners or other page elements that not only show, but also tell their message out loud. And for sure you, like me, in most cases it annoys. Personally, I believe that such elements on pages cannot be used (except in rare cases, such as browser games or online broadcasts), but if they do exist, you must provide a means to turn off the sound or reduce its volume directly on the page, and not by the operating system or speaker off buttons.
It is also advisable to abandon the background sound or, if you really want to, make it quiet and mute.
The following simple rules also apply to this provision:
- the text should be sufficiently contrasted with respect to the background, with the exception of secondary text and elements such as logos
- the user should be able to increase the text to at least 200%, and the page should not go apart
- no need to display text as a picture (if this does not have a clear justification)
- when typesetting the text, it is advisable to follow the general typography rules for the web: the line width is no more than 80 characters, the text does not align on both edges, the line spacing should be small and significantly less than the interval between paragraphs, etc.
Provide the ability to control all functionality from the keyboard
When I first sat down at the computer, the most popular work environment was the text Norton Commander. Without exception, all operations in it were convenient to do on the keyboard, and we used the mouse much less often than now in graphic operating systems. It is understandable: try without a mouse, with one Tab, get to the eighty-third icon on the desktop or to the link in the footer of your site.
However, from the old memory I often use the keyboard not only for entering text: the down key in the input fields or drop-down lists, ctrl-c / ctrl-v, Tab, Enter, etc. And although I feel mild, I am dissatisfied if pressing Enter does not send the form, and after entering the login key Tab does not move the cursor to the password field.
So the WCAG clause also talks about providing control over the functionality of content using the keyboard. This primarily relates to forms. A separate problem is single-page websites that are fashionable today (when switching to subsections of a site without reloading the page: a new page either creeps to the right or bottom, or pops up over the old one), parallax effects, a drop-down menu on mouseover, etc.
Check if your page matches this position very simple: move the mouse and try to perform all significant actions with the page only using the keyboard.
Allow enough time for users to familiarize themselves with and work with content.
This provision refers to time-limited content. For example, it can be changing frames of special offers or new products, online tests, online board games with a time limit for a game or a party, automatic leaflets for presentation slides, etc. Such restrictions can create a problem not only for the visually impaired, but also for older people for which the language of the content is not native. If possible, it is better to avoid time limits, and if it does not work out at all, give the user the option to manually pause or extend the validity period of the content by warning it in advance of the time.
Of course, there are times when it is impossible to extend the validity period, for example, online auctions, real-time selection of seats on the plane. For such cases, there are also tricks: to give more time to the auction step, to block the place chosen by the user, to give him excess time to confirm the choice, etc.
If the time limit is related to security issues (for example, the client-bank interrupts the session if the user is idle for a long time), then in addition to the warning about an imminent break of the session, if such a break did occur, you need to return the user to the place where he was before after re-authorization, without forcing to go all the way from the beginning a.
Do not use design elements that are known to be harmful to health.
This is about flashing or blinking too often on the page or its elements. (Here I would add sharp unexpected sounds.) I think the undesirability of such methods for conditionally healthy people is quite obvious. If for some reason you can’t do without such outbreaks, at least make them not very frequent.
Provide users with help and support in navigating, searching for content and in determining their current position on the site
And again, an experienced web developer will not find anything in this position that would contradict the logic when designing a site without taking into account the audience of people with disabilities:
- each page should have a title describing the content
- the link text should clearly enough describe the page that the visitor will get to when clicked (“detailed product information is here ” is a bad example; “see also detailed product information ” is good)
- the visitor should have several ways to find the page he needs (standard navigation, site map, search bar)
- when moving around the form using the keyboard (Tab), the active form field should be obviously highlighted
- on any page, the visitor should understand what kind of page and site it is
Also, during layout, it should be borne in mind that when moving around the page using the keyboard, the sequence of movement should be the same as when using the mouse; the meaning of the page should not be violated.
If the main content of the page is preceded by a large amount of secondary information (heading, advertising, navigation elements, secondary elements), then there should be an element as high as possible on the page, when clicked, the visitor will see the main content. However, using massive caps and hiding content for the second scroll of the screen - and so bad taste.
Make all text content readable and understandable
First, the language (or main language) of the page must be defined in the HTML code of the page. If the page contains blocks of text in another language (for example, quotes), their container must have the xml: lang attribute that defines the language. Secondly, if the text contains rare words, abbreviations or specific meanings of words, it makes sense to explain them immediately.
If the content is too specialized (for example, it uses formulas, scientific, medical or financial vocabulary), but is focused not only on a professional audience, it would be nice to provide alternative content content that is simpler both in meaning and in reading possibilities.
Web pages should display and function in a predictable way.
When developing, you should avoid the non-standard behavior of the page or its elements, which can confuse the user. Examples of erroneous page behavior:
- when the focus is moved from an incorrectly filled field to another field, the focus moves back without user demand
- when focusing on a field that requires explanation, a tooltip pops up automatically
- An explanation of the input field is displayed not next to it, but inside it, and disappears when focus is received
- standard site navigation on different pages is located or behaves differently
- if the role of the list (select tag) is for the user to choose which page to go to, the transition should be carried out after selecting an item and pressing the space bar or Enter, and not Esc or Tab
In other words, changing the context of the page (opening a new window, switching to another page, dynamically replacing a tangible amount of content) should be predictable for the user; its action that caused this change (submitting a form, moving focus, hovering over an element, scrolling) should, in the understanding of the user, be clearly associated with the consequences.
Help users avoid typing errors and correct them
Surely you have repeatedly seen error messages in the spirit of "Error No. 355" or "Stack Overflow" or "The form is incorrectly filled." You will see a window with such an inscription and look at it like a new gate, each time thinking: well, was it really difficult to write so that it was clear what should I do with this ?! But these inscriptions were not written by secretaries, but by programmers, and, moreover, good programmers. Have you noticed that with the growth of the professional level, developers are moving away from the "common people"? We know that the field with an asterisk is mandatory, that the date in Russia is filled in the format “dd.mm.yyyy”, that if the field “password” is followed by the same field without a signature, then this is a password replay, and the field next to the numbers is captcha.
If we take the place of a person whose perception of our form is difficult for one reason or another (non-native language, poor eyesight, age, lack of experience on the Internet), it will be much easier for us to compose the forms so that they are understandable for any category of users. By compiling a form, I mean not only its layout itself, but also a reaction to incorrect completion: the output location and contents of error messages, tips and templates.
The principles of confirmation and reversibility are also very important, especially in cases when it comes to legal or financial transactions (acceptance of the offer, sending the payment, etc.): the user needs, firstly, to provide the opportunity to verify the entered data and correct errors before sending, and secondly, if possible, the ability to recall the information sent (cancellation).
Maximize content compatibility with existing and emerging custom applications, including assistive technology
Sometimes, for the purpose of decorating, developers replace standard HTML elements with alternative means. For example, instead of a drop-down list - an invisible layer that appears when you click on an element; instead of radio batons - pictures with the image of turned on / off circles, instead of the submit button - a picture with onclick. It’s better to avoid such techniques, fortunately, the HTML / CSS capabilities are powerful enough for such visual effects, and if it doesn’t work at all, check for compatibility with assistive technologies.
And here again: semantically correct layout is very important!
Conclusion
As you can see, the developer doesn’t require anything exotic. Of course, the document itself is more complex and detailed, with levels of conformity, a glossary, etc. Unfortunately, the main part of the accompanying content (explanations, examples) has not yet been translated into Russian, but it is in abundance in the original .
In Russia, more than 13 million people with disabilities are registered, that is 10% of the country's population. That is, with certain assumptions, we can assume that every tenth visitor to your sites has any health restrictions. And if you take into account users of various gadgets for which the described principles are also applicable, as well as older people, their share in the audience of the site can grow up to 30-40%. Agree, even ten (not to mention forty) percent of visitors is more than a tangible figure in order to make sure that it is convenient for them to read your site, write, make purchases on it.
Personally, I believe that it is not necessary to follow the letter of the Guide exactly in each project: in some cases this may be too time-consuming. But if you keep in mind the basic principles and take them into account in your work, your projects will be much more friendly to a variety of users.
PS Thank you for your help in preparing the article by the experts of the Russian office of W3C Alexey Lyubimov and Daniel Novichkov .