Availability of interfaces. Lecture of Yandex
My name is Dima, I work in the Yandex office in St. Petersburg and I do internal services in the Toloka interface development team. This year I prepared a lecture for Schools for the development of interfaces . Below is its interpretation.
What is the availability of interfaces? For whom is it important and why should it be pursued? What are the basic techniques that make the interface accessible? In addition to these questions, the lecture clarifies the principles that underlie assistive technologies. I tried to understand 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 "accessibility"? What options do you have? For the blind, reading from the screen, with disabilities, coordination of movements That's right. Availability - the ability to use the interface by all, regardless of physical or technical limitations. was already a lecture I hope you understand the importance of this.
You should always prefer embedded HTML elements, and only if necessary create your own. The reason for this is simple: built-in elements already out of the box have the correct semantics and a number of functional features. When one talks about this, often the buttons are used as an example. Therefore, I will have two buttons.
They differ only in the inscription, but in reality only the left button is a button. It is based on the button tag. The right one is just a stylized div. Therefore, in the left button we can focus - button by default the focus element. The button has a disabled state in which it can not be pressed. And click on the button occurs by pressing Enter and Space, if we are in the focus of the button. And only this button has the correct semantic role, from the browser's point of view, it's a button, and when the screen reader gets there, he will say that it's a button. This is not the case with the button based on the div. The following items you will have to implement yourself. But why, if there is a built-in good browser API that you can use?
On accessibility it is important to think about before the stage of development and layout. Who ever worked or designed his side-projects in designing or drawing a design? We are more than half the room. A couple of tips in this direction. Do not allow too small or merging elements to appear in the appearance of your interfaces.
Also, do not use decorative or calligraphic fonts for the main text. Remember about users with poor eyesight, with a violation of color perception. About people who use monitors with poor color rendition. All of them can 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, taking into account the peculiarities of some users. For example, there are people with problems with motor skills, it is difficult for them to get into small elements. Therefore, make such elements a click area larger than the control or button. The same applies to the elements located close to each other. A person who has a problem with motor skills may miss and press the wrong thing. Spread the important elements further apart, and be sure to ask for confirmation of some irreversible operations, for example, data deletion.
The general point about uniformity of design, consistency, predictability and consistency. All your design should be designed in one style. All the blocks on your site should be located in one place. It should not be such that the block jumps from place to place when navigating through pages. This is especially critical for navigation. A person who does not see your site builds his image in his head, represents what he looks like. If from the page to the page your navigation will jump from place to place, then it will just 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 with a convenient way to interact with sites on the Internet.
Before you understand the intricacies, let's see how it works under the hood in terms of the browser. After loading your page, the browser starts parsing HTML markup, and builds a DOM tree based on it. I hope this structure is known to you, 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 it another data structure - accessibility tree. This tree contains information useful in terms of accessibility. This information is taken by assistive technologies, for example, screen readers. And give the user some convenient way to interact with the site. During this interaction, the DOM can change, so the browser monitors the changes in the DOM and updates the accessibility tree as needed. Assistive technologies take these changes and somehow modify the functionality that they provide to their users.
This is an isolated data structure. To her andYou can not access from the DOM, it can not be viewed or edited with JS. The implementation and management of this structure are completely handled by browsers. Stored in this tree information about the semantics of elements, through which assistive technologies understand how to interpret elements from the page.
Access to this information is now available only with the help of special tools. One such element is the DevTools Accessibility Inspector. Now the Chrome availability inspector is in the experimental technology section, which you can enable by visiting the Chrome Flags page. You include these technologies, then go to DevTools and turn on the very panel of accessibility. So she looks in business.
Various useful information is shown here. And immediately the question arises, where does this information come from and how can it be changed?
Just a native checkbox wrapped in a label. So it will be presented in the accessibility tree. We see that this is an object, it has fields, a type of checkbox, a name taken from the label, and a state that can be checked and unchecked.
Now we make the custom checkbox with the help of div, its state is denoted by style. But from the browser's point of view, assistive technologies, it will simply be text with some meaning. These two examples clearly illustrate what I said earlier: whenever possible, you should always use native elements. But often this is impossible. Then the ARIA standard comes to the rescue.
The ARIA specification adds special attributes that determine 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 role for describing the type of elements, the properties for describing its state.
In brief, let's see what the roles and properties are like, then we will fix it by examples. Let's start with the concept of a role. The role allows us to classify the elements on the page. It is set that we add to the HTML element of the attribute role 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 the usual buttons, radio buttons, tabs, tooltips. Next are the composite roles that aggregate elements of other roles. Obviously, a radiogroup consists of elements of a radio or a tablist consists of a tab. Then follows the 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 for states. They can describe what status the element now has. For example, the state for the widgets, they denote 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 that controls another element. Also, states can declare specific areas in which the content change is expected to occur. These areas are called live regions.
There are many roles and conditions. All of them can be read on the specification website.
Let's look at examples of the most frequently used roles.
We'll finish our custom checkbox. We take the same div, but now we add a checkbox for it, as well as an attribute that shows the state, aria-checked, true or false. Now we need to add the appropriate JS, and from the browser's point of view, this semantics will be an honest checkbox. You can do other things in the same way. For example, a button that will act as a switch, switch between states. It has its own switch role and an attribute denoting its current state.
An example of an integral role. There is a list with a tablist element, there are elements with tabs inside it. So we tell the browser, meaning that these elements are tab.
A more complex example is a multilevel menu. In addition to various roles, among which there is a structural role - navigation, - there are compound roles nested in 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. Or, for example, aria-hidden with a value of true, speaking to assistive technologies, to the browser that this element is currently hidden.
On this slide, I wanted to draw attention to the fact that the very addition of the state, roles does not change the behavior of the element, its functional. There is an element, you compiled it, wrote JS, and then using these attributes describe its behavior, which will be interpreted by assistive technologies that will provide the user with a convenient way of interaction. Adding aria-haspopup does not make the item expandable by itself. Or adding aria-hidden does not hide the element from the page, remember this.
About the attributes that establish the relationship between the elements. This attribute allows you to specify that one element controls another item. In this case, this is the "show settings" button, which hides or shows the block beneath them. We use the attribute aria-controls with the value of the id of the block that we manage. A similar example, but here we refer to the block that describes our current block, use the attribute aria-describedby. In this case, the screen readers will read the content and give the user more information about what will happen when you click this button.
It's no secret that now almost all sites on the Internet are dynamic, that is, the content on them changes without reloading the page. And here from the point of view of accessibility there are problems. How to notify assistive technologies, the same screen readers, what on the page there was a change? To do this, aria introduced the concept of live regions. They can be created either using the alert role or using the aria-live attribute. Now the screensaver will track the changes in these blocks, and if the change has occurred, it will read out the new content to the user. And if you specify role = "alert" or aria-live with the value assertive, then the pronunciation of the new content will occur immediately. If now the screen reader reads the content on the page, the reading will be interrupted, and the contents will be read into the live-region.
If you want the notification of new content to be more polite, then you need to create a live region using the aria-live attribute with the value of polite. Then it will wait until the current content is spoken, and will say the new content after.
It's important to remember an interesting feature. In order for live regions to work in different browsers on different operating systems, it's better to create them static. You create an element where the content will change, make it empty, hide, for example, visually, and then, if necessary, simply add new content there and show. Then you can be 100% sure that all the assistive technologies, all the browsers on all OSes accurately and correctly display it and read it.
Let's talk more about control from the keyboard and on the focus. For people who use predominantly or only a keyboard when browsing sites, there are two main keyboard shortcuts: Shift + Tab and Tab. Go to the next and previous focus element. When we talk about the focus and its transition through the page, it is important to ensure the correct sequence of the focus transition.
The focus is on the order of HTML markup. As the elements are located in the markup, so the focus will also go. If you change the position of the elements visually using some CSS properties, for example, using absolute positioning, float, or the order property of flexboxes and grids, you change the position of the element only visually, in the markup it remains in its original position.
A small example. The right column is on the right, we read from left to right, it seems to us that it goes after. And it is expected to get into it after the main content. But in the markup, the right column goes before the main content. And if a person visits the site with the help of a screen reader or simply starts navigating on it using the tab key, it first gets to the right column, and then to the main one. A person who your interface somehow sort out, and a blind person can get very confused.
Continuing on the focus, I want to focus on the focus ring, this is a stroke around the focused element. We all know it, and probably we do not like everything, because it spoils our design. Therefore, we disable it on the whole site.
We forbid this to people who see our site, but use it from the keyboard, to see the current location of the focus. It is unclear where we are now. That's why you can not completely disable it. If you do not like the look, then redefine it, and it's not necessary to use the outline property, you can use box-shadow, border, anything, just to make it visually noticeable on the site.
Another interesting feature. Perhaps you have noticed that different focused elements under the same conditions can behave differently. For example, there is an insert and a button. When we navigiruemsya on them with the help of tobacco, both are in focus. But if we click on the intuition, the focus around it will appear. If you click on the button, the focus does not appear.
Why does it work, what's the difference? Browsers have their own internal heuristics that determine whether a focus ring should be displayed around the element or not. Access to these heuristics can be obtained through such an interesting pseudo-selector.
It is applied to the elements for which the browser currently considers it necessary to display the focus ring. If we want to do the opposite, to show the stroke around the focused element only if the user navigates through the site using the keyboard, then we write such a not quite trivial selector, which can literally be read like this: if the element is focused, but at the moment the browser thinks that around it we do not need to show the focus, then we remove the outline. This technology can be used when you create your custom components. But, as it usually happens in the front-line, all the cool things do not work now. That's why this technology is experimental, now it is inaccessible in browsers, it can be used only with the help of polyphile, I will leave a link to it at the end of the presentation.
Interactive elements, buttons, links, input fields by default fall into the order of passing focus to taboos. But what if we want to add our own elements or elements that are not focused by default? Here the tabindex attribute comes to the rescue. If you set it to ? the element becomes focused. Plus, it will be added to the focus stream. The thread that we hit by pressing tab.
We have focused and non-focused elements and a div between them. If we navigate the site using tab, we get to the first button and the second button. If we add tabindex = 0 for the second block, it becomes focused and gets in the order of focus, it will be the second.
If the element is set to tabindex = -? it becomes focused, but the focus does not fall into the order of focus. However, it can be focused using JS.
tabindex> 0 specifies the actual focus order. Having three non-focused elements, we can make them focused, and the order of focus will be indicated explicitly by these indices.
tabindex> 0 is a powerful tool, but you do not want to use it. Any change in layout, in design can break this sequence, and then your interface will become unpredictable. You can not do this. Competent focus management in special situations. I will give an example of two components, where special focus control is used. This pop, in my opinion, is from the fourth Bootstrap.
Any good pop, in addition to obvious things - such as closing by clicking on ESC or closing by clicking on the overlay, - should return focus to the element from which it originally came. It is important that the good modal window does not go beyond its limits. And it does not matter whether it is cyclical or rests on the first or last element. It is important that we can not fail at any time for the page behind the modal window.
Another example, material design, is the main content and the menu on the left. Here, a similar situation, while the menu is hidden, we should not get into it by focus. We go taboo on the page, we do not fail anywhere. As soon as the menu opens, we put focus on the first point, and then we can focus on the rest. Everything, the menu is closed, it is inert to focus, we can not get into it. That it did not happen that the user after a few clicks on the tab fails somewhere and does not see the current focus position.
These examples are similar in that at some point you need to make elements on the page. In the case of a modal window, this is the entire page behind. In the case of a pull-out menu, this is the hidden menu of the page. We must make these elements inert to focus so that they do not get a focus. To solve this problem, there is a very simple way - the attribute inert.
It is given simply to the element, and it works obviously. We put inert for the element, it and all of its children become inert for the focus. This thing is cool, and like any cool thing, it does not work right now. This technology is experimental, for its work you need a polyphile.
Other solutions that you can use with JS. There are a lot of libraries to solve this problem. One of them is Focus Manager. It implements two methods. The method of capturing captures the focus on some element. The release function takes an argument where the focus will return after we release it. Again, we recall the modal window, by closing the modal window, the focus returns to that element, knor anything, where he came from. This is cool and convenient, it must be done.
And another solution for the reaction is just a wrapper that does not give the focus beyond its limits. You import and use - you do not even need to think.
Many libraries of modal windows for the reaction (for example, React Modal) already out of the box have such a logic of focus control.
Screenwriters are the most convenient and accessible assistive technology. What screen readers are there?
The first on the line VoiceOver, which comes with Apple's operating systems, is not only macOS, but iOS, WatchOS, and it provides native functionality for interacting with the interface for people with disabilities. This is a cool tool, easy to use, functional, there are a lot of voices, settings, you can very conveniently configure for yourself. But the problem is obvious, it's only under macOS.
If you look at the screens for Windows, NVDA comes first. This is a free screensaver. In fact, it implements the same thing as VoiceOver, any scrinriders do about the same, but it's less functional, less convenient, more difficult to configure.
The third solution for Windows is the paid screen reader JAWS. A cool, functional, powerful thing, as customizable as VoiceOver, but you have to pay for it.
Just talking about the screens can not make much sense. We need to see how they work, understand what it is. Therefore, I will now demonstrate on the example of VoiceOver how a screensaver can read your site.
The settings of the screensaver in the macOS are in the Accessibility tab or "Universal Access", there is a section called VoiceOver. Click on the checkbox "enable VoiceOver" or the combination of Cmd + F5. I'm sure who uses poppies, he casually did so many times, then long searched for where to turn it off. We press and go.
Welcome to macOS. The screen reader turns on, immediately begins to speak. All that he says, can be seen in the black rectangle from the bottom. Turn this menu, go to the browser and press tab to get to the first element on the page.
This is the main Yandex. We get to the first element on the page. Just note that the focus ring is overridden by default, it's in the Yandex style. What do we see when we hit this element?
First, the screensaver said that this is a link. He pronounced the title of this link. In the second line, he showed what element this link belongs to. It belongs to the block with the role of complimentary, this is an additional block on the page. Figure 2 says that in addition to this link there is also some element, that is, two of them. Press tab and get into the second element of this block.
Have fallen in the setup menu. The screen reader read out the correct role - it's a pop-up button. Remember that this is aria-haspopup. This button also has an additional state, it is minimized, and since this is a button, we can conveniently click on it with Enter or a space. Press the spacebar:
The status has changed, we proceed further.
We went through all the links in this popup. Please note that he says about viewed links that it is viewed. Remember about the focus of management. We said that in such elements it's cool, if the focus did not fall out, but cycled through them. No sooner said than done. In this element, we can not get the focus out, it's cool and convenient.
Go back to the settings, go to the next page.
We were in the news block. Judging by the type, it's a tablist, it's selected, it has the right status. Expectedly, we expect him to move over the rest of the tobacco with the help of arrows. And really, by clicking on the arrows, we will walk on the tags.
We pass inside.
We got on the list. At once the number of elements in the group was read. It's convenient, people understand how many elements in the group, how far you can go. The title of the link itself was also read. We go further on the links.
We fall into the button, which has alternative text. If it were not, we would just not understand what it is, there's an icon. But a person with a screen reader does not see this icon, so an alternative text. The roles and status are obvious, it's a pop-up button and stuff.
Opened the pop, close it from the keyboard, go ahead, skipping the news block.
We have the weather, but if there was no alternative text for the icon, we would not understand what the weather is now in St. Petersburg. Although, maybe this is understandable.
We go further, because the order of the elements is not confused, pressing tab, we move on the markup.
But if the page is large, it's not very convenient to walk with tab or shift + tab. Therefore, screen readers often provide convenient navigation functionality for your site. In VoiceOver, this tool is called a rotor, it is opened by pressing Ctrl + Cmd + U.
Here is a menu that contains various types of entities on the page. Here the benchmarks turned out to be the first. These are the same landmarks, special roles.
This gives the user a convenient way to go directly to the block of interest. In addition to landmarks, there are also controls, buttons, tabs, everything that can be clicked on, which will provoke actions on the page.
These are headlines. We talked about the importance of headlines. Here all the headings of the first level, but they will make it convenient to go, for example, to traffic jams or a TV program. References are the same.
The rotor, like VoiceOver, is highly customizable, many other entities can be added here.
For those who want to try the tool in the case, there are useful keyboard shortcuts.
Let's designate what should be paid special attention while ensuring the availability of the site, when checking the site for availability. Let's start with the elements on the page, the layout and semantics. The layout should be valid and correct from the point of view of the semantics and microsemantics of your elements, the macrosemantics of your entire page. Images and media content should be accessible, like the forms and your custom components. You have seen that the screensaver often uses roles and states, and in many ways, thanks to roles, one can understand what is happening on the page. The main thing is that your site is readable for everyone who has a bad monitor or poor vision. It is necessary to engage in the competent design of elements. Well, consistency. The site should be convenient to navigate with Tab or Shift + Tab. All interactive elements must be achievable, and all hidden elements are unattainable for focus.
We will analyze what will help us in the site audit for accessibility. Screenswriters. You saw that if you want to provide accessibility or check it on some site and just open it from the screen reader, you will immediately understand how people who do not see it can hear and understand this site.
Accessibility Inspector. Using it, it's easy to see what kind of semantics your site has under the hood of the site.
Audits tab in DevTools. In my opinion, it appeared with the 60th Chrome. It's convenient to watch, and it tells you that you have a wrong website, that you can fix and where.
A piece that looks like Audits is the Ax tab. This is a toolkit that allows you to conduct an automated test of the availability of your site. In its simplest form, it is available as an extension for the browser. You just download it, open the necessary site and see the following picture. You have a list of problems, a description of the problem, where it is located and, possibly, the way to solve it.
Also Ax is presented as a web driver for Selenium. If you want to make the availability check part of your test infrastructure, please use. Set up quickly and conveniently.
Ax CLI - in fact, the same as the extension for the browser, only in your terminal. Under the hood there is Phantom JS.
Here are four materials for further study. If the topic of accessibility seemed interesting to you, you can read it.
- Tutorial from Mozilla;
- The Web site is with advice on accessibility in Russian, very coolly designed;
- A11ycast - video on YouTube from the guys from Google, podcast, there's a lot of cool information;
- Inclusive components It is interesting from the point of view of how the available components are specifically implemented. On this site are various articles that step by step show how to implement different design components that are usual to us.
I hope you understand that accessibility is an important topic that you need to deal with the availability on your sites. Only you can make the life of people with disabilities easier.
References to materials from the presentation
- GOST R 52872-2012
- WCAG ???r3r3791.
Polifill for inert
- Polyfill for: focus-visible
- Focus manager
- React Focus Lock
- Ax Core
It may be interesting
Situs QQ Online
Situs QQ Online