Interface availability. Yandex lecture
My name is Dima, I work at the Yandex office in St. Petersburg and do internal services in the Toloki interface development team. This year, I prepared a lecture for the Interface Development School . Below is its decoding.
What is interface availability? For whom is it important and why should you strive for it? What are the basic techniques that make an interface available? In addition to these questions, the lecture clarifies the principles that underlie assistive technology. I tried to disassemble the theory and a large number of practical examples, as well as show the process of the screen reader.
- What is hidden under the fashionable term now accessibility? What are your options? For the blind, reading from the screen, with disabilities, coordination of movements ... That's right. Accessibility - the ability to use the interface by all, regardless of physical or technical limitations.
')
An accessible interface is an interface that is most convenient to use for a wide range of users. Perhaps someone had a question, why make the interfaces accessible? What motivations does this have? The first and, in my opinion, the most important motivation is moral. People with disabilities are no worse than others, they also want and have the opportunity to use the full functionality of the resources that you develop.
Financial aspect. People with disabilities are customers who buy your products, use your services, so accessibility also contributes to expanding your current market and entering new markets.
Legal aspect. The inherent right of access to information is embedded in the laws of many countries. For example, in the US and the EU, all web interfaces should be accessible to people with disabilities. In our case, this applies mainly to government websites; this applies to all others only as a recommendation.
Who are these people who care about accessibility? First of all - users with visual impairment, completely blind people, visually impaired people, people with color disturbances. These users are hard to see your site. They may not see your site at all. The second category - users with disorders of the musculoskeletal system. It is difficult for such people to use input devices, they have a problem with motility, spontaneous muscle contraction.
I would like to pay special attention to the fact that at any time any of us may face time constraints, and then he will not be able to use the interface in its usual form. For example, a right-handed person who breaks his right arm begins to experience problems with motor skills. And the interface, developed without taking these features into account, can simply become inaccessible to it.
Now in Russia about 10% of the population are people with a particular disability. And by no means the last place is occupied by people with vision problems or the locomotor system. And all these people are potential visitors to your site. Accessibility is especially important to them.
Technologies that help people use interfaces can be divided into two types: hardware and software. People with disabilities are assisted in using interfaces with special keyboards, mice, joysticks, and other input devices.
As an example, I want to bring this thing. This type of device is called Switch. Accessibility is not only about computers and laptops, it is also about mobile devices. A person with disabilities can access your website from a phone or tablet. This device connects to an iOS or Android device, and some user actions can be assigned to its buttons. For example, this Switch - with two large buttons, it is convenient to assign focus control to it on the page.
For users who do not see your interface, speech synthesis is not always convenient. Therefore, there is a braille display. This is a special output device that displays information in the form of tangible points in Braille. Great stuff, but she has two problems. She is very expensive, not every needy person can afford it.
In addition, people who have lost sight in a more mature age often do not know Braille and do not want to master it.
Software technology is also enough. These are tools for enlarging images on a page, for example, screen magnifiers that are built into Windows, macOS, these are software color modifiers and so on. For example, there is software that allows you to control the interface using the movement of the eyes and head. In macOS, such a program is built in, it is called Dwell Control. But among software technologies, screen readers occupy a special place. This is a special application that reads the contents of the site and OS to the user, provides him with convenient navigation functionality.
Screen readers are the most accessible and common way to perceive information for people with visual impairment. We will talk about them in more detail during the lecture.
A few words about the recommendations in the field of accessibility interfaces. We have this GOST, and in the West - WCAG and Section 508. The methods described in these recommendations do not affect the appearance of the site, but provide users with disabilities with some additional pieces for navigation and use.
Practices that help make your interface available today. An alternative description should convey brief information to the text, supplement or designate it.
The same goes for graphics and icons on the page. Remember: they also need extra support. If any additional element on your page is presented as an image, then it must be hidden from the screen reader using the aria-hidden = “true” attribute.
About attributes with the prefix aria talk further.
It is necessary to describe input fields using the label tag, for which we specify the for attribute with the id value of the input field. This not only allows you to quickly go to editing the control by clicking on the label, but also semantically links the control to its description, that is, the screen reader will read the description of this element to us. Specifies the data types of the input fields.
In addition to the validation rules that will automatically be added to these inputs, in many cases a convenient cross-browser input method will be presented. For example, as here, the calendar in the case of type Date or Color, if it is a color. If the browser does not support any of the types, input with the text type will be substituted, nothing will break.
Mark required fields using required or aria-required = ”true” attributes. Group related fields using the fieldset tag, using the legend element to specify the group header, where you can write not only the purpose of the group, but also the general characteristics of the fields (for example, all fields in this group are required).
We wrap the three radio buttons in the fieldset tag, and set the title in the legend tag. Now, regardless of which button is selected, the screen reader will read the contents of the legend tag. And the person who visits the site will understand what is happening in this form.
Show error and success messages.
About the title and so it is clear, the text in this tag should describe the purpose or name of the page. If you have a single page application, do not forget to change the contents of the title tag when navigating the page.
Specify the page language. To do this, you need to set the lang attribute in the HTML tag. This is good for SEO, it helps plug-in translators, as well as screen readers accurately determine the language of such a page. If you have several languages in your document, you can specify the lang attribute for individual tags. Observe the validity of the layout. This is important because screen readers may misinterpret invalid pages. The same goes for semantics. All elements on the page must be semantically correct, you must use HTML tags for their meaning. And when you create your custom elements, take care of the correct semantics.
Let's talk about examples in the field of semantics. First about the headlines. They are one of the most important in terms of semantics elements on the page. When a person enters the site using a screen reader, goes to an unknown page, the first thing he does on this page is to go through the headings. And screen readers even have a special mode that allows you to conveniently do this. If there are headings on your page and display a clear hierarchy, then it will be convenient for a person to navigate through the site, he will be able to quickly go to the desired section. It is very convenient, use it.
Another example of the importance of semantics is menu layout. If you make the menu as left, from the point of view of semantics it will be just a group. A div is a grouping tag, and inside it there will be some amount of unrelated elements, in this case just three links.
If you navigate by wrapping in a special semantic tag, inside of which there will be a list of elements, each of which is a link, then from the point of view of semantics, screen reader and browser this will be honest navigation, inside of which there is a list of three elements that can be conveniently used. move.
The following advice, I hope, is obvious to you: the correct use of semantic tags from the fifth HTML standard ensures that your layout is logically correctly interpreted by browsers and assistive technologies.
About adaptive layout and mobile version. You already had a lecture on adaptive layout, I hope you understand the importance of this.
You should always give preference to embedded HTML elements, and only if necessary create your own. The reason for this is simple: embedded elements already out of the box have the correct semantics and a number of functional features. When people talk about it, they often give buttons as an example. Therefore, I will have two buttons.
They differ only in the inscription, but in reality only the left button is the button. It is based on the button tag. The right one is just a stylized div. Therefore, in the left button we can focus - the button is by default the focused element. The button has a disabled state in which it cannot be pressed. And click on the button occurs by pressing Enter and Space, if we focus on the button. And only this button has the correct semantic role, from the point of view of the browser, the screen reader is a button, and when the screen reader gets there, he will say that this is a button. All this does not have a button based on a div. The following points you have to implement yourself. But why, if there is a built-in good browser API that can be used?
It is important to think about accessibility before the development and layout stage. Who has ever been involved in designing or drawing design at work or in their side projects? We are exactly more than half the hall. A couple of tips in this direction. Do not allow the appearance of their interfaces too small or merging with the background elements.
Also, do not use decorative or calligraphic fonts for the main text. Remember about users with poor eyesight, in violation of color perception. About people who use monitors with poor color reproduction. All of them may simply not see your interface elements. This is especially critical for control elements, for controls.
We talked about forms, but more from the point of view of semantics. Here, pay attention to the competent design of user interaction with forms, and taking into account the features of some users. For example, there are people with problems with motor skills, it can be difficult for them to get into small elements. Therefore, make such an area for clicks more than such controls or buttons. The same applies to elements located close to each other. A person who has a problem with motor skills may miss and press the wrong one. Spread important items further from each other, and be sure to request confirmation of some irreversible operations, such as deleting data.
The general point is about the uniformity of design, consistency, predictability and consistency. All your design should be designed in any one style. All blocks on your site should be located in the same places. There should not be such that the block jumps from place to place as you move through the pages. This is especially critical for navigation. A person who does not see your site, builds an image in his head, represents what he looks like. If from page to page your navigation will jump from place to place, then it will simply get confused in this, it will be impossible to use the site.
In addition to all the technologies we have learned about, there is a standard designed to provide users with disabilities a convenient way to interact with sites on the Internet.
Before we understand the intricacies, let's see how it works under the hood from the point of view of the browser. After loading your page, the browser starts to parse the HTML markup, and builds a DOM tree based on it. I hope you know this structure, it is based on the display of data in the browser, it can be changed using JS, etc. When the DOM tree is built, the browser builds on the basis of it a different data structure - accessibility tree. This tree contains information that is useful in terms of accessibility. Assistive technologies, for example, screen readers, take this information. And provide the user with some convenient way to interact with the site. During this interaction, the DOM may change, so the browser monitors changes in the DOM and updates the accessibility of the tree as needed. Assistive technologies take away these changes and somehow modify the functionality that they provide to their user.
This is an isolated data structure. It cannot be accessed from the DOM, it cannot be viewed or edited using JS. Browsers implement and manage this structure completely. Information about the semantics of elements is stored in this tree, with the help of which assistive technologies understand how to interpret elements from a page.
Access to this information is now available only with the help of special tools. One of these elements is the DevTools Accessibility Inspector. Now the Chrome Accessibility Inspector is in the experimental technologies section, which you can enable by going to the Chrome Flags page. You turn on these technologies, then go to DevTools and turn on the accessibility panel itself. So she looks in the case.
This shows various useful information. And the question immediately arises, where does this information come from and how can it be changed?
Small examples.
Just a native checkbox wrapped in a label. So it will be presented in accessibility tree. We see that this is an object, it has fields, a checkbox type, a name taken from a label, and a state that can be checked and unchecked.
Now we make a custom checkbox with a div, its state is denoted by style. But from the point of view of the browser, assistive technologies, it will be just a text with some meaning. These two examples vividly confirm what I said earlier: whenever possible, you should always use native elements. But often this is not possible. Then the ARIA standard comes to the rescue.
The ARIA specification adds special attributes that define exactly how the element will be represented in the accessibility tree, what properties it will have. The main thing that this specification gives us is the roles for describing the type of elements, properties for describing its state.
Briefly we will look at what roles and properties are, then we will fix it with examples. Let's start with the concept of the role. The role allows us to classify items on the page. It is set to add to the HTML element of the role attribute with the desired value.
There are many different roles in the standard, and they are divided into different groups. For example, the role of widgets. They are assigned to elements that are independent parts of the user interface. These are familiar buttons, radio buttons, tabs, tooltips. Next are the composite roles that aggregate the elements of other roles. Obviously, a radiogroup consists of radio elements or a tablist consists of tabs. This is followed by structural roles and landmarks, landmarks. These roles are given to large semantic blocks on the page.
In addition to roles, the ARIA standard also provides states. They can describe what status the item currently has. For example, the state for widgets, they indicate that the element is hidden, marked, blocked, etc.
There are also states that indicate the connection of elements. For example, an element describes another element, controls another element. States can also declare specific areas in which content is expected to change. These areas are called live regions.
Roles and states are many. All of them can be read on the site specifications.
Look at the examples of the most frequently used roles.
Let's finish our custom checkbox. We take the same div, but now we add the checkbox role for it, as well as an attribute that indicates the state, aria-checked, true or false. Now you need to add the appropriate JS, and from the point of view of the browser, semantics, this will be an honest checkbox. Other elements can be made in the same way. For example, a button that will act as a switch to switch between states. It has its own switch role and an attribute denoting its current state.
An example of a composite role. There is a list with a tablist element, inside it there are elements with tab roles. So we tell the browser, implying that these elements are tab.
A more complex example is the multi-level menu. In addition to the various roles, among which there is a structural role - navigation, - there are composite roles nested within each other. There are a couple of interesting states, for example, aria-haspopup with a value of true indicates that this element is drop-down. , , aria-hidden true, , , .
, , , . , , JS, , , . aria-haspopup . aria-hidden , .
, . , . « », . aria-controls id , . , , , aria-describedby. , .
, , . . , , ? aria live . alert, aria-live. , , , . role=”alert” aria-live assertive, . , , live-region.
, , live region aria-live polite. , , .
. live , . , , , , , , , , . 100%, , .
. , , : Shift + Tab Tab. . , .
HTML-. , . - CSS-, , , float order , , .
. , , , . . . tab, , . , - , .
, focus ring, . , , , . .
, , , . , . . , , outline, box-shadow, border, , .
. , , -. , . , . , . , .
, ? , , focus ring . .
, focus ring. , , , : , , , . , . , , . , , , .
, , , . , , ? tabindex. 0, . . , tab.
div . tab, . tabindex=0, , .
tabindex=-1, , . JS.
tabindex > 0 . , , .
tabindex > 0 — , . , , . . . , . , -, Bootstrap.
, — ESC , — , . , . , . , .
, material design, . , , . , . , , . , , , . , tab - .
, - . . . , . — inert.
, . inert , . , , , . , .
, JS. . — Focus Manager. . apture - . release , , . , , , . , .
— , . — .
(, React Modal) .
. ?
VoiceOver, Apple, macOS, iOS, WatchOS, . , , , , , . , macOS.
Windows, NVDA. . , , VoiceOver, , , , .
Windows — JAWS. , , , VoiceOver, .
. , , , . VoiceOver, .
macOS Accessability « », VoiceOver. “ VoiceOver” Cmd + F5. , , , , . , .
macOS. , . , , . , tab, .
. . , focus ring , . , ?
-, , . . , . complimentary, . 2 , - , . tab .
. — . , aria-haspopup. , , , Enter . :
, .
popup. , , . . , , , . No sooner said than done. , .
, .
. , tablist, , . . , , .
.
. . , , , . . .
, . , , , . , . , .
, , , .
, , , , . , , .
, , tab, .
, tab shift+tab . . VoiceOver , Ctrl+Cmd+U.
, . . landmarks, .
. , , , , , , .
. . , , , . — .
, VoiceOver, , .
, , — .
, , . , . , . , . , , , . , , . . . Tab Shift +Tab. , — .
, . . , - , , , .
Accessibility Inspector. , , .
Audits DevTools. -, 60- Chrome. , , , .
, Audits, — Axe. , . . , . , , , , .
Axe - Selenium. , — , . . Axe CLI — , , , . Phantom JS.
. , .
— Mozilla;
— , ;
— A11ycast — YouTube Google, , ;
— Inclusive components , . , , .
, , — , . .
What is interface availability? For whom is it important and why should you strive for it? What are the basic techniques that make an interface available? In addition to these questions, the lecture clarifies the principles that underlie assistive technology. I tried to disassemble the theory and a large number of practical examples, as well as show the process of the screen reader.
- What is hidden under the fashionable term now accessibility? What are your options? For the blind, reading from the screen, with disabilities, coordination of movements ... That's right. Accessibility - the ability to use the interface by all, regardless of physical or technical limitations.
')
An accessible interface is an interface that is most convenient to use for a wide range of users. Perhaps someone had a question, why make the interfaces accessible? What motivations does this have? The first and, in my opinion, the most important motivation is moral. People with disabilities are no worse than others, they also want and have the opportunity to use the full functionality of the resources that you develop.
Financial aspect. People with disabilities are customers who buy your products, use your services, so accessibility also contributes to expanding your current market and entering new markets.
Legal aspect. The inherent right of access to information is embedded in the laws of many countries. For example, in the US and the EU, all web interfaces should be accessible to people with disabilities. In our case, this applies mainly to government websites; this applies to all others only as a recommendation.
Who are these people who care about accessibility? First of all - users with visual impairment, completely blind people, visually impaired people, people with color disturbances. These users are hard to see your site. They may not see your site at all. The second category - users with disorders of the musculoskeletal system. It is difficult for such people to use input devices, they have a problem with motility, spontaneous muscle contraction.
I would like to pay special attention to the fact that at any time any of us may face time constraints, and then he will not be able to use the interface in its usual form. For example, a right-handed person who breaks his right arm begins to experience problems with motor skills. And the interface, developed without taking these features into account, can simply become inaccessible to it.
Now in Russia about 10% of the population are people with a particular disability. And by no means the last place is occupied by people with vision problems or the locomotor system. And all these people are potential visitors to your site. Accessibility is especially important to them.
Technologies that help people use interfaces can be divided into two types: hardware and software. People with disabilities are assisted in using interfaces with special keyboards, mice, joysticks, and other input devices.
As an example, I want to bring this thing. This type of device is called Switch. Accessibility is not only about computers and laptops, it is also about mobile devices. A person with disabilities can access your website from a phone or tablet. This device connects to an iOS or Android device, and some user actions can be assigned to its buttons. For example, this Switch - with two large buttons, it is convenient to assign focus control to it on the page.
For users who do not see your interface, speech synthesis is not always convenient. Therefore, there is a braille display. This is a special output device that displays information in the form of tangible points in Braille. Great stuff, but she has two problems. She is very expensive, not every needy person can afford it.
In addition, people who have lost sight in a more mature age often do not know Braille and do not want to master it.
Software technology is also enough. These are tools for enlarging images on a page, for example, screen magnifiers that are built into Windows, macOS, these are software color modifiers and so on. For example, there is software that allows you to control the interface using the movement of the eyes and head. In macOS, such a program is built in, it is called Dwell Control. But among software technologies, screen readers occupy a special place. This is a special application that reads the contents of the site and OS to the user, provides him with convenient navigation functionality.
Screen readers are the most accessible and common way to perceive information for people with visual impairment. We will talk about them in more detail during the lecture.
A few words about the recommendations in the field of accessibility interfaces. We have this GOST, and in the West - WCAG and Section 508. The methods described in these recommendations do not affect the appearance of the site, but provide users with disabilities with some additional pieces for navigation and use.
Practices that help make your interface available today. An alternative description should convey brief information to the text, supplement or designate it.
The same goes for graphics and icons on the page. Remember: they also need extra support. If any additional element on your page is presented as an image, then it must be hidden from the screen reader using the aria-hidden = “true” attribute.
About attributes with the prefix aria talk further.
It is necessary to describe input fields using the label tag, for which we specify the for attribute with the id value of the input field. This not only allows you to quickly go to editing the control by clicking on the label, but also semantically links the control to its description, that is, the screen reader will read the description of this element to us. Specifies the data types of the input fields.
In addition to the validation rules that will automatically be added to these inputs, in many cases a convenient cross-browser input method will be presented. For example, as here, the calendar in the case of type Date or Color, if it is a color. If the browser does not support any of the types, input with the text type will be substituted, nothing will break.
Mark required fields using required or aria-required = ”true” attributes. Group related fields using the fieldset tag, using the legend element to specify the group header, where you can write not only the purpose of the group, but also the general characteristics of the fields (for example, all fields in this group are required).
We wrap the three radio buttons in the fieldset tag, and set the title in the legend tag. Now, regardless of which button is selected, the screen reader will read the contents of the legend tag. And the person who visits the site will understand what is happening in this form.
Show error and success messages.
About the title and so it is clear, the text in this tag should describe the purpose or name of the page. If you have a single page application, do not forget to change the contents of the title tag when navigating the page.
Specify the page language. To do this, you need to set the lang attribute in the HTML tag. This is good for SEO, it helps plug-in translators, as well as screen readers accurately determine the language of such a page. If you have several languages in your document, you can specify the lang attribute for individual tags. Observe the validity of the layout. This is important because screen readers may misinterpret invalid pages. The same goes for semantics. All elements on the page must be semantically correct, you must use HTML tags for their meaning. And when you create your custom elements, take care of the correct semantics.
Let's talk about examples in the field of semantics. First about the headlines. They are one of the most important in terms of semantics elements on the page. When a person enters the site using a screen reader, goes to an unknown page, the first thing he does on this page is to go through the headings. And screen readers even have a special mode that allows you to conveniently do this. If there are headings on your page and display a clear hierarchy, then it will be convenient for a person to navigate through the site, he will be able to quickly go to the desired section. It is very convenient, use it.
Another example of the importance of semantics is menu layout. If you make the menu as left, from the point of view of semantics it will be just a group. A div is a grouping tag, and inside it there will be some amount of unrelated elements, in this case just three links.
If you navigate by wrapping in a special semantic tag, inside of which there will be a list of elements, each of which is a link, then from the point of view of semantics, screen reader and browser this will be honest navigation, inside of which there is a list of three elements that can be conveniently used. move.
The following advice, I hope, is obvious to you: the correct use of semantic tags from the fifth HTML standard ensures that your layout is logically correctly interpreted by browsers and assistive technologies.
About adaptive layout and mobile version. You already had a lecture on adaptive layout, I hope you understand the importance of this.
You should always give preference to embedded HTML elements, and only if necessary create your own. The reason for this is simple: embedded elements already out of the box have the correct semantics and a number of functional features. When people talk about it, they often give buttons as an example. Therefore, I will have two buttons.
They differ only in the inscription, but in reality only the left button is the button. It is based on the button tag. The right one is just a stylized div. Therefore, in the left button we can focus - the button is by default the focused element. The button has a disabled state in which it cannot be pressed. And click on the button occurs by pressing Enter and Space, if we focus on the button. And only this button has the correct semantic role, from the point of view of the browser, the screen reader is a button, and when the screen reader gets there, he will say that this is a button. All this does not have a button based on a div. The following points you have to implement yourself. But why, if there is a built-in good browser API that can be used?
It is important to think about accessibility before the development and layout stage. Who has ever been involved in designing or drawing design at work or in their side projects? We are exactly more than half the hall. A couple of tips in this direction. Do not allow the appearance of their interfaces too small or merging with the background elements.
Also, do not use decorative or calligraphic fonts for the main text. Remember about users with poor eyesight, in violation of color perception. About people who use monitors with poor color reproduction. All of them may simply not see your interface elements. This is especially critical for control elements, for controls.
We talked about forms, but more from the point of view of semantics. Here, pay attention to the competent design of user interaction with forms, and taking into account the features of some users. For example, there are people with problems with motor skills, it can be difficult for them to get into small elements. Therefore, make such an area for clicks more than such controls or buttons. The same applies to elements located close to each other. A person who has a problem with motor skills may miss and press the wrong one. Spread important items further from each other, and be sure to request confirmation of some irreversible operations, such as deleting data.
The general point is about the uniformity of design, consistency, predictability and consistency. All your design should be designed in any one style. All blocks on your site should be located in the same places. There should not be such that the block jumps from place to place as you move through the pages. This is especially critical for navigation. A person who does not see your site, builds an image in his head, represents what he looks like. If from page to page your navigation will jump from place to place, then it will simply get confused in this, it will be impossible to use the site.
In addition to all the technologies we have learned about, there is a standard designed to provide users with disabilities a convenient way to interact with sites on the Internet.
Before we understand the intricacies, let's see how it works under the hood from the point of view of the browser. After loading your page, the browser starts to parse the HTML markup, and builds a DOM tree based on it. I hope you know this structure, it is based on the display of data in the browser, it can be changed using JS, etc. When the DOM tree is built, the browser builds on the basis of it a different data structure - accessibility tree. This tree contains information that is useful in terms of accessibility. Assistive technologies, for example, screen readers, take this information. And provide the user with some convenient way to interact with the site. During this interaction, the DOM may change, so the browser monitors changes in the DOM and updates the accessibility of the tree as needed. Assistive technologies take away these changes and somehow modify the functionality that they provide to their user.
This is an isolated data structure. It cannot be accessed from the DOM, it cannot be viewed or edited using JS. Browsers implement and manage this structure completely. Information about the semantics of elements is stored in this tree, with the help of which assistive technologies understand how to interpret elements from a page.
Access to this information is now available only with the help of special tools. One of these elements is the DevTools Accessibility Inspector. Now the Chrome Accessibility Inspector is in the experimental technologies section, which you can enable by going to the Chrome Flags page. You turn on these technologies, then go to DevTools and turn on the accessibility panel itself. So she looks in the case.
This shows various useful information. And the question immediately arises, where does this information come from and how can it be changed?
Small examples.
Just a native checkbox wrapped in a label. So it will be presented in accessibility tree. We see that this is an object, it has fields, a checkbox type, a name taken from a label, and a state that can be checked and unchecked.
Now we make a custom checkbox with a div, its state is denoted by style. But from the point of view of the browser, assistive technologies, it will be just a text with some meaning. These two examples vividly confirm what I said earlier: whenever possible, you should always use native elements. But often this is not possible. Then the ARIA standard comes to the rescue.
The ARIA specification adds special attributes that define exactly how the element will be represented in the accessibility tree, what properties it will have. The main thing that this specification gives us is the roles for describing the type of elements, properties for describing its state.
Briefly we will look at what roles and properties are, then we will fix it with examples. Let's start with the concept of the role. The role allows us to classify items on the page. It is set to add to the HTML element of the role attribute with the desired value.
There are many different roles in the standard, and they are divided into different groups. For example, the role of widgets. They are assigned to elements that are independent parts of the user interface. These are familiar buttons, radio buttons, tabs, tooltips. Next are the composite roles that aggregate the elements of other roles. Obviously, a radiogroup consists of radio elements or a tablist consists of tabs. This is followed by structural roles and landmarks, landmarks. These roles are given to large semantic blocks on the page.
In addition to roles, the ARIA standard also provides states. They can describe what status the item currently has. For example, the state for widgets, they indicate that the element is hidden, marked, blocked, etc.
There are also states that indicate the connection of elements. For example, an element describes another element, controls another element. States can also declare specific areas in which content is expected to change. These areas are called live regions.
Roles and states are many. All of them can be read on the site specifications.
Look at the examples of the most frequently used roles.
Let's finish our custom checkbox. We take the same div, but now we add the checkbox role for it, as well as an attribute that indicates the state, aria-checked, true or false. Now you need to add the appropriate JS, and from the point of view of the browser, semantics, this will be an honest checkbox. Other elements can be made in the same way. For example, a button that will act as a switch to switch between states. It has its own switch role and an attribute denoting its current state.
An example of a composite role. There is a list with a tablist element, inside it there are elements with tab roles. So we tell the browser, implying that these elements are tab.
A more complex example is the multi-level menu. In addition to the various roles, among which there is a structural role - navigation, - there are composite roles nested within each other. There are a couple of interesting states, for example, aria-haspopup with a value of true indicates that this element is drop-down. , , aria-hidden true, , , .
, , , . , , JS, , , . aria-haspopup . aria-hidden , .
, . , . « », . aria-controls id , . , , , aria-describedby. , .
, , . . , , ? aria live . alert, aria-live. , , , . role=”alert” aria-live assertive, . , , live-region.
, , live region aria-live polite. , , .
. live , . , , , , , , , , . 100%, , .
. , , : Shift + Tab Tab. . , .
HTML-. , . - CSS-, , , float order , , .
. , , , . . . tab, , . , - , .
, focus ring, . , , , . .
, , , . , . . , , outline, box-shadow, border, , .
. , , -. , . , . , . , .
, ? , , focus ring . .
, focus ring. , , , : , , , . , . , , . , , , .
, , , . , , ? tabindex. 0, . . , tab.
div . tab, . tabindex=0, , .
tabindex=-1, , . JS.
tabindex > 0 . , , .
tabindex > 0 — , . , , . . . , . , -, Bootstrap.
, — ESC , — , . , . , . , .
, material design, . , , . , . , , . , , , . , tab - .
, - . . . , . — inert.
, . inert , . , , , . , .
, JS. . — Focus Manager. . apture - . release , , . , , , . , .
— , . — .
(, React Modal) .
. ?
VoiceOver, Apple, macOS, iOS, WatchOS, . , , , , , . , macOS.
Windows, NVDA. . , , VoiceOver, , , , .
Windows — JAWS. , , , VoiceOver, .
. , , , . VoiceOver, .
macOS Accessability « », VoiceOver. “ VoiceOver” Cmd + F5. , , , , . , .
macOS. , . , , . , tab, .
. . , focus ring , . , ?
-, , . . , . complimentary, . 2 , - , . tab .
. — . , aria-haspopup. , , , Enter . :
, .
popup. , , . . , , , . No sooner said than done. , .
, .
. , tablist, , . . , , .
.
. . , , , . . .
, . , , , . , . , .
, , , .
, , , , . , , .
, , tab, .
, tab shift+tab . . VoiceOver , Ctrl+Cmd+U.
, . . landmarks, .
. , , , , , , .
. . , , , . — .
, VoiceOver, , .
, , — .
, , . , . , . , . , , , . , , . . . Tab Shift +Tab. , — .
, . . , - , , , .
Accessibility Inspector. , , .
Audits DevTools. -, 60- Chrome. , , , .
, Audits, — Axe. , . . , . , , , , .
Axe - Selenium. , — , . . Axe CLI — , , , . Phantom JS.
. , .
— Mozilla;
— , ;
— A11ycast — YouTube Google, , ;
— Inclusive components , . , , .
, , — , . .
Links to materials from the presentation
- GOST R 52872-2012
- WCAG 2.0
- Polyfill for inert
- Polyfill for: focus-visible
- Focus manager
- React Focus Lock
- Ax Core
Source: https://habr.com/ru/post/424879/
All Articles