diff options
Diffstat (limited to 'files/ru/learn/accessibility')
| -rw-r--r-- | files/ru/learn/accessibility/accessibility_troubleshooting/index.html | 102 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/css_and_javascript/index.html | 358 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/html/index.html | 538 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/index.html | 56 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/mobile/index.html | 305 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/multimedia/index.html | 361 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/wai-aria_basics/index.html | 417 | ||||
| -rw-r--r-- | files/ru/learn/accessibility/what_is_accessibility/index.html | 211 |
8 files changed, 2348 insertions, 0 deletions
diff --git a/files/ru/learn/accessibility/accessibility_troubleshooting/index.html b/files/ru/learn/accessibility/accessibility_troubleshooting/index.html new file mode 100644 index 0000000000..f486ddb73d --- /dev/null +++ b/files/ru/learn/accessibility/accessibility_troubleshooting/index.html @@ -0,0 +1,102 @@ +--- +title: Устранение проблем доступности +slug: Learn/Accessibility/Accessibility_troubleshooting +translation_of: Learn/Accessibility/Accessibility_troubleshooting +original_slug: Learn/Доступность/Accessibility_troubleshooting +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}</div> + +<p class="summary">In the assessment for this module, we present to you a simple site with a number of accessibility issues that you need to diagnose and fix.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Prerequisites:</th> + <td>Basic computer literacy, a basic understanding of HTML, CSS, and JavaScript, an understanding of the <a href="/en-US/docs/Learn/Accessibility">previous articles in the course</a>.</td> + </tr> + <tr> + <th scope="row">Objective:</th> + <td>To test basic knowledge of accessibility fundamentals.</td> + </tr> + </tbody> +</table> + +<h2 id="Starting_point">Starting point</h2> + +<p>To get this assessment started, you should go and grab the <a href="https://github.com/mdn/learning-area/blob/master/accessibility/assessment-start/assessment-files.zip?raw=true">ZIP containing the files that comprise the example</a>. Decompress the contents into a new directory somewhere on your local computer.</p> + +<p>The finished assessment site should look like so:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14555/assessment-site-finished.png" style="border-style: solid; border-width: 1px; display: block; height: 457px; margin: 0px auto; width: 800px;"></p> + +<p>You will see some differences/issues with the display of the starting state of the assessment — this is mainly due to the differences in the markup, which in turn cause some styling issues as the CSS is not applied properly. Don't worry — you'll be fixing these problems in the upcoming sections!</p> + +<h2 id="Project_brief">Project brief</h2> + +<p>For this project, you are presented with a fictional nature site displaying a "factual" article about bears. As it stands, it has a number of accessibility issues — your task is to explore the existing site and fix them to the best of your abilities, answering the questions given below.</p> + +<h3 id="Color">Color</h3> + +<p>The text is difficult to read because of the current color scheme. Can you do a test of the current color contrast (text/background), report the results of the test, and then fix it by changing the assigned colors?</p> + +<h3 id="Semantic_HTML">Semantic HTML</h3> + +<ol> + <li>The content is still not very accessible — report on what happens when you try to navigate it using a screenreader.</li> + <li>Can you update the article text to make it easier for screenreader users to navigate?</li> + <li>The navigation menu part of the site (wrapped in <code><div class="nav"></div></code>) could be made more accessible by putting it in a proper HTML5 semantic element. Which one should it be updated to? Make the update.</li> +</ol> + +<div class="note"> +<p><strong>Note</strong>: You'll need to update the CSS rule selectors that style the <font> tags to their proper equivalents for the semantic headings. Once you add paragraph elements, you'll notice the styling looking better.</font></p> +</div> + +<h3 id="The_images"><font>The images</font></h3> + +<p><font>The images are currently inaccessible to screenreader users. Can you fix this?</font></p> + +<h3 id="The_audio_player"><font>The audio player </font></h3> + +<ol> + <li><font>The <code><audio></code> player isn't accessible to hearing impaired (deaf) people — can you add some kind of accessible alternative for these users?</font></li> + <li><font>The <code><audio></code> player isn't accessible to those using older browsers that don't support HTML5 audio. How can you allow them to still access the audio?</font></li> +</ol> + +<h3 id="The_forms"><font>The forms</font></h3> + +<ol> + <li><font>The <code><input></code> element in the search form at the top could do with a label, but we don't want to add a visible text label that would potentially spoil the design and isn't really needed by sighted users. How can you add a label that is only accessible to screenreaders?</font></li> + <li><font>The two <code><input></code> elements in the comment form have visible text labels, but they are not unambiguously associated with their labels — how do you achieve this? Note that you'll need to update some of the CSS rule as well.</font></li> +</ol> + +<h3 id="The_showhide_comment_control"><font>The show/hide comment control</font></h3> + +<p><font>The show/hide comment control button is not current keyboard-accessible. Can you make it keyboard accessible, both in terms of focusing it using the tab key, and activating it using the return key?</font></p> + +<h3 id="The_table"><font>The table</font></h3> + +<p><font>The data table is not currently very accessible — it is hard for screenreader users to associate data rows and columns together, and the table also has no kind of summary to make it clear what it shows. Can you add some features to your HTML to fix this problem?</font></p> + +<h3 id="Other_considerations"><font>Other considerations?</font></h3> + +<p><font>Can you list two more ideas for improvements that would make the website more accessible?</font></p> + +<h2 id="Assessment"><font>Assessment</font></h2> + +<p><font>If you are following this assessment as part of an organized course, you should be able to give your work to your teacher/mentor for marking. If you are self-learning, then you can get the marking guide fairly easily by asking on the </font><a href="https://discourse.mozilla.org/t/accessibility-troubleshooting-assessment/24691">discussion thread for this exercise</a><font>, or in the <a href="irc://irc.mozilla.org/mdn">#mdn</a> IRC channel on <a href="https://wiki.mozilla.org/IRC">Mozilla IRC</a>. Try the exercise first — there is nothing to be gained by cheating!</font></p> + +<p><font>{{PreviousMenu("Learn/Accessibility/Mobile", "Learn/Accessibility")}}</font></p> + +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> diff --git a/files/ru/learn/accessibility/css_and_javascript/index.html b/files/ru/learn/accessibility/css_and_javascript/index.html new file mode 100644 index 0000000000..125e7e09af --- /dev/null +++ b/files/ru/learn/accessibility/css_and_javascript/index.html @@ -0,0 +1,358 @@ +--- +title: CSS и JavaScript доступность - лучшие практики +slug: Learn/Accessibility/CSS_and_JavaScript +tags: + - CSS + - JavaScript +translation_of: Learn/Accessibility/CSS_and_JavaScript +original_slug: Learn/Доступность/CSS_and_JavaScript +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div> + +<p class="summary">CSS и JavaScript, при правильном использовании, появляется возможность получить доступный web - опыт ... или же они могут значительно навредить доступности если не правильно используются. Это статья в общих очертаниях описывает рекомендации по использованию CSS и JavaScript , это является лучшей практикой, поэтому следует учитывать для обеспечения того, чтобы даже сложное содержание было максимально доступным</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">необходимые условия:</th> + <td>Базовая компьютерная грамотность, базовое понимание HTML, CSS, и JavaScript, и понимать (что такое доступность) <a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">what accessibility is</a>.</td> + </tr> + <tr> + <th scope="row">Цели:</th> + <td>Приобрести хорошую осведомленность при использовании CSS и JavaScript в ваших web документах для максимального увелечения доступности и (not detract from it)-(привет я не понял как переводится эти слова так что помогите если понимаете).</td> + </tr> + </tbody> +</table> + +<h2 id="CSS_и_JavaScript_доступны">CSS и JavaScript доступны?</h2> + +<p>CSS и JavaScript не имеют такого же непосредственного значения для доступности как HTML, но они остаются способными для помощи или для повреждения доступности, в зависимости от того как их использовать. Другими словами, важно чтобы вы рассмотрели некоторые рекомендации для лучшей практики,чтобы убедится, что CSS JavaScript не разрушат доступность ваших документов.</p> + +<h2 id="CSS">CSS</h2> + +<p>Let's start off by looking at CSS.</p> + +<h3 id="Correct_semantics_and_user_expectation">Correct semantics and user expectation</h3> + +<p>It is possible to use CSS to make any HTML element look like <em>anything</em>, but this doesn't mean that you should. As we frequently mentioned in our <a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a> article, you should use the appropriate semantic element for the job, whenever possible. If you don't, it can cause confusion and usability issues for everyone, but particularly users with disabilities. Using correct semantics has a lot to do with user expectations — elements look and behave in certain ways, according to their functionality, and these common conventions are expected by users.</p> + +<p>As an example, a screen reader user can't navigate a page via heading elements if the developer hasn't appropriately used heading elements to markup the content. By the same token, a heading loses its visual purpose if you style it so it doesn't look like a heading.</p> + +<p>The rule of thumb is that you can update the styling of a page feature to fit in your design, but don't change it so much that it no longer looks or behaves as expected. The following sections summarize the main HTML features to consider.</p> + +<h4 id="Standard_text_content_structure">"Standard" text content structure</h4> + +<p>Headings, paragraphs, lists — the core text content of your page:</p> + +<pre class="brush: html notranslate"><h1>Heading</h1> + +<p>Paragraph</p> + +<ul> + <li>My list</li> + <li>has two items.</li> +</ul></pre> + +<p>Some typical CSS might look like this:</p> + +<pre class="brush: css notranslate">h1 { + font-size: 5rem; +} + +p, li { + line-height: 1.5; + font-size: 1.6rem; +}</pre> + +<p>You should:</p> + +<ul> + <li>Select sensible font sizes, line heights, letter spacing, etc. to make your text logical, legible, and comfortable to read.</li> + <li>Make sure your headings stand out from your body text, typically big and bold like the default styling. Your lists should look like lists.</li> + <li>Your text color should contrast well with your background color.</li> +</ul> + +<p>See <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals">HTML text fundamentals</a> and <a href="/en-US/docs/Learn/CSS/Styling_text">Styling text</a> for more information.</p> + +<h4 id="Emphasised_text">Emphasised text</h4> + +<p>Inline markup that confers specific emphasis to the text that it wraps:</p> + +<pre class="brush: html notranslate"><p>The water is <em>very hot</em>.</p> + +<p>Water droplets collecting on surfaces is called <strong>condensation</strong>.</p></pre> + +<p>You might want to add some simple coloring to your emphasised text:</p> + +<pre class="brush: css notranslate">strong, em { + color: #a60000; +}</pre> + +<p>You will however rarely need to style emphasis elements in any significant way. The standard conventions of bold and italic text are very recognisable, and changing the style can cause confusion. For more on emphasis, see <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals#Emphasis_and_importance">Emphasis and importance</a>.</p> + +<h4 id="Abbreviations">Abbreviations</h4> + +<p>An element that allows an abbreviation, acronym, or initialization to be associated with its expansion:</p> + +<pre class="brush: html notranslate"><p>Web content is marked up using <abbr title="Hypertext Markup Language">HTML</abbr>.</p></pre> + +<p>Again, you might want to style it in some simple way:</p> + +<pre class="brush: css notranslate">abbr { + color: #a60000; +}</pre> + +<p>The recognised styling convention for abbreviations is a dotted underline, and it is unwise to significantly deviate from this. For more on abbreviations, see <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Advanced_text_formatting#Abbreviations">Abbreviations</a>.</p> + +<h4 id="Links">Links</h4> + +<p>Hyperlinks — the way you get to new places on the web:</p> + +<pre class="brush: html notranslate"><p>Visit the <a href="https://www.mozilla.org">Mozilla homepage</a>.</p></pre> + +<p>Some very simple link styling is shown below:</p> + +<pre class="brush: css notranslate">a { + color: #ff0000; +} + +a:hover, a:visited, a:focus { + color: #a60000; + text-decoration: none; +} + +a:active { + color: #000000; + background-color: #a60000; +}</pre> + +<p>The standard link conventions are underlined and a different color (default: blue) in their standard state, another color variation when the link has previously been visited (default: purple), and yet another color when the link is activated (default: red). In addition, the mouse pointer changes to a pointer icon when links are moused over, and the link receives a highlight when focused (e.g. via tabbing) or activated. The following image shows the highlight in both Firefox (a dotted outline) and Chrome (a blue outline):</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14371/focus-highlight-firefox.png" style="display: block; height: 173px; margin: 0px auto; width: 319px;"></p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14369/focus-highlight-chrome.png" style="display: block; height: 169px; margin: 0px auto; width: 309px;"></p> + +<p>You can be creative with link styles, as long as you keep giving users feedback when they interact with the links. Something should definitely happen when states change, and you shouldn't get rid of the pointer cursor or the outline — both are very important accessibility aids for those using keyboard controls.</p> + +<h4 id="Form_elements">Form elements</h4> + +<p>Elements to allow users to input data into websites:</p> + +<pre class="brush: html notranslate"><div> + <label for="name">Enter your name</label> + <input type="text" id="name" name="name"> +</div></pre> + +<p>You can see some good example CSS in our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-css.html">form-css.html</a> example (<a href="http://mdn.github.io/learning-area/accessibility/css/form-css.html">see it live</a> also).</p> + +<p>Most of the CSS you'll write for forms will be for sizing the elements, lining up labels and inputs, and getting them looking neat and tidy.</p> + +<p>You shouldn't however deviate too much from the expected visual feedback form elements receive when they are focused, which is basically the same as links (see above). You could style form focus/hover states to make this behaviour more consistent across browsers or fit in better with your page design, but don't get rid of it altogether — again, people rely on these clues to help them know what is going on.</p> + +<h4 id="Tables">Tables</h4> + +<p>Tables for presenting tabular data.</p> + +<p>You can see a good, simple example of table HTML and CSS in our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/table-css.html">table-css.html</a> example (<a href="http://mdn.github.io/learning-area/accessibility/css/table-css.html">see it live also</a>).</p> + +<p>Table CSS generally serves to make the table fit better into your design and look less ugly. It is a good idea to make sure the table headers stand out (normally using bold), and use zebra striping to make different rows easier to parse.</p> + +<h3 id="Color_and_color_contrast">Color and color contrast</h3> + +<p>When choosing a color scheme for your website, make sure that the text (foreground) color contrasts well with the background color. Your design might look cool, but it is no good if people with visual impairments like color blindness can't read your content.</p> + +<p>There is an easy way to check whether your contrast is large enough to not cause problems. There are a number of contrast checking tools online that you can enter your foreground and background colors into, to check them. For example WebAIM's <a href="http://webaim.org/resources/contrastchecker/">Color Contrast Checker</a> is simple to use, and provides an explanation of what you need to conform to the WCAG criteria around color contrast.</p> + +<div class="note"> +<p><strong>Note</strong>: A high contrast ratio will also allow anyone using a smartphone or tablet with a glossy screen to better read pages when in a bright environment, such as sunlight.</p> +</div> + +<p>Another tip is to not rely on color alone for signposts/information, as this will be no good for those who can't see the color. Instead of marking required form fields in red, for example, mark them with an asterisk and in red.</p> + +<h3 id="Hiding_things">Hiding things</h3> + +<p>There are many instances where a visual design will require that not all content is shown at once. For example, in our <a href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">Tabbed info box example</a> (see <a href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">source code</a>) we have three panels of information, but we are <a href="/en-US/docs/Learn/CSS/CSS_layout/Positioning">positioning</a> them on top of one another and providing tabs that can be clicked to show each one (it is also keyboard accessible — you can alternatively use Tab and Enter/Return to select them).</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13368/tabbed-info-box.png" style="display: block; height: 400px; margin: 0px auto; width: 450px;"></p> + +<p>Screen reader users don't care about any of this — they are happy with the content as long as the source order makes sense, and they can get to it all. Absolute positioning (as used in this example) is generally seen as one of the best mechanisms of hiding content for visual effect, because it doesn't stop screen readers from getting to it.</p> + +<p>On the other hand, you shouldn't use {{cssxref("visibility")}}<code>:hidden</code> or {{cssxref("display")}}<code>:none</code>, because they do hide content from screen readers. Unless of course, there is a good reason why you want this content to be hidden from screen readers.</p> + +<div class="note"> +<p><strong>Note</strong>: <span class="subtitle"><a href="http://webaim.org/techniques/css/invisiblecontent/">Invisible Content Just for Screen Reader Users</a> has a lot more useful detail surrounding this topic.</span></p> +</div> + +<h3 id="Accept_that_users_can_override_styles">Accept that users can override styles</h3> + +<h4 id="Accept_that_users_can_override_your_styles">Accept that users can override your styles</h4> + +<p>It is possible for users to override your styles with their own custom styles, for example:</p> + +<ul> + <li>See Sarah Maddox's <a class="external external-icon" href="https://www.itsupportguides.com/knowledge-base/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-firefox/" rel="noopener">How to use a custom style sheet (CSS) with Firefox</a> for a useful guide covering how to do this manually in Firefox, and <a href="https://www.itsupportguides.com/knowledge-base/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-internet-explorer/">How to use a custom style sheet (CSS) with Internet Explorer</a> by Adrian Gordon for the equivalent <abbr>IE</abbr> instructions.</li> + <li>It is probably easier to do it using an extension, for example the Stylish extension is available for <a href="https://addons.mozilla.org/en-US/firefox/addon/stylish/">Firefox</a>, <a href="https://safari-extensions.apple.com/details/?id=com.sobolev.stylish-5555L95H45">Safari</a>, <a href="https://addons.opera.com/en/extensions/details/stylish/">Opera</a>, and <a href="https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe">Chrome</a>.</li> +</ul> + +<p>Users might do this for a variety of reasons. A visually impaired user might want to make the text bigger on all websites they visit, or a user with severe color deficiency might want to put all websites in high contrast colors that are easy for them to see. Whatever the need, you should be comfortable with this, and make your designs flexible enough so that such changes will work in your design. As an example, you might want to make sure your main content area can handle bigger text (maybe it will start to scroll to allow it all to be seen), and won't just hide it, or break completely.</p> + +<h2 id="JavaScript">JavaScript</h2> + +<p>JavaScript can also break accessibility, depending on how it is used.</p> + +<p>Modern JavaScript is a powerful language, and we can do so much with it these days, from simple content and UI updates to fully-fledged 2D and 3D games. There is no rule that says all content has to be 100% accessible to all people — you just need to do what you can, and make your apps as accessible as possible.</p> + +<p>Simple content and functionality is arguably easy to make accessible — for example text, images, tables, forms and push button that activate functions. As we looked at in our <a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a> article, the key considerations are:</p> + +<ul> + <li>Good semantics: Using the right element for the right job. For example, making sure you use headings and paragraphs, and {{htmlelement("button")}} and {{htmlelement("a")}} elements</li> + <li>Making sure content is available as text, either directly as text content, good text labels for form elements, or <a href="/en-US/docs/Learn/Accessibility/HTML#Text_alternatives">text alternatives</a>, e.g. alt text for images.</li> +</ul> + +<p>We also looked at an example of how to use JavaScript to build in functionality where it is missing — see <a href="/en-US/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a>. This is not ideal — really you should just use the right element for the right job — but it shows that it is possible in situations where for some reason you can't control the markup that is used. Another way to improve accessibility for non-semantic JavaScript-powered widgets is to use WAI-ARIA to provide extra semantics for screen reader users. The next article will also cover this in detail.</p> + +<p>Complex functionality like 3D games are not so easy to make accessible — a complex 3D game created using <a href="/en-US/docs/Web/API/WebGL_API">WebGL</a> will be rendered on a {{htmlelement("canvas")}} element, which has no facility at this time to provide text alternatives or other information for severely visually impaired users to make use of. It is arguable that such a game doesn't really have this group of people as a part of its main target audience, and it would be unreasonable to expect you to make it 100% accessible to blind people, however you could implement <a href="/en-US/docs/Games/Techniques/Control_mechanisms/Desktop_with_mouse_and_keyboard">keyboard controls</a> so it is usable by non-mouse users, and make the color scheme contrasting enough to be usable by those with color deficiencies.</p> + +<h3 id="The_problem_with_too_much_JavaScript">The problem with too much JavaScript</h3> + +<p>The problem often comes when people rely on JavaScript too much. Sometimes you'll see a website where everything has been done with JavaScript — the HTML has been generated by JavaScript, the CSS has been generated by JavaScript, etc. This has all kinds of accessibility and other issues associated with it, so it is not advised.</p> + +<p>As well as using the right element for the right job, you should also make sure you are using the right technology for the right job! Think carefully about whether you need that shiny JavaScript-powered 3D information box, or whether plain old text would do. Think carefully about whether you need a complex non-standard form widget, or whether a text input would do. And don't generate all your HTML content using JavaScript if at all possible.</p> + +<h3 id="Keeping_it_unobtrusive">Keeping it unobtrusive</h3> + +<p>You should keep <strong>unobtrusive JavaScript</strong> in mind when creating your content. The idea of unobtrusive JavaScript is that it should be used wherever possible to enhance functionality, not build it in entirely — basic functions should ideally work without JavaScript, although it is appreciated that this is not always an option. But again, a large part of it is using built-in browser functionality where possible.</p> + +<p>Good example uses of unobtrusive JavaScript include:</p> + +<ul> + <li>Providing client-side form validation, which alerts users to problems with their form entries quickly, without having to wait for the server to check the data. If it isn't available, the form will still work, but validation might be slower.</li> + <li>Providing custom controls for HTML5 <code><video></code>s that are accessible to keyboard-only users, along with a direct link to the video that can be used to access it if JavaScript is not available (the default <code><video></code> browser controls aren't keyboard accessible in most browsers).</li> +</ul> + +<p id="Client-side_form_validation">As an example, we've written a quick and dirty client-side form validation example — see <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> (also <a href="http://mdn.github.io/learning-area/accessibility/css/form-validation.html">see the demo live</a>). Here you'll see a simple form; when you try to submit the form with one or both fields left empty, the submit fails, and an error message box appears to tell you what is wrong.</p> + +<p>This kind of form validation is unobtrusive — you can still use the form absolutely fine without the JavaScript being available, and any sensible form implementation will have server-side validation active as well, because it is too easy for malicious users to bypass client-side validation (for example, by turning JavaScript off in the browser). The client-side validation is still really useful for reporting errors — users can know about mistakes they make instantly, rather than having to wait for a round trip to the server and a page reload. This is a definite usability advantage.</p> + +<div class="note"> +<p><strong>Note</strong>: Server-side validation has not been implemented in this simple demo.</p> +</div> + +<p>We've made this form validation pretty accessible too. We've used {{htmlelement("label")}} elements to make sure the form labels are unambiguously linked to their inputs, so screen readers can read them out alongside:</p> + +<pre class="brush: html notranslate"><label for="name">Enter your name:</label> +<input type="text" name="name" id="name"></pre> + +<p>We only do the validation when the form is submitted — this is so that we don't update the UI too often and potentially confuse screen reader (and possibly other) users:</p> + +<pre class="brush: js notranslate">form.onsubmit = validate; + +function validate(e) { + errorList.innerHTML = ''; + for(var i = 0; i < formItems.length; i++) { + var testItem = formItems[i]; + if(testItem.input.value === '') { + errorField.style.left = '360px'; + createLink(testItem); + } + } + + if(errorList.innerHTML !== '') { + e.preventDefault(); + } +}</pre> + +<div class="note"> +<p><strong>Note</strong>: In this example, we are hiding and showing the error message box using absolute positioning rather than another method such as visibility or display, because it doesn't interfere with the screen reader being able to read content from it.</p> +</div> + +<p>Real form validation would be much more complex than this — you'd want to check that the entered name actually looks like a name, the entered age is actually a number and is realistic (e.g. not a minus number, or four digits). Here we've just implemented a simple check that a value has been filled in to each input field (<code>if(testItem.input.value === '')</code>).</p> + +<p>When the validation has been performed, if the tests pass then the form is submitted. If there are errors (<code>if(errorList.innerHTML !== '')</code>) then we stop the form submitting (using <code><a href="/en-US/docs/Web/API/Event/preventDefault">preventDefault()</a></code>), and display any error messages that have been created (see below). This mechanism means that the errors will only be shown if there are errors, which is better for usability.</p> + +<p>For each input that doesn't have a value filled in when the form is submitted, we create a list item with a link and insert it in the <code>errorList</code>.</p> + +<pre class="brush: js notranslate">function createLink(testItem) { + var listItem = document.createElement('li'); + var anchor = document.createElement('a'); + anchor.textContent = testItem.input.name + ' field is empty: fill in your ' + testItem.input.name + '.'; + anchor.href = '#' + testItem.input.name; + anchor.onclick = function() { + testItem.input.focus(); + }; + listItem.appendChild(anchor); + errorList.appendChild(listItem); +}</pre> + +<p>Each link serves a dual purpose — it tells you what the error is, plus you can click on it/activate it to jump straight to the input element in question and correct your entry.</p> + +<div class="note"> +<p><strong>Note</strong>: The <code>focus()</code> part of this example is a bit tricky. Chrome and Edge (and newer versions of IE) will focus the element when the link is clicked, without needing the <code>onclick</code>/<code>focus()</code> block. Safari will only highlight the form element with the link on its own, so needs the <code>onclick</code>/<code>focus()</code> block to actually focus it. Firefox doesn't focus the inputs properly at all in this context, so Firefox users can't take advantage of this at present (although everything else works fine). The Firefox issue should be fixed soon — work is being done to give Firefox behaviour parity with other browsers (see {{bug(277178)}}).</p> +</div> + +<p>In addition, the <code>errorField</code> is placed at the top of the source order (although it is positioned differently in the UI using CSS), meaning that users can find out exactly what's wrong with their form submissions and get to the input elements in question by going back up to the start of the page.</p> + +<p>As a final note, we have used some WAI-ARIA attributes in our demo to help solve accessibility problems caused by areas of content constantly updating without a page reload (screen readers won't pick this up or alert users to it by default):</p> + +<pre class="notranslate"><div class="errors" role="alert" aria-relevant="all"> + <ul> + </ul> +</div></pre> + +<p>We will explain these attributes in our next article, which covers <a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> in much more detail.</p> + +<div class="note"> +<p><strong>Note</strong>: Some of you will probably be thinking about that fact that HTML5 forms have built-in validation mechanisms like the <code>required</code>, <code>min</code>/<code>minlength</code>, and <code>max</code>/<code>maxlength</code> attributes (see the {{htmlelement("input")}} element reference for more information). We didn't end up using these in the demo because cross-browser support for them is patchy (for example IE10 and above only, no Safari support).</p> +</div> + +<div class="note"> +<p><strong>Note</strong>: WebAIM's <a href="http://webaim.org/techniques/formvalidation/">Usable and Accessible Form Validation and Error Recovery</a> provides some further useful information about accessible form validation.</p> +</div> + +<h3 id="Other_JavaScript_accessibility_concerns">Other JavaScript accessibility concerns</h3> + +<p>There are other things to be aware of when implementing JavaScript and thinking about accessibility. We will add more as we find them.</p> + +<h4 id="mouse-specific_events">mouse-specific events</h4> + +<p>As you will be aware, most user interactions are implemented in client-side JavaScript using event handlers, which allow us to run functions in response to certain events happening. Some events can have accessibility issues. The main example you'll come across is mouse-specific events like <a href="/en-US/docs/Web/Events/mouseover">mouseover</a>, <a href="/en-US/docs/Web/Events/mouseout">mouseout</a>, <a href="/en-US/docs/Web/Events/dblclick">dblclick</a>, etc. Functionality that runs in response to these events will not be accessible using other mechanisms, like keyboard controls.</p> + +<p>To mitigate such problems, you should double up these events with similar events that can be activated by other means (so-called device-independent event handlers) — <a href="/en-US/docs/Web/Events/focus">focus</a> and <a href="/en-US/docs/Web/Events/blur">blur</a> would provide accessibility for keyboard users.</p> + +<p>Let's look at an example that highlights when this could be useful. Maybe we want to provide a thumbnail image that shows a larger version of the image when it is moused over or focused (like you'd see on an e-commerce product catalog.)</p> + +<p>We've made a very simple example, which you can find at <a href="http://mdn.github.io/learning-area/accessibility/css/mouse-and-keyboard-events.html">mouse-and-keyboard-events.html</a> (see also the <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/mouse-and-keyboard-events.html">source code</a>). The code features two functions that show and hide the zoomed-in image; these are run by the following lines that set them as event handlers:</p> + +<pre class="brush: js notranslate">imgThumb.onmouseover = showImg; +imgThumb.onmouseout = hideImg; + +imgThumb.onfocus = showImg; +imgThumb.onblur = hideImg;</pre> + +<p>The first two lines run the functions when the mouse pointer hovers over and stops hovering over the thumbnail, respectively. This won't allow us to access the zoomed view by keyboard though — to allow that, we've included the last two lines, which run the functions when the image is focused and blurred (when focus stops). This can be done by tabbing over the image, because we've included <code>tabindex="0"</code> on it.</p> + +<p>The <a href="/en-US/docs/Web/Events/click">click</a> event is interesting — it sounds mouse-dependent, but most browsers will activate <a href="/en-US/docs/Web/API/GlobalEventHandlers/onclick">onclick</a> event handlers after Enter/Return is pressed on a link or form element that has focus, or when such an element is tapped on a touchscreen device. This doesn't work by default however when you allow a non-default-focusable event to have focus using tabindex — in such cases you need to detect specifically when that exact key is pressed (see <a href="/en-US/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a>).</p> + +<h2 id="Summary">Summary</h2> + +<p>We hope this article has given you a good amount of detail and understanding about the accessibility issues surrounding CSS and JavaScript use on web pages.</p> + +<p>Next up, WAI-ARIA!</p> + +<div>{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}}</div> + +<div> +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> +</div> diff --git a/files/ru/learn/accessibility/html/index.html b/files/ru/learn/accessibility/html/index.html new file mode 100644 index 0000000000..75e886aa79 --- /dev/null +++ b/files/ru/learn/accessibility/html/index.html @@ -0,0 +1,538 @@ +--- +title: 'HTML: Хорошая основа для доступности' +slug: Learn/Accessibility/HTML +tags: + - HTML + - a11y + - Клавиатура + - Кнопки + - Начинающий + - Семантика + - Ссылки + - Формы + - вспомагательные технологии + - доступность +translation_of: Learn/Accessibility/HTML +original_slug: Learn/Доступность/HTML +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</div> + +<p class="summary">Большая часть содержимого интернета может быть сделана доступной просто благодаря использованию правильных HTML элементов по назначению. В этой статье подробно рассмотрено как HTML может быть использован для обеспечения максимальной доступности.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Необходимые знания:</th> + <td>Базовая компьютерная грамотность, базовое понимание HTML (смотрите <a href="/ru/docs/Learn/HTML/Введение_в_HTML">Введение в HTML</a>), и понимания, <a href="/ru/docs/Learn/Доступность/What_is_accessibility">что такое доступность</a>.</td> + </tr> + <tr> + <th scope="row">Цель:</th> + <td> + <p>Познакомиться с тем, какие особенности HTML способствуют доступности, и как использовать их на ваших веб-страницах должным образом.</p> + </td> + </tr> + </tbody> +</table> + +<h2 id="HTML_и_доступность">HTML и доступность</h2> + +<p>По мере изучения HTML: чтения статей, просмотра примеров и т.д., вы заметите одну общую тему — важность использования семантического HTML (иногда называемого POSH (Plain Old Semantic HTML), или «старый добрый семантический HTML»). Это означает использование HTML элементов по назначению насколько это возможно.</p> + +<p>Вы спросите, почему это так важно? В конце концов, можно использовать комбинацию CSS и JavaScript, чтобы заставить почти любой HTML элемент вести себя так, как вы захотите. Например, кнопка для воспроизведения видео на вашем сайте может быть обозначена вот так:</p> + +<pre class="brush: html"><div>Воспроизвести видео</div></pre> + +<p>Но, как вы увидите далее, в данном случае намного логичнее использовать правильный элемент:</p> + +<pre class="brush: html"><button>Воспроизвести видео</button></pre> + +<p>HTML элементы <code><button></code> не только имеют соответствующие кнопке стили по-умолчанию (которые вы скорее всего захотите переписать), они также имеют встроенную доступность с клавиатуры: между ними можно передвигаться с помощью кнопки <kbd>Tab</kbd> и активировать, используя <kbd>Enter</kbd>.</p> + +<p>Вёрстка с помощью семантического HTML не займёт больше времени, чем с помощью не семантического (плохого) HTML, если делать это последовательно с самого начала проекта, и это также имеет другие преимущества помимо доступности:</p> + +<ol> + <li><strong>Легче разрабатывать</strong> — как сказано выше, вы получаете функционал «из коробки», плюс проще для восприятия.</li> + <li><strong>Лучше для мобильных</strong> — семантический HTML легче по размеру, чем не семантический спаггети-код, и его легче сделать адаптивным.</li> + <li><strong>Хорошо для SEO</strong> — поисковики уделяют больше внимания ключевым словам внутри заголовков, ссылок и т.д., чем ключевым словам, помещённым в не семантический <code><div></code> и т.д., поэтому клиентам будет проще найти ваш сайт.</li> +</ol> + +<p>Давайте рассмотрим доступный HTML более детально.</p> + +<div class="note"> +<p><strong>Примечание</strong>: Желательно, чтобы у вас был установлен скринридер, чтобы вы могли тестировать примеры, приведённые ниже. Посмотрите наше <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">Руководство по скринридерам</a> для более подробной информации.</p> +</div> + +<h2 id="Хорошая_семантика">Хорошая семантика</h2> + +<p>Мы уже говорили о важности хорошей семантики, и почему нам стоит использовать HTML элементы по назначению. Это нельзя игнорировать, поскольку это одно из основных мест, где ломается доступность из-за плохой семантики, если должным образом не уделять внимания.</p> + +<p>В интернете люди делают очень странные вещи с HTML разметкой. Некоторые злоупотребляют HTML, используя устаревшие практики, которые не были полностью забыты, а некоторые просто не знают. В любом случае, вам стоит заменить по возможности плохой код, где бы вы его не увидели.</p> + +<p>У вас не всегда есть возможность избавиться от плохой вёрстки: ваши страницы могут быть сгенерированы каким-нибудь фреймворком на стороне сервера, над которым у вас нет полного контроля, или на страницах есть сторонний контент (такой как рекламные баннеры), которые вы также не контролируете.</p> + +<p>Цель не «всё или ничего», однако — каждое улучшение, которое вам под силу сделать, поможет обеспечить доступность.</p> + +<h3 id="Текстовый_контент">Текстовый контент</h3> + +<p>Одно из самых лучших вспомогательных средств доступности для пользователя скринридера — хорошая структура заголовков, параграфов, список и т.д. Пример хорошей семантики может выглядеть так:</p> + +<pre class="brush: html example-good line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h1</span><span class="punctuation token">></span></span>Мой заголовок<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h1</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">>Это первый раздел моей страницы.</span></span><span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">>Я добавлю ещё один параграф тут.</span></span><span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">> + +<ol> + <li>Это</li> + <li>список для</li> + <li>чтения</li> +</ol></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">></span></span>Мой подзаголовок<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>Это первый подраздел моей страницы. Я бы хотела, чтобы люди могли найти этот контент!<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>h2</span><span class="punctuation token">>Мой второй подзаголовок</</span></span><span class="tag token"><span class="tag token">h2</span><span class="punctuation token">></span></span> + +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>p</span><span class="punctuation token">></span></span>Это второй подраздел. Думаю, он намного интереснее, чем предыдущий.<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>p</span><span class="punctuation token">></span></span></code></pre> + +<p>Мы подготовили версию с длинными текстом, чтобы вы попробовали со скринридером (смотрите <a href="http://mdn.github.io/learning-area/accessibility/html/good-semantics.html">good-semantics.html</a>). Если вы попробуете поперемещаться, то увидите, как легко ориентироваться на странице:</p> + +<ol> + <li>Скринридер озвучивает каждый заголовок по мере перемещения, оповещая вас, что является заголовком, а что параграфом. </li> + <li>Он останавливается после каждого элемента, позволяя вам переместиться в любое другое место, которое вам надо.</li> + <li>Во многих скринридерах Вы можете перемещаться к следующему/предыдущему заголовкам.</li> + <li>Во многих скринридерах Вы также можете вызвать список всех заголовков, который можно использовать как содержание, чтобы найти определённую информацию. </li> +</ol> + +<p>Иногда люди используют презентационные элементы HTML и перенос строки, чтобы написать заголовки или параграфы:</p> + +<pre class="brush: html example-bad line-numbers language-html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>7<span class="punctuation token">"</span></span><span class="punctuation token">>Мой заголовок</span></span><span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="punctuation token">Это первый раздел моей страницы.</span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="punctuation token">Я добавлю ещё один параграф тут.</span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +1. Это +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +2. список для +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">> +3. чтения +</span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">>Мой подзаголовок</span></span><span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +Это первый подраздел моей страницы. Я бы хотела, чтобы люди могли найти этот контент! +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>font</span> <span class="attr-name token">size</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>5<span class="punctuation token">"</span></span><span class="punctuation token">>Мой второй подзаголовок</span></span><span class="tag token"><span class="tag token"><span class="punctuation token"></</span>font</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>br</span><span class="punctuation token">></span></span> +Это второй подраздел. Думаю, он намного интереснее, чем предыдущий.</code></pre> + +<p>Если вы попробуете полную версию с помощью скринридера (смотрите <a href="http://mdn.github.io/learning-area/accessibility/html/bad-semantics.html">bad-semantics.html</a>), вам не слишком это понравится: скринридеру нечего использовать как ориентир, поэтому вы не сможете получить содержание, а вся страница для скринридера — это один большой блок, поэтому он озвучит всё за один раз, без остановок. </p> + +<p>Есть и другие проблемы, помимо доступности — сложнее стилизовать контент, используя CSS, или манипулировать им с помощью JavaScript, например, потому что там нет элементов, которые можно использовать как селекторы.</p> + +<h4 id="Использование_понятного_языка">Использование понятного языка</h4> + +<p>Язык, который вы используете, также может влиять на доступность. В целом, лучше использовать понятный язык, который не слишком сложный, и который не использует ненужные жаргоны и сленг. Это помогает не только людям с когнитивными или другими нарушениями, но и читателям, для которых текст написан не на родном языке, молодым людям... на самом деле всем! Кроме этого, стоит избегать использование языка и символов, которые не могут быть чётко озвучено скринридером. Например:</p> + +<ul> + <li>Не используйте тире, если можете избежать этого. Вместо «5-7», напишите «от 5 до 7».</li> + <li>Не пишите сокращения: вместо «Янв» пишите «Январь».</li> + <li>Расшифровывайте аббревиатуры, как минимум один или два раза. Вместо «HTML» при первом употреблении, пишите «Hypertext Markup Language».</li> +</ul> + +<h3 id="Вёрстка">Вёрстка</h3> + +<p>В старые недобрые времена, люди верстали с помощью HTML-таблиц: использовали различные табличные ячейки для размещения шапки, подвала, боковую панель, колонку с основным контентом и т.д. Это плохая идея, потому что скринридер, скорее всего, выдаст непонятную озвучку, особенно, если раскладка сложная и имеет много вложенных таблиц.</p> + +<p>Посмотрите пример табличной вёрстки, открыв <a href="http://mdn.github.io/learning-area/accessibility/html/table-layout.html">table-layout.html</a>, которая выглядит примерно так:</p> + +<pre class="brush: html"><table width="1200"> + <!-- main heading row --> + <tr id="heading"> + <td colspan="6"> + + <h1 align="center">Шапка</h1> + + </td> + </tr> + <!-- nav menu row --> + <tr id="nav" bgcolor="#ffffff"> + <td width="200"> + <a href="#" align="center">Главная</a> + </td> + <td width="200"> + <a href="#" align="center">Наша команда</a> + </td> + <td width="200"> + <a href="#" align="center">Проекты</a> + </td> + <td width="200"> + <a href="#" align="center">Контакты</a> + </td> + <td width="300"> + <form width="300"> + <input type="search" name="q" placeholder="Поиск" width="300"> + </form> + </td> + <td width="100"> + <button width="100">Вперёд!</button> + </td> + </tr> + <!-- spacer row --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- main content and aside row --> + <tr id="main"> + <td id="content" colspan="4" bgcolor="#ffffff"> + + <!-- основной контент --> + </td> + <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top"> + <h2>Связанный контент</h2> + + <!-- второстепенный контент --> + + </td> + </tr> + <!-- spacer row --> + <tr id="spacer" height="10"> + <td> + + </td> + </tr> + <!-- footer row --> + <tr id="footer" bgcolor="#ffffff"> + <td colspan="6"> + <p>© 2050 никто. Все права защищены.</p> + </td> + </tr> + </table></pre> + +<p>Если вы попробуете поперемещаться с помощью скринридера, вероятно, он скажет вам, что перед вами таблица (хотя некоторые скринридеры могу различать табличную вёрстку от таблиц данных). После этого, скорее всего (в зависимости от того, какой скринридер вы используете), вам придётся переместиться в таблицу как в объект, посмотрев каждый элемент по отдельности, затем выйти из таблицы, чтобы продолжить перемещение по контенту.</p> + +<p>Табличная вёрстка — пережиток прошлого, который имел смысл, когда поддержка CSS не была сильно распространена среди браузеров, но она создаёт путаницу среди пользователей скринридеров, и плоха по многим другим причинам (злоупотребление таблицами, пожалуй, требует больше разметки, делает дизайн менее гибким). Не делайте так!</p> + +<p>Вы можете проверить эти утверждения, сравнив предыдущий опыт с <a href="http://mdn.github.io/learning-area/html/introduction-to-html/document_and_website_structure/">более современной структурой веб-сайта</a>, которая выглядит так:</p> + +<pre class="brush: html"><header> + <h1>Шапка</h1> +</header> + +<nav> + <!-- основная навигация --> +</nav> + +<!-- Основной контент нашей страницы --> +<main> + + <!-- На ней есть статьи --> + <article> + <h2>Заголовок статьи</h2> + + <!-- сама статья --> + </article> + + <aside> + <h2>Связанный контент</h2> + + <!-- второстепенный контент --> + </aside> + +</main> + +<!-- А здесь наш основной подвал, который используется на всех страницах нашего сайта --> + +<footer> + <!-- здесь содержимое подвала --> +</footer></pre> + +<p>Если вы попробуете нашу более современную структуру с помощью скринридера, вы увидите, что разметка больше не сбивает с толку скринридер. Она также более компактная с точки зрения размера кода, что означает, его легче поддерживать, а пользователям меньше скачивать (особенно для тех, у кого медленный интенет).</p> + +<p>На что ещё стоит обратить внимание при вёрстке — это использование семантических HTML5 элементов, которые можно увидеть в примере выше (смотрите <a href="/ru/docs/Web/HTML/Element#Секционирование_содержания">секционирование содержания)</a>: вы можно верстать, используя только вложенные {{htmlelement("div")}} элементы, но лучше использовать соответствующие секционные элементы, чтобы обернуть вашу основную навигацию ({{htmlelement("nav")}}), футер ({{htmlelement("footer")}}), повторяющийся контент ({{htmlelement("article")}}) и т.д. Эти элементы предоставляют дополнительную семантику для скринридеров (и других инструментов), чтобы давать пользователю дополнительную информацию о контенте, по которому они перемещаются (смотрите статью <a href="http://www.weba11y.com/blog/2016/04/22/screen-reader-support-for-new-html5-section-elements/">Screen Reader Support for new HTML5 Section Elements</a> для представления поддержки этих элементов с помощью скринридеров).</p> + +<div class="note"> +<p><strong>Примечание</strong>: Помимо того, что ваш контент имеет семантическую и красивую разметку, он должен иметь логический порядок в его исходном коде — позже вы всегда можете разместить элементы там, где хотите, с помощью CSS, но располагать элементы в правильном порядке нужно в самом начале, чтобы то, что зачитывает пользователям скринридер, имело смысл.</p> +</div> + +<h3 id="Элементы_интерфейса">Элементы интерфейса</h3> + +<p>Под элементами интерфейса мы подразумеваем основные элементы веб-страниц, с которыми взаимодействует пользователь, в основном это кнопки, ссылки и элементы форм. В этом разделе мы рассмотрим основные проблемы доступности, которые стоит учитывать при создании таких элементов. В следующих статьях про WAI-ARIA и мультимедиа мы рассмотрим другие аспекты доступности пользовательского интерфейса.</p> + +<p>Одним из ключевых аспектов доступуности элементов интерфейса является то, что браузеры по-умолчанию позволяют управлять ими с помощью клавиатуры. Вы можете проверить это, открыв в новой вкладке <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">native-keyboard-accessibility.html </a>(смотрите <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/native-keyboard-accessibility.html">исходный код</a>). Попробуйте понажимать клавишу <kbd>Tab</kbd>, после нескольких нажатий вы заметите, что фокус перемещается по всем фокусируемым элементам. Сфокусированные элеметы подсвечиваются браузерными стилями по-умолчанию (в зависимости от браузера они немного разные), чтобы можно было понять, какой элемент в фокусе.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14215/button-focused-unfocused.png" style="border-style: solid; border-width: 1px; display: block; height: 39px; margin: 0px auto; width: 288px;"></p> + +<p>Вы можете нажать <kbd>Enter</kbd>, чтобы перейти по сфокусированной ссылке или нажать кнопку (мы добавили немного JavaScript, чтобы кнопки выводили окно с сообщением), или начать печатать в текстовом поле (другие элементы формы имеют разное управление, например, у элемента {{htmlelement("select")}} можно отобразить опции и переключаться между ними, используя клавиши-стрелки вверх и вниз).</p> + +<div class="note"> +<p><strong>Примечание</strong>: Различные браузеры могут иметь разное управление с клавиатуры. Для более подробной информации смотрите <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Using native keyboard accessibility.</a></p> +</div> + +<p>Такое поведение вы получаете сразу по-умолчанию, просто используя правильные элементы, например:</p> + +<pre class="brush: html example-good"><h1>Ссылки</h1> + +<p>Это ссылка ведёт на сайт <a href="https://www.mozilla.org">Mozilla</a>.</p> + +<p>Другая ссылка на <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p> + +<h2>Кнопки</h2> + +<p> + <button data-message="Это из первой кнопки">Нажми меня!</button> + <button data-message="Это из второй кнопки">Меня тоже нажми!</button> + <button data-message="Это из третьей кнопки">И меня!</button> +</p> + +<h2>Форма</h2> + +<form> + <div> + <label for="name">Укажите ваше имя:</label> + <input type="text" id="name" name="name"> + </div> + <div> + <label for="age">Укажите ваш возраст:</label> + <input type="text" id="age" name="age"> + </div> + <div> + <label for="mood">Выберите ваше настроение:</label> + <select id="mood" name="mood"> + <option>Счастливый</option> + <option>Грустный</option> + <option>Злой</option> + <option>Обеспокоенный</option> + </select> + </div> +</form></pre> + +<p>Это предполагает использование соответствующим образом ссылок, кнопок, элементов форм и меток (включая элемент {{htmlelement("label")}} для элементов форм).</p> + +<p>Однако, опять же, люди иногда делают странные вещи с HTML. Например, иногда вы видите кнопки, размеченные с помощью элемента {{htmlelement("div")}}:</p> + +<pre class="brush: html example-bad"><div data-message="Это из первой кнопки">Нажми меня!</div> +<div data-message="Это из второй кнопки">Меня тоже нажми!</div> +<div data-message="Это из третьей кнопки">И меня!</div></pre> + +<p>Такой код не советуется использовать: вы сразу же теряете нативную доступность с клавиатуры, которая у вас была бы, если просто использовать элемент {{htmlelement("button")}}, к тому же {{htmlelement("div")}} по-умолчанию не имеет кнопочных стилей.</p> + +<h4 id="Добавление_доступности_с_клавиатуры">Добавление доступности с клавиатуры</h4> + +<p>Для добавления доступности с клавиатуры несоответствующим элементам придётся немного поработать (вы можете посмотреть пример, открыв <a class="external external-icon" href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a>, а также <a class="external external-icon" href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">исходный код</a>). Мы дали нашим поддельным <code><div></code>-кнопкам возможность фокусироваться (в том числе через <kbd>Tab</kbd>), указав аттрибут <code>tabindex="0"</code>:</p> + +<pre class="brush: html"><div data-message="Это из первой кнопки" tabindex="0">Кликни меня!</div> +<div data-message="Это из второй кнопки" tabindex="0">Меня тоже кликни!</div> +<div data-message="Это из третьей кнопки" tabindex="0">И меня!</div></pre> + +<p>Аттрибут {{htmlattrxref("tabindex")}} в первую очередь предназначен для того, чтобы менять порядок фокусируемых элементов в последовательной навигации (указанный в виде положительного целого числа). Это почти всегда — плохая идея, которая может вызвать большую путаницу. Используйте его, если он правда необходим, например, если визуальный порядок сильно отличается от исходного, и вы хотите более логичную последовательную навигацию. Есть два варианта значений <code>tabindex</code>:</p> + +<ul> + <li><code>tabindex="0"</code> — как указано выше, это значение позовляет элементу быть выделеным и достигнутым с помощью последовательной навигации. Это самое полезное значение <code>tabindex</code>.</li> + <li><code>tabindex="-1"</code> — позволяет элементам, которые обычно не принимают фокусное выделение, получать его программно, например, с помощью JavaScript, или как цель якорной ссылки.</li> +</ul> + +<p>Хотя дополнение, которые мы сделали, позволяет нам перемещаться по кнопкам с помощью <kbd>Tab</kbd>, оно не позволяет нам активировать их кнопкой <kbd>Enter</kbd>. Для этого нам необходимо добавить хитрый кусочек JavaScript:</p> + +<pre class="brush: js line-numbers language-js"><code class="language-js">document<span class="punctuation token">.</span>onkeydown <span class="operator token">=</span> <span class="keyword token">function</span><span class="punctuation token">(</span>e<span class="punctuation token">)</span> <span class="punctuation token">{</span> + <span class="keyword token">if</span><span class="punctuation token">(</span>e<span class="punctuation token">.</span>keyCode <span class="operator token">===</span> <span class="number token">13</span><span class="punctuation token">)</span> <span class="punctuation token">{</span> <span class="comment token">// Кнопка Enter</span> + document<span class="punctuation token">.</span>activeElement<span class="punctuation token">.</span><span class="function token">click</span><span class="punctuation token">(</span><span class="punctuation token">)</span><span class="punctuation token">;</span> + <span class="punctuation token">}</span> +<span class="punctuation token">}</span><span class="punctuation token">;</span></code></pre> + +<p>Мы навешиваем обработчик событий на <code>document</code> для обнаружения нажатий с клавиатуры. Далее, через свойство объекта события <code><a href="/ru/docs/Web/API/KeyboardEvent/keyCode">keyCode</a></code>, проверяем, какая кнопка была нажата. Если код клавиши совпадает с кодом клавиши <kbd>Enter</kbd>, мы выполняем функцию, которая хранится в обработчике кнопки <code>onclick</code>, используя <code>document.activeElement.click().</code> <code><a href="/ru/docs/Web/API/Document/activeElement">activeElement</a></code> возвращает текущий сфокусированный элемент.</p> + +<p>Слишком много дополнительной мороки с добавлением такой функциональности. И обязательно будут ещё проблемы. <strong>Лучше просто сразу использовать правильные элементы по назначению.</strong></p> + +<h4 id="Содержательные_текстовые_метки">Содержательные текстовые метки</h4> + +<p>Текстовые метки (описания) для элементов интерфейса полезны всем пользователям, но их правильное описание — особенно важно для пользователей с ограниченными способностями.</p> + +<p>Вы должны следить за тем, чтобы кнопки и ссылки имели понятные и уникальные текстовые описания. Не используйте фразу «Кликните здесь», потому что пользователи скринридеров иногда вызывают список кнопок и элементов форм. В примере ниже можно увидеть такой список, вызванный из VoiceOver на Mac.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14335/voiceover-formcontrols.png" style="display: block; height: 604px; margin: 0px auto; width: 802px;"></p> + +<p>Удостоверьтесь, что описания вне контекста имеют смысл, так же как и в контексте параграфа, в котором они содержаться. Например, вот хороший текст для ссылки:</p> + +<pre class="brush: html example-good"><p>Киты очень классные существа. <a href="whales.html">Узнай больше о китах</a>.</p></pre> + +<p>а это плохой текст для ссылки:</p> + +<pre class="brush: html example-bad"><p>Киты очень классные существа. Чтобы узнать больше о китах, <a href="whales.html">нажмите здесь</a>.</p></pre> + +<div class="note"> +<p><strong>Примечание: </strong>Более подробно о создании ссылок и лучших практиках можно почитать в статье «<a href="/ru/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks">Создание ссылок</a>». Также посмотреть на примеры хороших и плохих ссылок можно на <a class="external external-icon" href="http://mdn.github.io/learning-area/accessibility/html/good-links.html">good-links.html</a> и <a class="external external-icon" href="http://mdn.github.io/learning-area/accessibility/html/bad-links.html">bad-links.html</a>. </p> +</div> + +<p>Описания форм также важны для понимания, что нужно вводить в каждое текстовое поле. Следующий пример кажется достаточно разумным:</p> + +<pre class="brush: html example-bad">Укажите ваше имя: <input type="text" id="name" name="name"></pre> + +<p>Однако, это не совсем удобно для пользователей с ограниченными возможностями. В примере нет ничего, что могло бы однозначно связать описание текстового поля с самим текстовым полем, и чётко указать, как его заполнить, если вы не можете видеть. Если бы вы воспользовались скринридером, скорее всего он озвучил описание примерно как «редактировать текст».</p> + +<p>Следующий пример намного лучше:</p> + +<pre class="brush: html example-good"><div> + <label for="name">Укажите ваше имя:</label> + <input type="text" id="name" name="name"> +</div></pre> + +<p>С такой разметкой описание будет явно связано с текстовым полем, и будет звучать как «Укажите ваше имя: редактировать текст».</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14337/voiceover-good-form-label.png" style="display: block; margin: 0 auto;"></p> + +<p>Как бонус, в большинстве браузеров привязка описания к полю ввода означает, что вы можете щелкнуть по описанию, чтобы выбрать/активировать элемент формы. Это облегчает нажатие на элемент формы из-за увеличенной зоны нажатия.</p> + +<div class="note"> +<p><strong>Примечание</strong>: Посмотреть на хорошие и плохие пример форм можно на <a href="http://mdn.github.io/learning-area/accessibility/html/good-form.html">good-form.html</a> и <a href="http://mdn.github.io/learning-area/accessibility/html/bad-form.html">bad-form.html</a>.</p> +</div> + +<h2 id="Доступные_таблицы">Доступные таблицы</h2> + +<p>Обычные таблицы с данными можно сверстать очень простой разметкой, например:</p> + +<pre class="brush: html"><table> + <tr> + <td>Имя</td> + <td>Возраст</td> + <td>Пол</td> + </tr> + <tr> + <td>Гавриил</td> + <td>13</td> + <td>Мужской</td> + </tr> + <tr> + <td>Эвелина</td> + <td>8</td> + <td>Женский</td> + </tr> + <tr> + <td>Фрида</td> + <td>5</td> + <td>Женский</td> + </tr> +</table></pre> + +<p>Но есть проблемы — пользователи скринридера никак не смогут связать вместе строки или столбцы в группу данных. Чтобы это сделать, нужно знать какие из строк являются заголовками, и озаглавливают ли они строки, столбцы и т.д. Для таблицы выше это можно определить только визуально (попробуйте сами на примере, открыв <a href="http://mdn.github.io/learning-area/accessibility/html/bad-table.html">bad-table.html</a>).</p> + +<p>Теперь посмотрим на <a href="https://github.com/mdn/learning-area/blob/master/css/styling-boxes/styling-tables/punk-bands-complete.html">пример таблицы с панк-группами</a>, где можно увидеть несколько вспомогательных средств:</p> + +<ul> + <li>Заголовки таблиц определены, используя элементы {{htmlelement("th")}}; можно также указать являются ли они заголовками для строк или столбцов с помощью аттрибута <code>scope</code>. Это даёт нам полные группы данных, которые скринридер обработает как отдельные блоки.</li> + <li>Элемент {{htmlelement("caption")}} и аттрибут <code>summary</code> у элемента {{htmlelement("table")}} выполняют похожую работу — они выступают в качестве альтернативного текста для таблицы, предоставляя пользователям скринридера краткое содержание. Элемент <code><caption></code> обычно предпочтительнее, так как контент становится доступнее и для зрячих пользователей, которые могут посчитать это полезным. На самом деле необязательно ни то, ни другое.</li> +</ul> + +<div class="note"> +<p><strong>Примечание</strong>: Более подробную информацию о доступных таблицах можно узнать в статье <a href="/ru/docs//ru/docs/Learn/HTML/Tables/Advanced">HTML-таблицы: продвинутые возможности и доступность</a>.</p> +</div> + +<h2 id="Альтернативный_текст">Альтернативный текст</h2> + +<p>В то время как текстовый контент доступен по-умолчанию, этого нельзя сказать о мультимедийном контенте — изображения/видео-контент не может быть просмотрен людьми с нарушениями зрения, а аудио контент не может быть услышан людьми с нарушениями слуха. Мы подробно рассмотрим видео и аудио контент в статье о доступности мультимедиа позже, но в этой статье мы рассмотрим доступность для простого элемента {{htmlelement("img")}}.</p> + +<p>У нас есть простой пример, <a href="http://mdn.github.io/learning-area/accessibility/html/accessible-image.html">accessible-image.html</a>, который содержит четыре копии одного и того же изображения:</p> + +<pre><img src="dinosaur.png"> + +<img src="dinosaur.png" + alt="Красный тираннозавр Рекс: стоящий как человек двуногий динозавр, с маленькими передними лапами и большой головой с большим количеством острых зубов."> + +<img src="dinosaur.png" + alt="Красный тираннозавр Рекс: стоящий как человек двуногий динозавр, с маленькими передними лапами и большой головой с большим количеством острых зубов." + title="Красный динозавр Mozilla"> + + +<img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">Красный тираннозавр Рекс Mozilla: стоящий как человек двуногий динозавр, с маленькими передними лапами и большой головой с большим количеством острых зубов.</p> +</pre> + +<p>Первое изображение, когда оно просматривается программой чтения с экрана, не очень помогает пользователю — например, VoiceOver озвучивает его как «/dinosaur.png, image». Он озвучивает имя файла, чтобы попытаться помочь. В этом примере пользователь, по крайней мере, будет знать, что это какой-то динозавр, но часто файлы могут загружаться с программно-генерируемыми именами (например, с цифровой камеры), и эти имена файлов, скорее всего, не обеспечат контекста для содержимого изображения.</p> + +<div class="note"> +<p><strong>Примечание</strong>: Вот почему вы никогда не должны включать текстовое содержимое в изображение — скринридеры просто не могут получить к нему доступ.Есть и другие недостатки — вы не можете выбрать его и скопировать/вставить. Просто не делайте этого!</p> +</div> + +<p>Когда скринридер встретит второе изображение, он озвучит аттрибут <code>alt</code> полностью: «Красный тираннозавр Рекс: стоящий как человек двуногий динозавр, с маленькими передними лапами и большой головой с большим количеством острых зубов».</p> + +<p>Это подчёркивает важность не только использования содержательных файловых имён в случаях отсутствия, так называемого, <strong>альтернативного текста</strong>, но также важность предоставления альтернативного текста в аттрибуте <code>alt</code>, где это возможно. Заметьте, что содержание аттрибута <code>alt</code> должно всегда предоставлять прямое представление изображения и то, что оно визуально передаёт. Любые личные знания или дополнительное описание не должны быть включены, так как это не принесёт пользы людям, которые не видели изображение ранее.</p> + +<p>Также стоит учитывать, имеют ли изображения значение внутри вашего контента, или они исключительно для украшения без смысла. Если они декоративные, лучше оставить значение аттрибута <code>alt</code> пустым (смотрите «<a href="#Пустые_аттрибуты_alt">Пустые аттрибуты alt</a>») или просто вставить их как фон с помощью CSS.</p> + +<div class="note"> +<p><strong>Примечание</strong>: Для более подробной информации об изображениях и лучших практиках читайте «<a href="/ru/docs/Learn/HTML/Multimedia_and_embedding/Изображения_в_HTML">Изображения в HTML»</a> и «<a href="/ru/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Адаптивные изображения</a>».</p> +</div> + +<p>Если вы всё же хотите предоставить дополнительную контекстуальную информацию, поместите её в тексте рядом с изображением или внутри аттрибута <code>title</code>, как показано ниже. В этом случае большинство скринридеров озвучат альтернативный текст, аттрибут <code>title</code> и имя файла. Дополнительно, при наведении мышкой браузеры отобразят текст из аттрибута <code>title</code> как всплывающую подсказку.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14333/title-attribute.png" style="display: block; margin: 0 auto;"></p> + +<p>Давайте взглянем на четвёртый способ:</p> + +<pre class="brush: html"><img src="dinosaur.png" aria-labelledby="dino-label"> + +<p id="dino-label">Красный тираннозавр Mozilla ... </p></pre> + +<p>В этом случае мы вообще не используем аттрибут <code>alt</code>. Вместо этого мы представили наше описание изображения как обычный параграф, указали <code>id</code>, и потом использовали аттрибут <code>aria-labelledby</code>, сославшись на тот <code>id</code>. Это вынуждает скринридеры использовать параграф как альтернативный текст/описание изображения. Это особенно удобно, если вы хотите использовать один текст как описание для нескольких изображений, что невозомжно с помощью аттрибута <code>alt</code>.</p> + +<div class="note"> +<p><strong>Примечание</strong>: <code>aria-labelledby</code> — часть спецификации <a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a>, которая позволяет разработчиками добавлять, где требуется, дополнительную семантику разметке для улучшения доступности при использовании скринридеров. Чтобы узнать больше о том, как это работает, читайте статью <a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">«Основы WAI-ARIA».</a></p> +</div> + +<h3 id="Другие_механизмы_альтернативного_текста">Другие механизмы альтернативного текста</h3> + +<p>У изображений есть ещё один механизм для предоставления описательного текста. Например, есть аттрибут <code>longdesc</code>, который предназначен для указания отдельной веб-страницы, содержащей расширенное описание изображения:</p> + +<pre class="brush: html"><img src="dinosaur.png" longdesc="dino-info.html"></pre> + +<p>Звучит, как хорошая идея, особенно для такой инфографики как диаграммы с большим количеством информации, которую, в качестве альтернативы, можно представить в виде доступной таблицы с данными (смотрите предыдущий раздел). Однако, <code>longdesc</code> нестабильно поддерживается скринридерами, и контент полностью недоступен пользователям, которые не используют скринридеры. Пожалуй, намного лучше будет вставить длинное описание на страницу вместе с изображением, или указать обычную ссылку.</p> + +<p>HTML5 содержит два новых элемента — {{htmlelement("figure")}} и {{htmlelement("figcaption")}}, которые, как предполагается, должны связывать какую-любо фигуру (всё что угодно, необязательно изображение) с заголовком фигуры:</p> + +<pre class="brush: html"><figure> + <img src="dinosaur.png" alt="Тираннозавр организации Mozilla"> + <figcaption>Красный тираннозавр Рекс: стоящий как человек двуногий динозавр, с маленькими передними лапами и большой головой с большим количеством острых зубов.</figcaption> +</figure></pre> + +<p>К сожалению, большинство скринридеров, кажется, пока ещё не умеют связывать заголовки фигур с самими фигурами, но такая структура элементов удобна для CSS стилизации, к тому же, она предоставляет способ расположить описание рядом с изображением в исходнике.</p> + +<h3 id="Пустые_аттрибуты_alt">Пустые аттрибуты alt</h3> + +<pre class="brush: html"><h3> + <img src="article-icon.png" alt=""> + Тираннозавр Рекс: король динозвров +</h3></pre> + +<p>Бывает, что в дизайне страницы присутствуют изображения, но они исполняют декоративную роль. В примере выше вы можете заметить, что у изображения пустой аттрибут <code>alt</code> — это сделано, чтобы скринридер опознал изображение, но не стал озвучивать её описание (вместо этого, он бы озвучил её как «изображение», или аналогично).</p> + +<p>Причина, по которой стоит использовать пустой аттрибут <code>alt</code>, вместо того, чтобы просто его не указывать в том, что большинство скринридеров объявят весь URL-адрес изображения, если не указан <code>alt</code>. В пример выше изображение используется как украшение для связанного с ним заголовка. В таких случаях и случаях, когда изображение является украшением и не имеет ценное содержание, вы должны использовать пустой аттрибут <code>alt</code>. Другой вариант — использовать aria роль role="presentation". Это также предотвратит озвучивание скринридером альтернативного текста.</p> + +<div class="note"> +<p><strong>Примечание</strong>: По возможности для отображения декоративных изображений вы должны использовать CSS.</p> +</div> + +<h2 id="Заключение">Заключение</h2> + +<p>Теперь вы должны хорошо разбираться в написании доступного HTML для большинства случаев. Наша статья про основы WAI-ARIA также заполнит пробелы в знаниях, но эта статья посвящена основам. Далее мы рассмотрим CSS и JavaScript, и как хорошое или плохое их использование влияет на доступность. </p> + +<p>{{PreviousMenuNext("Learn/Accessibility/What_is_Accessibility","Learn/Accessibility/CSS_and_JavaScript", "Learn/Accessibility")}}</p> + + + +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> diff --git a/files/ru/learn/accessibility/index.html b/files/ru/learn/accessibility/index.html new file mode 100644 index 0000000000..36a072e071 --- /dev/null +++ b/files/ru/learn/accessibility/index.html @@ -0,0 +1,56 @@ +--- +title: Доступность +slug: Learn/Accessibility +tags: + - CSS + - HTML + - JavaScript + - Удобство + - доступность +translation_of: Learn/Accessibility +original_slug: Learn/Доступность +--- +<div>{{LearnSidebar}}</div> + +<p class="summary">Изучение HTML, CSS, и JavaScript полезно, если вы хотите стать веб-разработчиком, но ваши знания должны быть глубже обычного использования технологий — вы должны быть ответственны и максимизировать доступность ваших веб-приложений, не лишая никого возможности их использования. Чтобы достигнуть этого, вы можете следовать общепринятым лучшим практикам (которые демонстрируются в статьях посвященных <a href="/ru-RU/docs/Learn/HTML">HTML</a>, <a href="/ru-RU/docs/Learn/CSS">CSS</a> и <a href="/ru-RU/docs/Learn/JavaScript">JavaScript</a>), проводить <a href="/ru-RU/docs/Learn/Tools_and_testing/Cross_browser_testing">кросс-браузерное тестирование</a> и обращать внимание на доступность с самого начала. В этом модуле мы рассмотрим эту тему в деталях.</p> + +<h2 id="Прежде_чем_начать">Прежде чем начать</h2> + +<p>Чтобы разобраться с большей частью материалов этого модуля, хорошей идеей будет проходить одновременно один или несколько из модулей других тем (<a href="/ru-RU/docs/Learn/HTML">HTML</a>, <a href="/ru-RU/docs/Learn/CSS">CSS</a> или <a href="/ru-RU/docs/Learn/JavaScript">JavaScript</a>), или, что ещё лучше, пройти соответствующие части данного модуля во время изучения этих технологий.</p> + +<div class="note"> +<p><strong>Примечание</strong>: Если вы работаете на компьютере/планшете/другом устройстве, на котором у вас нет возможности создавать файлы, вы можете попробовать большую часть примеров кода в онлайн программах, таких как <a href="http://jsbin.com/">JSBin</a> или <a href="https://thimble.mozilla.org/">Thimble</a>.</p> +</div> + +<h2 id="Справочники">Справочники</h2> + +<dl> + <dt><a href="/ru/docs/Learn/Accessibility/What_is_accessibility">Что такое доступность?</a></dt> + <dd>Данная статья открывает модуль, в котором рассматривается, что такое доступность на самом деле — она включает в себя группы людей, которые нам нужно учитывать и почему, какие инструменты используют разные пользователи для взаимодействия с вебом, и как мы можем сделать доступность частью нашего рабочего процесса веб-разработки.</dd> + <dt><a href="/ru-RU/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></dt> + <dd>Большая часть содержимого интернета может быть сделана доступной просто благодаря использованию HTML элементов по назначению. В этой статье подробно рассмотрено как HTML может быть использован для обеспечения максимальной доступности.</dd> + <dt><a href="/ru-RU/docs/Learn/Accessibility/CSS_and_JavaScript">Лучшие практики CSS и JavaScript для обеспечения доступности</a></dt> + <dd>CSS и JavaScript, при правильном использовании, также имеют потенциал для обеспечения доступности, но при неправильном использовании они могут существенно ухудшить доступность. Эта статья раскрывает некоторые из лучших практик CSS и JavaScript которые должны помочь сделать даже очень сложное содержимое как можно более доступным.</dd> + <dt><a href="/ru-RU/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></dt> + <dd><em>Web Accessibility Initiative - Accessible Rich Internet Applications </em>— это технологический стандарт для предоставления возможности полноценного использования Интернета людьми с физическими ограничениями.<br> + Исходя из предыдущей статьи, иногда создание сложных элементов управления пользовательским интерфейсом, которые включают в себя не семантический HTML и динамический контент, обновляемый с помощью JavaScript, может быть затруднено. WAI-ARIA — это технология, которая может помочь в решении таких проблем, добавляя дополнительную семантику, которую браузеры и вспомогательные технологии могут распознавать и использовать, чтобы пользователи знали, что происходит. Здесь мы покажем, как использовать его на базовом уровне для улучшения доступности.</dd> + <dt><a href="/ru-RU/docs/Learn/Accessibility/Multimedia">Доступный мультимедиа контент</a></dt> + <dd>Другая категория контента, которая может создавать проблемы с доступностью, это мультимедиа — видео, аудио и изображения, которые должны быть предоставлены с надлежащей текстовой альтернативой, чтобы их могли понять с помощью вспомогательных технологий и их пользователи. В этой статье показано, как это можно сделать.</dd> + <dt><a href="/ru-RU/docs/Learn/Accessibility/Mobile">Доступность на мобильных устройствах</a></dt> + <dd>Поскольку веб-доступ на мобильных устройствах является настолько популярным, и на популярных платформах, таких как iOS и Android, есть полноценные средства обеспечения доступности, важно учитывать доступность вашего веб-контента для этих платформ. В этой статье рассматриваются соображения доступности для мобильных устройств.</dd> +</dl> + +<h2 id="Проверка_знаний">Проверка знаний</h2> + +<dl> + <dt><a href="/ru-RU/docs/Learn/Accessibility/Accessibility_troubleshooting">Найди недочеты в доступности</a></dt> + <dd>В этом блоке представлен достаточно простой сайт, в котором, однако, есть множество недочетов в доступности. Необходимо найти их и починить.</dd> +</dl> + +<h2 id="Также_советуем_посмотреть">Также советуем посмотреть</h2> + +<ul> + <li><a href="https://egghead.io/courses/start-building-accessible-web-applications-today">Начать создание доступных веб-приложений сегодня</a> — отличная серия видеоуроков Марси Саттона.</li> + <li><a href="https://dequeuniversity.com/resources/">Ресурсы университета Deque</a> — включает примеры кода, ссылки для чтения с экрана и другие полезные ресурсы.</li> + <li><a href="http://webaim.org/resources/">Ресурсы WebAIM</a> — включает руководства, контрольные списки, инструменты и многое другое.</li> +</ul> diff --git a/files/ru/learn/accessibility/mobile/index.html b/files/ru/learn/accessibility/mobile/index.html new file mode 100644 index 0000000000..89826dcd23 --- /dev/null +++ b/files/ru/learn/accessibility/mobile/index.html @@ -0,0 +1,305 @@ +--- +title: Мобильная доступность +slug: Learn/Accessibility/Mobile +tags: + - Mobile +translation_of: Learn/Accessibility/Mobile +original_slug: Learn/Доступность/Mobile +--- +<div> +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<p class="summary">With web access on mobile devices being so popular, and popular platforms such as iOS and Android having fully fledged accessibility tools, it is important to consider the accessibility of your web content on these platforms. This article looks at mobile-specific accessibility considerations.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Prerequisites:</th> + <td>Basic computer literacy, a basic understanding of HTML, CSS, and JavaScript, and an understanding of the <a href="/en-US/docs/Learn/Accessibility">previous articles in the course</a>.</td> + </tr> + <tr> + <th scope="row">Objective:</th> + <td>To understand what problems exist with accessibility on mobile devices, and how to overcome them.</td> + </tr> + </tbody> +</table> + +<h2 id="Accessibility_on_mobile_devices">Accessibility on mobile devices</h2> + +<p>The state of accessibility — and support for web standards in general — is good in modern mobile devices. Long gone are the days when mobile devices ran completely different web technologies to desktop browsers, forcing developers to use browser sniffing and serve them completely separate sites (although quite a few companies still detect usage of mobile devices and serve them a separate mobile domain).</p> + +<p>These days, mobile devices in general can handle "full fat" websites, and the main platforms even have screenreaders built in to enable visually impaired users to use them successfully. Modern mobile browsers tend to have good support for <a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a>, too.</p> + +<p>To make a website accessible and usable on mobile, you just need to follow general good web design and accessibility best practices.</p> + +<p>There are some exceptions that need special consideration for mobile; the main ones are:</p> + +<ul> + <li>Control mechanisms — Make sure interface controls such as buttons are accessible on mobiles (i.e., mainly touchscreen), as well as desktops/laptops (mainly mouse/keyboard).</li> + <li>User input — Make user input requirements as painless as possible on mobile (e.g., in forms, keep typing to a minimum).</li> + <li>Responsive design — Make sure layouts work on mobile, conserve image download sizes, and think about provision of images for high-resolution screens.</li> +</ul> + +<h2 id="Summary_of_screenreader_testing_on_Android_and_iOS">Summary of screenreader testing on Android and iOS</h2> + +<p>The most common mobile platforms have fully functional screenreaders. These function in much the same way as desktop screenreaders, except they are largely operated using touch gestures rather than key combinations.</p> + +<p>Let's look at the main two: TalkBack on Android and VoiceOver on iOS.</p> + +<h3 id="Android_TalkBack">Android TalkBack</h3> + +<p>The TalkBack screenreader is built into the Android operating system.</p> + +<p>To turn it on, select <em>Settings > Accessibility > TalkBack</em>, and then press the slider switch to turn it on. Follow any additional on-screen prompts that you are presented with.</p> + +<p><strong>Note:</strong> Older versions of TalkBack are turned on in <a href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">slightly different ways</a>.</p> + +<p>When TalkBack is turned on, your Android device's basic controls will be a bit different. For example:</p> + +<ol> + <li>Single-tapping an app will select it, and the device will read out what the app is.</li> + <li>Swiping left and right will move between apps, or buttons/controls if you are in a control bar. The device will read out each option.</li> + <li>Double-tapping anywhere will open the app/select the option.</li> + <li>You can also "explore by touch" — hold your finger down on the screen and drag it around, and your device will read out the different apps/items you move across.</li> +</ol> + +<p>If you want to turn TalkBack off:</p> + +<ol> + <li>Navigate to your <em>Settings</em> app using the above gestures.</li> + <li>Navigate to <em>Accessibility > TalkBack</em>.</li> + <li>Navigate to the slider switch and activate it to turn it off.</li> +</ol> + +<p><strong>Note:</strong> You can get to your homescreen at any time by swiping up and left in a smooth motion. If you have more than one homescreen, you can move between them by swiping two fingers left and right.</p> + +<p>For a more complete list of TalkBack gestures, see <a href="https://support.google.com/accessibility/android/answer/6151827">Use TalkBack gestures</a>.</p> + +<h4 id="Unlocking_the_phone">Unlocking the phone</h4> + +<p>When TalkBack is turned on, unlocking the phone is a bit different.</p> + +<p>You can do a two-finger swipe up from the bottom of the lock screen. If you've set a passcode or pattern for unlocking your device, you will then be taken to the relevant entry screen to enter it.</p> + +<p>You can also explore by touch to find the <em>Unlock</em> button at the bottom middle of the screen, and then double-tap.</p> + +<h4 id="Global_and_local_menus">Global and local menus</h4> + +<p>TalkBack allows you to access global and local context menus, wherever you have navigated to on the device. The former provides global options relating to the device as a whole, and the latter provides options relating just to the current app/screen you are in.</p> + +<p>To get to these menus:</p> + +<ol> + <li>Access the global menu by quickly swiping down, and then right.</li> + <li>Access the local menu by quickly swiping up, and then right.</li> + <li>Swipe left and right to cycle between the different options.</li> + <li>Once you've selected the option you want, double-click to choose that option.</li> +</ol> + +<p>For details on all the options available under the global and local context menus, see <a href="https://support.google.com/accessibility/android/answer/6007066">Use global and local context menus</a>.</p> + +<h4 id="Browsing_web_pages">Browsing web pages</h4> + +<p>You can use the local context menu while in a web browser to find options to navigate web pages using just the headings, form controls, or links, or navigate line by line, etc.</p> + +<p>For example, with TalkBack turned on:</p> + +<ol> + <li>Open your web browser.</li> + <li>Activate the URL bar.</li> + <li>Enter a web page that has a bunch of headings on it, such as the front page of bbc.co.uk. To enter the text of the URL: + <ul> + <li>Select the URL bar by swiping left/right till you get to it, and then double-tapping.</li> + <li>Hold your finger down on the virtual keyboard until you get the character you want, and then release your finger to type it. Repeat for each character.</li> + <li>Once you've finished, find the Enter key and press it.</li> + </ul> + </li> + <li>Swipe left and right to move between different items on the page.</li> + <li>Swipe up and right with a smooth motion to enter the local content menu.</li> + <li>Swipe right until you find the "Headings and Landmarks" option.</li> + <li>Double-tap to select it. Now you'll be able to swipe left and right to move between headings and ARIA landmarks.</li> + <li>To go back to the default mode, enter the local context menu again by swiping up and right, select "Default", and then double-tap to activate.</li> +</ol> + +<p><strong>Note:</strong> See <a href="https://support.google.com/accessibility/android/answer/6283677?hl=en&ref_topic=3529932">Get started on Android with TalkBack</a> for more complete documentation.</p> + +<h3 id="iOS_VoiceOver">iOS VoiceOver</h3> + +<p>A mobile version of VoiceOver is built into the iOS operating system.</p> + +<p>To turn it on, go to Your <em>Settings</em> app and select <em>General > Accessibility > VoiceOver</em>. Press the <em>VoiceOver</em> slider to enable it (you'll also see a number of other options related to VoiceOver on this page).</p> + +<p>Once VoiceOver is enabled, the iOS's basic control gestures will be a bit different:</p> + +<ol> + <li>A single tap will cause the item you tap on to be selected; your device will speak the item you've tapped on.</li> + <li>You can also navigate the items on the screen by swiping left and right to move between them, or by sliding your finger around on the screen to move between different items (when you find the item you want, you can remove your finger to select it).</li> + <li>To activate the selected item (e.g., open a selected app), double-tap anywhere on the screen.</li> + <li>Swipe with three fingers to scroll through a page.</li> + <li>Tap with two fingers to perform a context-relevant action — for example, taking a photo while in the camera app.</li> +</ol> + +<p>To turn it off again, navigate back to <em>Settings > General > Accessibility > VoiceOver</em> using the above gestures, and toggle the <em>VoiceOver</em> slider back to off.</p> + +<h4 id="Unlock_phone">Unlock phone</h4> + +<p>To unlock the phone, you need to press the home button (or swipe) as normal. If you have a passcode set, you can select each number by swiping/sliding (as explained above) and then double-tapping to enter each number when you've found the right one.</p> + +<h4 id="Using_the_Rotor">Using the Rotor</h4> + +<p>When VoiceOver is turned on, you have a navigation feature called the Rotor available to you, which allows you to quickly choose from a number of common useful options. To use it:</p> + +<ol> + <li>Twist two fingers around on the screen like you are turning a dial. Each option will be read aloud as you twist further around. You can go back and forth to cycle through the options.</li> + <li>Once you've found the option you want: + <ul> + <li>Release your fingers to select it.</li> + <li>If it is an option you can iterate the value of (such as Volume or Speaking Rate), you can do a swipe up or down to increase or decrease the value of the selected item.</li> + </ul> + </li> +</ol> + +<p>The options available under the Rotor are context-sensitive — they will differ depending on what app or view you are in (see below for an example).</p> + +<h4 id="Browsing_web_pages_2">Browsing web pages</h4> + +<p>Let's have a go at web browsing with VoiceOver:</p> + +<ol> + <li>Open your web browser.</li> + <li>Activate the URL bar.</li> + <li>Enter a web page that has a bunch of headings on it, such as the front page of bbc.co.uk. To enter the text of the URL: + <ul> + <li>Select the URL bar by swiping left/right until you get to it, and then double-tapping.</li> + <li>For each character, hold your finger down on the virtual keyboard until you get the character you want, and then release your finger to select it. Double-tap to type it.</li> + <li>Once you've finished, find the Enter key and press it.</li> + </ul> + </li> + <li>Swipe left and right to move between items on the page. You can double-tap an item to select it (e.g., follow a link).</li> + <li>By default, the selected Rotor option will be Speaking Rate; you can currently swipe up and down to increase or decrease the speaking rate.</li> + <li>Now turn two fingers around the screen like a dial to show the rotor and move between its options. Here are a few examples of the options available: + <ul> + <li><em>Speaking Rate</em>: Change the speaking rate.</li> + <li><em>Containers</em>: Move between different semantic containers on the page.</li> + <li><em>Headings</em>: Move between headings on the page.</li> + <li><em>Links</em>: Move between links on the page.</li> + <li><em>Form Controls</em>: Move between form controls on the page.</li> + <li><em>Language</em>: Move between different translations, if they are available.</li> + </ul> + </li> + <li>Select <em>Headings</em>. Now you'll be able to swipe up and down to move between headings on the page.</li> +</ol> + +<p><strong>Note:</strong> For a more complete reference covering the VoiceOver gestures available and other hints on accessibility testing on iOS, see <a href="https://developer.apple.com/library/content/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html#//apple_ref/doc/uid/TP40012619-CH3">Test Accessibility on Your Device with VoiceOver</a>.</p> + +<h2 id="Control_mechanisms">Control mechanisms</h2> + +<p>In our CSS and JavaScript accessibility article, we looked at the idea of events that are specific to a certain type of control mechanism (see <a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#mouse-specific_events">Mouse-specific events</a>). To recap, these cause accessibility issues because other control mechanisms can't activate the associated functionality.</p> + +<p>As an example, the <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onclick">click</a> event is good in terms of accessibility — an associated event handler can be invoked by clicking the element the handler is set on, tabbing to it and pressing Enter/Return, or tapping it on a touchscreen device. Try our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-button-example.html">simple-button-example.html</a> example (<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-button-example.html">see it running live</a>) to see what we mean.</p> + +<p>Alternatively, mouse-specific events such as <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onmousedown">mousedown</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onmouseup">mouseup</a> create problems — their event handlers cannot be invoked using non-mouse controls.</p> + +<p>If you try to control our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-box-drag.html">simple-box-drag.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/mobile/simple-box-drag.html">see example live</a>) example with keyboard or touch, you'll see the problem. This occurs because we are using code such as the following:</p> + +<pre><code>div.onmousedown = function() { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + movePanel(); +} + +document.onmouseup = stopMove;</code></pre> + +<p>To enable other forms of control, you need to use different, yet equivalent events — for example, touch events work on touchscreen devices:</p> + +<pre><code>div.ontouchstart = function(e) { + initialBoxX = div.offsetLeft; + initialBoxY = div.offsetTop; + positionHandler(e); + movePanel(); +} + +panel.ontouchend = stopMove;</code></pre> + +<p>We've provided a simple example that shows how to use the mouse and touch events together — see <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/multi-control-box-drag.html">multi-control-box-drag.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/mobile/multi-control-box-drag.html">see the example live</a> also).</p> + +<p><strong>Note:</strong> You can also see fully functional examples showing how to implement different control mechanisms at <a href="https://developer.mozilla.org/en-US/docs/Games/Techniques/Control_mechanisms">Implementing game control mechanisms</a>.</p> + +<h2 id="Responsive_design">Responsive design</h2> + +<p><a href="https://developer.mozilla.org/en-US/docs/Web/Apps/Progressive/Responsive">Responsive design</a> is the practice of making your layouts and other features of your apps dynamically change depending on factors such as screen size and resolution, so they are usable and accessible to users of different device types.</p> + +<p>In particular, the most common problems that need to be addressed for mobile are:</p> + +<ul> + <li>Suitability of layouts for mobile devices. A multi-column layout won't work as well on a narrow screen, for example, and the text size may need to be increased so it is legible. Such issues can be solved by creating a responsive layout using technologies such as <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries">media queries</a>, <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport</a>, and <a href="https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Flexbox">flexbox</a>.</li> + <li>Conserving image sizes downloaded. In general, small screen devices won't need images that are as large as their desktop counterparts, and they are more likely to be on slow network connections. Therefore, it is wise to serve smaller images to narrow screen devices as appropriate. You can handle this using <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">responsive image techniques</a>.</li> + <li>Thinking about high resolutions. Many mobile devices have high-resolution screens, and therefore need higher-resolution images so that the display can continue to look crisp and sharp. Again, you can serve images as appropriate using responsive image techniques. In addition, many image requirements can be fulfilled using the SVG vector images format, which is well-supported across browsers today. SVG has a small file size and will stay sharp regardless of whatever size is being displayed (see <a href="https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web">Adding vector graphics to the web</a> for more details).</li> +</ul> + +<p><strong>Note:</strong> We won't provide a full discussion of responsive design techniques here, as they are covered in other places around MDN (see above links).</p> + +<h3 id="Specific_mobile_considerations">Specific mobile considerations</h3> + +<p>There are other important issues to consider when making sites more accessible on mobile. We have listed a couple here, but we will add more when we think of them.</p> + +<h4 id="Not_disabling_zoom">Not disabling zoom</h4> + +<p>Using <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport</a>, it is possible to disable zoom, using code like this in your {{htmlelement("head")}}:</p> + +<pre><code><meta name="viewport" content="user-scalable=no"></code></pre> + +<p>You should never do this if at all possible — many people rely on zoom to be able to see the content of your website, so taking this functionality away is a really bad idea. There are certain situations where zooming might break the UI; in such cases, if you feel that you absolutely need to disable zoom, you should provide some other kind of equivalent, such as a control for increasing the text size in a way that doesn't break your UI.</p> + +<h4 id="Keeping_menus_accessible">Keeping menus accessible</h4> + +<p>Because the screen is so much narrower on mobile devices, it is very common to use media queries and other technologies to make the navigation menu shrink down to a tiny icon at the top of the display — which can be pressed to reveal the menu only if it's needed — when the site is viewed on mobile. This is commonly represented by a "three horizontal lines" icon, and the design pattern is consequently known as a "hamburger menu".</p> + +<p>When implementing such a menu, you need to make sure that the control to reveal it is accessible by appropriate control mechanisms (normally touch for mobile), as discussed in {{anch("Control mechanisms")}} above, and that the rest of the page is moved out of the way or hidden in some way while the menu is being accessed, to avoid confusion with navigating it.</p> + +<p>Click here for a <a href="http://fritz-weisshart.de/meg_men/">good hamburger menu example</a>.</p> + +<h2 id="User_input">User input</h2> + +<p>On mobile devices, inputting data tends to be more annoying for users than the equivalent experience on desktop computers. It is more convenient to type text into form inputs using a desktop or laptop keyboard than a touchscreen virtual keyboard or a tiny mobile physical keyboard.</p> + +<p>For this reason, it is worth trying to minimize the amount of typing needed. As an example, instead of getting users to fill out their job title each time using a regular text input, you could instead offer a {{htmlelement("select")}} menu containing the most common options (which also helps with consistency in data entry), and offer an "Other" option that displays a text field to type any outliers into. You can see a simple example of this idea in action in <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/common-job-types.html">common-job-types.html</a> (see the <a href="http://mdn.github.io/learning-area/accessibility/mobile/common-job-types.html">common jobs example live</a>).</p> + +<p>It is also worth considering the use of HTML5 form input types such as date on mobile platforms as they handle them well — both Android and iOS, for example, display usable widgets that fit well with the device experience. See <a href="https://github.com/mdn/learning-area/blob/master/accessibility/mobile/html5-form-examples.html">html5-form-examples.html</a> for some examples (see the <a href="http://mdn.github.io/learning-area/accessibility/mobile/html5-form-examples.html">HTML5 form examples live</a>) — try loading these and manipulating them on mobile devices. For example:</p> + +<ul> + <li>Types <code>number</code>, <code>tel</code>, and <code>email</code> display suitable virtual keyboards for entering numbers/telephone numbers.</li> + <li>Types <code>time</code> and <code>date</code> display suitable pickers for selecting times and dates.</li> +</ul> + +<p>If you want to provide a different solution for desktops, you could always serve different markup to your mobile devices using feature detection. See <a href="http://diveinto.html5doctor.com/detect.html#input-types">input types</a> for raw information on detecting different input types, and also check out our <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection">feature detection article</a> for much more information.</p> + +<h2 id="Summary">Summary</h2> + +<p>In this article we have provided you with some details about common mobile accessibility-specific issues and how to overcome them. We also took you through usage of the most common screenreaders to aid you in accessibility testing.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://www.smashingmagazine.com/guidelines-for-mobile-web-development/">Guidelines For Mobile Web Development</a> — A list of articles in <em>Smashing Magazine</em> covering different techniques for mobile web design.</li> + <li><a href="http://www.creativebloq.com/javascript/make-your-site-work-touch-devices-51411644">Make your site work on touch devices</a> — Useful article about using touch events to get interactions working on mobile devices.</li> +</ul> + +<div>{{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}}</div> + +<div> +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> +</div> +</div> diff --git a/files/ru/learn/accessibility/multimedia/index.html b/files/ru/learn/accessibility/multimedia/index.html new file mode 100644 index 0000000000..b75e4b89b8 --- /dev/null +++ b/files/ru/learn/accessibility/multimedia/index.html @@ -0,0 +1,361 @@ +--- +title: Доступность мультимедиа +slug: Learn/Accessibility/Multimedia +tags: + - JavaScript +translation_of: Learn/Accessibility/Multimedia +original_slug: Learn/Доступность/Multimedia +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}</div> + +<p class="summary">Another category of content that can create accessibility problems is multimedia — video, audio, and image content need to be given proper textual alternatives so they can be understood by assistive technologies and their users. This article shows how.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Prerequisites:</th> + <td>Basic computer literacy, a basic understanding of HTML, CSS, and JavaScript, an understanding of <a href="/en-US/docs/Learn/Accessibility/What_is_accessibility">what accessibility is</a>.</td> + </tr> + <tr> + <th scope="row">Objective:</th> + <td>To understand the accessibility issues behind multimedia, and how to overcome them.</td> + </tr> + </tbody> +</table> + +<h2 id="Multimedia_and_accessibility">Multimedia and accessibility</h2> + +<p>So far in this module we have looked at a variety of content and what needs to be done to ensure its accessibility, ranging from simple text content to data tables, images, native controls such as form elements and buttons, and even more complex markup structures (with <a href="/en-US/docs/Learn/Accessibility/WAI-ARIA_basics">WAI-ARIA</a> attributes).</p> + +<p>This article on the other hand looks at another general class of content that arguably isn't as easy to ensure accessibility for — multimedia. Images, videos, {{htmlelement("canvas")}} elements, Flash movies, etc., aren't as easily understood by screenreaders or navigated by the keyboard, and we need to give them a helping hand.</p> + +<p>But don't despair — here we will help you navigate through the techniques available for making multimedia more accessible.</p> + +<h2 id="Simple_images">Simple images</h2> + +<p>We already covered simple text alternatives for HTML images in our <a href="/en-US/docs/Learn/Accessibility/HTML">HTML: A good basis for accessibility</a> article — you can refer back to there for the full details. In short, you should ensure that where possible visual content has an alternative text available for screenreaders to pick up and read to their users.</p> + +<p>For example:</p> + +<pre class="brush: html"><img src="dinosaur.png" + alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."> +</pre> + +<h2 id="Accessible_audio_and_video_controls">Accessible audio and video controls</h2> + +<p>Implementing controls for web-based audio/video shouldn't be a problem, right? Let's investigate.</p> + +<h3 id="The_problem_with_native_HTML5_controls">The problem with native HTML5 controls</h3> + +<p>HTML5 video and audio instances even come with a set of inbuilt controls that allow you to control the media straight out of the box. For example (see <code>native-controls.html</code> <a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/native-controls.html">source code</a> and <a href="http://mdn.github.io/learning-area/accessibility/multimedia/native-controls.html">live</a>):</p> + +<pre class="brush: html"><audio controls> + <source src="viper.mp3" type="audio/mp3"> + <source src="viper.ogg" type="audio/ogg"> + <p>Your browser doesn't support HTML5 audio. Here is a <a href="viper.mp3">link to the audio</a> instead.</p> +</audio> + +<br> + +<video controls> + <source src="rabbit320.mp4" type="video/mp4"> + <source src="rabbit320.webm" type="video/webm"> + <p>Your browser doesn't support HTML5 video. Here is a <a href="rabbit320.mp4">link to the video</a> instead.</p> +</video></pre> + +<p>The controls attribute provides play/pause buttons, seek bar, etc. — the basic controls you'd expect from a media player. It looks like so in Firefox and Chrome:</p> + +<p><img alt="Screenshot of Video Controls in Firefox" src="https://mdn.mozillademos.org/files/14440/native-controls-firefox.png" style="display: block; height: 361px; margin: 0px auto; width: 400px;"></p> + +<p><img alt="Screenshot of Video Controls in Chrome" src="https://mdn.mozillademos.org/files/14438/native-controls-chrome.png" style="display: block; height: 344px; margin: 0px auto; width: 400px;"></p> + +<p>However, there are problems with these controls:</p> + +<ul> + <li>They are not keyboard accessible, in any browser except for Opera</li> + <li>Different browsers give the native controls differing styling and functionality, and they aren't stylable, meaning that they can't be easily made to follow a site style guide.</li> +</ul> + +<p>To remedy this, we can create our own custom controls. Let's look at how.</p> + +<h3 id="Creating_custom_audio_and_video_controls">Creating custom audio and video controls</h3> + +<p>HTML5 video and audio share an API — HTML Media Element — which allows you to map custom functionality to buttons and other controls — both of which you define yourself.</p> + +<p>Let's take the video example from above and add custom controls to them.</p> + +<h4 id="Basic_setup">Basic setup</h4> + +<p>First, grab a copy of our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/custom-controls-start.html">custom-controls-start.html</a>, <a href="https://github.com/mdn/learning-area/blob/master/accessibility/multimedia/custom-controls.css">custom-controls.css</a>, <a href="https://raw.githubusercontent.com/mdn/learning-area/master/accessibility/multimedia/rabbit320.mp4">rabbit320.mp4</a>, and <a href="https://raw.githubusercontent.com/mdn/learning-area/master/accessibility/multimedia/rabbit320.webm">rabbit320.webm</a> files and save them in a new directory on your hard drive.</p> + +<p>Create a new file called main.js and save it in the same directory.</p> + +<p>First of all, let's look at the HTML for the video player, in the HTML:</p> + +<pre class="brush: html"><section class="player"> + <video controls> + <source src="rabbit320.mp4" type="video/mp4"> + <source src="rabbit320.webm" type="video/webm"> + <p>Your browser doesn't support HTML5 video. Here is a <a href="rabbit320.mp4">link to the video</a> instead.</p> + </video> + + <div class="controls"> + <button class="playpause">Play</button> + <button class="stop">Stop</button> + <button class="rwd">Rwd</button> + <button class="fwd">Fwd</button> + <div class="time">00:00</div> + </div> +</section></pre> + +<h4 id="JavaScript_basic_setup">JavaScript basic setup</h4> + +<p>We've inserted some simple control buttons below our video. These controls of course won't do anything by default; to add functionality, we will use JavaScript.</p> + +<p>We will first need to store references to each of the controls — add the following to the top of your JavaScript file:</p> + +<pre class="brush: js">var playPauseBtn = document.querySelector('.playpause'); +var stopBtn = document.querySelector('.stop'); +var rwdBtn = document.querySelector('.rwd'); +var fwdBtn = document.querySelector('.fwd'); +var timeLabel = document.querySelector('.time');</pre> + +<p>Next, we need to grab a reference to the video/audio player itself — add this line below the previous lines:</p> + +<pre class="brush: js">var player = document.querySelector('video');</pre> + +<p>This holds a reference to a {{domxref("HTMLMediaElement")}} object, which has several useful properties and methods available on it that can be used to wire up functionality to our buttons.</p> + +<p>Before moving onto creating our button functionality, let's remove the native controls so they don't get in the way of our custom controls. Add the following, again at the bottom of your JavaScript:</p> + +<pre class="brush: js">player.removeAttribute('controls');</pre> + +<p>Doing it this way round rather than just not including the controls attribute in the first place has the advantage that if our JavaScript fails for any reason, the user still has some controls available.</p> + +<h4 id="Wiring_up_our_buttons">Wiring up our buttons</h4> + +<p>First, let's set up the play/pause button. We can get this to toggle between play and pause with a simple conditional function, like the following. Add it to your code, at the bottom:</p> + +<pre class="brush: js">playPauseBtn.onclick = function() { + if(player.paused) { + player.play(); + playPauseBtn.textContent = 'Pause'; + } else { + player.pause(); + playPauseBtn.textContent = 'Play'; + } +};</pre> + +<p>Next, add this code to the bottom, which controls the stop button:</p> + +<pre class="brush: js">stopBtn.onclick = function() { + player.pause(); + player.currentTime = 0; + playPauseBtn.textContent = 'Play'; +};</pre> + +<p>There is no <code>stop()</code> function available on {{domxref("HTMLMediaElement")}}s, so instead we <code>pause()</code> it, and at the same time set the <code>currentTime</code> to 0.</p> + +<p>Next, our rewind and fast forward buttons — add the following blocks to the bottom of your code:</p> + +<pre class="brush: js">rwdBtn.onclick = function() { + player.currentTime -= 3; +}; + +fwdBtn.onclick = function() { + player.currentTime += 3; + if(player.currentTime >= player.duration || player.paused) { + player.pause(); + player.currentTime = 0; + playPauseBtn.textContent = 'Play'; + } +};</pre> + +<p>These are very simple, just adding or subtracting 3 seconds to the <code>currentTime</code> each time they are clicked. In a real video player, you'd probably want a more elaborate seeking bar, or similar.</p> + +<p>Note that we also check to see if the <code>currentTime</code> is more than the total media <code>duration</code>, or if the media is not playing, when the Fwd button is pressed. If either conditions are true, we simply stop the video, to avoid the user interface going wrong if they attempt to fast forward when the video is not playing, or fast forward past the end of the video.</p> + +<p>Last of all, add the following to the end of the code, to control the time elapsed display:</p> + +<pre class="brush: js">player.ontimeupdate = function() { + var minutes = Math.floor(player.currentTime / 60); + var seconds = Math.floor(player.currentTime - minutes * 60); + var minuteValue; + var secondValue; + + if (minutes<10) { + minuteValue = "0" + minutes; + } else { + minuteValue = minutes; + } + + if (seconds<10) { + secondValue = "0" + seconds; + } else { + secondValue = seconds; + } + + mediaTime = minuteValue + ":" + secondValue; + timeLabel.textContent = mediaTime; +};</pre> + +<p>Each time the time updates (once per second), we fire this function. It works out the number of minutes and seconds from the given currentTime value that is just in seconds, adds a leading 0 if either the minute or second value is less than 10, and then create the display readout and adds it to the time label.</p> + +<h4 id="Further_reading">Further reading</h4> + +<p>This gives you a basic idea of how to add custom player functionality to video/audio player instances. For more information on how to add more complex features to video/audio players, including Flash fallbacks for older browsers, see:</p> + +<ul> + <li><a href="/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery">Audio and video delivery</a></li> + <li><a href="/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Video_player_styling_basics">Video player styling basics</a></li> + <li><a href="/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/cross_browser_video_player">Creating a cross-browser video player</a></li> +</ul> + +<p>We've also created an advanced example to show how you could create an object-oriented system that finds every video and audio player on the page (no matter how many there are) and adds our custom controls to it. See <a href="http://mdn.github.io/learning-area/accessibility/multimedia/custom-controls-OOJS/">custom-controls-oojs</a> (also <a href="https://github.com/mdn/learning-area/tree/master/accessibility/multimedia/custom-controls-OOJS">see the source code</a>).</p> + +<h2 id="Audio_transcripts">Audio transcripts</h2> + +<p>To provide deaf people with access to audio content, you really need to create text transcripts. These can either be included on the same page as the audio in some way, or included on a separate page and linked to.</p> + +<p>In terms of actually creating the transcript, your options are:</p> + +<ul> + <li>Commercial services — You could pay a professional to do the transcription, see for example companies like <a href="https://scribie.com/">Scribie</a>, <a href="https://castingwords.com/">Casting Words</a>, or <a href="https://www.rev.com/">Rev</a>. Look around and ask advice to make sure you find a reputable company that you'll be able to work with effectively.</li> + <li>Community/grass roots/self transcription — If you are part of an active community or team in your workplace, then you could ask them for help with doing the translations. You could even have a go at doing them yourself.</li> + <li>Automated services — There are AI services available, like <a href="https://trint.com">Trint</a>. Upload a video/audio file to the site, and it automatically transcribes it for you. On YouTube you can choose to generate automated captions/transcripts. Depending on how clear the spoken audio is, the resulting transcript quality will vary greatly. </li> +</ul> + +<p>As with most things in life, you tend to get what you pay for; different services will vary in accuracy and time taken to produce the transcript. If you pay a reputable company or AI service to do the transcription, you will probably get it done rapidly and to a high quality. If you don't want to pay for it, you are likely to get it done at a lower quality, and/or slowly.</p> + +<p>It is not OK to publish an audio resource but promise to publish the transcript later on — such promises often aren't kept, which will erode trust between you and your users. If the audio you are presenting is something like a face to face meeting or live spoken performance, it would be acceptable to take notes during the performance, publish them in full along with the audio, then seek help in cleaning up the notes afterwards.</p> + +<h3 id="Transcript_examples">Transcript examples</h3> + +<p>If you use an automated service, then you'll probably have to use the user interface that the tool provides. For example, take a look at <a href="https://www.youtube.com/watch?v=zFFBsj97Od8">Audio Transcription Sample 1</a> and choose <em>More > Transcript</em>.</p> + +<p>If you are creating your own user interface to present your audio and associated transcript, you can do it however you like, but it might make sense to include it in a showable/hideable panel; see our <a href="http://mdn.github.io/learning-area/accessibility/multimedia/audio-transcript-ui/">audio-transcript-ui</a> example (also see the <a href="https://github.com/mdn/learning-area/tree/master/accessibility/multimedia/audio-transcript-ui">source code</a>).</p> + +<h3 id="Audio_descriptions">Audio descriptions</h3> + +<p>On occasions where there are visuals accompanying your audio, you'll need to provide audio descriptions of some kind to describe that extra content.</p> + +<p>In many cases this will simply take the form of video, in which case you can implement captions using the techniques described in the next section of the article.</p> + +<p>However, there are some edge cases. You might for example have an audio recording of a meeting that refers to an accompanying resource such as a spreadsheet or chart. In such cases, you should make sure that the resources are provided along with the audio + transcript, and specifically link to them in the places where they are referred to in the transcript. This of course will help all users, not just people who are deaf.</p> + +<div class="note"> +<p><strong>Note</strong>: An audio transcript will in general help multiple user groups. As well as giving deaf users access to the information contained in the audio, think about a user with a low bandwidth connection, who would find downloading the audio inconvenient. Think also about a user in a noisy environment like a pub or bar, who is trying to access the information but can't hear it over the noise.</p> +</div> + +<h2 id="Video_text_tracks">Video text tracks</h2> + +<p>To make video accessible for deaf, blind, or even other groups of users (such as those on low bandwidth, or who don't understand the language the video is recorded in), you need to include text tracks along with your video content.</p> + +<div class="note"> +<p><strong>Note</strong>: text tracks are also useful for potentially any user, not just those with disabilities. for example, some users may not be able to hear the audio because they are in noisy environments (like a crowded bar when a sports game is being shown) or might not want to disturb others if they are in a quiet place (like a library.)</p> +</div> + +<p>This is not a new concept — television services have had closed captioning available for quite a long time:</p> + +<p><img alt='Frame from an old-timey cartoon with closed captioning "Good work, Goldie. Keep it up!"' src="https://mdn.mozillademos.org/files/14436/closed-captions.png" style="display: block; height: 240px; margin: 0px auto; width: 320px;"></p> + +<p>Whereas many countries offer English films with subtitles written in their own native languages, and different language subtitles are often available on DVDs, for example</p> + +<p><img alt='An English film with German subtitles "Emo, warum erkennst du nicht die Schonheit dieses Ortes?"' src="https://mdn.mozillademos.org/files/14442/Subtitles_German.jpg" style="display: block; margin: 0 auto;"></p> + +<p>There are different types of text track with different purposes. The main ones you'll come across are:</p> + +<ul> + <li>Captions — There for the benefit of deaf users who can't hear the audio track, including the words being spoken, and contextual information such as who spoke the words, if the people were angry or sad, and what mood the music is currently creating.</li> + <li>Subtitles — Include translations of the audio dialog, for users that don't understand the language being spoken.</li> + <li>Descriptions — These include descriptions for blind people who can't see the video, for example what the scene looks like.</li> + <li>Chapter titles — Chapter markers intended to help the user navigate the media resource</li> +</ul> + +<h3 id="Implementing_HTML5_video_text_tracks">Implementing HTML5 video text tracks</h3> + +<p>Text tracks for displaying with HTML5 video need to be written in WebVTT, a text format containing multiple strings of text along with metadata such as what time in the video you want each text string to be displayed, and even limited styling/positioning information. These text strings are called cues.</p> + +<p>A typical WebVTT file will look something like this:</p> + +<pre>WEBVTT + +1 +00:00:22.230 --> 00:00:24.606 +This is the first subtitle. + +2 +00:00:30.739 --> 00:00:34.074 +This is the second. + + ...</pre> + +<p>To get this displayed along with the HTML media playback, you need to:</p> + +<ul> + <li>Save it as a .vtt file in a sensible place.</li> + <li>Link to the .vtt file with the {{htmlelement("track")}} element. <code><track></code> should be placed within <code><audio></code> or <code><video></code>, but after all <code><source></code> elements. Use the {{htmlattrxref("kind","track")}} attribute to specify whether the cues are subtitles, captions, or descriptions. Furthermore, use {{htmlattrxref("srclang","track")}} to tell the browser what language you have written the subtitles in.</li> +</ul> + +<p>Here's an example:</p> + +<pre class="brush: html"><video controls> + <source src="example.mp4" type="video/mp4"> + <source src="example.webm" type="video/webm"> + <track kind="subtitles" src="subtitles_en.vtt" srclang="en"> +</video></pre> + +<p>This will result in a video that has subtitles displayed, kind of like this:</p> + +<p><img alt='Video player with standard controls such as play, stop, volume, and captions on and off. The video playing shows a scene of a man holding a spear-like weapon, and a caption reads "Esta hoja tiene pasado oscuro."' src="https://mdn.mozillademos.org/files/7887/video-player-with-captions.png" style="display: block; height: 365px; margin: 0px auto; width: 593px;"></p> + +<p>For more details, please read <a href="/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video">Adding captions and subtitles to HTML5 video</a>. You can find <a href="http://iandevlin.github.io/mdn/video-player-with-captions/">the example</a> that goes along with this article on Github, written by Ian Devlin (see the <a href="https://github.com/iandevlin/iandevlin.github.io/tree/master/mdn/video-player-with-captions">source code</a> too.) This example uses some JavaScript to allow users to choose between different subtitles. Note that to turn the subtitles on, you need to press the "CC" button and select an option — English, Deutsch, or Español.</p> + +<div class="note"> +<p><strong>Note</strong>: Text tracks and transcriptions also help you with {{glossary("SEO")}}, since search engines especially thrive on text. Text tracks even allow search engines to link directly to a spot partway through the video.</p> +</div> + +<h2 id="Other_multimedia_content">Other multimedia content</h2> + +<p>The above sections don't cover all types of multimedia content that you might want to put on a web page. You might also need to deal with games, animations, slideshows, embedded video, and content created using other available technologies such as:</p> + +<ul> + <li><a href="/en-US/docs/Web/API/Canvas_API">HTML5 canvas</a></li> + <li>Flash</li> + <li>Silverlight</li> +</ul> + +<p>For such content, you need to deal with accessibility concerns on a case by case basis. In some cases it is not so bad, for example:</p> + +<ul> + <li>If you are embedding audio content using a plugin technology like Flash or Silverlight, you can probably just provide an audio transcript in the same manner as we already showed above in the {{anch("Transcript examples")}} section.</li> + <li>If you are embedding video content using a plugin technology like Flash or Silverlight, you can take advantage of captioning/subtitling techniques available to those technologies. For example, see <a href="http://www.adobe.com/accessibility/products/flash/captions.html">Flash captions</a>, <a href="https://support.brightcove.com/en/video-cloud/docs/using-flash-only-player-api-closed-captioning">Using the Flash-Only Player API for Closed Captioning</a>, or <a href="https://blogs.msdn.microsoft.com/anilkumargupta/2009/05/01/playing-subtitles-with-videos-in-silverlight/">Playing Subtitles with Videos in Silverlight</a>.</li> +</ul> + +<p>However, other multimedia is not so easy to make accessible. If for example you are dealing with an immersive 3D game or virtual reality app, it really is quite difficult to provide text alternatives for such an experience, and you might argue that blind users are not really in the target audience bracket for such apps.</p> + +<p>You can however make sure that such an app has good enough color contrast and clear presentation so it is perceivable to those with low vision/color blindness, and also make it keyboard accessible. Remember that accessibility is about doing as much as you can, rather than striving for 100% accessibility all the time, which is often impossible.</p> + +<h2 id="Summary">Summary</h2> + +<p>This chapter has provided a summary of accessibility concerns for multimedia content, along with some practical solutions.</p> + +<p>{{PreviousMenuNext("Learn/Accessibility/WAI-ARIA_basics","Learn/Accessibility/Mobile", "Learn/Accessibility")}}</p> + +<p> </p> + +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> + +<p> </p> diff --git a/files/ru/learn/accessibility/wai-aria_basics/index.html b/files/ru/learn/accessibility/wai-aria_basics/index.html new file mode 100644 index 0000000000..576855fcdb --- /dev/null +++ b/files/ru/learn/accessibility/wai-aria_basics/index.html @@ -0,0 +1,417 @@ +--- +title: Основы WAI-ARIA +slug: Learn/Accessibility/WAI-ARIA_basics +tags: + - JavaScript +translation_of: Learn/Accessibility/WAI-ARIA_basics +original_slug: Learn/Доступность/WAI-ARIA_basics +--- +<div>{{LearnSidebar}}</div> + +<div>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</div> + +<p class="summary"><font>Исходя из предыдущей статьи, иногда создание сложных элементов UI, которые включают в себя неcемантичный HTML и динамически обновляемый с помощью JavaScript контент, может быть затруднено. </font><font>WAI-ARIA - это технология, которая может помочь в решении таких проблем, добавляя дополнительную разметку, которую браузеры и вспомогательные технологии могут распознавать и использовать, чтобы пользователи знали, что происходит. В этой статье</font><font> мы покажем, как использовать эту технологию на базовом уровне для улучшения доступности.</font></p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Необходимые знания:</th> + <td>Базовая компьютерная грамотность, базовое понимание HTML, CSS и JavaScript, понимание <a href="/en-US/docs/Learn/Accessibility">предыдущей статьи курса</a>.</td> + </tr> + <tr> + <th scope="row">Цель:</th> + <td>Ознакомиться с WAI-ARIA и узнать, как эту технологию можно использовать для включения полезной дополнительной семантики в целях повышения доступности.</td> + </tr> + </tbody> +</table> + +<h2 id="Что_такое_WAI-ARIA">Что такое WAI-ARIA?</h2> + +<p>Давайте начнем с рассмотрения того, что такое WAI-ARIA и чем она может быть полезна.</p> + +<h3 id="Новый_набор_проблем">Новый набор проблем</h3> + +<p>С тех пор как веб-приложения стали более сложными и динамичными, появились новые специальные возможности и проблемы.</p> + +<p><font><font>Например, HTML5 ввел ряд семантических элементов, </font><font>чтобы определить общую разметку страниц ( </font></font><a href="https://developer.mozilla.org/ru/docs/Web/HTML/Element/nav" title="HTML-элемент <nav> определяет отдельную секцию документа, назначение которой обозначение ссылок навигации (как внутри текущего документа, так и ведущих на другую страницу). В качестве примера такой секции можно привести меню, якорные ссылки."><code><nav></code></a><font><font>, </font></font><a href="https://developer.mozilla.org/ru/docs/Web/HTML/Element/footer" title="HTML-элемент <footer> представляет нижний колонтитул (футер, подвал) для своего ближайшего элемента секционного контента или секционного корня. Футер обычно содержит информацию об авторе секции, информацию об авторском праве или ссылки на связанные документы."><code><footer></code></a><font><font>и т.д.). До того как </font><font>они были доступны, разработчики просто использовали </font></font><a href="https://developer.mozilla.org/ru/docs/Web/HTML/Element/div" title='Элемент разделения контента HTML (<div>) является базовым контейнером для элементов основного потока ( flow content ). Он не влияет на контент или формат пока не стилизован, используя CSS. Являясь "чистым" контейнером, элемент <div> по своему существу не представляет ничего. Между тем, он используется для группировки контента, что позволяет легко его стилизовать, используя '><code><div></code></a><font><font> с идентификаторами или классами, например </font></font><code><div class="nav"></code><font><font>, но это создавало проблемы, так как не было никакого простого способа найти определенный раздел страницы программным способом.</font></font></p> + +<p>Первоначальным решением было добавить одну или несколько скрытых ссылок вверху страницы для ссылки на навигацию (или на что-то еще), например:</p> + +<pre class="brush: html"><a href="#hidden" class="hidden">Skip to navigation</a></pre> + +<p>Но это все еще не очень точно, и может использоваться только тогда, когда программа чтения с экрана читает сверху страницы.</p> + +<p>В качестве другого примера, в приложения стали использовать сложные элементы управления, такие как поля выбора даты, ползунки для выбора значений и т.д. HTML5 предоставляет специальные типы ввода для отображения таких элементов управления:</p> + +<pre class="brush: html"><input type="date"> +<input type="range"></pre> + +<p><font><font>Они не очень хорошо поддерживаются в разных браузерах, и их очень сложно стилизовать, что делает их не очень полезными для интеграции с дизайном сайтов. </font><font>В результате разработчики нередко используют библиотеки JavaScript, которые генерируют такие элементы управления, как последовательность вложенных </font></font><a href="https://wiki.developer.mozilla.org/ru/docs/Web/HTML/Element/div" title="Элемент разделения контента HTML (<div>) является универсальным контейнером для потокового контента. Он не влияет на контент или макет до тех пор, пока не будет стилизован с помощью CSS."><code><div></code></a><font><font>элементов или ячеек таблиц с именами классов, которые затем стилизуются с помощью CSS и управляют с помощью JavaScript.</font></font></p> + +<p>The problem here is that visually they work, but screenreaders can't make any sense of what they are at all, and their users just get told that they can see a jumble of elements with no semantics to describe what they mean.</p> + +<h3 id="Enter_WAI-ARIA">Enter WAI-ARIA</h3> + +<p><a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> is a specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking. There are three main features defined in the spec:</p> + +<ul> + <li><strong>Roles</strong> — These define what an element is or does. Many of these are so-called landmark roles, which largely duplicate the semantic value of HTML5 structural elements e.g. <code>role="navigation"</code> ({{htmlelement("nav")}}) or <code>role="complementary"</code> ({{htmlelement("aside")}}), but there are also others that describe different pages structures, such as <code>role="banner"</code>, <code>role="search"</code>, <code>role="tabgroup"</code>, <code>role="tab"</code>, etc., which are commonly found in UIs.</li> + <li><strong>Properties</strong> — These define properties of elements, which can be used to give them extra meaning or semantics. As an example, <code>aria-required="true"</code> specifies that a form input needs to be filled in to be valid, whereas <code>aria-labelledby="label"</code> allows you to put an ID on an element, then reference it as being the label for anything else on the page, including multiple elements, which is not possible using <code><label for="input"></code>. As an example, you could use <code>aria-labelledby</code> to specify that a key description contained in a {{htmlelement("div")}} is the label for multiple table cells, or you could use it as an alternative to image alt text — specify existing information on the page as an image's alt text, rather than having to repeat it inside the <code>alt</code> attribute. You can see an example of this at <a href="/en-US/docs/Learn/Accessibility/HTML?document_saved=true#Text_alternatives">Text alternatives</a>.</li> + <li><strong>States</strong> — Special properties that define the current conditions of elements, such as <code>aria-disabled="true"</code>, which specifies to a screenreader that a form input is currently disabled. States differ from properties in that properties don't change throughout the lifecycle of an app, whereas states can change, generally programmatically via JavaScript.</li> +</ul> + +<p>An important point about WAI-ARIA attributes is that they don't affect anything about the web page, except for the information exposed by the browser's accessibility APIs (where screenreaders get their information from). WAI-ARIA doesn't affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.</p> + +<div class="note"> +<p><strong>Note</strong>: You can find a useful list of all the ARIA roles and their uses, with links to futher information, in the WAI-ARIA spec — see <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definition of Roles</a>.</p> + +<p>The spec also contains a list of all the properties and states, with links to further information — see <a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definitions of States and Properties (all aria-* attributes)</a>.</p> +</div> + +<h3 id="Where_is_WAI-ARIA_supported">Where is WAI-ARIA supported?</h3> + +<p>This is not an easy question to answer. It is difficult to find a conclusive resource that states what features of WAI-ARIA are supported, and where, because:</p> + +<ol> + <li>There are a lot of features in the WAI-ARIA spec.</li> + <li>There are many combinations of operating system, browser, and screenreader to consider.</li> +</ol> + +<p>This last point is key — To use a screenreader in the first place, your operating system needs to run browsers that have the necessary accessibility APIs in place to expose the information screenreaders need to do their job. Most popular OSes have one or two browsers in place that screenreaders can work with. The Paciello Group has a fairly up-to-date post that provides data for this — see <a href="https://www.paciellogroup.com/blog/2014/10/rough-guide-browsers-operating-systems-and-screen-reader-support-updated/">Rough Guide: browsers, operating systems and screen reader support updated</a>.</p> + +<p>Next, you need to worry about whether the browsers in question support ARIA features and expose them via their APIs, but also whether screenreaders recognise that information and present it to their users in a useful way.</p> + +<ol> + <li>Browser support is generally quite good — at the time of writing, <a href="http://caniuse.com/#feat=wai-aria">caniuse.com</a> stated that global browser support for WAI-ARIA was around 88%.</li> + <li>Screenreader support for ARIA features isn't quite at this level, but the most popular screenreaders are getting there. You can get an idea of support levels by looking at Powermapper's <a href="http://www.powermapper.com/tests/screen-readers/aria/">WAI-ARIA Screen reader compatibility</a><span> article.</span></li> +</ol> + +<p>In this article, we won't attempt to cover every WAI-ARIA feature, and its exact support details. Instead, we will cover the most critical WAI-ARIA features for you to know about; if we don't mention any support details, you can assume that the feature is well-supported. We will clearly mention any exceptions to this.</p> + +<div class="note"> +<p><strong>Note</strong>: Some JavaScript libraries support WAI-ARIA, meaning that when they generate UI features like complex form controls, they add ARIA attributes to improve the accessibility of those features. If you are looking for a 3rd party JavaScript solution for rapid UI development, you should definitely consider the accessibility of its UI widgets as an important factor when making your choice. Good examples are jQuery UI (see <a href="https://jqueryui.com/about/#deep-accessibility-support">About jQuery UI: Deep accessibility support</a>), <a href="https://www.sencha.com/products/extjs/">ExtJS</a>, and <a href="https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html">Dojo/Dijit</a>.</p> +</div> + +<h3 id="When_should_you_use_WAI-ARIA">When should you use WAI-ARIA?</h3> + +<p>We talked about some of the problems that prompted WAI-ARIA to be created earlier on, but essentially, there are four main areas that WAI-ARIA is useful in:</p> + +<ol> + <li><strong>Signposts/Landmarks</strong>: ARIA's <code>role</code> attribute values can act as landmarks that either replicate the semantics of HTML5 elements (e.g. {{htmlelement("nav")}}), or go beyond HTML5 semantics to provide signposts to different functional areas, e.g <code>search</code>, <code>tabgroup</code>, <code>tab</code>, <code>listbox</code>, etc.</li> + <li><strong>Dynamic content updates</strong>: Screenreaders tend to have difficulty with reporting constantly changing content; with ARIA we can use <code>aria-live</code> to inform screenreader users when an area of content is updated, e.g. via <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>, or <a href="/en-US/docs/Web/API/Document_Object_Model">DOM APIs</a>.</li> + <li><strong>Enhancing keyboard accessibility</strong>: There are built-in HTML elements that have native keyboard accessibility; when other elements are used along with JavaScript to simulate similar interactions, keyboard accessibility and screenreader reporting suffers as a result. Where this is unavoidable, WAI-ARIA provides a means to allow other elements to receive focus (using <code>tabindex</code>).</li> + <li><strong>Accessibility of non-semantic controls</strong>: When a series of nested <code><div></code>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, accessibility can suffer — screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In these situations, ARIA can help to provide what's missing with a combination of roles like <code>button</code>, <code>listbox</code>, or <code>tabgroup</code>, and properties like <code>aria-required</code> or <code>aria-posinset</code> to provide further clues as to functionality.</li> +</ol> + +<p>One thing to remember though — <strong>you should only use WAI-ARIA when you need to!</strong> Ideally, you should <em>always</em> use <a href="/en-US/docs/Learn/Accessibility/HTML">native HTML features</a> to provide the semantics required by screenreaders to tell their users what is going on. Sometimes this isn't possible, either because you have limited control over the code, or because you are creating something complex that doesn't have an easy HTML element to implement it. In such cases, WAI-ARIA can be a valuable accessibility enhancing tool.</p> + +<p>But again, only use it when necessary!</p> + +<div class="note"> +<p><strong>Note</strong>: Also, try to make sure you test your site with a variety of <em>real</em> users — non-disabled people, people using screenreaders, people using keyboard navigation, etc. They will have better insights than you about how well it works.</p> +</div> + +<h2 id="Practical_WAI-ARIA_implementations">Practical WAI-ARIA implementations</h2> + +<p>In the next section we'll look at the four areas in more detail, along with practical examples. Before you continue, you should get a screenreader testing setup put in place, so you can test some of the examples as you go through.</p> + +<p>See our section on <a href="/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">testing screenreaders</a> for more information.</p> + +<h3 id="SignpostsLandmarks">Signposts/Landmarks</h3> + +<p>WAI-ARIA adds the <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions"><code>role</code> attribute</a> to browsers, which allows you to add extra semantic value to elements on your site wherever they are needed. The first major area in which this is useful is providing information for screenreaders so that their users can find common page elements. Let's look at an example — our <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-no-roles">website-no-roles</a> example (<a href="http://mdn.github.io/learning-area/accessibility/aria/website-no-roles/">see it live</a>) has the following structure:</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav> + <ul>...</ul> + <form> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article>...</article> + <aside>...</aside> +</main> + +<footer>...</footer></pre> + +<p>If you try testing the example with a screenreader in a modern browser, you'll already get some useful information. For example, VoiceOver gives you the following:</p> + +<ul> + <li>On the <code><header></code> element — "banner, 2 items" (it contains a heading and the <code><nav></code>).</li> + <li>On the <code><nav></code> element — "navigation 2 items" (it contains a list and a form).</li> + <li>On the <code><main></code> element — "main 2 items" (it contains an article and an aside).</li> + <li>On the <code><aside></code> element — "complementary 2 items" (it contains a heading and a list).</li> + <li>On the search form input — "Search query, insertion at beginning of text".</li> + <li>On the <code><footer></code> element — "footer 1 item".</li> +</ul> + +<p>If you go to VoiceOver's landmarks menu (accessed using VoiceOver key + U and then using the cursor keys to cycle through the menu choices), you'll see that most of the elements are nicely listed so they can be accessed quickly.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14420/landmarks-list.png" style="display: block; margin: 0 auto;"></p> + +<p>However, we could do better here. the search form is a really important landmark that people will want to find, but it is not listed in the landmarks menu or treated like a notable landmark, beyond the actual input being called out as a search input (<code><input type="search"></code>). In addition, some older browsers (most notably IE8) don't recognise the semantics of the HTML5 elements.</p> + +<p>Let's improve it by the use of some ARIA features. First, we'll add some role attributes to our HTML structure. You can try taking a copy of our original files (see <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/index.html">index.html</a> and <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/website-no-roles/style.css">style.css</a>), or navigating to our <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-aria-roles">website-aria-roles</a> example (<a href="http://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/">see it live</a>), which has a structure like this:</p> + +<pre class="brush: html"><header> + <h1>...</h1> + <nav role="navigation"> + <ul>...</ul> + <form role="search"> + <!-- search form --> + </form> + </nav> +</header> + +<main> + <article role="article">...</article> + <aside role="complementary">...</aside> +</main> + +<footer>...</footer></pre> + +<p>We've also given you a bonus feature in this example — the {{htmlelement("input")}} element has been given the attribute <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code>, which gives it a descriptive label to be read out by a screenreader, even though we haven't included a {{htmlelement("label")}} element. In cases like these, this is very useful — a search form like this one is a very common, easily recognised feature, and adding a visual label would spoil the page design.</p> + +<pre class="brush: html"><input type="search" name="q" placeholder="Search query" aria-label="Search through site content"></pre> + +<p>Now if we use VoiceOver to look at this example, we get some improvements:</p> + +<ul> + <li>The search form is called out as a separate item, both when browsing through the page, and in the Landmarks menu.</li> + <li>The label text contained in the <code>aria-label</code> attribute is read out when the form input is highlighted.</li> +</ul> + +<p>Beyond this, the site is more likely to be accessible to users of older browsers such as IE8; it is worth including ARIA roles for that purpose. And if for some reason your site is built using just <code><div></code>s, you should definitely include the ARIA roles to provide these much needed semantics!</p> + +<p>The improved semantics of the search form have shown what is made possible when ARIA goes beyond the semantics available in HTML5. You'll see a lot more about these semantics and the power of ARIA properties/attributes below, especially in the {{anch("Accessibility of non-semantic controls")}} section. For now though, let's look at how ARIA can help with dynamic content updates.</p> + +<h3 id="Dynamic_content_updates">Dynamic content updates</h3> + +<p>Content loaded into the DOM can be easily accessed using a screenreader, from textual content to alternative text attached to images. Traditional static websites with largely text content are therefore easy to make accessible for people with visual impairments.</p> + +<p>The problem is that modern web apps are often not just static text — they tend to have a lot of dynamically updating content, i.e. content that updates without the entire page reloading via a mechanism like <a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>, <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>, or <a href="/en-US/docs/Web/API/Document_Object_Model">DOM APIs</a>. These are sometimes referred to as <strong>live regions</strong>.</p> + +<p>Let's look at a quick example — see <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> (also <a href="http://mdn.github.io/learning-area/accessibility/aria/aria-no-live.html">see it running live</a>). In this example we have a simple random quote box:</p> + +<pre class="brush: html"><section> + <h1>Random quote</h1> + <blockquote> + <p></p> + </blockquote> +</section></pre> + +<p>Our JavaScript loads a JSON file via <code><a href="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a></code> containing a series of random quotes and their authors. Once that is done, we start up a <code><a href="/en-US/docs/Web/API/WindowTimers/setInterval">setInterval()</a></code> loop that loads a new random quote into the quote box every 10 seconds:</p> + +<pre class="brush: js">var intervalID = window.setInterval(showQuote, 10000);</pre> + +<p>This works OK, but it is not good for accessibility — the content update is not detected by screenreaders, so their users would not know what is going on. This is a fairly trivial example, but just imagine if you were creating a complex UI with lots of constantly updating content, like a chat room, or a strategy game UI, or a live updating shopping cart display — it would be impossible to use the app in any effective way without some kind of way of alerting the user to the updates.</p> + +<p>WAI-ARIA fortunately provides a useful mechanism to provide these alerts — the <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-live">aria-live</a></code> property. Applying this to an element causes screenreaders to read out the content that is updated. How urgently the content is read out depends on the attribute value:</p> + +<ul> + <li><code>off:</code> The default. Updates should not be announced.</li> + <li><code>polite</code>: Updates should be announced only if the user is idle.</li> + <li><code>assertive</code>: Updates should be announced to the user as soon as possible.</li> +</ul> + +<p>We'd like you to take a copy of <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> and <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/quotes.json">quotes.json</a>, and update your <code><section></code> tag as follows:</p> + +<pre class="brush: html"><section aria-live="assertive"></pre> + +<p>This will cause a screenreader to read out the content as it is updated.</p> + +<div class="note"> +<p><strong>Note</strong>: Most browsers will throw a security exception if you try to do an <code>XMLHttpRequest</code> call from a <code>file://</code> URL, e.g. if you just load the file by loading it directly into the browser (via double clicking, etc.). To get it to run, you will need to upload it to a web server, for example <a href="/en-US/docs/Learn/Common_questions/Using_Github_pages">using GitHub</a>, or a local web server like <a href="http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/">Python's SimpleHTTPServer</a>.</p> +</div> + +<p>There is an additional consideration here — only the bit of text that updates is read out. It might be nice if we always read out the heading too, so the user can remember what is being read out. To do this, we can add the <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-atomic">aria-atomic</a></code> property to the section. Update your <code><section></code> tag again, like so:</p> + +<pre class="brush: html"><section aria-live="assertive" aria-atomic="true"></pre> + +<p>The <code>aria-atomic="true"</code> attribute tells screenreaders to read out the entire element contents as one atomic unit, not just the bits that were updated.</p> + +<div class="note"> +<p><strong>Note</strong>: You can see the finished example at <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html">aria-live.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-live.html">see it running live</a>).</p> +</div> + +<div class="note"> +<p><strong>Note</strong>: The <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> property is also quite useful for controlling what gets read out when a live region is updated. You can for example only get content additions or removals read out.</p> +</div> + +<h3 id="Enhancing_keyboard_accessibility">Enhancing keyboard accessibility</h3> + +<p>As discussed in a few other places in the module, one of the key strengths of HTML with respect to accessibility is the built-in keyboard accessibility of features such as buttons, form controls, and links. Generally, you are able to use the tab key to move between controls, the Enter/Return key to select or activate controls, and occasionally other controls as needed (for example the up and down cursor to move between options in a <code><select></code> box).</p> + +<p>However, sometimes you will end up having to write code that either uses non-semantic elements as buttons (or other types of control), or uses focusable controls for not quite the right purpose. You might be trying to fix some bad code you've inherited, or you might be building some kind of complex widget that requires it.</p> + +<p>In terms of making non-focusable code focusable, WAI-ARIA extends the <code>tabindex</code> attribute with some new values:</p> + +<ul> + <li><code>tabindex="0"</code> — as indicated above, this value allows elements that are not normally tabbable to become tabbable. This is the most useful value of <code>tabindex</code>.</li> + <li><code>tabindex="-1"</code> — this allows not normally tabbable elements to receive focus programmatically, e.g. via JavaScript, or as the target of links. </li> +</ul> + +<p>We discussed this in more detail and showed a typical implementation back in our HTML accessibility article — see <a href="/en-US/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in">Building keyboard accessibility back in</a>.</p> + +<h3 id="Accessibility_of_non-semantic_controls">Accessibility of non-semantic controls</h3> + +<p>This follows on from the previous section — when a series of nested <code><div></code>s along with CSS/JavaScript is used to create a complex UI-feature, or a native control is greatly enhanced/changed via JavaScript, not only can keyboard accessibility suffer, but screenreader users will find it difficult to work out what the feature does if there are no semantics or other clues. In such situations, ARIA can help to provide those missing semantics.</p> + +<h4 id="Form_validation_and_error_alerts">Form validation and error alerts</h4> + +<p>First of all, let's revisit the form example we first looked at in our CSS and JavaScript accessibility article (read <a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#Keeping_it_unobtrusive">Keeping it unobtrusive</a> for a full recap). At the end of this section we showed that we have included some ARIA attributes on the error message box that appears when there are validation errors when you try to submit the form:</p> + +<pre class="brush: html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>div</span> <span class="attr-name token">class</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>errors<span class="punctuation token">"</span></span> <span class="attr-name token">role</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>alert<span class="punctuation token">"</span></span> <span class="attr-name token">aria-relevant</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>all<span class="punctuation token">"</span></span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>ul</span><span class="punctuation token">></span></span> + <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>ul</span><span class="punctuation token">></span></span> +<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>div</span><span class="punctuation token">></span></span></code></pre> + +<ul> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#alert">role="alert"</a></code> automatically turns the element it is applied to into a live region, so changes to it are read out; it also semantically identifies it as an alert message (important time/context sensitive information), and represents a better, more accessible way of delivering an alert to a user (modal dialogs like <code><a href="/en-US/docs/Web/API/Window/alert">alert()</a></code> calls have a number of accessibility problems; see <a href="http://webaim.org/techniques/javascript/other#popups">Popup Windows</a> by WebAIM).</li> + <li>An <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant</a></code> value of <code>all</code> instructs the screenreader to read out the contents of the error list when any changes are made to it — i.e. when errors are added or removed. This is useful because the user will want to know what errors are left, not just what has been added or removed from the list.</li> +</ul> + +<p>We could go further with our ARIA usage, and provide some more validation help. How about indicating whether fields are required in the first place, and what range the age should be?</p> + +<ol> + <li>At this point, take a copy of our <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">form-validation.html</a> and <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/validation.js">validation.js</a> files, and save them in a local directory.</li> + <li>Open them both in a text editor and have a look at how the code works.</li> + <li>First of all, add a paragraph just above the opening <code><form></code> tag, like the one below, and mark both the form <code><label></code>s with an asterisk. This is normally how we mark required fields for sighted users. + <pre class="brush: html"><p>Fields marked with an asterisk (*) are required.</p></pre> + </li> + <li>This makes visual sense, but it isn't as easy to understand for screenreader users. Fortunately, WAI-ARIA provides the <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-required">aria-required</a></code> attribute to give screenreaders hints that they should tell users that form inputs need to be filled in. Update the <code><input></code> elements like so: + <pre class="brush: html"><input type="text" name="name" id="name" aria-required="true"> + +<input type="number" name="age" id="age" aria-required="true"></pre> + </li> + <li>If you save the example now and test it with a screenreader, you should hear something like "Enter your name star, required, edit text".</li> + <li>It might also be useful if we give screenreader users and sighted users an idea of what the age value should be. This is often presented as a tooltip, or placeholder inside the form field perhaps. WAI-ARIA does include <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemin">aria-valuemin</a></code> and <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemax">aria-valuemax</a></code> properties to specify min and max values, but these currently don't seem very well supported; a better supported feature is the HTML5 <code>placeholder</code> attribute, which can contain a message that is shown in the input when no value is entered, and is read out by a number of screenreaders. Update your number input like this: + <pre class="brush: html"><input type="number" name="age" id="age" placeholder="Enter 1 to 150" aria-required="true"></pre> + </li> +</ol> + +<div class="note"> +<p><strong>Note</strong>: You can see the finished example live at <a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html">form-validation-updated.html</a>.</p> +</div> + +<p>WAI-ARIA also enables some advanced form labelling techniques, beyond the classic {{htmlelement("label")}} element. We already talked about using the <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code> property to provide a label where we don't want the label to be visible to sighted users (see the {{anch("Signposts/Landmarks")}} section, above). There are some other labelling techniques that use other properties such as <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby">aria-labelledby</a></code> if you want to designate a non-<code><label></code> element as a label or label multiple form inputs with the same label, and <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-describedby">aria-describedby</a></code>, if you want to associate other information with a form input and have it read out as well. See <a href="http://webaim.org/techniques/forms/advanced">WebAIM's Advanced Form Labeling article</a><span class="subtitle"> for more details.</span></p> + +<p><span class="subtitle">There are many other useful properties and states too, for indicating the status of form elements. For example, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-disabled">aria-disabled</a>="true"</code> can be used to indicate that a form field is disabled. Many browsers will just skip past disabled form fields, and they won't even be read out by screenreaders, but in some cases they will be perceived, so it is a good idea to include this attribute to let the screenreader know that a disabled input is in fact disabled.</span></p> + +<p><span class="subtitle">If the disabled state of an input is likely to change, then it is also a good idea to indicate when it happens, and what the result is. For example, in our <a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-checkbox-disabled.html">form-validation-checkbox-disabled.html</a> demo there is a checkbox that when checked, enables another form input to allow further information be entered. We've set up a hidden live region:</span></p> + +<pre class="brush: html"><p class="hidden-alert" aria-live="assertive"></p></pre> + +<p>which is hidden from view using absolute positioning. When this is checked/unchecked, we update the text inside the hidden live region to tell screenreader users what the result of checking this checkbox is, as well as updating the <code>aria-disabled</code> state, and some visual indicators too:</p> + +<pre class="brush: js">function toggleMusician(bool) { + var instruItem = formItems[formItems.length-1]; + if(bool) { + instruItem.input.disabled = false; + instruItem.label.style.color = '#000'; + instruItem.input.setAttribute('aria-disabled', 'false'); + hiddenAlert.textContent = 'Instruments played field now enabled; use it to tell us what you play.'; + } else { + instruItem.input.disabled = true; + instruItem.label.style.color = '#999'; + instruItem.input.setAttribute('aria-disabled', 'true'); + instruItem.input.removeAttribute('aria-label'); + hiddenAlert.textContent = 'Instruments played field now disabled.'; + } +}</pre> + +<h4 id="Describing_non-semantic_buttons_as_buttons">Describing non-semantic buttons as buttons</h4> + +<p>A few times in this course already, we've mentioned the native accessibilty of (and the accessibility issues behind using other elements to fake) buttons, links, or form elements (see <a href="/en-US/docs/Learn/Accessibility/HTML#UI_controls">UI controls</a> in the HTML accessibility article, and {{anch("Enhancing keyboard accessibility")}}, above). Basically, you can add keyboard accessibility back in without too much trouble in many cases, using <code>tabindex</code> and a bit of JavaScript.</p> + +<p>But what about screenreaders? They still won't see the elements as buttons. If we test our <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a> example in a screenreader, our fake buttons will be reported using phrases like "Click me!, group", which is obviously confusing.</p> + +<p>We can fix this using a WAI-ARIA role. Make a local copy of <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">fake-div-buttons.html</a>, and add <code><a href="https://www.w3.org/TR/wai-aria-1.1/#button">role="button"</a></code> to each button <code><div></code>, for example:</p> + +<pre><div data-message="This is from the first button" tabindex="0" role="button">Click me!</div></pre> + +<p>Now when you try this using a screenreader, you'll have buttons be reported using phrases like "Click me!, button" — much better.</p> + +<div class="note"> +<p><strong>Note</strong>: Don't forget however that using the correct semantic element where possible is always better. If you want to create a button, and can use a {{htmlelement("button")}} element, you should use a {{htmlelement("button")}} element!</p> +</div> + +<h4 id="Guiding_users_through_complex_widgets">Guiding users through complex widgets</h4> + +<p>There are a whole host of other <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">roles</a> that can identify non-semantic element structures as common UI features that go beyond what's available in standard HTML, for example <code><a href="https://www.w3.org/TR/wai-aria-1.1/#combobox">combobox</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#slider">slider</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tree">tree</a></code>. You can see a number of userful examples in the <a href="https://dequeuniversity.com/library/">Deque university code library</a>, to give you an idea of how such controls can be made accessible.</p> + +<p>Let's go through an example of our own. We'll return to our simple absolutely-positioned tabbed interface (see <a href="/en-US/docs/Learn/Accessibility/CSS_and_JavaScript#Hiding_things">Hiding things</a> in our CSS and JavaScript accessibility article), which you can find at <a class="external external-icon" href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">Tabbed info box example</a> (see <a class="external external-icon" href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">source code</a>).</p> + +<p>This example as-is works fine in terms of keyboard accessibility — you can happily tab between the different tabs and select them to show the tab contents. It is also fairly accessible too — you can scroll through the content and use the headings to navigate , even if you can't see what is happening on screen. It is however not that obvious what the content is — a screenreader currently reports the content as a list of links, and some content with three headings. It doesn't give you any idea of what the relationship is between the content. Giving the user more clues as to the structure of the content is always good.</p> + +<p>To improve things, we've created a new version of the example called <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-tabbed-info-box.html">aria-tabbed-info-box.html</a> (<a href="http://mdn.github.io/learning-area/accessibility/aria/aria-tabbed-info-box.html">see it running live</a>). We've updated the structure of the tabbed interface like so:</p> + +<pre class="brush: html"><ul role="tablist"> + <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li> + <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li> +</ul> +<div class="panels"> + <article class="active-panel" role="tabpanel" aria-hidden="false"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> + <article role="tabpanel" aria-hidden="true"> + ... + </article> +</div></pre> + +<div class="note"> +<p><strong>Note</strong>: The most striking change here is that we've removed the links that were originally present in the example, and just used the list items as the tabs — this was done because it makes things less confusing for screenreader users (the links don't really take you anywhere; they just change the view), and it allows the setsize/position in set features to work better — when these were put on the links, the browser kept reporting "1 of 1" all the time, not "1 of 3", "2 of 3", etc.</p> +</div> + +<p>The new features are as follows:</p> + +<ul> + <li>New roles — <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tablist">tablist</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tab">tab</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code> — these identify the important areas of the tabbed interface — the container for the tabs, the tabs themselves, and the corresponding tabpanels.</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-selected">aria-selected</a></code> — Defines which tab is currently selected. As different tabs are selected by the user, the value of this attribute on the different tabs is updated via JavaScript.</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-hidden">aria-hidden</a></code> — Hides an element from being read out by a screenreader. As different tabs are selected by the user, the value of this attribute on the different tabs is updated via JavaScript.</li> + <li><code>tabindex="0"</code> — As we've removed the links, we need to give the list items this attribute to provide it with keyboard focus.</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-setsize">aria-setsize</a></code> — This property allows you to specify to screenreaders that an element is part of a series, and how many items the series has.</li> + <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-posinset">aria-posinset</a></code> — This property allows you to specify what position in a series an element is in. Along with <code>aria-setsize</code>, it provides a screenreader with enough information to tell you that you are currently on item "1 of 3", etc. In many cases, browsers should be able to infer this information from the element hierarchy, but it certainly helps to provide more clues.</li> +</ul> + +<p>In our tests, this new structure did serve to improve things overall. The tabs are now recognised as tabs (e.g. "tab" is spoken by the screenreader), the selected tab is indicated by "selected" being read out with the tab name, and the screenreader also tells you which tab number you are currently on. In addition, because of the <code>aria-hidden</code> settings (only the non-hidden tab ever has <code>aria-hidden="false"</code> set), the non-hidden content is the only one you can navigate down to, meaning the selected content is easier to find.</p> + +<div class="note"> +<p><strong>Note</strong>: If there is anything you explicitly don't want screen readers to read out, you can give them the <code>aria-hidden="true"</code> attribute.</p> +</div> + +<h2 id="Summary">Summary</h2> + +<p>This article has by no means covered all that's available in WAI-ARIA, but it should have given you enough information to understand how to use it, and know some of the most common patterns you will encounter that require it.</p> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definition of Roles</a> — ARIA roles reference.</li> + <li><a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definitions of States and Properties (all aria-* attributes)</a> — properties and states reference.</li> + <li><a href="https://dequeuniversity.com/library/">Deque university code library</a> — a library of really useful practical examples showing complex UI controls made accessible using WAI-ARIA features.</li> + <li><a href="http://w3c.github.io/aria-practices/">WAI-ARIA Authoring Practices</a> — very detailed design patterns from the W3C, explaining how to implement different types of complex UI control whilst making them accessible using WAI-ARIA features.</li> + <li><a href="https://www.w3.org/TR/html-aria/">ARIA in HTML</a> — A W3C spec that defines, for each HTML feature, what accessibility (ARIA) semantics that feature implicitly has set on it by the browser, and what WAI-ARIA features you may set on it if extra semantics are required.</li> +</ul> + +<p>{{PreviousMenuNext("Learn/Accessibility/CSS_and_JavaScript","Learn/Accessibility/Multimedia", "Learn/Accessibility")}}</p> + +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> diff --git a/files/ru/learn/accessibility/what_is_accessibility/index.html b/files/ru/learn/accessibility/what_is_accessibility/index.html new file mode 100644 index 0000000000..84dc970c42 --- /dev/null +++ b/files/ru/learn/accessibility/what_is_accessibility/index.html @@ -0,0 +1,211 @@ +--- +title: Что такое доступность? +slug: Learn/Accessibility/What_is_accessibility +tags: + - CSS + - HTML + - JavaScript + - Изучение + - Клавиатура + - Написание скриптов + - Начинающий + - Программные средства + - Статья + - Считыватель экрана + - вспомогательная технология + - доступность +translation_of: Learn/Accessibility/What_is_accessibility +original_slug: Learn/Доступность/What_is_accessibility +--- +<div>{{LearnSidebar}}</div> + +<div>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</div> + +<p class="summary">Данная статья открывает модуль, в котором рассматривается, что такое доступность на самом деле — она включает в себя группы людей, которые нам нужно учитывать и почему, какие инструменты используют разные пользователи для взаимодействия с вебом, и как мы можем сделать доступность частью нашего рабочего процесса веб-разработки.</p> + +<table class="learn-box standard-table"> + <tbody> + <tr> + <th scope="row">Необходимые знания:</th> + <td>Базовая компьютерная грамотность, базовое понимание HTML и CSS.</td> + </tr> + <tr> + <th scope="row">Цель:</th> + <td>Узнать, что такое доступность, и как она влияет на вас как на веб-разработчика.</td> + </tr> + </tbody> +</table> + +<h2 id="Итак_что_такое_доступность">Итак, что такое доступность?</h2> + +<p>Доступность — это практика, позволяющая использовать ваши сайты как можно большему числу людей. Мы традиционно думаем об этом как о доступности для людей с ограниченными возможностями, но на самом деле, в это число входят и другие группы пользователей, которые используют мобильные устройства либо имеют медленное сетевое соединение.</p> + +<p>Вы также можете думать о доступности как о способе предоставления равных прав и одинаковых возможностей, независимо от способностей или обстоятельств. Точно так же, как не правильно лишать человека права посещать разнообразные места, только потому что он перемещается в инвалидном кресле (общественные здания в наши дни обычно имеют пандусы для инвалидных колясок или лифты), так и не правильно исключать кого-либо из веб-пространства из-за того, что у них слабое зрение или они используют мобильный телефон. Мы все разные, но все мы люди, и поэтому имеем одинаковые (человеческие) права.</p> + +<p>Помимо того, что доступность это просто хороший тон, она также регулируется законодательством в некоторых странах и может поспособствовать открытию важных рынков, которые в противном случае не смогут использовать ваши услуги, покупать ваши продукты и т. д.</p> + +<p>Доступность и опыт её применения принесут пользу всем:</p> + +<ul> + <li>Семантический HTML (который улучшает доступность) также улучшает SEO, делая ваш сайт более доступным для поиска или продажи.</li> + <li>Забота о доступности демонстрирует хорошую этику и мораль, что улучшает ваш имидж в обществе.</li> + <li>Другие хорошие практики, улучшающие доступность, также делают сайт более удобным для использования другими группами, такими как пользователи мобильных телефонов, пользователи с низкой скоростью сети и т.д. На самом деле, каждый может извлечь выгоду из многих таких улучшений.</li> + <li>Мы упоминали, что это также закон в некоторых местах?</li> +</ul> + +<h2 id="Какие_виды_ограниченных_возможностей_мы_рассматриваем">Какие виды ограниченных возможностей мы рассматриваем?</h2> + +<p>Люди с ограниченными возможностями так же разнообразны, как и люди без них, так и своими недостатками. Ключевой урок заключается в том, чтобы думать за пределами вашего собственного компьютера и того, как вы используете Интернет, и начать изучать как его используют другие — <em>вы не ваши пользователи. </em>Ниже разъясняются основные виды инвалидности, а также любые специализированные инструменты, которые используются для доступа к веб-контенту (известные как <strong>вспомогательные технологии</strong>).</p> + +<div class="note"> +<p><strong>Примечание</strong>: в информационном бюллетене Всемирной организации здравоохранения по вопросам <a class="external external-icon" href="https://www.who.int/ru/news-room/fact-sheets/detail/disability-and-health">Инвалидности и Здоровья</a> говорится, что "Более 1 миллиарда людей, около 15% населения мира, имеют какую-либо форму инвалидности" и "От 110 до 190 миллионов взрослых испытывают значительные трудности в функционировании."</p> +</div> + +<h3 id="Люди_с_нарушениями_зрения">Люди с нарушениями зрения</h3> + +<p>Сюда относятся люди со слепотой, слабым зрением, дальтонизмом и другие. Многие из этих людей используют экранные лупы (либо физические лупы, либо программные возможности масштабирования — большинство браузеров и операционных систем в наши дни имеют возможности масштабирования), а некоторые будут использовать программы чтения с экрана, то есть программное обеспечение, которое читает цифровой текст вслух:</p> + +<ul> + <li>Некоторые платные коммерческие продукты, такие как <a class="external external-icon" href="http://www.freedomscientific.com/Products/Blindness/JAWS">JAWS</a> (Windows) и <a class="external external-icon" href="http://www.gwmicro.com/window-eyes/">Window Eyes</a> (Windows).</li> + <li>Некоторые бесплатные продукты, такие как <a class="external external-icon" href="http://www.nvaccess.org/">NVDA</a> (для Windows), <a class="external external-icon" href="http://www.chromevox.com/">ChromeVox</a> (браузер Chrome, Windows и Mac ОС Х) и <a class="external external-icon" href="https://wiki.gnome.org/Projects/Orca">Orca</a> (Linux).</li> + <li>Некоторые из них встроены в операционную систему, например <a class="external external-icon" href="http://www.apple.com/accessibility/osx/voiceover/">VoiceOver</a> (Mac OS X и iOS), <a class="external external-icon" href="https://support.microsoft.com/en-us/help/22798/windows-10-narrator-get-started">Экранный диктор</a>(<a class="external external-icon" href="https://support.microsoft.com/en-us/help/22798/windows-10-narrator-get-started">Narrator</a>) (Microsoft Windows), <a class="external external-icon" href="http://www.chromevox.com/">ChromeVox</a> (в Chrome OS) и <a class="external external-icon" href="https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback">TalkBack</a> (Android).</li> +</ul> + +<p>Хорошая идея ознакомиться с экранными дикторами; вы можете настроить экранный считыватель и поиграть с ним, чтобы получить представление о том, как это работает. Более подробную информацию об их использовании см. в <a href="/ru/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">руководстве по кросс-браузерному тестированию</a>. Видео ниже предоставляет краткий пример взаимодействия с экранными читателями.</p> + +<p>{{EmbedYouTube("IK97XMibEws")}}</p> + +<p> </p> + +<p>Что касается статистики: по оценкам Всемирной Организации Здравоохранения: "285 миллионов человек во всем мире страдают нарушениями зрения: 39 миллионов слепы и 246 имеют слабовидение." (см. <a class="external external-icon" href="http://www.who.int/ru/news-room/fact-sheets/detail/blindness-and-visual-impairment">Нарушения зрения и слепота</a>). Это большая и значительная группа пользователей, которые просто упущены, потому что ваш сайт не закодирован должным образом — почти такой же размер, как и население Соединенных Штатов Америки.</p> + +<h3 id="Люди_с_нарушениями_слуха">Люди с нарушениями слуха</h3> + +<p>Эта группа людей либо имеет низкий уровень слуха, либо вообще не слышит. Люди с нарушениями слуха используют ATs (см. <a class="external external-icon" href="https://www.nidcd.nih.gov/health/assistive-devices-people-hearing-voice-speech-or-language-disorders">Вспомогательные устройства для людей с нарушениями слуха, голоса, речи или языка</a>), но на самом деле нет специальных ATs, специфичных для использования на компьютере или в интернете.</p> + +<p>Однако существуют специальные техники, которые следует учитывать для предоставления текстовых альтернатив аудиоконтенту, который люди смогут читать, от простых текстовых транскриптов до текстовых дорожек (т.е. подписей), которые могут отображаться вместе с видео. Об этом будет рассказано в статье позже.</p> + +<p>Люди с нарушениями слуха представляют значительную базу пользователей — "360 миллионов человек в мире страдают от инвалидизирующей потери слуха", — говорится в информационном бюллетене Всемирной Организации Здравоохранения о <a class="external external-icon" href="https://www.who.int/ru/news-room/fact-sheets/detail/deafness-and-hearing-loss">Глухоте и потере слуха</a>.</p> + +<h3 id="Люди_с_ограниченными_физическими_возможностями">Люди с ограниченными физическими возможностями </h3> + +<p>Это группа людей, которые имеют инвалидность в отношении движения, которая может включать в себя чисто физические проблемы (такие как потеря конечности или паралич), или неврологические/генетические расстройства, которые приводят к слабости или потере контроля в конечностях. Некоторые люди могут испытывать трудности с выполнением точных движений рук, необходимых для использования мыши, в то время как другие могут быть более серьезно затронуты, возможно, значительно парализованы до такой степени, что им нужно использовать <a class="external external-icon" href="https://www.performancehealth.com/baseball-cap-head-pointer">указатель головы</a> для взаимодействия с компьютером.</p> + +<p>Этот вид инвалидности также может быть результатом старости, а не какой-либо конкретной травмы или состояния, а также может быть результатом аппаратных ограничений — у некоторых пользователей может не быть мыши.</p> + +<p>Управление элементами с помощью клавиатуры является обычным требованием, которое влияет на процесс веб-разработки — мы обсудим доступ с клавиатруы в последующих статьях модуля. Хорошая идея, чтобы попробовать пользоваться веб-сайтами, только с помощью клавиатуры, чтобы увидеть, что из этого выйдет и как это работает. Например, можно ли использовать клавишу Tab для перемещения между различными элементами управления веб-формы? Вы можете найти больше деталей об использовании клавиатуры в нашей секции <a href="/ru/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Using_native_keyboard_accessibility">Cross browser testing Using native keyboard accessibility</a>.</p> + +<p>С точки зрения статистики, значительное количество людей имеют нарушения мобильности. Центры США по контролю и профилактике заболеваний <a class="external external-icon" href="http://www.cdc.gov/nchs/fastats/disability.htm">Инвалидности и Функционирования (Неинституционализированные взрослые в возрасте 18 лет и старше)</a> сообщают, что в США "Процент взрослых с любым физическим нарушением функционирования: 16,1%".</p> + +<h3 id="Люди_с_когнитивными_нарушениями">Люди с когнитивными нарушениями</h3> + +<p>Вероятно, самый широкий спектр инвалидности можно увидеть в этой категории — когнитивные нарушения в широком смысле могут относиться к инвалидности от психических заболеваний до трудностей в обучении, трудности в понимании и концентрации, такие как <a class="external external-icon" href="https://www.nimh.nih.gov/health/topics/attention-deficit-hyperactivity-disorder-adhd/index.shtml">СДВГ (синдром дефицита внимания и гиперактивности)</a>, людям <a class="external external-icon" href="https://www.nimh.nih.gov/health/topics/autism-spectrum-disorders-asd/index.shtml">аутистического спектра</a>, людям с <a class="external external-icon" href="https://www.nimh.nih.gov/health/topics/schizophrenia/index.shtml">шизофренией</a>, и множество других типов нарушений. Такие недостатки могут повлиять на многие детали повседневной жизни из-за проблем с памятью, решением, пониманием, вниманием и т. д.</p> + +<p>Наиболее распространенные способы, вызванные когнитивными нарушениями, которые могут повлиять на использование веб-сайта — трудности с пониманием того, как выполнить задачу; вспомнить, как сделать что-то, что было ранее выполнено; повышенное разочарование в запутанных рабочих процессах или непоследовательных макетах/навигации/других функциях страницы.</p> + +<p>В отличие от других проблем доступности интернета, невозможно назначить быстрые исправления для многих проблем доступности, связанных с когнитивными нарушениями; лучшее решение, которое у вас есть — это проектировать веб-сайты таким образом, чтобы они были логичными, последовательными и удобными для использования настолько, насколько это возможно. Например, убедитесь, что:</p> + +<ul> + <li>страницы согласованы — навигация, шапка и подвал (хедер и футер), а так же главный контент всегда находятся в одном месте.</li> + <li>инструменты хорошо разработаны и просты в использовании.</li> + <li>многоступенчатые процессы разбиты на логические этапы, с регулярными напоминаниями о том, как далеко вы прошли, и сколько осталось до завершения процесса, если это необходимо.</li> + <li>рабочие процессы логичны, просты и требуют как можно меньше взаимодействий. Например, регистрация и вход на веб-сайт зачастую неоправданно сложны.</li> + <li>страницы не слишком длинные или плотные с точки зрения количества информации, представленной сразу.</li> + <li>язык, используемый на ваших страницах, настолько прост и удобен, насколько это возможно, и не полон ненужного жаргона и сленга.</li> + <li>важные моменты и контент выделены некоторым способом.</li> + <li>ошибки пользователя четко выделены, с подсказкой и предлагаемым решением.</li> +</ul> + +<p>Это не "методы доступности" как таковые — это хорошая практика проектирования. Они принесут пользу всем, кто использует ваши сайты, и должны быть стандартной частью вашей работы.</p> + +<p>С точки зрения статистики, опять же цифры значительны. Отчет Корнелльского университета <a class="external external-icon" href="http://www.disabilitystatistics.org/StatusReports/2014-PDF/2014-StatusReport_US.pdf">О состоянии инвалидности за 2014 год</a> (PDF, 511 КБ)(en) показывает, что в 2014 году 4,5% людей в США в возрасте 21-64 лет имели ту или иную форму когнитивной инвалидности.</p> + +<div class="note"> +<p><strong>Примечание</strong>: <a href="http://webaim.org/articles/cognitive/">Страница о когнитивных расстройствах</a> на WebAIM обепечивает полезное распространение этих идей, и это, безусловно, стоит прочитать.</p> +</div> + +<h2 id="Реализация_доступности_в_проекте">Реализация доступности в проекте</h2> + +<p>Распространенный миф о доступности заключается в том, что доступность является дорогостоящим "дополнением" для реализации проекта. Этот миф на самом деле может быть правдой, если:</p> + +<ul> + <li>Вы пытаетесь "модифицировать" доступность на существующем сайте, который имеет значительные проблемы в этом плане.</li> + <li>Вы только начали рассматривать доступность и непокрытые смежные вопросы на последних этапах проекта.</li> +</ul> + +<p>Если вы рассматриваете доступность с самого начала проекта, то стоимость создания доступного контента должна быть весьма небольшой.</p> + +<p>При планировании проекта учитывайте тестирование доступности в своём режиме тестирования, как при тестировании любого другого важного сегмента целевой аудитории (например, настольный или мобильный браузер). Тестируйте на ранних этапах и часто, выполняя автоматические тесты, чтобы выявить программно обнаруживаемые отсутствующие функции (такие как отсутствующий <a href="https://developer.mozilla.org/ru/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Text_alternatives">альтернативный текст</a> изображения или неправильная ссылка — см. <a href="/ru/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Element_relationships_and_context">Element relationships and context</a>), и тестируйте с некоторыми нетрудоспособными групами пользователей, чтобы увидеть, насколько хорошо для них работают более сложные функции сайта. Например:</p> + +<ul> + <li>Может ли мой виджет выбора даты использоваться людьми, использующими программы чтения с экрана?</li> + <li>Если контент обновляется динамически, знают ли об этом люди с ослабленным зрением?</li> + <li>Мои интефейсные кнопки доступны с помощью клавиатуры и сенсорного интерфейса?</li> +</ul> + +<p>Вы можете и должны хранить заметку о потенциальных проблемных местах в контенте, которые будут нуждаться в доработке, чтобы сделать их доступыми, убедитесь, что они тщательно протестированы, и подумайте о решениях/альтернативах. Текстовый контент (как вы увидите в следующей статье) довольно прост, но как насчет вашего мультимедийного контента, и красивой 3D-графики? Вы должны смотреть на свой бюджет проекта и реально думать о том, какие решения у вас есть, чтобы сделать такой контент доступным? Вы можете заплатить за расшифровку всего вашего мультимедийного контента, это может быть дорогостоящим, но будет сделано.</p> + +<p>Кроме того, будьте реалистами. "100% доступность" является недостижимым идеалом — вы всегда столкнетесь с каким-то случаем, который приводёт к тому, что определенный пользователь найдёт определенный контент трудным в использовании, но вы должны сделать столько, сколько сможете. Если вы планируете использовать трехмерную круговую диаграмму, созданную с помощью WebGL, вы можете включить таблицу данных в качестве доступного альтернативного представления данных. Или, вы можете просто включить таблицу и избавиться от 3D круговой диаграммы-таблица доступна для всех, быстрее кодировать, меньше ресурсов процессора, и проще в обслуживании.</p> + +<p>С другой стороны, если вы работаете на веб-сайте галереи с интересным трехмерным искусством, было бы неразумно ожидать, что каждое произведение искусства будет идеально доступно для людей с нарушениями зрения, учитывая, что это полностью визуальная среда.</p> + +<p>Чтобы показать, что вы заботитесь о доступности и думали о ней, опубликуйте на своем сайте заявление о доступности, в котором подробно излагается, какова ваша политика в отношении доступности, и какие шаги вы предприняли для обеспечения доступности сайта. Если кто-то жалуется, что у вашего сайта есть проблема с доступностью, начните с ним диалог, проявите сочувствие и примите разумные меры, чтобы попытаться устранить проблему.</p> + +<div class="note"> +<p><strong>Note</strong>: В нашей статье <a href="https://developer.mozilla.org/ru/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Text_alternatives">«Об общих проблемах доступности»</a> рассматриваются особенности доступности, которые необходимо протестировать более подробно.</p> +</div> + +<p>Подведём итоги:</p> + +<ul> + <li>Думайте о доступности с самого начала проекта, тестируйте рано и часто. Как и любая другая ошибка, проблема доступности становится более дорогой, чтобы исправлять её позже.</li> + <li>Имейте в виду, что многие рекомендации по доступности выгодны всем, а не только пользователям с ограниченными возможностями. Например, семантическая разметка полезна не только для программ чтения с экрана, но и для быстрой загрузки и повышения производительности, так лучше для всех, особенно для мобильных устройств, и/или для медленных соединений.</li> + <li>Опубликуйте заявление о доступности на своем сайте и общайтесь с людьми, у которых есть проблемы.</li> +</ul> + +<h2 id="Руководство_по_доступности_и_закон">Руководство по доступности и закон</h2> + +<p>Существует множество чеклистов и наборов руководств, на которых можно основываться при тестировании доступности, которые на первый взгляд могут показаться ошеломляющими. Наш совет — ознакомиться с основными областями, о которых вам необходимо позаботиться, а также понять структуры руководящих принципов, которые наиболее актуальны для вас.</p> + +<ul> + <li>Для начала, W3C опубликовал большой и очень подробный документ, который включает в себя очень точные, независимые от технологии критерии соответствия доступности. Они называются <a class="external external-icon" href="https://www.w3.org/Translations/WCAG20-ru/WCAG20-ru-20130220/">Рекомендациями по доступности веб-контента</a> (<a class="external external-icon" href="https://www.w3.org/WAI/intro/wcag.php">Web Content Accessibility Guidelines</a> — WCAG), и они никоим образом не являются кратким описанием. Критерии разделяются на четыре основные категории, которые определяют, как реализации можно сделать восприимчивыми, работоспособными, понятными и устойчивыми. Лучшее место, чтобы получить легкое представление и начать обучение это <a class="external external-icon" href="https://www.w3.org/WAI/WCAG20/glance/Overview.html">WCAG at a Glance</a>. Нет необходимости изучать WCAG наизусть — знайте об основных проблемных областях и используйте различные методы и инструменты, чтобы выделить любые области, которые не соответствуют критериям WCAG (подробнее см. ниже).</li> + <li>В вашей стране также может быть предусмотрено специальное законодательство, регулирующее необходимость обеспечения доступности веб-сайтов, обслуживающих их население, например, <a class="external external-icon" href="http://www.section508.gov/content/learn">Раздел 508 Закона о реабилитации</a> в США, <a class="external external-icon" href="https://www.einfach-fuer-alle.de/artikel/bitv_english/">Федеральное постановление о безбарьерных информационных технологиях</a> в Германии, <a class="external external-icon" href="http://www.legislation.gov.uk/ukpga/2010/15/contents">Закон о равенстве</a> в Великобритании, <a class="external external-icon" href="http://www.agid.gov.it/agenda-digitale/pubblica-amministrazione/accessibilita">Accessibilità</a> в Италии, <a class="external external-icon" href="https://www.humanrights.gov.au/world-wide-web-access-disability-discrimination-act-advisory-notes-ver-41-2014">Закон о дискриминации инвалидов</a> в Австралии и т.д.</li> +</ul> + +<p>Поэтому, хотя WCAG представляет собой набор руководств, в вашей стране, вероятно, будут приняты законы, регулирующие доступность веба или, по крайней мере, доступность обществественных услуг (которые могут включать в себя веб-сайты, телевидение, физические пространства и т.д.). Это хорошая идея — узнать, каковы ваши законы. Если вы не предпримете никаких усилий, чтобы проверить, что ваш контент доступен, у вас могут возникнуть проблемы с законом, если люди с ограниченными возможностями жалуются на это.</p> + +<p>Это звучит серьезно, но на самом деле вам просто нужно рассматривать доступность в качестве основного приоритета вашей практики веб-разработки, как описано выше. В случае сомнений обратитесь за советом к квалифицированному юристу. Мы не собираемся предлагать больше советов, чем эти, потому что мы не юристы.</p> + +<h2 id="Специальные_API_доступа">Специальные API доступа</h2> + +<p>Веб-браузеры используют <strong>специальные API доступа</strong> (предоставляемые базовой операционной системой) которые предоставляют информацию, полезную для вспомогательных технологий (AT). AT обычно используют семантическую информацию, поэтому эта информация не включает такие вещи, как информация о стилях или JavaScript. Эта информация структурирована в дереве информации, которое называется <strong>деревом доступности</strong>.</p> + +<p>Различные операционные системы имеют разные API доступа:</p> + +<ul> + <li>Windows: MSAA/IAccessible, UIAExpress, IAccessible2</li> + <li>Mac OS X: NSAccessibility</li> + <li>Linux: AT-SPI</li> + <li>Android: Accessibility framework</li> + <li>iOS: UIAccessibility</li> +</ul> + +<p>Там, где нативная семантическая информация, предоставляемая элементами HTML в ваших веб-приложениях, падает, вы можете дополнить ее функциями из <a class="external" href="https://www.w3.org/TR/wai-aria/">спецификации WAI-ARIA</a>, которые добавляют семантическую информацию в дерево доступности для улучшения доступности. Вы можете узнать больше о WAI-ARIA в нашей статье <a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">основы WAI-ARIA</a>.</p> + +<h2 id="Заключение">Заключение</h2> + +<p>Эта статья должна была дать вам полезный обзор специальных возможностей, показать, почему это так важно, и посмотреть, как вы можете вписать его в свой рабочий процесс. Теперь у вас также должна быть жажда узнать о деталях реализации, которые помогут сделать сайты доступными, и мы начнем с этого в следующем разделе, рассматривая, почему HTML является хорошей основой для доступности.</p> + +<p>{{NextMenu("Learn/Accessibility/HTML", "Learn/Accessibility")}}</p> + +<h2 id="В_этом_модуле">В этом модуле</h2> + +<ul> + <li><a href="/ru/docs/Learn/Доступность/What_is_accessibility">Что такое доступность?</a></li> + <li><a href="/ru/docs/Learn/Accessibility/HTML">HTML: Хорошая основа для доступности</a></li> + <li><a href="/ru/docs/Learn/Accessibility/CSS_and_JavaScript">CSS и JavaScript доступность - лучшие практики</a></li> + <li><a href="/ru/docs/Learn/Accessibility/WAI-ARIA_basics">Основы WAI-ARIA</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Multimedia">Доступность мультимедиа</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Mobile">Мобильная доступность</a></li> + <li><a href="/ru/docs/Learn/Accessibility/Accessibility_troubleshooting">Устранение проблем доступности</a></li> +</ul> |