Labeling Controls
Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus. In most cases, this is done by using the <label> element.
Labels need to describe the purpose of the form control. This section of the tutorial describes how to provide labels that are properly associated with form controls. Later sections explain how to provide instructions, validate user input, and provide feedback to help users complete your form.
A label and a form control should be associated with each other either implicitly or explicitly. Web browsers provide the label as a larger clickable area, for example, to select or activate the control. It also ensures that assistive technology can refer to the correct label when presenting a form control.
Associating labels explicitly
Whenever possible, use the label element to associate text with form elements explicitly. The for attribute of the label must exactly match the id of the form control.
Hiding label text
A label for a form control helps everyone better understand its purpose. In some cases, the purpose may be clear enough from the context when the content is rendered visually. The label can be hidden visually, though it still needs to be provided within the code to support other forms of presentation and interaction, such as for screen reader and speech input users. The method used in this tutorial to hide an element visually but make it available for assistive technologies is explained in Note on hiding element.
In the example below, the search field is positioned directly beside the search button. The purpose of the text input field is evident from the context in most situations.
Hiding the label element
In this approach, the <label> element is provided to identify a form control within the code, but it is visually hidden to avoid redundancy for users who can derive the purpose from the visual cues.
Using aria-label
The aria-label attribute can also be used to identify form controls. This approach is well supported by screen readers and other assistive technology, but, unlike the title attribute (see below), the information is not conveyed to visual users. The approach should therefore only be used when the label of the control is clear from the surrounding content, like the button in the example below.
Using aria-labelledby
The aria-labelledby attribute can also be used to identify form controls. This approach is well supported by screen readers and other assistive technology, but, unlike the title attribute (see below), the information is not conveyed to visual users. The approach should therefore only be used when the label of the control is clear from the surrounding content, like the button in the example below.
The id of the element containing the label text is used as the value of the aria-labelledby attribute.
Using the title attribute
The title attribute can also be used to identify form controls. This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the title attribute as a replacement for the label element, possibly because the title attribute is often used to provide non-essential information. The information of the title attribute is shown to visual users as a tool tip when hovering over the form field with the mouse.
Note on hiding elements
Screen readers and other assistive technology, just as web browsers, hide elements from their users when they are styled using display: none; and visibility: hidden; .
The common approach used to hide information visually but keep them available to screen reader and other assistive technology users is to use CSS that will keep the information technically visible but practically hidden. For example, presenting the label in a 1-by-1 pixel area, as demonstrated with the CSS class visuallyhidden (do not confuse with CSS visibility: hidden ) below:
Note that interactive elements are still active when using this code, so it is not suitable to hide other parts of forms but the labels.
Associating labels implicitly
In some situations, form controls cannot be labeled explicitly. For example, a content author might not know the id of a form field generated by a script, or that script might not add an id at all. In this case, the label element is used as a container for both the form control and the label text, so that the two are associated implicitly. Generally, explicit labels are better supported by assistive technology.
Labeling buttons
The label of a <button> element is set inside the element and can include markup. This allows more advanced accessibility hints to be included, like marking up language change. When using the <input> element to create buttons, the label is set in the value attribute of the element.
If the image button ( <input type=»image»> ) is used, the label is set in the alt attribute, for example: <input type=»image» src=»searchbutton.png» alt=»Search»> . See Functional Images for more information on how to describe images in buttons.
Visual position of label text
In left-to-right languages, it is customary to visually position labels to the right of radio buttons and checkboxes, and to the left or directly above other form fields. Maintaining this practice increases predictability and understandability of your form for all users.
In general, placing labels above the form fields helps reduce horizontal scrolling for people with low vision and mobile device users. However, the usefulness of this approach depends on other design aspects, such as the proximity of other nearby form fields and content, and needs to be assessed individually. The aim should be to maintain a close and distinct visual relationship between the label and the form control.
These tutorials provide best-practice guidance on implementing accessibility in different situations. This page combined the following WCAG success criteria and techniques from different conformance levels:
Success Criteria:
-
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) Headings and labels describe topic or purpose. (Level AA) Labels or instructions are provided when content requires user input. (Level A) For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
Techniques:
Help improve this page
Please share your ideas, suggestions, or comments via e-mail to the publicly-archived list wai-eo-editors@w3.org or via GitHub.
- Brian Elton
- see Acknowledgements
Developed by the Education and Outreach Working Group (EOWG). Developed with support from the WAI-ACT project, co-funded by the European Commission IST Programme.
Strategies, standards, and supporting resources to make the Web accessible to people with disabilities.
Copyright © 2023 World Wide Web Consortium (W3C ® ). See Permission to Use WAI Material.
aria-label
The aria-label attribute defines a string value that labels an interactive element.
Description
Sometimes the default accessible name of an element is missing, or does not accurately describe its contents, and there is no content visible in the DOM that can be associated with the object to give it meaning. A common example is a button containing an SVG or icon font (which you shouldn’t be using) without any text.
In cases where an interactive element has no accessible name, or an accessible name that isn’t accurate, and there is no content visible in the DOM that can be referenced via the aria-labelledby attribute, the aria-label attribute can be used to define a string that labels the interactive element on which it is set. This provides the element with its accessible name.
Note: aria-label is intended for use on interactive elements, or elements made to be interactive via other ARIA declarations, when there is no appropriate text visible in the DOM that could be referenced as a label
Most content has an accessible name generated from its immediate wrapping element’s text content. Accessible names can also be created by certain attributes or associated elements.
By default, a button’s accessible name is the content between the opening and closing <button> tags, an image’s accessible name is the content of its alt attribute, and a form input’s accessible name is the content of the associated <label> element.
If none of these options are available, or if the default accessible name is not appropriate, use the aria-label attribute to define the accessible name of an element.
aria-label can be used in cases where text that could label the element is not visible. If there is visible text that labels an element, use aria-labelledby instead.
The purpose of aria-label is the same as aria-labelledby . Both provide an accessible name for an element. If there is no visible name for the element you can reference, use aria-label to provide the user with a recognizable accessible name. If the label text is available in the DOM, and referencing the DOM content and acceptable user experience, prefer to use aria-labelledby . Don’t include both. If both are present on the same element, aria-labelledby will take precedence over aria-label .
Note: While aria-label is allowed on any element that can have an accessible name, in practice, aria-label is only supported on interactive elements, widgets, landmarks, images and iframes.
The aria-label attribute can be used with regular, semantic HTML elements; it is not limited to elements that have an ARIA role assigned.
Don’t «overuse» aria-label . For example, use visible text with aria-describedby or aria-description , not aria-label , to provide additional instructions or clarify the UI. Always remember, you don’t need to target instructions to screen readers only; if instructions are needed, provide them to everyone (or, preferably, make your UI more intuitive).
Not all elements can be given an accessible name. Neither aria-label nor aria-labelledby should be used with non-interactive elements or inline structural role such as with code , term , or emphasis nor roles whose semantics will not be mapped to the accessibility API, including presentation , none , and hidden . The aria-label attribute is intended for interactive elements only. Use aria-label to ensure an accessible name is provided when none is visible in the DOM for all interactive elements, like links, videos, form controls, landmark roles, and widget roles.
If you give your <iframe> s a title , your images an alt attributes, and your input’s associated <label> s, aria-label is not necessary. But, if present, the aria-label will take precedence over the title , alt and <label> as your iframe , image, or input’s accessible name, respectively.
Note: The aria-label is only «visible» to assistive technologies. If the information is important enough to add for AT users, consider making it visible for all users.
Values
A string of text that will be the accessible name for the object.
ARIAMixin API
The ariaLabel property, part of the Element interface, reflects the value of the aria-label attribute.
The ariaLabel property, part of the ElementInternals interface, reflects the value of the aria-label attribute.
Associated roles
Used in almost all roles except roles that can not be provided an accessible name by the author.
The aria-label attribute is NOT supported in:
Note: The aria-label attribute is intended for interactive elements only. When placed on non-interactive elements, such as those listed above, it may not be read or may confuse your users as a non-interactive element that acts like an interactive one.
Aria label html что это
The aria-label helps define a string and provides additional information about the structure of the document for users using assistive technology. In most cases, arial-label is used to replace an existing label with more precise information. However, we should be careful while using aria-label as it does not work with all HTML elements.
The aria-label attribute can be used with HTML elements such as:
- select
- textarea
- button
- a(when href=”#” is in use)
- audio and video(when control=”#” is in use)
The aria-label attribute does not always work with HTML elements like span, p, div. It may work across some of the browse assistive technology combinations.
Syntax:
Here, a button will be created with “click” written on it. The aria-label – Provides a label that exact mentions its output/function by using assistive technologies.
Example:
Here, as you can see an HTML page will open and will contain buttons side by side that are identical to each other without any difference. Now if someone is using a chromevox extension in chrome and have their earphone on while pressing tab, then they will hear the word “open” when the first button is selected, whereas when the second button is selected they will hear the phrase “opens a new window”. This is particularly useful in cases of people with bad eyesight who can see the two buttons but can’t comprehend the text written on them.
Output:
Before clicking the button:
Доступный дизайн компонентов на примерах. Дизайнеру про ARIA-атрибуты, порядок фокуса и другое
Эта информация пригодится вам, если вы создаёте дизайн новых компонентов или тестируете интерфейсы, трудитесь в связке с фронтенд-разработчиком или сами им являетесь, но мало знаете про доступность.
Я расскажу об основных руководствах по доступности и о ключевых моментах, на которые стоит обратить внимание, а именно: о порядке фокуса, о клавиатурном взаимодействии и об ARIA-атрибутах. Я также покажу, как документация помогает нам при разработке доступных (т. е. отвечающих требованиям доступности) компонентов.
Примечание: Под доступностью (accessibility) я подразумеваю соответствие требованиям доступности для пользователей с ограниченными возможностями. Подробнее о том, что это значит, можно прочитать в статье про доступность. Также напомню, что хороший дизайн — это не только про «красивое», но и про «удобное», а accessibility — это часть usability.
Учитываем доступность при разработке компонента
Предположим, вам потребовалось разработать дизайн всплывающей подсказки (тултипа), которая появляется при наведении курсора на информационную иконку. Каждому из наших пользователей, вне зависимости от имеющихся у него ограничений, мы должны обеспечить равный доступ к информации во всплывающей подсказке. Тут можно порекомендовать следующий подход.
Представьте, что ваш пользователь применяет:
только мышь или другое аналогичное устройство ввода с указателем;
экранный увеличитель (лупу);
программу чтения с экрана (скринридер).
Обо всём этом уже подумали разработчики стандарта Web Content Accessibility Guidelines (WCAG), созданного консорциумом W3C . В настоящее время принята версия 2.1; на русском языке с ней можно частично ознакомиться в версии 2.0, которая полностью вошла в версию 2.1. В стандарте не просто прописаны основные принципы. По каждому из них можно прочитать подробно: почему этот принцип важен, как он поможет пользователям с теми или иными нарушениями здоровья, а также как обеспечить его выполнение на практике.
Примечание: в некоторых странах соответствие требованиям WCAG закреплено на законодательном уровне. Но если вы будете разрабатывать сайт или приложения для США, то вам придётся изучить Section 508. Эти два стандарта очень похожи, но некоторые отличия всё-таки есть; о них можно почитать здесь.
Мышь. Человек, использующий мышь, может навести курсор на иконку и увидеть подсказку, т.е. здесь проблем не возникает. Не забываем, что размер самой иконки для пользователей мыши должен быть не меньше 24х24 пикселей, а для пользователей сенсорных экранов — 44–48 пикселей.
Клавиатура. У человека, использующего для взаимодействия с сайтом исключительно клавиатуру, уже могут возникнуть сложности — очевидно, что мы не в состоянии навести курсор без мыши. Для такого пользователя мы предусматриваем возможность активировать подсказку с клавиатуры, а именно перейти к иконке клавишей Tab, а когда фокус окажется на ней — показать подсказку. Для этого нужно включить нашу иконку в порядок фокуса. Также нам нужна возможность закрыть подсказку клавишей Esc.
Экранный увеличитель. Для пользователей экранной лупы особенно важны принципы, изложенные в п. 1.4.13 WCAG — ‘Content on Hover or Focus’. Контент, появляющийся при наведении на элемент курсора или при фокусировке элемента, должен соответствовать следующим критериям:
Dismissible (отклоняемость) — контент можно отклонить без перемещения фокуса или курсора. Например, можно предоставить пользователю возможность закрыть подсказку клавишей Esc.
Hoverable (наводимость курсором) — курсор можно перевести с кнопки на появляющийся контент (в нашем случае подсказку), и при этом контент не исчезает. При большом увеличении экрана высока вероятность того, что в определённый момент времени пользователь видит только часть контента — например, кнопку-триггер и начало появившейся подсказки. Чтобы просмотреть всю подсказку, пользователь должен иметь возможность отвести курсор от кнопки и перевести его на всплывшее окно, и при этом подсказка не должна закрываться.
Persistent (постоянство) — появляющийся дополнительный контент остаётся видимым, пока фокус или курсор не убрали с кнопки или дополнительного контента либо пока пользователь не отклонит контент клавишей Esc.
Скринридер. Что насчёт людей, использующих программы чтения с экрана? Наша иконка уже включена в порядок следования фокуса, а значит, невидящий пользователь сможет перейти к ней, используя клавиатуру. При этом нам нужно, чтобы текст подсказки зачитался вслух, и здесь на помощь приходят ARIA-атрибуты (о том, что это такое, — чуть ниже), в данном случае — aria-describedby. При добавлении этого лейбла к HTML-атрибутам иконки содержимое подсказки станет «видимым» — точнее, слышимым — для пользователя программы чтения с экрана. Когда элемент окажется в фокусе, он зачитается примерно следующим образом: «Информационная иконка», «Текст подсказки».
Таким образом, каждый из наших пользователей гарантированно увидит или услышит текст всплывающей подсказки, а значит, наша задача успешно решена.
ARIA-атрибуты
Дело в том, что скринридеры и другие вспомогательные технологии по умолчанию «умеют» взаимодействовать лишь со стандартными элементами HTML — кнопками, полями ввода, заголовками и т.д. А значит, некоторые продвинутые функции и кастомные компоненты вашего сайта могут стать попросту недоступны тем, кто не использует мышь или применяет программу чтения с экрана. В этом случае ARIA-атрибуты незаменимы. Дизайнеру не обязательно знать их все, но понимать, как они работают, — полезно. Рассмотрим несколько примеров.
Aria-label — помогает присвоить компоненту заголовок, который видим исключительно программам чтения с экрана.
Например, вы разместили в интерфейсе кнопку редактирования с иконкой карандаша. Она симпатичная и не занимает много места, а изображение карандаша обычно ассоциируется с действием редактирования. Видящий пользователь быстро считает смысл.
Для пользователя скринридера в этом случае будет полезно добавить пояснительный лейбл, который будет скрыт от глаз, но не от программ чтения с экрана. Применим свойство aria-label=»Редактировать», и при перемещении фокуса на кнопку она зачитается как «Кнопка “Редактировать”».
Атрибут можно использовать в случае, когда вы не хотите перегружать интерфейс визуально, но вам нужно обеспечить ясность восприятия пользователям с ограниченными возможностями.
Aria-labelledby — позволяет сделать отсылку к другому видимому названию или заголовку, например если у вас есть группа радиокнопок с общей подписью.
Aria-describedby — предоставляет дополнительную информацию к имеющемуся видимому заголовку, например если у вас есть поле ввода с названием ‘Password’ и текстовым пояснением требований к длине и составу пароля.
Пример использования свойства aria-describedby из бесплатного курса Web Accessibility от Google (https://classroom.udacity.com/courses/ud891), урок 5 (для просмотра нужна регистрация на сайте Udacity; вводить данные банковской карты при этом не нужно).
Aria-disabled — позволяет включить неактивный (disabled) компонент в порядок следования фокуса (focus order). В норме, при переходе по клавише Tab неактивный компонент будет пропущен, а значит, для пользователя скринридера этот компонент как бы не будет существовать. В целом это правильно, но в некоторых случаях нам нужно, чтобы пользователь с ограниченными возможностями тоже «видел» элемент.
Представим, что у нас есть форма обратной связи и кнопка «Отправить». Кнопка по умолчанию неактивна, но при заполнении полей ввода она становится доступной — довольно распространённый и привычный паттерн. Мы видим, что кнопка, пусть и полупрозрачная, там есть, и мы видим, как в ответ на заполнение полей она активируется. Пользователю скринридера в этом случае также необходимо знать, что кнопка в форме есть, но она неактивна. Это поможет сопоставить состояние кнопки с необходимостью заполнить поля для её активации.
Со всеми ARIA-атрибутами можно ознакомиться на W3.org.
Порядок следования фокуса
Для того чтобы упростить работу людей, пользующихся только клавиатурой, необходимо знать базовые требования к поведению фокуса.
Фокус может находиться только на интерактивных элементах, т.е. кнопках, ссылках, чекбоксах и т.д. Для навигации по тексту, заголовкам и таблицам в программах чтения с экрана есть другие инструменты.
Порядок следования фокуса должен соответствовать визуальному или логическому порядку расположения интерактивных элементов на экране.
Неактивные элементы управления не фокусируются.
Клавиша Tab переносит фокус к следующему компоненту, Shift+Tab — к предыдущему. Внутри компонентов движение фокуса осуществляется чаще всего клавишами стрелок (об этом — в следующем разделе).
На примере ниже правила следования фокуса нарушены, неинтерактивный элемент — текст соглашения, принимаемого нажатием на чекбокс, — фокусируется. Для того чтобы пользователь мог прочитать текст, соотносящийся с чекбоксом ‘I accept these terms’, можно применить уже упоминавшееся свойство aria-describedby.
Текст соглашения не должен включаться в порядок фокуса, вместо этого следует использовать свойство aria-describedby.
Примечание: этот принцип может упростить жизнь даже тем пользователям, у которых нет никаких ограничений — ни постоянных, ни временных. Некоторым людям просто удобнее работать с формой с клавиатуры.
Клавиатурное взаимодействие
Когда пользователь взаимодействует с интерфейсом, он ожидает, что объекты будут реагировать определённым образом на определённые клавиатурные нажатия. Мы привыкли, что галочку можно поставить/снять пробелом, выпадающий список открывается по Alt+стрелка вниз и т.д. Если же элемент управления не взаимодействует с клавиатурой так, как мы ожидаем, то нам легко это увидеть и решить задачу при помощи мыши или тачскрина. Проблемы начинаются, если пользователь не может увидеть элемент интерфейса или нажать на него.
Здесь нам приходит на помощь ещё одно руководство от W3C — WAI-ARIA Authoring Practices. Его цель — показать, как использовать WAI-ARIA при разработке доступных компонентов. В разделе ‘Design Patterns and Widgets’ для каждого компонента описано клавиатурное взаимодействие, а также роли и ARIA-атрибуты, которые полезно использовать при его создании.
Например, для группы радиокнопок будут действовать следующие правила:
Клавиша Tab или Tab+Shift переносит фокус на группу радиокнопок.
Пробел выбирает радиокнопку, если она ещё не выбрана.
Клавиши стрелок вправо и вниз передвигают фокус от одной радиокнопки к другой внутри группы, снимая выбор с предыдущей и выбирая текущую кнопку. И так далее.
Рекомендую сверяться с этим руководством как можно чаще, а также добавлять полезные страницы в закладки.
Использование документации
Напоследок рассмотрим использование документации по доступности на примере разработки модального диалога. Представим, что на экране появляется окно с текстом ошибки. Видящий пользователь заметит его мгновенно, но как оповестить невидящего о том, что на экране что-то изменилось?
Как упоминалось выше, в стандарте WAI-ARIA и руководстве WAI-ARIA прописаны правила поведения всех основных компонентов. В нашем случае нужно использовать роль alertdialog — Alert and Message Dialogs, он же диалог ошибки или окно сообщения.
Здесь пора рассказать об одном из ключевых понятий WAI-ARIA — о ролях.
Роль (обозначается aria-атрибутом role) — это определённый паттерн взаимодействия пользователя с интерфейсом. В стандарте прописан исчерпывающий список ролей, которые мы можем присвоить нашим элементам управления. С их помощью можно обозначить, например, что наш div будет вести себя как чекбокс, и тогда скринридер не только зачитает текст из этого блока, но и сообщит, проставлена ли там галочка, а также проиграет соответствующий звук. Этот звук для невидящего пользователя будет таким же сигналом, как для видящего — квадратик и галочка. Пользователь поймёт, что с элементом можно взаимодействовать — поставить или убрать галочку, нажав на пробел.
При этом важно понимать: когда мы назначаем элементу управления ту или иную роль, мы как бы берём на себя обязательство, что снабдим этот элемент по крайней мере минимально необходимым набором ARIA-атрибутов, которые нужны скринридерам для его правильного озвучивания. Например, для чекбокса нужно указать не только его имя, но и состояние (checked / unchecked). ‘No ARIA is better, than bad ARIA’.
Вернёмся к нашему диалогу. Роль alertdialog позволяет вспомогательным технологиям и браузеру распознать диалог предупреждения или сообщения об ошибке и озвучить его появление специальным образом, например проиграв системный звук предупреждения.
Из пояснения к роли alertdialog в разделе ‘WAI-ARIA Roles, States, and Properties’ мы узнаём, что для элемента с ролью alertdialog мы должны указать значение одного из атрибутов (подробнее о них уже написано выше):
aria-labelledby — указывает на видимый элемент, содержащий заголовок диалога, либо
aria-label — если видимого заголовка нет, и нам нужно указать его только для скринридера.
Кроме того, необходимо указать значение атрибута aria-describedby, если в диалоге есть описательный текст. Как говорилось выше, атрибут aria-labelledby указывает, что элемент поименован неким заголовком. У нас это окно, которое ссылается к собственному названию и при открытии озвучивается примерно следующим образом: «Диалог», «Заголовок диалога» (например, «Подтвердите удаление»), «Текст в диалоге» (например, «Удалённый элемент нельзя будет восстановить»). При этом невидящий пользователь получит чёткое представление о том, какое именно окно появилось на экране.
Далее, WAI-ARIA сообщает нам, что alertdialog является подклассом модального диалога (роль dialog), а значит, мы должны выполнить те требования, которые указаны и для этой роли. Читаем руководство к модальному диалогу:
Фокус переходит на первый активный элемент в диалоге.
После закрытия диалога фокус переходит на предыдущий элемент (кроме случаев, когда логика процесса требует поместить его на элемент, следующий за предыдущим).
Контент под диалогом затемнён и неактивен.
Если эти требования не выполнить, пользователь не сможет взаимодействовать с содержимым диалога.
При появлении окна его заголовок зачитается благодаря атрибуту aria-labelledby, а фокус переместится на первый интерактивный элемент — текстовое поле. При переходе фокуса на поле ‘Special instructions’ дополнительное описание зачитается благодаря свойству aria-describedby.
Таким образом, нам ничего не нужно придумывать самим — все важные моменты уже прописаны в документации.
Примечание: WAI-ARIA не только инструктирует нас по отдельной роли, но и помогает в её выборе. В частности, нам поясняют, что следует отличать роль alertdialog от роли alert — динамического контента (live region), который содержит важную и/или срочную информацию, которую нужно донести до пользователя, не перенося на неё фокус. Динамический контент (live regions) определяется в WAI-ARIA как область веб-страницы, которая меняется в результате внешних событий, в то время как фокус пользователя находится где-то в другой области той же страницы. Примеры таких областей — окно чата, виджет с курсами валют или таймер. Раньше такие области были «невидимы» для ассистивных технологий, теперь же стандарт позволяет обрабатывать их при помощи атрибутов aria-live, aria-relevant, aria-atomic и aria-busy.
Тестирование
После базового знакомства с ARIA-атрибутами, правилами поведения фокуса и правилами клавиатурного взаимодействия вы можете попробовать протестировать интерфейс самостоятельно.
Убедитесь в том, что интерактивные элементы фокусируются, фокус визуально различим и его порядок соответствует расположению элементов на экране.
Проверьте клавиатурное взаимодействие с каждым из интерактивных элементов. Выпадающие списки должны появляться по нажатию Alt+стрелка вниз, элементы списка и радиокнопки — выбираться по клавишам стрелок, кнопки — нажиматься по Enter, чекбоксы — менять своё состояние при нажатии пробела, тултипы — исчезать при нажатии Esc и т.п.
Установите бесплатное расширение для Chrome — Screen Reader от Google. С его помощью можно проверить, корректно ли озвучиваются элементы интерфейса.
Заключение
Как эти знания помогают мне в повседневной работе? Проведение самостоятельного исследования требований доступности и размещение чётких правил поведения компонента экономит время разработчиков, занимающихся интерфейсной частью продукта.
Требования можно заносить в отдельный документ, но мне удобнее делать пометки непосредственно в файле Figma, размещая список параметров соответствия рядом с дизайном компонента.
Напоследок хочу ещё раз напомнить, что доступный дизайн улучшит юзабилити не только для людей с постоянными нарушениями здоровья, но и для обычных пользователей. Все пользователи выиграют, если:
все интерактивные элементы доступны с клавиатуры,
всё внятно и логично подписано.
Для этого мы прежде всего используем обычный HTML/CSS, общие стандарты UX и здравый смысл. А в помощь нам созданы
стандарт WCAG, описывающий принципы доступности,
стандарт WAI-ARIA, благодаря которому нам не нужно выбирать между доступностью сайта или приложения для скринридеров и созданием сложных, динамических дизайнов — мы можем реализовать и то, и другое одновременно,
руководство WAI-ARIA Authoring Practices, подробно описывающий, как сделать доступным тот или иной элемент управления.
Примечание: если вам стало интересно, то есть также бесплатный курс от Google на Udacity (на английском языке) — там можно чуть больше погрузиться в тему.