Adapting a website for users with disabilities is not difficult.
Web developers to adapt sites for the visually impaired (and other categories of people with disabilities) are twofold. On the one hand, I have not yet met a man who would say “there are too few of them to spend time on them”; on the other hand, in the conditions 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, often just scares. Meanwhile, the majority of WCAG 2.0 recommendations from the W3C consortium (Web Content Accessibility Guidelines, Web Content Accessibility Guidelines) on closer examination tritely coincide with etiquette rules, recommendations for adapting websites for mobile devices, and simply not so difficult to implement. At the same time, following these recommendations will simplify 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 presentation of all twelve provisions of WCAG 2.0, which I bring to your attention.
The easiest and most universal way of perceiving information for any person is printed text. It is not always optimal for conditionally healthy people (as we know, there are no absolutely healthy people): it is better to listen to songs, to watch videos. But the text format is good because its perceptibility can easily be improved: the visually impaired with the help of a screen magnifier or increasing the font with the means of the operating system, the blind with the help of computer-aided text or displaying it on the Braille display. Therefore, all content that can be presented in textual form should also be presented (or a textual presentation should be offered 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 exactly what a long video contains to decide whether to watch it? Or find the fragment you need, which is “somewhere in the middle”? Or does the audio speaker do it too quickly or unintelligible? 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 sequence does not fully describe the content of the video. The textual analogue should also include a description of what is important 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 based on the same principles.
And the usefulness of subtitles in the video has not been canceled.
Assistive technologies designed for computerized sounding of text perceive the HTML page as a sequence of text, and not as a collection of blocks that are geometrically placed on the page. It is therefore very important in the source code of the page to observe the same sequence of blocks that is implied in the display. For example, when absolute divs are positioned, they must be listed in the same sequence as shown on the page. It also imposes limitations on the sensory characteristics of the content (color, location, etc.). Examples 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 “press the green button if you agree with the terms of the offer”.
It is also useful to provide the user with a lightweight page (for example, a print version).
And, of course, it is important to use a semantically correct layout. Not only for assistive technologies, but also for other cases of automatic content extraction, for example, search engines.
Let's start with color. Color coding is a useful thing. For example, the save button / icon may be green and the delete button red. Or, the user is offered to choose a color for some task: it is much clearer to draw colored squares and suggest clicking on the color you like, than choosing from the drop-down list the values ​​“green”, “red”, etc.
But you cannot use color as the only way to convey information or designate an action. The red button should clearly indicate “delete” (or it should have the corresponding title attribute), the same applies to colored squares. Another example, which, unfortunately, is very common: highlighting incorrectly filled form fields with a red border. Color coding is not enough here: you need at least to list all the wrong fields and indicate exactly what the error is (there are few digits in the phone number, the email does not match the format).
This position also applies to audio content played automatically. Surely you, like me, met intrusive banners or other elements of the pages that not only show, but also tell their message aloud. And surely you, like me, in most cases it is annoying. Personally, I believe that such elements cannot be used on the pages (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 decrease its volume directly on the page, and not using the operating system or the off button speakers.
It is also desirable to abandon the background sound or, if you really really want to, make it quiet and disconnectable.
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, the operations in it were convenient to do on the keyboard, and we used the mouse much less frequently than now, in graphic operating systems. This is understandable: try without a mouse, using Tab one to get to the eighty-third icon on the desktop or to the link in the footer of your site.
However, using the old memory, I often use the keyboard not only to enter text: the “down” key in the input fields or drop-down lists, ctrl-c / ctrl-v, Tab, Enter, etc. And although I feel easy, I am dissatisfied if the form is not sent by pressing Enter, and after entering the login the Tab key does not move the cursor to the password field.
WCAG is also talking about providing control over the functionality of the content using the keyboard. First of all it refers to the forms. There is a separate problem - today's one-page sites (when the transition to the subsections of the site takes place without reloading the page: the new page either crawls out to the right or below, or pops up over the old one), parallax effects, drop-down menus, etc.
It is very easy to check the compliance of your page with this position: move the mouse away and try to perform all significant actions with the page using the keyboard only.
This provision deals with time-limited content. For example, it can be changing shots of special offers or new products, online tests, board online games with a limit on the course or party time, automatic slideshows of presentations, etc. Such restrictions can create a problem not only for the visually impaired, but also for the elderly for which the language of the content is not native. If possible, time constraints should be avoided, and if it does not work at all, give the user a manual opportunity to pause or extend the validity of the content, warning him in advance about the expiration of time.
Of course, there are cases when it is impossible to extend the validity period, for example, online auctions, the choice of a seat on a plane in real time. For such cases, there are also tricks: give more time to the auction step, block the place selected 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 terminates the session, if the user is idle for a long time), then in addition to the warning about the imminent rupture of the session, if such a gap does occur, you need to re-authorize the user to return to the place where he was before that, not forcing him to re-go all the way from the beginning.
Here we are talking about flashes or blinking of the page or its elements too often. (I would add harsh unexpected sounds to it.) I think the undesirability of such techniques for healthy people is quite obvious. If for some reason you cannot do without such flashes, you should at least make them not very frequent.
Again, an experienced web developer will not find anything in this situation that would contradict the logic when designing a website without taking into account the audience of people with disabilities:
Also during layout you should take into account 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 (header, advertisement, navigation elements, minor elements), then as far as possible on the page there should be an element, when clicked, the visitor will see the main content. However, to use massive caps and hide content on the second scrolling of the screen - and so bad form.
First, the language (or primary language) of the page must be defined in the HTML code of the page. If the page contains text blocks in another language (for example, quotes), their container must have an 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 lexicon), but focuses not only on a professional audience, it would be nice to provide alternative content for the content, which is simpler in meaning and in reading possibilities.
When designing, you should avoid unusual behavior of the page or its elements, which can confuse the user. Examples of erroneous page behavior:
In other words, changing the page context (opening a new window, switching to another page, dynamically replacing a significant amount of content) should be predictable for the user; its action, which caused this change (sending the form, shifting the focus, hovering the mouse over the element, scrolling), should be clearly associated with the consequences in the user's understanding.
Surely you have repeatedly seen error messages in the spirit of "Error # 355" or "Stack Overflow" or "The form is filled incorrectly." You will see a window with such an inscription and look at it as a new gate, thinking every time: well, was it really difficult to write so that it was clear what should I do about it ?! But these inscriptions were written not 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 after the “password” field there is the same field without a signature, then this is a repeat of the password, and the field next to the digits 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 put together forms so that they can be understood by any category of users. By composing a form, I mean not only the layout itself, but also a reaction to incorrect filling: the place of output and the contents of error messages, hints 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 a payment, etc.): the user needs, first, to provide the ability to verify the entered data and correct errors before sending, and secondly, if possible, the ability to revoke the sent information (cancellation).
Sometimes for the purpose of embellishment, 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 radiobatons - pictures with the image of the on / off circles, instead of the submission button - a picture with onclick. It is better to avoid such techniques, since the HTML / CSS capabilities are powerful enough for such visual effects, and if it doesn’t work out at all, check for compatibility with assistive technologies.
And here again: semantically correct layout is very important!
As you can see, the Exotic Web Content Accessibility Guide from the developer is not required. Of course, the document itself is more complex and detailed, with levels of compliance, a glossary, etc. Unfortunately, the main part of the accompanying content (explanations, examples) has not yet been translated into Russian, but it is in excess 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 the users of various gadgets, for which the principles described are also applicable, as well as older people, their share in the site’s audience can grow 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 they are comfortable reading your site, writing, making purchases on it.
Personally, I think that it is not necessary to follow the letter of the Guide in every project exactly: in some cases it may be too laborious. 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 the most diverse users.
PS I thank for the help in the preparation of 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 its possible conversion into alternative forms suitable for different users.
The easiest and most universal way of perceiving information for any person is printed text. It is not always optimal for conditionally healthy people (as we know, there are no absolutely healthy people): it is better to listen to songs, to watch videos. But the text format is good because its perceptibility can easily be improved: the visually impaired with the help of a screen magnifier or increasing the font with the means of the operating system, the blind with the help of computer-aided text or displaying it on the Braille display. Therefore, all content that can be presented in textual form should also be presented (or a textual presentation should be offered 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, switches). Such elements cannot be represented as text, they must use the label tag and the attributes alt, title. This will help to programmatically associate an input field with an explanatory inscription and, as a result, convey the meaning of the element to the user.
- Tests or exercises that can not be represented as text. In this case, at least a brief text-explanation of this exercise is necessary. The same applies to content that creates a specific sensory perception (pictures, music without words).
- Captcha First, you need a clear explanation of why this input field is needed and how to enter it (for sure you have met the “ascetic” captcha, consisting only of a picture and an input field, without text explanations?). Secondly, captcha should have an alternative information output (audio captcha).
- Non-text elements intended for decoration, formatting or not visible at all. Such elements should be described in such a way that assistive technologies (for example, sounding text) ignore them. That is, for example, to make design in CSS or not to prescribe attributes alt and title.
Provide an alternative version of time-limited media content.
Have you ever had a situation where you need to quickly understand exactly what a long video contains to decide whether to watch it? Or find the fragment you need, which is “somewhere in the middle”? Or does the audio speaker do it too quickly or unintelligible? 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 sequence does not fully describe the content of the video. The textual analogue should also include a description of what is important 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 based on 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 computerized sounding of text perceive the HTML page as a sequence of text, and not as a collection of blocks that are geometrically placed on the page. It is therefore very important in the source code of the page to observe the same sequence of blocks that is implied in the display. For example, when absolute divs are positioned, they must be listed in the same sequence as shown on the page. It also imposes limitations on the sensory characteristics of the content (color, location, etc.). Examples 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 “press the green button if you agree with the terms of the offer”.
It is also useful to provide the user with a lightweight page (for example, a print version).
And, of course, it is important to use a semantically correct layout. Not only for assistive technologies, but also for other cases of automatic content extraction, for example, search engines.
Simplify viewing and listening to content by separating important parts from non-essential ones.
Let's start with color. Color coding is a useful thing. For example, the save button / icon may be green and the delete button red. Or, the user is offered to choose a color for some task: it is much clearer to draw colored squares and suggest clicking on the color you like, than choosing from the drop-down list the values ​​“green”, “red”, etc.
But you cannot use color as the only way to convey information or designate an action. The red button should clearly indicate “delete” (or it should have the corresponding title attribute), the same applies to colored squares. Another example, which, unfortunately, is very common: highlighting incorrectly filled form fields with a red border. Color coding is not enough here: you need at least to list all the wrong fields and indicate exactly what the error is (there are few digits in the phone number, the email does not match the format).
This position also applies to audio content played automatically. Surely you, like me, met intrusive banners or other elements of the pages that not only show, but also tell their message aloud. And surely you, like me, in most cases it is annoying. Personally, I believe that such elements cannot be used on the pages (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 decrease its volume directly on the page, and not using the operating system or the off button speakers.
It is also desirable to abandon the background sound or, if you really really want to, make it quiet and disconnectable.
The following simple rules also apply to this provision:
- the text should be sufficiently contrast to the background, with the exception of background text and elements such as logos
- the user should be able to increase the text to at least 200%, and at the same time the page should not be parted
- no need to output the text as a picture (unless it has a clear justification)
- when typing text, it is advisable to follow the general rules of typography for the web: the width of the line is no more than 80 characters, the text is not aligned at both edges, the line spacing should be small and significantly less than the interval between paragraphs, etc.
Provide keyboard management functionality
When I first sat down at the computer, the most popular work environment was the text Norton Commander. Without exception, the operations in it were convenient to do on the keyboard, and we used the mouse much less frequently than now, in graphic operating systems. This is understandable: try without a mouse, using Tab one to get to the eighty-third icon on the desktop or to the link in the footer of your site.
However, using the old memory, I often use the keyboard not only to enter text: the “down” key in the input fields or drop-down lists, ctrl-c / ctrl-v, Tab, Enter, etc. And although I feel easy, I am dissatisfied if the form is not sent by pressing Enter, and after entering the login the Tab key does not move the cursor to the password field.
WCAG is also talking about providing control over the functionality of the content using the keyboard. First of all it refers to the forms. There is a separate problem - today's one-page sites (when the transition to the subsections of the site takes place without reloading the page: the new page either crawls out to the right or below, or pops up over the old one), parallax effects, drop-down menus, etc.
It is very easy to check the compliance of your page with this position: move the mouse away and try to perform all significant actions with the page using the keyboard only.
Give users plenty of time to read and work with content.
This provision deals with time-limited content. For example, it can be changing shots of special offers or new products, online tests, board online games with a limit on the course or party time, automatic slideshows of presentations, etc. Such restrictions can create a problem not only for the visually impaired, but also for the elderly for which the language of the content is not native. If possible, time constraints should be avoided, and if it does not work at all, give the user a manual opportunity to pause or extend the validity of the content, warning him in advance about the expiration of time.
Of course, there are cases when it is impossible to extend the validity period, for example, online auctions, the choice of a seat on a plane in real time. For such cases, there are also tricks: give more time to the auction step, block the place selected 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 terminates the session, if the user is idle for a long time), then in addition to the warning about the imminent rupture of the session, if such a gap does occur, you need to re-authorize the user to return to the place where he was before that, not forcing him to re-go all the way from the beginning.
Do not use intentionally harmful design elements.
Here we are talking about flashes or blinking of the page or its elements too often. (I would add harsh unexpected sounds to it.) I think the undesirability of such techniques for healthy people is quite obvious. If for some reason you cannot do without such flashes, you should at least make them not very frequent.
Provide users with assistance and support in navigating, searching for content and determining their current position on the site.
Again, an experienced web developer will not find anything in this situation that would contradict the logic when designing a website without taking into account the audience of people with disabilities:
- each page should have a title that describes the content
- the link text should explicitly describe the page where the visitor will hit when clicked (“detailed information about the product is here ” is a bad example; “see also detailed information about the product ” is good)
- The visitor must have several ways to search for the page he needs (standard navigation, site map, search string)
- when moving around the form using the keyboard (Tab) the active field of the form should be clearly highlighted
- on any page it should be clear to the visitor what the page and the site are
Also during layout you should take into account 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 (header, advertisement, navigation elements, minor elements), then as far as possible on the page there should be an element, when clicked, the visitor will see the main content. However, to use massive caps and hide content on the second scrolling of the screen - and so bad form.
Make all text content readable and understandable.
First, the language (or primary language) of the page must be defined in the HTML code of the page. If the page contains text blocks in another language (for example, quotes), their container must have an 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 lexicon), but focuses not only on a professional audience, it would be nice to provide alternative content for the content, which is simpler in meaning and in reading possibilities.
Web pages should be displayed and function in a predictable way.
When designing, you should avoid unusual behavior of the page or its elements, which can confuse the user. Examples of erroneous page behavior:
- when moving the focus from an incorrectly filled field to another field, the focus moves back without the user's demand
- when focusing on a field that requires clarification, a hint window pops up automatically
- the explanation for the input field is not displayed 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 list role (select tag) is for the user to choose which page to go to, the transition should be made after selecting the item and pressing the space bar or Enter, and not Esc or Tab
In other words, changing the page context (opening a new window, switching to another page, dynamically replacing a significant amount of content) should be predictable for the user; its action, which caused this change (sending the form, shifting the focus, hovering the mouse over the element, scrolling), should be clearly associated with the consequences in the user's understanding.
Help users avoid typing errors and correct them.
Surely you have repeatedly seen error messages in the spirit of "Error # 355" or "Stack Overflow" or "The form is filled incorrectly." You will see a window with such an inscription and look at it as a new gate, thinking every time: well, was it really difficult to write so that it was clear what should I do about it ?! But these inscriptions were written not 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 after the “password” field there is the same field without a signature, then this is a repeat of the password, and the field next to the digits 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 put together forms so that they can be understood by any category of users. By composing a form, I mean not only the layout itself, but also a reaction to incorrect filling: the place of output and the contents of error messages, hints 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 a payment, etc.): the user needs, first, to provide the ability to verify the entered data and correct errors before sending, and secondly, if possible, the ability to revoke the sent information (cancellation).
Ensure maximum content compatibility with existing and developing custom applications, including assistive technologies.
Sometimes for the purpose of embellishment, 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 radiobatons - pictures with the image of the on / off circles, instead of the submission button - a picture with onclick. It is better to avoid such techniques, since the HTML / CSS capabilities are powerful enough for such visual effects, and if it doesn’t work out at all, check for compatibility with assistive technologies.
And here again: semantically correct layout is very important!
Conclusion
As you can see, the Exotic Web Content Accessibility Guide from the developer is not required. Of course, the document itself is more complex and detailed, with levels of compliance, a glossary, etc. Unfortunately, the main part of the accompanying content (explanations, examples) has not yet been translated into Russian, but it is in excess 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 the users of various gadgets, for which the principles described are also applicable, as well as older people, their share in the site’s audience can grow 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 they are comfortable reading your site, writing, making purchases on it.
Personally, I think that it is not necessary to follow the letter of the Guide in every project exactly: in some cases it may be too laborious. 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 the most diverse users.
PS I thank for the help in the preparation of the article by the experts of the Russian office of W3C Alexey Lyubimov and Daniel Novichkov .
Source: https://habr.com/ru/post/165697/
All Articles