From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- .../aria/aria_live_regions/index.html | 111 +++++ .../accessibility/aria/aria_techniques/index.html | 169 +++++++ .../index.html | 87 ++++ .../using_the_aria-label_attribute/index.html | 68 +++ .../using_the_aria-labelledby_attribute/index.html | 140 ++++++ files/ru/web/accessibility/aria/index.html | 123 +++++ .../aria/roles/checkbox_role/index.html | 149 ++++++ files/ru/web/accessibility/aria/roles/index.html | 80 ++++ .../ru/web/accessibility/at-apis/gecko/index.html | 9 + .../accessibility/at-apis/gecko/roles/index.html | 498 +++++++++++++++++++++ .../at-apis/gecko/roles/role_document/index.html | 31 ++ .../gecko/roles/role_password_text/index.html | 27 ++ files/ru/web/accessibility/at-apis/index.html | 176 ++++++++ files/ru/web/accessibility/index.html | 54 +++ .../index.html | 206 +++++++++ .../mobile_accessibility_checklist/index.html | 90 ++++ .../accessibility/understanding_wcag/index.html | 59 +++ .../understanding_wcag/keyboard/index.html | 87 ++++ .../perceivable/color_contrast/index.html | 56 +++ .../understanding_wcag/perceivable/index.html | 359 +++++++++++++++ .../index.html" | 50 +++ 21 files changed, 2629 insertions(+) create mode 100644 files/ru/web/accessibility/aria/aria_live_regions/index.html create mode 100644 files/ru/web/accessibility/aria/aria_techniques/index.html create mode 100644 files/ru/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html create mode 100644 files/ru/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html create mode 100644 files/ru/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html create mode 100644 files/ru/web/accessibility/aria/index.html create mode 100644 files/ru/web/accessibility/aria/roles/checkbox_role/index.html create mode 100644 files/ru/web/accessibility/aria/roles/index.html create mode 100644 files/ru/web/accessibility/at-apis/gecko/index.html create mode 100644 files/ru/web/accessibility/at-apis/gecko/roles/index.html create mode 100644 files/ru/web/accessibility/at-apis/gecko/roles/role_document/index.html create mode 100644 files/ru/web/accessibility/at-apis/gecko/roles/role_password_text/index.html create mode 100644 files/ru/web/accessibility/at-apis/index.html create mode 100644 files/ru/web/accessibility/index.html create mode 100644 files/ru/web/accessibility/keyboard-navigable_javascript_widgets/index.html create mode 100644 files/ru/web/accessibility/mobile_accessibility_checklist/index.html create mode 100644 files/ru/web/accessibility/understanding_wcag/index.html create mode 100644 files/ru/web/accessibility/understanding_wcag/keyboard/index.html create mode 100644 files/ru/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html create mode 100644 files/ru/web/accessibility/understanding_wcag/perceivable/index.html create mode 100644 "files/ru/web/accessibility/\320\262\320\265\320\261-\321\200\320\260\320\267\321\200\320\260\320\261\320\276\321\202\320\272\320\260/index.html" (limited to 'files/ru/web/accessibility') diff --git a/files/ru/web/accessibility/aria/aria_live_regions/index.html b/files/ru/web/accessibility/aria/aria_live_regions/index.html new file mode 100644 index 0000000000..6f22cb75a6 --- /dev/null +++ b/files/ru/web/accessibility/aria/aria_live_regions/index.html @@ -0,0 +1,111 @@ +--- +title: ARIA Live Regions +slug: Web/Accessibility/ARIA/ARIA_Live_Regions +translation_of: Web/Accessibility/ARIA/ARIA_Live_Regions +--- +

Introduction

+ +

In the past, a web page change could only be spoken in entirety which often annoyed a user, or by speaking very little to nothing, making some or all information inaccessible. Until recently, screen readers have not been able to improve this because no standardized markup existed to alert the screen reader to a change. ARIA live regions fill this gap and provide suggestions to screen readers regarding whether and how to interrupt users with a change.

+ +

Simple Live Regions

+ +

Dynamic content which updates without a page reload is generally either a region or a widget. Simple content changes which are not interactive should be marked as live regions. Below is a list of each related ARIA live region property with a description.

+ +
    +
  1. aria-live: The aria-live=POLITENESS_SETTING is used to set the priority with which screen reader should treat updates to live regions - the possible settings are: off/polite/assertive. The default setting is 'off'. This attribute is by far the most important.
  2. +
  3. +

    aria-controls: The aria-controls=[IDLIST] is used to associate a control with the regions that it controls. Regions are identified just like an ID in a div, and multiple regions can be associated with a control using a space, e.g. aria-controls="myRegionID1 myRegionsID2".

    + +
    Not known if the aria-controls aspect of live regions is implemented in current ATs, or which. Needs research.
    +
  4. +
+ +

Normally, only aria-live="polite" is used. Any region which receives updates that are important for the user to receive, but not so rapid as to be annoying, should receive this attribute. The screen reader will speak changes whenever the user is idle.

+ +

For regions which are not important, or would be annoying because of rapid updates or other reasons, silence them with aria-live="off".

+ +

Simple Use Case: combobox updates useful on-screen information

+ +

A website specializing in providing information about birds provides a drop down box. When a bird is selected from the drop down, a region on the page is updated with details about the type of bird selected.

+ +

<select size="1" id="bird-selector" aria-controls="bird-info"><option> .... </select>

+ +

<div role="region" id="bird-info" aria-live="polite">

+ +

As the user selects a new bird, the info is spoken. Because "polite" is chosen, the screen reader will wait until the user pauses. Thus, moving down the list will not speak every bird the user visits, only the one finally chosen.

+ +

Preferring Specialized Live Region Roles

+ +

In the following well-known predefined cases it is better to use a specific provided "live region role":

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RoleDescriptionCompatibility Notes
logChat, error, game or other type of logTo maximize compatibility, add a redundant aria-live="polite" when using this role.
statusA status bar or area of the screen that provides an updated status of some kind. Screen reader users have a special command to read the current status.To maximize compatibility, add a redundant aria-live="polite" when using this role.
alertError or warning message that flashes on the screen. Alerts are particularly important for client side validation notices to users. (TBD: link to ARIA form tutorial with aria info)To maximize compatibility, some people recommend adding a redundant aria-live="assertive" when using this role. However, adding both aria-live and role=alert causes double speaking issues in VoiceOver on iOS.
progressbarA hybrid between a widget and a live region. Use this with aria-valuemin, aria-valuenow and aria-valuemax. (TBD: add more info here). 
marqueefor text which scrolls, such as a stock ticker. 
timeror any kind of timer or clock, such as a countdown timer or stopwatch readout. 
+ +

Advanced Live Regions

+ +

(TBD: what is supported where?)

+ +
    +
  1. aria-atomic: The aria-atomic=BOOLEAN is used to set whether or not the screen reader should always present the live region as a whole, even if only part of the region changes - the possible settings are false/true where false is the default.
  2. +
  3. aria-relevant: The aria-relevant=[LIST_OF_CHANGES] is used to set what types of changes are relevant to a live region - the possible settings are additions/removals/text/all where "additions text" is the default.
  4. +
  5. aria-labelledby: The aria-labelledby=[IDLIST] is used to associate a region with its labels, similar to aria-controls but instead associating labels to the region and again label identifiers are separated with a space.
  6. +
  7. aria-describedby: The aria-describedby=[IDLIST] is used to associate a region with its descriptions, similar to aria-controls but instead associating descriptions to the region and description identifiers are separated with a space.
  8. +
+ +

Advanced Use Case: Roster

+ +

A chat site would like to display a list of users currently logged on. Display a list of users where a user's log-in and log-out status will be reflected dynamically (without a page reload).

+ +
<ul id="roster" aria-live="polite" aria-relevant="additions removals">
+	<!-- use JavaScript to add remove users here-->
+</ul>
+
+ +

Breakdown of ARIA live properties:

+ + + +

TBD: Realistic use case for aria-atomic="true"

diff --git a/files/ru/web/accessibility/aria/aria_techniques/index.html b/files/ru/web/accessibility/aria/aria_techniques/index.html new file mode 100644 index 0000000000..2e29856a5c --- /dev/null +++ b/files/ru/web/accessibility/aria/aria_techniques/index.html @@ -0,0 +1,169 @@ +--- +title: Использование ARIA +slug: Web/Accessibility/ARIA/ARIA_Techniques +tags: + - ARIA + - Accessibility + - NeedsTranslation + - TopicStub +translation_of: Web/Accessibility/ARIA/ARIA_Techniques +--- +

 

+ +

 Роли

+ +

 

+ +

Роли виджета

+ +
+ +
+ +

Композиционные роли

+ +

Приведенные ниже методы описывают каждую композиционную роль, а также их требуемые и необязательные дочерние роли.

+ +
+ +
+ +

Document structure roles

+ +
+ +
+ +

Landmark roles

+ +
+ +
+ +

States and properties

+ +

 

+ +

Widget attributes

+ +
+ +
+ +

Live region attributes

+ +
+ +
+ +

Drag & drop attributes

+ +
+ +
+ +

Relationship attributes

+ +
+ +
diff --git a/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html new file mode 100644 index 0000000000..c23c3725b4 --- /dev/null +++ b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-describedby_attribute/index.html @@ -0,0 +1,87 @@ +--- +title: Использование атрибута aria-describedby +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute +tags: + - доступность +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute +--- +

Описание

+ +

Атрибут aria-describedby используется для указания ID элементов, описывающих объект. Он используется для установления отношений между элементами управления или группами и текстом, описывающим их. Это очень похоже на aria-labelledby: лэйбл описывает сущность объекта, в то время как описание предоставляет дополнительную информацию, которая может понадобиться пользователю.

+ +

Атрибут aria-describedby используется не только для элементов форм; он, также, используется для связывания статического текста с элементами управления, группами элементов, панелями, областями, которые имеют заголовок, определениями, и др. В разделе {{ anch("Examples") }} ниже приведено больше информации о том как использовать атрибут в этих случаях.

+ +

Этот атрибут может использоваться с любым типичным элементом HTML-форм; он не ограничивается элементами, которым назначена  ARIA role .

+ +

Значение

+ +

разделенный пробелами список ID элементов

+ +

Возможные последствия для пользовательских агентов и вспомогательных технологийP

+ + + +
Примечание: Мнения о том, как вспомогательная технология должна справляться с этой техникой, могут отличаться. Приведенная выше информация является одним из таких мнений и поэтому не носит нормативного характера.
+ +

Примеры

+ +

Пример 1: Связвание приложения и описания

+ +

В примере ниже, вводный параграф описывает приложение календаря. aria-describedby используется для связывания параграфа с контейнером приложения.

+ +
<div role="application" aria-labelledby="calendar" aria-describedby="info">
+    <h1 id="calendar">Calendar</h1>
+    <p id="info">
+        This calendar shows the game schedule for the Boston Red Sox.
+    </p>
+    <div role="grid">
+        ...
+    </div>
+</div>
+
+ +

Пример 2: Кнопка закрытия

+ +

В примере ниже, ссылка, которая функционирует как кнопка закрытия диалога, описана в другом месте документа. Атрибут aria-describedby используется для связывания описания с ссылкой.

+ +
<button aria-label="Close" aria-describedby="descriptionClose"
+    onclick="myDialog.close()">X</button>
+
+...
+
+<div id="descriptionClose">Closing this window will discard any information entered and
+return you back to the main page</div>
+
+ +

Рабочие примеры:

+ + + +

Примечания

+ + + +

Использование ARIA ролей

+ +

все элементы базовой разметки

+ +

Связанные ARIA методы

+ + + +

Совместимость

+ +

TBD: добавить информацию о поддержке для общих UA и AT комбинаций продуктов

+ +

Дополнительные ресурсы

+ + diff --git a/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html new file mode 100644 index 0000000000..b76b9de8c8 --- /dev/null +++ b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-label_attribute/index.html @@ -0,0 +1,68 @@ +--- +title: Использование атрибута aria-label +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +tags: + - ARIA + - HTML + - aria-label + - Клиент + - доступность +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-label_attribute +--- +

Атрибут  aria-label  создаёт текстовую метку текущего элемента в случае отсутствия видимого текста описания элемента. Если есть видимый текст, обозначающий элемент, используйте вместо этого aria-labelledby.

+ +

Этот атрибут может быть использован для любого стандартного HTML элемента; не ограничивается элементами с ARIA role.

+ +

Значение

+ +

строка

+ +

Возможные эффекты на клиентские приложения и вспомогательные технологии

+ +
+

Edit section

+
+ +
Примечание: Мнения могут отличаться от того, как вспомогательные технологии должны справляться с этой техникой. Информация, представленная выше, является одним из таких мнений и поэтому не является нормативной.
+ +

Примеры

+ +
+

Пример 1: Множественные лейблы

+ +

В примере ниже, кнопка стилизована под типичную кнопку "закрыть" с X посередине. Поскольку нет ничего обозначающего значение того, что кнопка закрывает диалог, то aria-label атрибут используется чтобы обеспечить метку для любой вспомогающей технологии.

+
+ +
<button aria-label="Close" onclick="myDialog.close()">X</button>
+
+ +

Рабочие примеры:

+ +

Заметки

+ + + +

Использование ARIA ролями

+ +

Все элементы базовой разметки

+ +

Связанные ARIA техники

+ + + +

Совместимость

+ +

Будет определено позднее: Добавить информацию о поддержке для общих комбинаций продуктов UA и AT

+ +

Дополнительные ресурсы

+ + diff --git a/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html new file mode 100644 index 0000000000..8736fc801a --- /dev/null +++ b/files/ru/web/accessibility/aria/aria_techniques/using_the_aria-labelledby_attribute/index.html @@ -0,0 +1,140 @@ +--- +title: Использование атрибута aria-labelledby +slug: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute +translation_of: Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-labelledby_attribute +--- +

Описание

+ +

Атрибут aria-labelledby содержит идентификаторы (атрибут id) меток для таких обьектов как элементы ввода (input), виджеты, группы. Атрибут создаёт связь между обьектами и их метками. Вспомогательные технологии, такие как средства чтения экрана, используют этот атрибут чтобы собирать все метки в каталог документа, из которого пользователь может перемещаться между ними. Без идентификатора (атрибута id) вспомогательные технологии не могут собрать данные обьекты в каталог.

+ +

aria-labelledby очень похож на aria-describedby: Метка (label) предоставляет основную информацию об обьекте, в то время как описание (description) даёт более полную/детальную информацию которая может понадобится пользователю.

+ +

В дополнение к элементам формы вы можете использовать атрибут aria-labelledby, чтобы связать статический текст с виджетами, группами элементов, панелями, областями, которые имеют заголовок, определения и другие типы объектов. Ниже, в разделе {{ anch("Примеры") }} приведенны примеры и информация как использовать атрибут в данном виде.

+ +

Чтобы повысить совместимость с клиетскими приложениями которые не поддерживают ARIA атрибуты, вы можете использовать aria-labelledby вместе элементом {{ HTMLElement("label") }} (используя for атрибут)

+ +

Этот атрибут может быть использован в любом типичном HTML элементе формы, он не ограничен элементами которые имеют атрибут ARIA role

+ +

Значение

+ +

Список идентификаторов (id) разделенных пробелом

+ +

Возможные эфекты в клиентских приложениях и вспомогательных технологиях

+ +

Когда клиенсткое приложение вычисляют доступное имя элемента который имеет и атрибут aria-labelledby, и атрибут aria-label, они отдадут приоритет aria-labelledby

+ +

Примеры

+ +

Example 1: Multiple Labels

+ +

In the example below, each input field is labelled by both its own individual label and by the label for the group:

+ +
<div id="billing">Billing</div>
+
+<div>
+    <div id="name">Name</div>
+    <input type="text" aria-labelledby="billing name"/>
+</div>
+<div>
+    <div id="address">Address</div>
+    <input type="text" aria-labelledby="billing address"/>
+</div>
+
+ +

Example 2: Associating Headings With Regions

+ +

In the example below, header elements are associated with the content they head. Note that the region being referenced is the region that contains the header.

+ +
<div role="main" aria-labelledby="foo">
+   <h1 id="foo">Wild fires spread across the San Diego Hills</h1>
+   Strong winds expand fires ignited by high temperatures ...
+</div>
+
+ +

Example 3: Radio Groups

+ +

In the example below, the container of a radiogroup is associated with its label using the aria-labelledby attribute:

+ +
<div id="radio_label">My radio label</div>
+<ul role="radiogroup" aria-labelledby="radio_label">
+    <li role="radio">Item #1</li>
+    <li role="radio">Item #2</li>
+    <li role="radio">Item #3</li>
+</ul>
+
+ +

Example 4: Dialog Label

+ +

In the example below, the header element that labels the dialog is referred to by the aria-labelledby attribute:

+ +
<div role="dialog" aria-labelledby="dialogheader">
+    <h2 id="dialogheader">Choose a File</h2>
+    ... Dialog contents
+</div>
+
+ +

Example 5: Inline Definition

+ +

In the example below, the definition of a term that is described in the natural flow of the narrative is associated with the term itself using the aria-labelledby attribute:

+ +
<p>The doctor explained it had been a <dfn id="placebo">placebo</dfn>, or <span role="definition" aria-labelledby="placebo">
+an inert preparation prescribed more for the mental relief of the patient than for its actual effect on a disorder.</span>
+</p>
+
+ +

Example 6: Definition Lists

+ +

In the example below, the definitions in a formal definition list are associated with the terms they define using the aria-labelledby attribute:

+ +
<dl>
+    <dt id="anathema">anathema</dt>
+    <dd role="definition" aria-labelledby="anathema">a ban or curse solemnly pronounced by ecclesiastical authority
+                                                     and accompanied by excommunication</dd>
+    <dd role="definition" aria-labelledby="anathema">a vigorous denunciation : cursor</dd>
+
+    <dt id="homily">homily</dt>
+    <dd role="definition" aria-labelledby="homily">a usually short sermon</dd>
+    <dd role="definition" aria-labelledby="homily">a lecture or discourse on or of a moral theme</dd>
+</dl>
+
+ +

Example 7: Menus

+ +

In the example below, a popup menu is associated with its label using the aria-labelledby attribute:

+ +
<div role="menubar">
+    <div role="menuitem" aria-haspopup="true" id="fileMenu">File</div>
+    <div role="menu" aria-labelledby="fileMenu">
+        <div role="menuitem">Open</div>
+        <div role="menuitem">Save</div>
+        <div role="menuitem">Save as ...</div>
+        ...
+    </div>
+    ...
+</div>
+
+ +

Notes 

+ +

The most common accessibility API mapping for a label is the accessible name property

+ +

Used by ARIA roles

+ +

All elements of the base markup

+ + + + + +

Compatibility

+ +

TBD: Add support information for common UA and AT product combinations

+ +

Additional resources

+ + diff --git a/files/ru/web/accessibility/aria/index.html b/files/ru/web/accessibility/aria/index.html new file mode 100644 index 0000000000..b2dc0f6ec3 --- /dev/null +++ b/files/ru/web/accessibility/aria/index.html @@ -0,0 +1,123 @@ +--- +title: ARIA +slug: Web/Accessibility/ARIA +tags: + - ARIA + - Web + - доступность +translation_of: Web/Accessibility/ARIA +--- +

Accessible Rich Internet Applications (ARIA) определяет способ сделать веб контент и веб приложения (особенно те, которые разработаны с помощью Ajax и JavaScript) более доступными для людей с ограниченными возможностями. Например, ARIA делает доступным навигационные маркеры, JavaScript виджеты, подсказки на форме, сообщения об ошибках, автоматические обновления и многое другое.

+ +

ARIA - это набор специальных атрибутов, которые могут быть добавлены в любую разметку,  но особенно подходят для HTML. Атрибут role определяет тип объекта (такие как статья, оповещение или ползунок). Дополнительные ARIA атрибуты предоставляют другие полезные возможности, такие как описания для форм или текущее значение индикатора выполнения.

+ +

Поддержка ARIA реализована в большинстве современных браузеров и программах экранного доступа. Конечно, реализации различаются, и старые технологии не поддерживают их полностью (либо вообще не поддерживают). Используйте постепенно деградирующий "щадящий" ARIA, или просите пользователей использовать новые технологии.

+ +
+

Note: Пожалуйста, примите участие в написании и/или переводе статей чтобы сделать ARIA понятнее и доступнее для тех, кто только начинает изучать материал! Не хватает на это времени? Тогда отправьте свои предложения в список рассылки Mozilla по теме accessibility, или на IRC каналс тэгом #accessibility.

+
+ +
+
+

Начало работы с ARIA

+ +
+
Введение в ARIA
+
Быстрое введение в превращение динамического контента в доступный с помощью ARIA. Смотрите также классическую статью ARIA intro by Gez Lemon, from 2008.
+
Web Applications and ARIA FAQ
+
Ответы на часто задаваемые вопросы о том как и почему нужно использовать ARIA в разработке интерфейсов веб-приложений.
+
Записи использования экранных читалок с ARIA.
+
На этих видео можно увидеть реальные и учебные примеры того ARIA улучшает доступность.
+
Использование ARIA в HTML
+
Практическое руководство для разработчиков. Содержит рекомендации по использованию ARIA-атрибутов при разметке.
+
+ +

Простое улучшение ARIA

+ +
+
Улучшение навигации по странице с помощью ARIA Landmarks
+
Хорошее введение в использование ARIA landmarks для улучшения навигации для пользователей с экранными читалками. Стоит также заглянуть в заметки по поддержке ARIA landmarks читалками и примеры использования на реальных сайтах (опубликовано в Июле 2011).
+
Улучшение доступности форм
+
ARIA используется не только для обозначения динамического контента! Узнайте, как улучшить доступность форм HTML используя дополнительные ARIA-атрибуты.
+
Live regions (в процессе написания)
+
Live regions подсказывают экранным читалкам как правильно обрабатывать изменения контента на странице.
+
Использование ARIA Live Regions для оповещения об изменении контента страницы
+
Краткая сводка об использовании live regions от создателей JAWS screen reader software. Live regions также поддерживаются NVDA в Firefox и VoiceOver в Safari.
+
+ +

ARIA для виджетов на JavaScript.

+ +
+
Навигация с помощью клавиатуры и фокус в виджетах на JavaScript
+
Первый шаг в создании доступных JavaScript виджетов, позволяющих производить навигацию с помощью клавиатуры. Статья описывает последовательные шаги по достижению цели. Еще один хороший ресурс - статья Yahoo! об управлении фокусом.
+
Style Guide for Keyboard Navigation
+
В этом руководстве описываются способы управления самыми распространенными виджетами с клавиатуры.
+
+ +

Дополнительные ресурсы по ARIA

+ +
+
Виджеты. Техники, руководства, примеры.
+
Нужен слайдер, меню или другой виджет? здесь вы можете найти все, что нужно
+
JavaScript UI библиотеки со встроенной поддержкой ARIA.
+
Если вы начинаете новый проект, то вам стоит обратить внимание на UI библиотеки, имеющие встроенную поддержку ARIA. Внимание: статья 2009 года — то, что она описывает, стоит вынести в отдельную статью на MDN, которая будет поддерживаться в актуальном состоянии.
+
+
+ +
+

Список рассылки.

+ +
+
Открытая Google Group, посвященная ARIA
+
Здесь можно задать вопрос об ARIA, а также предложить улучшение существующей документации, которая находится там же.
+
+ +

Блоги

+ +

Хотя информация в блогах быстро теряет актуальность, все же в них можно почерпнуть ценную информацию из первых рук - разработчиков, развивающих ARIA.

+ +

Paciello Group

+ +

Accessible Culture

+ +

Обнаружение багов.

+ +

Сообщайте об ошибках ARIA в браузерах, экранных читалках и библиотеках JavaScript.

+ +

Примеры

+ +
+
ARIA. Библиотека примеров.
+
Набор примеров по которым можно многому научиться.
+
Различные демки библиотек с доступными JS виджетами.
+
jQuery, YUI
+
Yahoo! Mail
+
Детище Yahoo! - Yahoo! Mail, веб-приложение, выглядящее практически как нативное и вполне доступное. После обзора Yahoo! Mail с использованием экранной читалки Marco Zehe сказал: "Хорошая работа, не сбавляйте обороты!".
+
Yahoo! Search
+
Yahoo! проделали невероятную работу по продвижению ARIA в своем поисковике, используя все возможности и делясь своим опытом. Yahoo! Search использует одновременно ARIA landmarks, live regions, и widgets.
+
+ +

Стандартизация.

+ +
+
WAI-ARIA Activities Overview at W3C
+
Authoritative Overview of WAI-ARIA Standardization efforts by the Web Accessibility Initiative (WAI)
+
WAI-ARIA Specification
+
The W3C specification itself, useful as a reference. Note that, at this stage, it is important to test compatibility, as implementations are still inconsistent.
+
WAI-ARIA Authoring Practices
+
+

Like the W3C WAI-ARIA specification, the official best practices represents a future ideal — a day when authors can rely on consistent ARIA support across browsers and screen readers. The W3C documents provide an in-depth view of ARIA.

+ +

For now, web developers implementing ARIA should maximize compatibility. Use best practices docs and examples based on current implementations.

+
+
Open AJAX Accessibility Task Force
+
The Open AJAX effort centers around developing tools, sample files, and automated tests for ARIA.
+
Under Construction: WCAG 2.0 ARIA Techniques
+
The community needs a complete set of WCAG techniques for WAI-ARIA + HTML, so that organizations can be comfortable claiming their ARIA-enabled content is WCAG compliant. This is important when regulations or policies are based on WCAG.
+
+
+
+ + + +

Accessibility, AJAX, JavaScript

diff --git a/files/ru/web/accessibility/aria/roles/checkbox_role/index.html b/files/ru/web/accessibility/aria/roles/checkbox_role/index.html new file mode 100644 index 0000000000..b9eb71997d --- /dev/null +++ b/files/ru/web/accessibility/aria/roles/checkbox_role/index.html @@ -0,0 +1,149 @@ +--- +title: 'ARIA: checkbox role' +slug: Web/Accessibility/ARIA/Roles/checkbox_role +translation_of: Web/Accessibility/ARIA/Roles/checkbox_role +--- +

\{{ariaref}}

+ +

checkbox role используется для переключаемых интерактивных элементов управления. Элементы, содержащие role="checkbox" также должны включать aria-checked атрибут, чтобы продемонстрировать состояние чекбокса ассистивным технологиям.

+ +
<span role="checkbox" aria-checked="false" tabindex="0" aria-labelledby="chk1-label">
+</span> <label id="chk1-label">Remember my preferences</label>
+ +

Первое правило ARIA -  если у нативного HTML элемента или атрибута присутствует небходимая семантика или поведение, следует использовать его, а не использовать другой элемент не по назначению, добавляя ARIA. Вместо этого лучше использовать HTML checkbox  <input type="checkbox">, который изначально предоставляет необходимый функционал:

+ +
<input type="checkbox" id="chk1-label">
+<label for="chk1-label">Запомнить мои предпочтения</label>
+ +

Описание

+ +

Нативный HTML checkbox  элемент управления может находиться только в двух состояниях отмеченности - "отмечен" или "не отмечен", с неопределенным состоянием, устанавливаемым с помощью JavaScript. Аналогично элемент с role="checkbox"  может находиться в трех состояниях, обозначенных через aria-checked атрибут: true, false, or mixed.

+ +

Поскольку чекбокс является интерактивным элементом, он должен быть фокусируемым и доступным при помощи клавиатуры. Если роль установлена для нефокусируемого элемента, чтобы исправить ситуацию, используйте атрибут tabindex. Ожидаемый способ активации чекбокса при помощи клавиатуры - Пробел .

+ +

Разработчику необходимо динамически изменять значение атрибута aria-checked при активации чекбокса.

+ +

Связанные WAI-ARIA Роли, Состояния, и Свойства

+ +
+
+ +
+
aria-checked
+
+

Значение aria-checked определяет состояние чекбокса. Этот атрибут может принимать одно из трех значений:

+ +

true
+     Чекбокс отмечен
+ false
+     Чекбокс не отмечен
+ mixed
+     Чекбокс частично отмечен, или в неопределенном состоянии

+
+
tabindex="0"
+
Делает элемент фокусируемым, так что пользователь ассистивных технологий может сразу перейти к нему и начать читать.
+
+ +

Взаимодействие с клавиатурой

+ + + + + + + + + + + + +
КлавишаФункция
ПробелАктивирует чекбокс
+ +

Необходимый JavaScript

+ +

Необходимый обработчики событий

+ +
+
onclick
+
Обрабатывает клики, которые изменяют состояние чекбокса, меняя значение атрибута aria-checked и внешний вид чекбокса так, чтобы он выглядел отмеченным млм неотмеченным для зрячего пользователя.
+
onKeyPress
+
Обрабатывает случай, когда пользователь нажимает Пробел для смены состояния чекбокса путем изменения значения атрибута aria-checked и внешнего вида чекбокса так, чтобы он выглядел отмеченным млм неотмеченным для зрячего пользователя.
+
+ +
+
+ +

Примеры

+ +

Пример ниже создает простой чекбокс, используя CSS и JavaScript для обработкиотмеченного и неотмеченного состояний элемента.

+ +

HTML

+ +
<span role="checkbox" id="chkPref" aria-checked="false" onclick="changeCheckbox()" onKeyPress="changeCheckbox()"
+   tabindex="0" aria-labelledby="chk1-label"></span>
+<label id="chk1-label" onclick="changeCheckbox()" onKeyPress="changeCheckbox()">Запомнить мои предпочтения</label>
+ +

CSS

+ +
[role="checkbox"] {
+    padding:5px;
+}
+
+[aria-checked="true"]::before {
+    content: "[x]";
+}
+
+[aria-checked="false"]::before {
+    content: "[ ]";
+}
+ +

JavaScript

+ +
function changeCheckbox(event) {
+    let item = document.getElementById('chkPref');
+    switch(item.getAttribute('aria-checked')) {
+        case "true":
+            item.setAttribute('aria-checked', "false");
+            break;
+        case "false":
+            item.setAttribute('aria-checked', "true");
+            break;
+    }
+}
+ +

{{EmbedLiveSample("Examples", 230, 250)}}

+ +

Проблемы доступности

+ +

Когда checkbox роль добавлена к элементу, юзер агент должен сделать следующее:

+ + + +

Продукты, использующие ассистивные технологии должны сделать следующее:

+ + + +
Замечание: Мнения относительно того, как ассистивные технологии должны работать в таких случаях, отличаются. Информация, приведенная выше, также одно из таких мнений, и не является нормативом.
+ +

Лучшие практики

+ +

Первое правило ARIA - если у нативного HTML элемента или атрибута присутствует небходимая семантика или поведение, следует использовать его, а не использовать другой элемент не по назначению, добавляя ARIA, чтобы сделать его доступным. По существу, рекомендуется использовать нативный HTML checkbox  вместо воспроизведения функциональности чекбокса с помощью JavaScript и ARIA.

+ +

Смотрите также:

+ + + +

 

diff --git a/files/ru/web/accessibility/aria/roles/index.html b/files/ru/web/accessibility/aria/roles/index.html new file mode 100644 index 0000000000..b86909d5a7 --- /dev/null +++ b/files/ru/web/accessibility/aria/roles/index.html @@ -0,0 +1,80 @@ +--- +title: WAI-ARIA Roles +slug: Web/Accessibility/ARIA/Roles +tags: + - ARIA + - ARIA Roles + - Accessibility + - NeedsTranslation + - Reference + - Rôles + - TopicStub +translation_of: Web/Accessibility/ARIA/Roles +--- +

This page lists reference pages covering all the WAI-ARIA roles discussed on MDN. For a full list of roles, see Using ARIA: Roles, States, and Properties

+ +

{{SubpagesWithSummaries}}

+ + diff --git a/files/ru/web/accessibility/at-apis/gecko/index.html b/files/ru/web/accessibility/at-apis/gecko/index.html new file mode 100644 index 0000000000..9cd605e79d --- /dev/null +++ b/files/ru/web/accessibility/at-apis/gecko/index.html @@ -0,0 +1,9 @@ +--- +title: Gecko +slug: Web/Accessibility/AT-APIs/Gecko +tags: + - NeedsTranslation + - TopicStub +translation_of: Mozilla/Tech/Accessibility/AT-APIs/Gecko +--- +{{wiki.localize('System.API.page-generated-for-subpage')}} diff --git a/files/ru/web/accessibility/at-apis/gecko/roles/index.html b/files/ru/web/accessibility/at-apis/gecko/roles/index.html new file mode 100644 index 0000000000..3279dc94f1 --- /dev/null +++ b/files/ru/web/accessibility/at-apis/gecko/roles/index.html @@ -0,0 +1,498 @@ +--- +title: Gecko Roles +slug: Web/Accessibility/AT-APIs/Gecko/Roles +tags: + - AT_APIs + - Accessibility + - NeedsTranslation + - Reference + - TopicStub +translation_of: Mozilla/Tech/Accessibility/AT-APIs/Gecko/Roles +--- +

« AT APIs Support Page

+

This page offers a list of accessible roles used in Gecko. Role constants are defined in the nsIAccessibleRole interface.

+
+
+ ROLE_NOTHING
+
+ Used when the accessible item doesn't have a strongly defined role.
+
+ ROLE_TITLEBAR
+
+ Represents a title or caption bar for a window. Used by MSAA only, this is supported automatically by Microsoft Windows.
+
+ ROLE_MENUBAR
+
+ Represents the menu bar (positioned beneath the title bar of a window on most platforms or at the top of the screen on Mac OS X) from which menus are selected by the user.
+
+ ROLE_SCROLLBAR
+
+ Represents a vertical or horizontal scroll bar, which is part of the client area or used in a control.
+
+ ROLE_GRIP
+
+ Represents a special mouse pointer, which allows a user to manipulate user interface elements such as windows. For example, a user clicks and drags a sizing grip in the lower-right corner of a window to resize it
+
+ ROLE_SOUND
+
+ Represents a system sound, which is associated with various system events.
+
+ ROLE_CURSOR
+
+ Represents the system mouse pointer.
+
+ ROLE_CARET
+
+ Represents the system caret.
+
+ ROLE_ALERT
+
+ Represents an alert or a condition that a user should be notified about. Assistive Technologies typically respond to the role by reading the entire onscreen contents of containers advertising this role. Should be used for warning dialogs, etc.
+
+ ROLE_WINDOW
+
+ Represents the window frame, which contains child objects such as a title bar, client, and other objects contained in a window. The role is supported automatically by Microsoft Windows.
+
+ ROLE_INTERNAL_FRAME
+
+ A sub-document.
+
+ ROLE_MENUPOPUP
+
+ Represents a menu, which presents a list of options from which the user can make a selection to perform an action.
+
+ ROLE_MENUITEM
+
+ Represents a menu item, which is an entry in a menu that a user can choose to carry out a command, select an option.
+
+ ROLE_TOOLTIP
+
+ Represents a tooltip that provides helpful hints; this is generally displayed at the mouse cursor position.
+
+ ROLE_APPLICATION
+
+ Represents a main window for an application.
+
+ ROLE_DOCUMENT
+
+ Represents a document window. A document window is always contained within an application window.
+
+ ROLE_PANE
+
+ Represents a pane within a frame or document window. Users can navigate between panes and within the contents of the current pane, but cannot navigate between items in different panes. Thus, panes represent a level of grouping lower than frame windows or documents, but above individual controls.
+
+ ROLE_CHART
+
+ Represents a graphical image used to represent data.
+
+ ROLE_DIALOG
+
+ Represents a dialog box or message box.
+
+ ROLE_BORDER
+
+ Represents a window border.
+
+ ROLE_GROUPING
+
+ Logically groups other objects.
+
+ ROLE_SEPARATOR
+
+ Used to visually divide a space into two regions, such as a separator menu item or a bar that divides split panes within a window.
+
+ ROLE_TOOLBAR
+
+ Represents a toolbar, which is a grouping of controls (push buttons or toggle buttons) that provides easy access to frequently used features.
+
+ ROLE_STATUSBAR
+
+ Represents a status bar, which is an area at the bottom of a window that displays information about the current operation, state of the application, or selected object. The status bar has multiple fields, which display different kinds of information.
+
+ ROLE_TABLE
+
+ Represents a table that contains rows and columns of cells, and optionally, row headers and column headers.
+
+ ROLE_COLUMNHEADER
+
+ Represents a column header, providing a visual label for a column in a table.
+
+ ROLE_ROWHEADER
+
+ Represents a row header, which provides a visual label for a table row.
+
+ ROLE_COLUMN
+
+ Represents a column of cells within a table.
+
+ ROLE_ROW
+
+ Represents a row of cells within a table.
+
+ ROLE_CELL
+
+ Represents a cell within a table.
+
+ ROLE_LINK
+
+ Represents a link to something else. This object might look like text or a graphic, but it acts like a button.
+
+ ROLE_HELPBALLOON
+
+ Displays a Help topic in the form of a ToolTip or Help balloon.
+
+ ROLE_CHARACTER
+
+ Represents a cartoon-like graphic object, such as Microsoft Office Assistant, which is displayed to provide help to users of an application.
+
+ ROLE_LIST
+
+ Represents a list box, allowing the user to select one or more items.
+
+ ROLE_LISTITEM
+
+ Represents an item in a list.
+
+ ROLE_OUTLINE
+
+ Represents an outline or tree structure, such as a tree view control, that displays a hierarchical list and allows the user to expand and collapse branches.
+
+ ROLE_OUTLINEITEM
+
+ Represents an item in an outline or tree structure.
+
+ ROLE_PAGETAB
+
+ Represents a page tab, it is a child of a page tab list.
+
+ ROLE_PROPERTYPAGE
+
+ Represents a property sheet.
+
+ ROLE_INDICATOR
+
+ Represents an indicator, such as a pointer graphic, that points to the current item.
+
+ ROLE_GRAPHIC
+
+ Represents a picture.
+
+ ROLE_STATICTEXT
+
+ Represents read-only text, such as labels for other controls or instructions in a dialog box. Static text cannot be modified or selected.
+
+ ROLE_TEXT_LEAF
+
+ Represents selectable text that allows edits or is designated read-only.
+
+ ROLE_PUSHBUTTON
+
+ Represents a push button control.
+
+ ROLE_CHECKBUTTON
+
+ Represents a check box control.
+
+ ROLE_RADIOBUTTON
+
+ Represents an option button, also called a radio button. It is one of a group of mutually exclusive options. All objects sharing a single parent that have this attribute are assumed to be part of single mutually exclusive group.
+
+ ROLE_COMBOBOX
+
+ Represents a combo box; an edit control with an associated list box that provides a set of predefined choices.
+
+ ROLE_DROPLIST
+
+ Represents the calendar control.
+
+ ROLE_PROGRESSBAR
+
+ Represents a progress bar, dynamically showing the user the percent complete of an operation in progress.
+
+ ROLE_DIAL
+
+ Represents a dial or knob whose purpose is to allow a user to set a value.
+
+ ROLE_HOTKEYFIELD
+
+ Represents a hot-key field that allows the user to enter a combination or sequence of keystrokes.
+
+ ROLE_SLIDER
+
+ Represents a slider, which allows the user to adjust a setting in given increments between minimum and maximum values.
+
+ ROLE_SPINBUTTON
+
+ Represents a spin box, which is a control that allows the user to increment or decrement the value displayed in a separate "buddy" control associated with the spin box.
+
+ ROLE_DIAGRAM
+
+ Represents a graphical image used to diagram data.
+
+ ROLE_ANIMATION
+
+ Represents an animation control, which contains content that changes over time, such as a control that displays a series of bitmap frames.
+
+ ROLE_EQUATION
+
+ Represents a mathematical equation. It is used by MATHML.
+
+ ROLE_BUTTONDROPDOWN
+
+ Represents a button that drops down a list of items.
+
+ ROLE_BUTTONMENU
+
+ Represents a button that drops down a menu.
+
+ ROLE_BUTTONDROPDOWNGRID
+
+ Represents a button that drops down a grid.
+
+ ROLE_WHITESPACE
+
+ Represents blank space between other objects.
+
+ ROLE_PAGETABLIST
+
+ Represents a container of page tab controls.
+
+ ROLE_CLOCK
+
+ Represents a control that displays time.
+
+ ROLE_SPLITBUTTON
+
+ Represents a button on a toolbar that has a drop-down list icon directly adjacent to the button.
+
+ ROLE_IPADDRESS
+
+ Represents an edit control designed for an Internet Protocol (IP) address. The edit control is divided into sections for the different parts of the IP address.
+
+ ROLE_ACCEL_LABEL
+
+ Represents a label control that has an accelerator.
+
+ ROLE_ARROW
+
+ Represents an arrow in one of the four cardinal directions.
+
+ ROLE_CANVAS
+
+ Represents a control that can be drawn into and is used to trap events.
+
+ ROLE_CHECK_MENU_ITEM
+
+ Represents a menu item with a check box.
+
+ ROLE_COLOR_CHOOSER
+
+ Represents a specialized dialog that lets the user choose a color.
+
+ ROLE_DATE_EDITOR
+
+ Represents control whose purpose is to allow a user to edit a date.
+
+ ROLE_DESKTOP_ICON
+
+ An iconified internal frame in an ROLE_DESKTOP_PANE.
+
+ ROLE_DESKTOP_FRAME
+
+ A desktop pane. A pane that supports internal frames and iconified versions of those internal frames.
+
+ ROLE_DIRECTORY_PANE
+
+ A directory pane. A pane that allows the user to navigate through and select the contents of a directory. May be used by a file chooser.
+
+ ROLE_FILE_CHOOSER
+
+ A file chooser. A specialized dialog that displays the files in the directory and lets the user select a file, browse a different directory, or specify a filename. May use the directory pane to show the contents of a directory.
+
+ ROLE_FONT_CHOOSER
+
+ A font chooser. A font chooser is a component that lets the user pick various attributes for fonts.
+
+ ROLE_CHROME_WINDOW
+
+ Frame role. A top level window with a title bar, border, menu bar, etc. It is often used as the primary window for an application.
+
+ ROLE_GLASS_PANE
+
+ A glass pane. A pane that is guaranteed to be painted on top of all panes beneath it.
+
+ ROLE_HTML_CONTAINER
+
+ A document container for HTML, whose children represent the document content.
+
+ ROLE_ICON
+
+ A small fixed size picture, typically used to decorate components.
+
+ ROLE_LABEL
+
+ Presents an icon or short string in an interface.
+
+ ROLE_LAYERED_PANE
+
+ A layered pane. A specialized pane that allows its children to be drawn in layers, providing a form of stacking order. This is usually the pane that holds the menu bar as well as the pane that contains most of the visual components in a window.
+
+ ROLE_OPTION_PANE
+
+ A specialized pane whose primary use is inside a dialog.
+
+ ROLE_PASSWORD_TEXT
+
+ A text object uses for passwords, or other places where the text content is not shown visibly to the user.
+
+ ROLE_POPUP_MENU
+
+ A temporary window that is usually used to offer the user a list of choices, and then hides when the user selects one of those choices.
+
+ ROLE_RADIO_MENU_ITEM
+
+ A radio button that is a menu item.
+
+ ROLE_ROOT_PANE
+
+ A root pane. A specialized pane that has a glass pane and a layered pane as its children. Its children can include scroll bars and a viewport.
+
+ ROLE_SCROLL_PANE
+
+ A scroll pane. An object that allows a user to incrementally view a large amount of information.
+
+ ROLE_SPLIT_PANE
+
+ A split pane. A specialized panel that presents two other panels at the same time. Between the two panels is a divider the user can manipulate to make one panel larger and the other panel smaller.
+
+ ROLE_TABLE_COLUMN_HEADER
+
+ The header for a column of a table.
+
+ ROLE_TABLE_ROW_HEADER
+
+ The header for a row of a table.
+
+ ROLE_TEAR_OFF_MENU_ITEM
+
+ A menu item used to tear off and reattach its menu.
+
+ ROLE_TERMINAL
+
+ Represents an accessible terminal.
+
+ ROLE_TEXT_CONTAINER
+
+ Collection of objects that constitute a logical text entity.
+
+ ROLE_TOGGLE_BUTTON
+
+ A toggle button. A specialized push button that can be checked or unchecked, but does not provide a separate indicator for the current state.
+
+ ROLE_TREE_TABLE
+
+ Representas a control that is capable of expanding and collapsing rows as well as showing multiple columns of data.
+
+ ROLE_VIEWPORT
+
+ A viewport. An object usually used in a scroll pane. It represents the portion of the entire data that the user can see. As the user manipulates the scroll bars, the contents of the viewport can change.
+
+ ROLE_HEADER
+
+ Header of a document page.
+
+ ROLE_FOOTER
+
+ Footer of a document page.
+
+ ROLE_PARAGRAPH
+
+ A paragraph of text.
+
+ ROLE_RULER
+
+ A ruler such as those used in word processors.
+
+ ROLE_AUTOCOMPLETE
+
+ A text entry having dialog or list containing items for insertion into an entry widget, for instance a list of words for completion of a text entry.
+
+ ROLE_EDITBAR
+
+ An editable text object in a toolbar.
+
+ ROLE_ENTRY
+
+ An control whose textual content may be entered or modified by the user.
+
+ ROLE_CAPTION
+
+ A caption describing another object.
+
+ ROLE_DOCUMENT_FRAME
+
+ A visual frame or container which contains a view of document content. Document frames may occur within another Document instance, in which case the second document may be said to be embedded in the containing instance. HTML frames are often ROLE_DOCUMENT_FRAME. Either this object, or a singleton descendant, should implement the Document interface.
+
+ ROLE_HEADING
+
+ Heading.
+
+ ROLE_PAGE
+
+ An object representing a page of document content. It is used in documents which are accessed by the user on a page by page basis.
+
+ ROLE_SECTION
+
+ A container of document content.
+
+ ROLE_REDUNDANT_OBJECT
+
+ An object which is redundant with another object in the accessible hierarchy. ATs typically ignore objects with this role.
+
+ ROLE_FORM
+
+ A container of form controls.
+
+ ROLE_IME
+
+ An object which is used to allow input of characters not found on a keyboard, such as the input of Chinese characters on a Western keyboard.
+
+ ROLE_APP_ROOT
+
+  ???
+
+ ROLE_PARENT_MENUITEM
+
+ Represents a menu item, which is an entry in a menu that a user can choose to display another menu.
+
+ ROLE_CALENDAR
+
+ A calendar that allows the user to select a date.
+
+ ROLE_COMBOBOX_LIST
+
+ A list of items that is shown by combobox.
+
+ ROLE_COMBOBOX_OPTION
+
+ A item of list that is shown by combobox
+
+ ROLE_IMAGE_MAP
+
+ An image map -- has child links representing the areas
+
+ ROLE_OPTION
+
+ An option in a listbox
+
+ ROLE_RICH_OPTION
+
+ A rich option in a listbox, it can have other widgets as children
+
+ ROLE_LISTBOX
+
+ A list of options
+
+
+

Editor's note: Use template ROLE_ to get reference on accessible role. It looks like ROLE_MENUITEM.

+
diff --git a/files/ru/web/accessibility/at-apis/gecko/roles/role_document/index.html b/files/ru/web/accessibility/at-apis/gecko/roles/role_document/index.html new file mode 100644 index 0000000000..0116e62762 --- /dev/null +++ b/files/ru/web/accessibility/at-apis/gecko/roles/role_document/index.html @@ -0,0 +1,31 @@ +--- +title: ROLE_DOCUMENT +slug: Web/Accessibility/AT-APIs/Gecko/Roles/ROLE_DOCUMENT +translation_of: Mozilla/Tech/Accessibility/AT-APIs/Gecko/Roles/ROLE_DOCUMENT +--- +

« Gecko Roles Page

+

Represents a document window. A document window is always contained within an application window.

+

Interfaces

+ +

Mapped to

+ +

Used by

+ +

diff --git a/files/ru/web/accessibility/at-apis/gecko/roles/role_password_text/index.html b/files/ru/web/accessibility/at-apis/gecko/roles/role_password_text/index.html new file mode 100644 index 0000000000..3157da6c12 --- /dev/null +++ b/files/ru/web/accessibility/at-apis/gecko/roles/role_password_text/index.html @@ -0,0 +1,27 @@ +--- +title: ROLE PASSWORD TEXT +slug: Web/Accessibility/AT-APIs/Gecko/Roles/ROLE_PASSWORD_TEXT +translation_of: Mozilla/Tech/Accessibility/AT-APIs/Gecko/Roles/ROLE_PASSWORD_TEXT +--- +

 

+ +

« Gecko Roles Page

+ +

Description

+ +

A text object uses for passwords, or other places where the text content is not shown visibly to the user.

+ +

Mapped to

+ + + +

Used by

+ + diff --git a/files/ru/web/accessibility/at-apis/index.html b/files/ru/web/accessibility/at-apis/index.html new file mode 100644 index 0000000000..43b7f1d8b6 --- /dev/null +++ b/files/ru/web/accessibility/at-apis/index.html @@ -0,0 +1,176 @@ +--- +title: AT APIs Support +slug: Web/Accessibility/AT-APIs +tags: + - AT_APIs + - Accessibility + - NeedsTranslation + - TopicStub +translation_of: Mozilla/Tech/Accessibility/AT-APIs +--- +

Introduction

+ +
Documentation is in progress still. But in the meantime it more up-to-date and contains more details than existed analogues for AT-SPI and MSAA
+ +

This documentation explains how makers of screen readers, voice dictation packages, onscreen keyboards, magnification software and other assitive technologies can support Gecko-based software. We provide for them the support of these products on Windows, Linux/Unix and OS X platforms.

+ +

Accessible Gecko

+ +

Gecko is a rendering engine that Firefox, SeaMonkey, Netscape and yelp use. Gecko can render a variety of content, not just HTML and supports key web standards such as Cascading Style Sheets, Javascript and the W3C DOM. Gecko also handles the users keystrokes and mouse clicks. Gecko is the core architecture that we are adding accessibility to, in order to support basic accessibility in all applications that are based on it.

+ +

Gecko Based Applications

+ +

Gecko can be used in two ways to create application:

+ +

Embedded Clients

+ +

Embedded clients use Gecko only in the content window, at the moment for HTML and generic XML only. They typically use standard Windows controls for their user interface -- the area outside of the client content window, plus the context menu.

+ + + +

XUL Applications

+ +

XUL applications make full use of the Gecko architecture, not only for HTML content, but also for the entire user interface. Widgets such as menus, tab panels, tree views and dialogs are provided via an XML language called XUL (eXtensible User-interface Language). None of the user interface contains standard OS controls. This is done to ensure a common look and feel across all supported platforms, and to allow for different skins (appearances). Developing a XUL window is not that different from developing a web page, but the elements available to add widgets are more powerful and designed to be similar to desktop widgets.

+ +

Examples of XUL applications:

+ + + +

Gecko Version

+ +

For Firefox and all other Gecko-based products: this documentation applies to up-to-date product builds based on Gecko 1.9.2 -- currently not available on official releases. However most of described features are supported starting from Gecko 1.9.0 (Firefox 3.0). However it's preferable to grab the current build of Firefox or any other Gecko-based product to be up to dated:

+ + + +

Determining if Accessibility is Enabled in a Firefox

+ +

Accessibility is enabled on Windows and Linux platforms by default. As well you might find helpful the about:accessibilityenabled Firefox extension.

+ +

Supported AT APIs

+ +

AT APIs terms

+ +
+
Microsoft Active Accessibility (MSAA)
+
an API devised by Microsoft so that accessibility aids can track what's going on inside the user interface of any software package that supports it. If you seriously need to understand MSAA, you'll need to read the docs on MSDN and play with the sample apps and code that come with MSAA SDK 1.3. (I recommend SDK 1.3 because the MSAA SDK 2.0 doesn't come with the source code to the testing tools. The other differences are not important).
+
IAccessible2 (IA2)
+
IAccessible2 is a new accessibility API which complements Microsoft's earlier work on MSAA. This API fills critical accessibility API gaps in the MSAA offering.
+
Assistive Technology Service Provider Interface (AT-SPI)
+
an API devised by Sun Microsystems so that accessibility aids can track what's going on inside the user interface of any software package that supports it. If you seriously need to understand AT-SPI, you'll need to read the docs on gnome.org and play with the available sample apps and code, such as at-poke. Please note that the web docs are sometimes out of date, and the latest AT-SPI is available on CVS.
+
Universal Access (UA)
+
Universal Access (UA) is the Apple's accessibility framework.
+
+ +

Windows platform

+ +

We support MSAA (Microsoft Active Accessibility) and IAccessible2 on Windows. Also we expose MS COM interfaces ISimpleDOM* to provide an access to DOM tree.

+ +

IAccessible2 is a set of interfaces that overlay the MSAA (IAccessible) and DOM (ISimpleDOM*) interface support. Any object that supports IAccessible will also support IAccessible2 and possibly any of the other IA2 interfaces.

+ +

Linux/Unix platform

+ +

We support ATK/AT-SPI interfaces on Linux.

+ +

Mac platform

+ +

We currently support only a subset of Universal Access. The rest of the Mozilla Universal Access support is in progress.

+ +

Accessible Web Specifications

+ +

Gecko exposes the number of XML languages including HTML to AT. Refer to accessible web specifications page to learn what and how markup languages are exposed.

+ +

AT APIs Implementation Details

+ +

Refer to implementation details page to see how Gecko supports interesting AT API. There you will find information how AT API interfaces, roles, states and etc are mapped into Gecko accessibility API and visa versa.

+ +

Keyboard User Interface and API

+ +

Fortunately, Gecko uses the standard keyboard API's for each supported platform. The Mozilla keyboard shortcuts for content are similar to what is used in other browsers. Here is a list of Firefox keyboard shortcuts.

+ +

Test Tools

+ +

Here you will find a list of tools to test accessibility Gecko-based applications.

+ + + +

Screen Readers

+ +

Here's a list of screen readers we are oriented to in the first place.

+ + + +

Contacts

+ +

Please discuss accessibility issues on the Mozilla Accessibility groups or on the Mozilla Accessibility IRC channel.

diff --git a/files/ru/web/accessibility/index.html b/files/ru/web/accessibility/index.html new file mode 100644 index 0000000000..5906df0a22 --- /dev/null +++ b/files/ru/web/accessibility/index.html @@ -0,0 +1,54 @@ +--- +title: Доступность +slug: Web/Accessibility +tags: + - Accessibility + - Advanced + - Landing + - TopicStub + - Веб-разработка +translation_of: Web/Accessibility +--- +

Доступность (Accessibility, A11y в англоязычной среде) в веб-разработке — это обеспечение возможности использования сайтов как можно большим числом людей, включая тех, чьи способности как-либо ограничены.

+ +

Технологии облегчают жизнь многим людям. А людям с ограниченными возможностями технологии дают такие возможности, которые ранее им были недоступны. Доступность в контексте разработки подразумевает создание такого контента, пользоваться которым мог бы каждый, несмотря на индивидуальные физические или когнитивные способности и вне зависимости от того, как они получают доступ в сеть.

+ +

«Термин "специальные возможности" часто применяется для описания возможности использования или удобства использования системы людьми с ограниченными возможностями, например, инвалидами на креслах-колясках. Это понятие следует понимать более широко, например, оно охватывает шрифт Брайля, пандусы для инвалидов на креслах-колясках, аудио-сигналы на пешеходных переходах, оборудованные рифленой тактильной плиткой пешеходные дорожки, разработку веб-сайтов и так далее." Статья Accessibility в английской Википедии

+ +

"Интернет принципиально создан для всех людей на Земле, независимо от их аппаратных, программных, языковых, культурных, территориальных, физических или умственных способностей." W3C - Accessibility

+ +
+
+

Документация

+ +
+
Веб-разработка
+
Набор статей для привлечения внимания к проблемам веб-разработки в мире специальных возможностей.
+
ARIA
+
Набор статей о том, как сделать HTML-файлы доступнее с помощью ARIA.
+
Разработка вспомогательных технологий (технических средств реабилитации, ТСР)
+
Набор статей для разработчиков ТСР.
+
Mobile accessibility checklist
+
Этот документ предоставляет краткий список требований к разработке специальных возможностей для мобильных приложений.
+
+ +

Смотреть все статьи о Специальных возможностях...

+
+ + +
diff --git a/files/ru/web/accessibility/keyboard-navigable_javascript_widgets/index.html b/files/ru/web/accessibility/keyboard-navigable_javascript_widgets/index.html new file mode 100644 index 0000000000..00b91b8257 --- /dev/null +++ b/files/ru/web/accessibility/keyboard-navigable_javascript_widgets/index.html @@ -0,0 +1,206 @@ +--- +title: Навигация с клавиатуры в JavaScript +slug: Web/Accessibility/Keyboard-navigable_JavaScript_widgets +tags: + - Accessibility + - DOM +translation_of: Web/Accessibility/Keyboard-navigable_JavaScript_widgets +--- +

Как сделать для JavaScript-виджетов на основе span или div возможность навигации с клавиатуры.

+ +

Обзор

+ +

Веб-приложения часто используют JavaScript, чтобы имитировать работу различных элементов, перешедших в веб с десктопных приложений: динамические меню, закладки, нестандартные элементы форм. Все эти элементы можно назвать виджетами. В вёрстке виджеты обычно состоят из набора HTML-элементов {{HTMLElement("div")}} и {{HTMLElement("span")}}, которые по умолчанию не предоставляют возможности работать с ними, используя клавиатуру. В данной статье описывается техника, позволяющая сделать JS-виджеты управляемыми с клавиатуры.

+ +

Использование tabindex

+ +

Атрибут tabindex был представлен в спецификации HTML 4. Он позволяет задать порядок, в котором элементы будут получать фокус при навигации с клавиатуры. Текущая реализация, описанная в HTML 5 draft specs, довольно сильно отличается от первоначальной. Все распространённые браузеры теперь придерживаются новой спецификации.

+ +

В данной таблице описано поведение элементов в зависимости от значения атрибута tabindex:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Атрибут tabindex +

Фокус при помощи мыши или программно через element.focus()

+
Фокус при навигации с клавиатуры (Tab)
ОтсутствуетРаботает согласно правилам платформы для конкретного элемента (возможен для элементов форм, ссылок и т.п.)Работает согласно правилам платформы для конкретного элемента
Менее нуля (tabindex="-1")ВозможенНевозможен. Разработчик должен использовать focus() при нажатии стрелочек на клавиатуре и других клавиш.
Нуль (tabindex="0")ВозможенПроисходит поочередно, исходя из позиции элемента внутри документа
Более нуля (например tabindex="33")ВозможенЗначение атрибута tabindex указывает очередность, в которой элемент получит фокус. Чем меньше значение атрибута, тем раньше элемент получит фокус. В любом случае, фокус придет на такие элементы раньше, чем на элементы с tabindex="0" и элементы, которые способны получить фокус без атрибута tabindex (например, tabindex="7" получит фокус раньше tabindex="11")
+ +

Простые контролы

+ +

Чтобы сделать простой виджет доступным через клавишу Tab, задайте tabindex="0" на HTML элементах {{HTMLElement("div")}} или {{HTMLElement("span")}}, из которых он состоит. Ниже представлен пример эмулирования чекбоксов. Вместо элементов input в примере используется {{HTMLElement("span")}}.

+ +

Пример 1: Простой виджет, эмулирующий работу чекбосов путем смены изображений. Виджет использует tabindex, чтобы обеспечить доступ с клавиатуры.

+ +
<!-- Без атрибута tabindex, элементы <span> не смогут принимать фокус с клавиатуры -->
+<div>
+    <span role="checkbox" aria-checked="true" tabindex="0">
+        <img src="checked.gif" role="presentation" alt="" />
+        Добавить декоративную корзину с фруктами
+    </span>
+</div>
+<div>
+    <span role="checkbox" aria-checked="true" tabindex="0">
+        <img src="checked.gif" role="presentation" alt="" />
+        Добавить поющую телеграмму
+    </span>
+</div>
+<div>
+    <span role="checkbox" aria-checked="false" tabindex="0">
+        <img src="unchecked.gif" role="presentation" alt="" />
+        С предоплатой
+    </span>
+</div>
+
+ +

Сгруппированные контролы

+ +

Безусловно есть необходимость создания более сложных виджетов. В качестве примеров можно привести меню, панели табов, различные динамические таблицы, представления для информации, имеющей древовидную структуру. Для таких контролов родительский элемент должен иметь атрибут tabindex="0". В таком случае он сможет попасть в фокус с клавиатуры. Все дочерние элменты (пункты меню, отдельные табы, ячейки, строки) должны иметь tabindex="-1", чтобы не попадать в фокус при нажатии tab. Пользователи должны иметь возможность путешествовать по дочерним элементам при помощи стрелочек на клавиатуре.

+ +

Ниже приведен пример, который демонстрирует использование этой техники для реализации вложенного меню. После того, как в фокус попадает основной элемент меню ({{HTMLElement("ul")}}), разработчик должен программно управлять фокусом, реагируя на нажития клавиш со стрелочками. Для описания техники управления фокусом внутри виджета смотрите раздел «Управление фокусом внутри виджета» ниже в данной статье.

+ +

Пример 2: Меню, использующее атрибут tabindex для осуществления доступа с клавиатуры

+ +
<ul id="mb1" tabindex="0">
+  <li id="mb1_menu1" tabindex="-1"> Шрифт
+    <ul id="fontMenu" title="Шрифт" tabindex="-1">
+      <li id="sans-serif" tabindex="-1">Sans-serif</li>
+      <li id="serif" tabindex="-1">Serif</li>
+      <li id="monospace" tabindex="-1">Monospace</li>
+      <li id="fantasy" tabindex="-1">Fantasy</li>
+    </ul>
+  </li>
+  <li id="mb1_menu2" tabindex="-1"> Стиль
+    <ul id="styleMenu" title="Стиль" tabindex="-1">
+      <li id="italic" tabindex="-1">Наклонный</li>
+      <li id="bold" tabindex="-1">Жирный</li>
+      <li id="underline" tabindex="-1">Подчеркнутый</li>
+    </ul>
+  </li>
+  <li id="mb1_menu3" tabindex="-1"> Выравнивание
+    <ul id="justificationMenu" title="Выравнивание" tabindex="-1">
+      <li id="left" tabindex="-1">Слева</li>
+      <li id="center" tabindex="-1">По центру</li>
+      <li id="right" tabindex="-1">Справа</li>
+      <li id="justify" tabindex="-1">По ширине</li>
+    </ul>
+  </li>
+</ul>
+ +

Неактивные (disabled) контролы

+ +

Когда элемент управления становится неактивным, он должен не попадать в фокус при нажатии на tab, что обеспечивается выставлением у элемента атрибута tabindex="-1". Обратите внимание, что неактивные элементы в пределах сгруппированного виджета (такие как, подпункты меню ) должны иметь возможность быть выбранными при помощи стрелочек на клавиатуре.

+ +

Управление фокусом внутри виджета

+ +

Когда пользователь уходит с виджета, а потом возвращается обратно, фокус должен вернутся на определенный элемент, у которого был фокус раньше. Например, на конкретный элемент дерева или ячейку. Есть два варианта, которыми этого можно добиться:

+ +
    +
  1. Переходящий tabindex: програмное перемещение фокуса
  2. +
  3. aria-activedescendant: управление «виртуальным» фокусом
  4. +
+ +

Техника первая: Переходящий tabindex

+ +

Идея данной техники заключается в выставлении атрибута tabindex в нулевое значение для элемента, который последним находился в фокусе. При этом если пользователь уйдет табом с виджета, а потом вернется обратно, элемент восстановит фокус правильно. Заметьте, что выставляя tabindex в "0", необходимо выставлять tabindex="-1" для предыдущего выделенного элемента. Эта техника требует выставлять фокус элементам программно, реагируя на нажатие клавиш.

+ +

Для этого необходимо слушать событие keydown для каждого дочернего элемента виджета. Когда пользователь нажимает на стрелочки на клавиатуре, чтобы переместиться на другой элемент следует:

+ +
    +
  1. программно применить фокус к другому элементу
  2. +
  3. изменить tabindex элемента в фокусе на 0
  4. +
  5. изменить tabindex предыдущего элемента на -1
  6. +
+ +

По ссылке Вы можете увидеть пример WAI-ARIA tree view, использующий эту технику.

+ +
Советы
+ +
Используйте element.focus() чтобы задать фокус элементу
+ +

Не используйте createEvent(), initEvent() and dispatchEvent() чтобы задать фокус. Событие DOM focus должно использовать только для получения информации о том, что произошел фокус на элемент, оно генерируется системой, когда какой-либо элемент попал в фокус. Оно не должно использовать для того, чтобы задать фокус. Вместо этого используйте element.focus().

+ +
Используйте событие onfocus чтобы отслеживать фокус
+ +

При разработке не стоит расчитывать, что фокус будет меняться только в следствие манипуляций пользователя с клавиатурой и мышью. Вспомогательные программы, такие как screen readers могут задавать фокус элементам. Отслеживайте события onfocus и onblur, вместо событий мыши и клавиатуры.

+ +

onfocus и onblur могут быть использованы с любыми елементами. Сейчас в стандартах не описано метода для получения элемента, находящегося в фокусе. Поэтому если вам потребуется отслеживать элемент с фокусом, его надо будет запоминать в переменную.

+ +

Техника вторая: aria-activedescendant

+ +

Эта техника позволяет объединить  каждый отдельно взятый обработчик  событий в контейнер графического элемента и использовать  aria-activedescendent для слежения за "виртуальным" фокусом . (Для получения более подробной информации относительно ARIA обратите внимание на  обзор доступных веб-приложений и виджетов .)

+ +

The aria-activedescendant property identifies the ID of the descendent element that currently has the virtual focus. The event handler on the container must respond to key and mouse events by updating the value of aria-activedescendant and ensuring that the current item is styled appropriately (for example, with a border or background color). See the source code of this ARIA radiogroup example for a direct illustration of how this works.

+ +
Tips
+ +
scrollIntoView
+ +

Note that the use of this pattern requires the author to ensure that the current focused widget is scrolled into view. You should be able to use the {{domxref("element.scrollIntoView()")}} function, but we recommend confirming this works for you in your target browsers using the quirksmode test.

+ +
Issues
+ + + +

Рекомендации

+ +

Используйте onkeydown для отлова событий вместо onkeypress

+ +

В IE событие keypress срабатывает только для буквенно-цифровых клавиш. Используйте onkeydown вместо этого.

+ +

Убедитесь, что клавиатура и мышь производят одинаковое действие

+ +

Чтобы обеспечить независимый от устройства ввода механизм взаимодействия с пользователем, обработчики событий мыши и клавиатуры должны совместно использовать код там, где это необходимо. Например, код, который обновляет значение tabindex или стили, когда пользователь переключается между элементами c помощью стрелок, должен выполняться и обработчиками клика мыши, чтобы применить те же самые изменения.

+ +

Убедитесь, что можно использовать клавиатуру для активации элемента 

+ +

Чтобы обеспечить использование клавиатуры для активации элемента, любые обработчики событий мыши должны быть также связаны с событиями клавиатуры. Например, чтобы клавиша Enter активировала элемент, если у вас есть onclick="doSomething()", вам необходимо также связать doSomething() с событием нажатия клавиши: onkeydown="return event.keyCode != 13 || doSomething();".

+ +

Не используйте :focus для стилизации фокусировки (если вы поддерживаете IE 7 и более ранние)

+ +

IE 7 и более ранние версии не поддерживают :focus псевдо-селектор; не используйте его для стилизации фокуса. Вместо этого, установите стили с помощью обработчика событий onfocus, например, добавив название CSS стиля аттрибуту class.

+ +

Always draw the focus for tabindex="-1" items and elements that receive focus programatically

+ +

IE will not automatically draw the focus outline for items that programatically receive focus. Choose between changing the background color via something like this.style.backgroundColor = "gray"; or add a dotted border via this.style.border = "1px dotted invert". In the dotted border case you will need to make sure those elements have an invisible 1px border to start with, so that the element doesn't grow when the border style is applied (borders take up space, and IE doesn't implement CSS outlines).

+ +

Prevent used key events from performing browser functions

+ +

If your widget handles a key event, prevent the browser from also handling it (for example, scrolling in response to the arrow keys) by using your event handler's return code. If your event handler returns false, the event will not be propagated beyond your handler.

+ +

For example:

+ +
<span tabindex="-1" onkeydown="return handleKeyDown();">
+ +

If handleKeyDown() returns false, the event will be consumed, preventing the browser from performing any action based on the keystroke.

+ +

Don't rely on consistent behavior for key repeat, at this point

+ +

Unfortunately onkeydown may or may not repeat depending on what browser and OS you're running on.

diff --git a/files/ru/web/accessibility/mobile_accessibility_checklist/index.html b/files/ru/web/accessibility/mobile_accessibility_checklist/index.html new file mode 100644 index 0000000000..3b5bfdd43f --- /dev/null +++ b/files/ru/web/accessibility/mobile_accessibility_checklist/index.html @@ -0,0 +1,90 @@ +--- +title: Контрольный список по мобильной доступности +slug: Web/Accessibility/Mobile_accessibility_checklist +tags: + - Мобильная разработка + - доступность +translation_of: Web/Accessibility/Mobile_accessibility_checklist +--- +
+

Этот документ содержит краткий список требований доступности для разработчиков мобильных приложений. Он будет обновляться по мере появления новых техник и подходов.

+
+ +

Цвет

+ + + +

Видимость

+ + + +

Фокус

+ + + +

Текстовые эквиваленты

+ + + +

Обработка состояния

+ + + +

Общие рекомендации

+ + + +
+

Note: The original version of this document was written by Yura Zenevich.

+
+ +

 

diff --git a/files/ru/web/accessibility/understanding_wcag/index.html b/files/ru/web/accessibility/understanding_wcag/index.html new file mode 100644 index 0000000000..fe71b20ebc --- /dev/null +++ b/files/ru/web/accessibility/understanding_wcag/index.html @@ -0,0 +1,59 @@ +--- +title: Understanding the Web Content Accessibility Guidelines +slug: Web/Accessibility/Understanding_WCAG +tags: + - NeedsTranslation + - TopicStub + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

This set of articles provides quick explanations to help you understand the steps that need to be taken to conform to the recommendations outlined in the W3C Web Content Accessibility Guidelines 2.0 or 2.1 (or just WCAG, for the purposes of this writing).

+ +

The WCAG 2.0 and 2.1 provide a detailed set of guidelines for making web content more accessible to people with a wide variety of disabilities. It is comprehensive but incredibly detailed, and quite difficult to gain a rapid understanding of. For this reason, we have summarised the practical steps you need to take to satisfy the different recommendations, with further links to more details where required.

+ +

The four principles

+ +

WCAG is broadly broken down into four principles — major things that web content must be to be considered accessible (see Understanding the Four Principles of Accessibility for the WCAG definitions).

+ +

Each of the links below will take you to pages that further expand on these areas, giving you practical advice on how to write your web content so it conforms to the success criteria outlined in each of the WCAG 2.0 and 2.1 guidelines that further sub-divides each principle.

+ + + +

Should I use WCAG 2.0 or 2.1?

+ +

WCAG 2.1 is the most recent and relevant accessibility standard. Use WCAG 2.1 to help more people with disabilities and reduce the future legal risk for web site owners. Target WCAG 2.0 first when allocating resources. Then step up to WCAG 2.1. 

+ +

What is WCAG 2.1?

+ +

WCAG 2.1 was published as an official recommendation on 05 June 2018. The European Union (EU) adopted WCAG 2.1 as the digital accessibility standard in September 2018. W3C published a press release WCAG 2.1 Adoption in Europe

+ +

WCAG 2.1 includes:

+ + + + + +

This guide is intended to provide practical information to help you build better, more accessible websites. However, we are not lawyers, and none of this constitutes legal advice. If you are worried about the legal implications of web accessibility, we'd recommend that you check the specific legislation governing accessibility for the web/public resources in your country or locale, and seek the advice of a qualified lawyer.

+ +

What is accessibility? and particularity the Accessibility guidelines and the law section provide more related information.

diff --git a/files/ru/web/accessibility/understanding_wcag/keyboard/index.html b/files/ru/web/accessibility/understanding_wcag/keyboard/index.html new file mode 100644 index 0000000000..1b92442abf --- /dev/null +++ b/files/ru/web/accessibility/understanding_wcag/keyboard/index.html @@ -0,0 +1,87 @@ +--- +title: Русский +slug: Web/Accessibility/Understanding_WCAG/Keyboard +translation_of: Web/Accessibility/Understanding_WCAG/Keyboard +--- +

Чтобы веб-страница была полностью доступной, она должна быть управляема кем-то, кто использует только клавиатуру для доступа к ней и управления ею. Сюда входят пользователи программ чтения с экрана, но также могут быть пользователи, у которых есть проблемы с использованием указывающего устройства, такого как мышь или трекбол, или у которых мышь не работает в данный момент, или которые просто предпочитают использовать клавиатуру для ввода, когда это возможно.

+ +

Фокусируемые элементы должны иметь интерактивную семантику

+ +

Если элемент можно сфокусировать с помощью клавиатуры, он должен быть интерактивным; то есть пользователь должен иметь возможность что-то сделать с ним и произвести какое-либо изменение (например, активировать ссылку или изменить параметр).

+ +
+

Note: One important exception to this rule is if the element has role="document" applied to it, inside an interactive context (such as role="application"). In such a case, focusing the nested document is the only way of returning assistive technology to a non-interactive state (often called "browse mode").

+
+ +

Most interactive elements are focusable by default; you can make an element focusable by adding a tabindex=0 attribute value to it. However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events.

+ +

See also

+ + + +

Avoid using tabindex attribute greater than zero

+ +

The tabindex attribute indicates that an element is focusable using the keyboard. A value of zero indicates that the element is part of the default focus order, which is based on the ordering of elements in the HTML document. A positive value puts the element ahead of those in the default ordering; elements with positive values are focused in the order of their tabindex values (1, then 2, then 3, etc.).

+ +

This creates confusion for keyboard-only users when the focus order differs from the logical order of the page. A better strategy is to structure the HTML document so that focusable elements are in a logical order, without the need to re-order them with positive tabindex values.

+ +

See also

+ + + +

Clickable elements must be focusable and should have interactive semantics

+ +

If an element can be clicked with a pointing device, such as a mouse, then it should also be focusable using the keyboard, and the user should be able to do something by interacting with it.

+ +

An element is clickable if it has an onclick event handler defined. You can make it focusable by adding a tabindex=0 attribute value to it. You can make it operable with the keyboard by defining an onkeydown event handler; in most cases, the action taken by event handler should be the same for both types of events.

+ +

See also

+ + + +

Interactive elements must be able to be activated using a keyboard

+ +

If the user can interact with an element using touch or a pointing device, then the element should also support interacting using the keyboard. That is, if you have defined event handlers for touch or click events, you should also define them for keyboard events. The keyboard event handlers should enable the effectively the same interaction as the touch or click handlers.

+ +

See also

+ + + +

Interactive elements must be focusable

+ +

If the user can interact with an element (for example, using touch or a pointing device), then it should be focusable using the keyboard. You can make it focusable by adding a tabindex=0 attribute value to it. That will add the element to the list of elements that can be focused by pressing the Tab key, in the sequence of such elements as defined in the HTML document.

+ +

See also

+ + + +

Focusable element must have focus styling

+ +

Any element that can receive keyboard focus should have visible styling that indicates when the element is focused. You can do this with the :focus CSS pseudo-class.

+ +

Standard focusable elements such as links and input fields are given special styling by the browser by default, so you might not need to specify focus styling for such elements, unless you want the focus styling to be more distinctive.

+ +

If you create your own focusable components, be sure that you also define focus styling for them.

+ +

See also

+ + diff --git a/files/ru/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html b/files/ru/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html new file mode 100644 index 0000000000..e63497f6ee --- /dev/null +++ b/files/ru/web/accessibility/understanding_wcag/perceivable/color_contrast/index.html @@ -0,0 +1,56 @@ +--- +title: Цветовой контраст +slug: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast +tags: + - WCAG + - Контраст + - доступность +translation_of: Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast +--- +

Описание проблемы

+ +

Цветовой контраст между фоном и содержимым переднего плана (обычно текстом) должен быть минимальным, чтобы обеспечить удобство чтения. Хорошо иметь крутой дизайн на своем сайте, но он бесполезен, если ваши пользователи не могут прочитать контент.

+ +

Пример хорошего контраста:An example of good color contrast consisting of the words good contrast with a light purple background.

+ +

Пример плохого контраста:An example of bad color contrast consisting of the words bad contrast with a dark purple background.

+ +

Наличие хорошего цветового контраста на вашем сайте принесёт пользу всем вашим пользователям, но в особенности будет полезно пользователям с определенными типами дальтонизма и другими подобными условиями, которые испытывают затруднения при распознавании похожих цветов.

+ +

Связанные с WCAG критерии успеха

+ +
+
1.4.3 Минимальный контраст (AA)
+
Цветовой контраст между фоном и содержимым переднего плана должен быть минимальным, чтобы обеспечить удобочитаемость: +
    +
  • Текст и его фон должны иметь контрастность не менее 4.5.1.
  • +
  • Текст заголовка (или просто крупный текст) должен иметь соотношение не менее 3.1. Крупный текст определяется как минимум 18pt или 14pt полужирный.
  • +
+
+
1.4.6 Улучшенный контраст (AAA)
+
Это следует и основывается на критерии 1.4.3. +
    +
  • Текст и его фон должны иметь контрастность не менее 7.1.
  • +
  • Текст заголовка (или просто крупный текст) должен иметь соотношение не менее 4.5.1.
  • +
+
+
1.4.11 Нетекстовый контраст (AA) (добавлен в 2.1)
+
Минимальное соотношение цветовой контрастности для компонентов пользовательского интерфейса и графических объектов должно составлять 3 к 1.
+
+ +

Решение

+ +

При выборе цветовой схемы для вашего сайта, выберите цвета переднего плана и фона, которые имеют хороший контраст. Сделайте цветовой контраст настолько хорошим, насколько это возможно в рамках ваших проектных ограничений — в идеале используйте рейтинг AAA (см. 1.4.6 выше), или в крайнем случае, соответствуйте рейтингу AA (см. 1.4.3 выше).

+ +

Если вы используете нетекстовый контент, такой как видео или анимация, вы должны следовать 1.4.11.

+ +

Чтобы проверить свой контраст при выборе цвета, используйте такой инструмент, как Color Contrast Checker от WebAIM.

+ +

Вы также можете проверить цветовой контраст на лету с помощью инструментов разработчика Firefox — см. наше руководство Инспектор доступности, и в частности раздел Цветовой контраст.

+ +

Смотрите также

+ + diff --git a/files/ru/web/accessibility/understanding_wcag/perceivable/index.html b/files/ru/web/accessibility/understanding_wcag/perceivable/index.html new file mode 100644 index 0000000000..8388c3206f --- /dev/null +++ b/files/ru/web/accessibility/understanding_wcag/perceivable/index.html @@ -0,0 +1,359 @@ +--- +title: Perceivable +slug: Web/Accessibility/Understanding_WCAG/Perceivable +tags: + - Accessibility + - NeedsTranslation + - Principle 1 + - TopicStub + - WCAG + - Web Content Accessibility Guidelines + - contrast + - different presentation + - text alternatives + - time-based media +translation_of: Web/Accessibility/Understanding_WCAG/Perceivable +--- +

This article provides practical advice on how to write your web content so that it conforms to the success criteria outlined in the Perceivable principle of the Web Content Accessibility Guidelines (WCAG) 2.0 and 2.1. Perceivable states that users must be able to perceive it in some way, using one or more of their senses.

+ +
+

Note: To read the W3C definitions for Perceivable and its guidelines and success criteria, see Principle 1: Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

+
+ +

Guideline 1.1 — Providing text alternatives for non-text content

+ +

The key here is that text can be converted to other forms people with disabilities can use, so for example spoken by a screenreader, zoomed in, or represented on a braille display. Non-text content refers to multimedia such as images, audio, and video.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Success criteriaHow to conform to the criteriaPractical resource
1.1.1 Provide text equivalents  (A)All images that convey meaningful content should be given suitable alternative text.Text alternatives.
Complex images or charts should have an accessible alternative provided, either on the same page or linked to. Use a regular link rather than the longdesc attribute. +

A text description may work, or an accessible data table (see HTML table advanced features and accessibility). Also see Other text alternative mechanisms for the argument against longdesc.

+
Multimedia content (e.g. audio or video) should at least have a descriptive identification available (e.g. a caption or similar). +

See Text alternatives for static caption options, and Audio transcripts, Video text tracks, and Other multimedia content for other alternatives.

+
UI Controls such as form elements and buttons should have text labels that describe their purpose.Buttons are simple — you should make sure the button text describes the function of the button (e.g. <button>Upload image</button>). For further information on other UI controls, see UI controls.
Implement decorative (non-content) images, video, etc., in a way that is invisible to assistive technology, so it doesn't confuse users. +

Decorative images should be implemented using CSS background images (see Backgrounds).  If you have to include an image via an {{htmlelement("img")}} element, give it a blank alt (alt=""), otherwise screenreaders may try to read out the filepath, etc.

+ +

If you are including background video or audio that autoplays, make it as unobtrusive as possible. Don't make it look/sound like content, and provide a control to turn it off. Ideally, don't include it at all.

+
+ +
+

Note: Also see the WCAG description for Guideline 1.1: Text alternatives.

+
+ +

Guideline 1.2 — Providing text alternatives for time-based media

+ +

Time-based media refers to multimedia with a duration, i.e. audio and video. Also note that if the audio/video serves as an alternative to existing text content, you don't need to provide another text alternative.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Success criteriaHow to conform to the criteriaPractical resource
1.2.1 Provide alternatives for pre-recorded audio-only and video-only content (A)A transcript should be provided for prerecorded audio-only media, and a transcript or audio description should be provided for prerecorded video-only media (i.e. silent video).See Audio transcripts for transcript information. No audio description tutorial available as yet.
1.2.2 Provide captions for web-based video (A)You should provide captions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't hear the audio part of the video.See Video text tracks for HTML5 video captions, and Other multimedia content for other technologies. See also Add your own subtitles & closed captions (YouTube).
1.2.3 Provide text transcript or audio description for web-based video (A)You should provide text transcripts or audio descriptions for video presented on the web, e.g. HTML5 video. This is for the benefit of people who can't see the visual part of the video, and don't get the full content from the audio alone.See Audio transcripts for transcript information. No audio description tutorial available as yet.
1.2.4 Provide captions for live audio (AA)You should provide synchronized captions for all live multimedia that contains audio (e.g. video conferences, live audio broadcasts.) 
1.2.5 Provide audio descriptions for prerecorded video (AA)Audio descriptions should be provided for prerecorded video, but only where the existing audio does not convey the full meaning expressed by the video. 
1.2.6 Provide sign language equivalent to prerecorded audio (AAA)An equivalent sign language video should be provided for any prerecorded content containing audio. 
1.2.7 Provide extended video with audio descriptions (AAA)Where audio descriptions cannot be provided (see 1.2.5) due to video timing issues (e.g. there are no suitable pauses in the content in which to insert the audio descriptions), an alternative version of the video should be provided that includes inserted pauses (and audio descriptions). 
1.2.8 Provide an alternative for prerecorded media (AAA)For all content that features video, a descriptive text transcript should be provided, for example a script of the movie you are watching. This is for the benefit of hearing impaired viewers who cannot hear the content.See Audio transcripts for transcript information.
1.2.9 Provide a transcript for live audio (AAA)For any live audio content being broadcast, a descriptive text should be provided, for example a script of the play or musical you are listening to. This is for the benefit of hearing impaired viewers who cannot hear the content.See Audio transcripts for transcript information.
+ +
+

Note: Also see the WCAG description for Guideline 1.2: Time-based Media: Provide alternatives for time-based media.

+
+ +

Guideline 1.3 — Create content that can be presented in different ways

+ +

This guideline refers to the ability of content to be consumed by users in multiple ways, accomodating their differing needs.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Success criteriaHow to conform to the criteriaPractical resource
1.3.1 Info and relationships (A) +

Any content structure — or visual relationship made between content —  can also be determined programmatically, or be inferred from text description. The main situations in which this is relevant are:

+ +
    +
  • Text labels and the form elements they describe are associated unambiguously using the {{htmlelement("label")}} element, which can be picked up by screenreaders, etc.
  • +
  • Image alt text — content images should have text available that clearly describes the image's contents, which can be programmatically associated with it (e.g. alt text), or otherwise is easy to associate (e.g. describes it and is sat right next to it). This should means that the full meaning can still be inferred even if you can't see the image.
  • +
  • Lists — if the order of list items is important, and ordered list should be used ({{htmlelement("ol")}}).
  • +
+
The whole of +

HTML: A good basis for accessibility is packed with information about this, but you should particularly refer to Good semantics, UI controls, and Text alternatives.

+
1.3.2 Meaningful content sequence (A)A sensible, logical reading order should be easy to determine for any content, even if it is visually presented in an unusual way. The order should be made obvious by use of correct semantic elements (e.g. headings, paragraphs), with CSS being used to create any unusual layout styles, irrespective of the markup.Again, refer to HTML: A good basis for accessibility.
1.3.3 Sensory characteristics (A) +

Instructions for operating controls or understanding content do not rely on a single sense — this may prove inaccessible to people with a disability related to that sense, or a device that does not support that sense. So for example:

+ +
    +
  • "Click the round button to continue" — The button should be clearly labelled so that it is obvious that it is the button you need to press. If there are multiple buttons, make sure there are all clearly labelled to distinguish their function.
  • +
  • "Listen to the audio instructions for guidance" — This is obviously problematic — audio will be inaccessible to those with heading impairments, whereas text can be read, but also spoken by a screenreader if required.
  • +
  • "Swipe from the right hand side of the screen to reveal the menu" — some users might not be able to swipe the screen, either due to disability or because their device does not support touch. An alternative should be provided, such as a keyboard shortcut or button that can be activated by keyboard or other means.
  • +
+ +
+

Note: Conveying instructions solely by color is related, but covered in a different guideline — 1.4.1.

+
+
 
1.3.4 Orientation (AA) added in 2.1Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential. +

Understanding Orientation 

+
1.3.5 Identify Input Purpose (AA) added in 2.1 +

 

+ +

Follow the list of 53 input fields to programmatically identify the purpose of a field.   

+
Understanding Identify Input Purpose
1.3.6 Identify Purpose (AAA) added in 2.1In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.Understanding Identify Purpose
+ +
+

Note: Also see the WCAG description for Guideline 1.3: Adaptable: Create content that can be presented in different ways without losing information or structure.

+
+ +

Guideline 1.4: Make it easier for users to see and hear content including separating foreground from background

+ +

This guideline relates to making sure core content is easy to discernable from backgrounds and other decoration. The classic example is color (both color contrast and use of color to convey instructions), but it applies in other situations too.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Success criteriaHow to conform to the criteriaPractical resource
1.4.1 Use of color (A) +

Color should not be solely relied upon to convey information — for example, in forms you should never mark required fields purely with a color (like red). Instead (or as well as), something like an asterisk with a label of "required" would be more appropriate.

+
See Color and color contrast and Multiple labels.
1.4.2 Audio controls (A)For any audio that plays for longer than three seconds, accessible controls should be provided to play and pause the audio/video, and mute/adjust volume.Use native <button>s to provide accessible keyboard controls, as shown in Video player syling basics.
1.4.3 Minimum contrast (AA) +

The color contrast between background and foreground content should be at a minimum level to ensure legibility:

+ +
    +
  • Text and its background should have a contrast ratio of at least 4.5.1.
  • +
  • Heading (or just larger) text should have a ratio of at least 3.1. Larger text is defined as at least 18pt, or 14pt bold.
  • +
+
See Color and color contrast.
1.4.4 Resize text (AA)The page should be readable and usable when the text size is doubled. This means that designs should be responsive, so that when the text size is increased, the content is still accessible. 
1.4.5 Images of text (AA)Images should NOT be used to present content where text would do the job. For example, if an image is mostly textual, it could be represented using text as well as images. 
1.4.6 Enhanced contrast (AAA) +

This follows, and builds on, criterion 1.4.3.

+ +
    +
  • Text and its background should have a contrast ratio of at least 7.1.
  • +
  • Heading (or just larger) text should have a ratio of at least 4.5.1. Larger text is defined as at least 18pt, or 14pt bold.
  • +
+
 
1.4.7 Low or no background audio (AAA)Prerecorded audio recordings that primarily feature speech should have minimal background noise, so the content can be easily understood. 
1.4.8 Visual presentation (AAA) +

For text content presentation, the following should be true:

+ +
    +
  • Foreground and background colors should be user-selectable.
  • +
  • Text blocks should be no wider than 80 characters (or glyphs), for maximum readability.
  • +
  • Text should not be fully justified (e.g. text-align: justify;)
  • +
  • line height should be at least 1.5 times the text size within paragraphs (e.g. line-height: 1.5;), and at least 2.25 times the text size between paragraphs (e.g. padding: 2.25rem;)
  • +
  • When the text size is doubled, the content should not need to be scrolled.
  • +
+
 
1.4.9 Images of text (No Exception) (AAA)Text should not be presented as part of an image unless it is purely decoration (i.e. it does not convey any content), or cannot be presented in any other way. 
1.4.10 Reflow (AA) added in 2.1 +
    +
  • No horizontal scrolling for right-to-left languages (like English) or left-to-right languages (like Arabic)   
  • +
  • No vertical scrolling for top-to-bottom languages (like Japanese)
  • +
  • Except for parts of the content which require two-dimensional layout for usage or meaning (like a large data table).
  • +
+
Understanding Reflow
1.4.11 Non-Text Contrast(AA) added in 2.1Minimum color contrast ratio of 3 to 1 for user interface components and graphical objects. Understanding Non-Text Contrast
1.4.12 Text Spacing (AA) added in 2.1 +

No loss of content or functionality occurs when the following styles are applied: 

+ +
    +
  • Line height (line spacing) to at least 1.5 times the font size;
  • +
  • Spacing following paragraphs to at least 2 times the font size;
  • +
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • +
  • Word spacing to at least 0.16 times the font size.
  • +
+
Understanding Text Spacing
1.4.13 Content on Hover or Focus (AA) added in 2.1 +

Additional content appear and disappear in coordination with hover and keyboard focus, this success criterion specifies three conditions that must be met:

+ +
    +
  • dismissable (can be closed/removed)
  • +
  • hoverable (the additional content does not disappear when the pointer is over it) 
  • +
  • persistent (the additional content does not disappear without user action)
  • +
+
Understanding Content on Hover or Focus
+ +
+

Note: Also see the WCAG description for Guideline 1.4: Distinguishable: Make it easier for users to see and hear content including separating foreground from background..

+
+ +

 

+ +

See Also

+ + + +

 

diff --git "a/files/ru/web/accessibility/\320\262\320\265\320\261-\321\200\320\260\320\267\321\200\320\260\320\261\320\276\321\202\320\272\320\260/index.html" "b/files/ru/web/accessibility/\320\262\320\265\320\261-\321\200\320\260\320\267\321\200\320\260\320\261\320\276\321\202\320\272\320\260/index.html" new file mode 100644 index 0000000000..3c20770967 --- /dev/null +++ "b/files/ru/web/accessibility/\320\262\320\265\320\261-\321\200\320\260\320\267\321\200\320\260\320\261\320\276\321\202\320\272\320\260/index.html" @@ -0,0 +1,50 @@ +--- +title: Веб-разработка +slug: Web/Accessibility/Веб-разработка +tags: + - ARIA + - Web Development + - XUL + - доступность +translation_of: Web/Accessibility +--- +

Здесь ссылки на более подробную информацию для разработчиков о доступности (accessibility) в Веб и в XUL.

+ + + + + + + + +
+

Доступность в Вебе

+ +
+
ARIA для разработчиков
+
ARIA позволяет делать доступным динамический HTML-контент. Examples are live content regions and JavaScript widgets.
+
Keyboard-navigable JavaScript widgets
+
До недавнего времени у веб-разработчиков, желавших сделать свои виджеты на основе <div>, <span> и стилей доступными с клавиатуры, не было the proper techniques. Управляемость с клавиатуры — одно из минимальных требований accessibility, о которых должен знать каждый разработчик.
+
+ +

Доступность XUL

+ +
+
 
+
Building accessible custom components in XUL
+
How to use DHTML Accessibility techniques to add accessibility to your custom XUL components.
+
Accessible XUL authoring guidelines
+
When authored according to these guidelines, XUL is capable of generating accessible user interfaces. Coders, reviewers, designers and QA engineers should be familiar with these guidelines.
+
+
+

Внешние ресурсы

+ +
+
Dive into Accessibility
+
Эта книга отвечает на два вопроса. Первый — «Зачем мне делать мой сайт более доступным?» Второй — «Как мне сделать мой сайт более доступным?»
+
Accessible Web Page Authoring
+
A handy web accessibility checklist, from IBM.
+
+
+ +

 

-- cgit v1.2.3-54-g00ecf