Interface availability. Yandex lecture

  • Tutorial
My name is Dima, I work in the Yandex office in St. Petersburg and deal with internal services in the Toloki interface development team. This year I prepared a lecture for the Interface Development School . Below is its transcript.

What is interface availability? For whom is it important and why should we 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 options do you have? 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.

The available interface is the 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? In the first place - 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 violations 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 has broken his right arm begins to experience problems with motor skills. And the interface, developed without taking into account these features, can be simply 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 a switch. Accessibility is not only about computers and laptops, it is also about mobile devices. A person with disabilities can access your site 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 the image on the page, for example, screen magnifiers that are built into Windows, macOS, these are software color modifiers and so on. For example, there is a software that allows you to control the interface using the movement of the eyes and head. In macOS, such a program is embedded, 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 the 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 the input fields using the label tag, in 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 are automatically 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 is clear, the text in this tag should describe the purpose or name of the page. If you have a single page application, then 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, and screen readers accurately determine the language of such a page. If you have several languages ​​in the 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 make a navigation, wrapping it 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 will be 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 have correct semantics and a number of functional features out of the box. 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. Right - just a stylized div. Therefore, in the left button we can focus - the button is the default 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 designs 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 the area of ​​clicks for such elements larger than the control or the button. 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, 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 another 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 tree as needed.

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 changes are expected to occur. 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 that indicates 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. Or, for example, aria-hidden with a value of true, telling assistive technologies, the browser, that this element is currently hidden.

In this slide, I wanted to note that the addition of the state itself, the roles in no way changes the behavior of the element, its functionality. There is an element, you put it up, wrote JS, and then use these attributes to describe its behavior, which will be interpreted by assistive technologies that will provide the user with a convenient way to interact. Adding aria-haspopup does not make the element pop-up by itself. Or adding aria-hidden does not hide the element from the page, remember this.

Pro attributes that establish the relationship between elements. This attribute allows you to indicate that one element controls another element. In this case, this is the "show settings" button that hides or shows the block below them. We use the aria-controls attribute with the id value of the block we control. A similar example, but here we refer to the block that describes our current block, use the aria-describedby attribute. In this case, screen readers will read the contents to us and provide the user with more information about what will happen by clicking on 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 problems arise. How to notify assistive technologies, the same screen readers, that a change occurred on the page? To do this, aria introduced the concept of live regions. They can be created either by using the alert role, or by using the aria-live attribute. Now the screen reader will track changes in these blocks, and if a change has occurred, it will read 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 the screen reader now reads the content on the page, the reading is interrupted, and the content is read into the live-region.

If you want the notification about new content to be more polite, then you need to create a live region using the aria-live attribute with the value polite. Then he will wait until the current content is pronounced, and will say the new content after.

It is important to remember an interesting feature. To live regions work in different browsers on different operating systems, it is better to create them static. You create an element where the content will change, make it empty, hide it, for example, visually, and then, if necessary, simply add new content there and show it. Then you can be 100% sure that all assistive technologies, all browsers on all operating systems will accurately and correctly display and read it.

More talk about keyboard control and focus. For people who use mainly or only the keyboard when browsing websites, there are two main keyboard shortcuts: Shift + Tab and Tab. Move to the next and previous focusable item. When we talk about the focus and its transition on the page, it is important to ensure the correct sequence of focus transition.

The focus is in order of HTML markup. As the elements are located in the markup, so the focus will go. If you change the position of elements visually using some CSS properties, for example, using absolute positioning, float or order property of flex boxes and grids, then you change the position of the element only visually, in the markup it remains in the same place.

A small example. The right column is on the right, we read from left to right, it seems to us that it comes after. And expectedly should get into it after the main content. But in the markup, the right column goes before the main content. And if a person enters the site with the help of a screen reader or simply starts navigating through it using the tab key, it will first get to the right column, and then to the main one. The person who will understand your interface somehow, 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 her, and probably do not like everything, because it spoils our design. Therefore, we disable it throughout the site.

By this we forbid people who see our site, but use it from the keyboard, to see the current location of the focus. It is not clear where we are now. That is why it can not be completely disabled. If you do not like the look, then redefine it, and you do not need to use the outline property, you can use box-shadow, border, anything, so long as it is clearly visible on the site.

Another great feature. You may have noticed that different focused elements may behave differently under the same conditions. For example, there is an input and a button. When we navigate through them using taba, both are in focus. But if we click the mouse on the input, the focus around it will appear. If we press the button, the focus does not appear.

Why does this work, what difference does it make? Browsers have their own internal heuristics, which determine whether focus ring should appear around an element or not. Access to these heuristics can be obtained through such an interesting pseudo-selector.

It is applied to elements for which the browser currently considers it necessary to display a focus ring. If we want to do the opposite, display a stroke around a focused element only if the user navigates through the site using the keyboard, then we write such a not quite trivial selector that can literally be read like this: if the element is focusable, but currently the browser thinks that it is around It is not necessary to show the focus, then we remove the stroke. This technology can be used when creating your custom components. But, as is usually the case in the front end, all the cool stuff is not working right now. That is why this technology is experimental, now in browsers is not available, it can only be used with a polyfill, 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 focusing on taboos. But what to do if we want to add to this order our own elements or elements that are not focused by default? This is where the tabindex attribute comes in. If you set it to 0, the item will become focusable. Plus it will be added to the flow of focus. The thread that we hit by pressing tab.

We have focusable and unfocused elements and a div between them. If we navigate through the site using the tab, we get to the first button and the second button. If we add tabindex = 0 for the second block, it will become focusable and get into focus order, become the second.

If the element is set with tabindex = -1, it will become focusable, but the focus will not be in order. However, he can focus on using JS.

tabindex> 0 sets the actual focus order. Having three non-focused elements, we can make them focusable, and the order of focus will be indicated explicitly by these indices.

tabindex> 0 is a powerful tool, but it is undesirable to use it. Any change in the layout, design can break this sequence, and then your interface will become unpredictable. So you can not do. Competent focus management in special situations. I will give an example of two components where special focus control is used. This popup, in my opinion, from the fourth Bootstrap.

Any good popup, in addition to the obvious things - such as closing by pressing ESC or closing by clicking on the overlay - should return the focus to the element where it originally came from. It is important that in a good modal window the focus does not go beyond it. It does not matter whether it is cyclical or rests on the first or last element. It is important that at no time can we fail for a page past a modal window.

Another example, material design, is the main content and the menu on the left. Here is a similar situation, as long as the menu is hidden, we should not get into it with a focus. We go taboo on the page, do not fall anywhere. As soon as the menu opens, we put the focus in the first item, and then we can go focus on the rest. Everything, the menu is closed, it is inert for the focus, we cannot get into it in any way. So that it does not happen that the user after a few clicks on the tab falls somewhere and does not see the current position of the focus.

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 whole page behind. In the case of a drop-down menu, this is a hidden page menu. We must make these elements inert to focus so that the focus does not fall into them. To solve this problem, there is a very simple way - the inert attribute.

It is assigned simply to the element, and it works obviously. We set an inert for an element, it and all its children become inert for the focus. This thing is cool, and, like any cool thing, now does not work. This technology is experimental, for its work you need a polyfill.

Other solutions you can use with JS. There are a large number of libraries to solve this problem. One of them is Focus Manager. It implements two methods. Capture method captures focus on some element. The release function takes an argument where the focus will return after we release it. Again we remember the modal window, focusing on that element, button or whatever it came from is returning to closing the modal window. This is cool and convenient, it should be done.

And another solution for the reactor is simply a wrapper that prevents the focus from moving beyond its limits. You import and use - you don’t even need to think.

Many libraries of modal windows for the reactor (for example, React Modal) already have this logic of focus control out of the box.

Screen readers are the most convenient and accessible assistive technology. What are screen readers?

The first in line for VoiceOver, which comes with Apple's operating systems, is not only macOS, but also 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 large number of voices, settings, it can be very convenient for you to customize. But the problem is obvious, it is only under macOS.

If you look at screen readers for Windows, NVDA comes first. This is a free screen reader. In fact, it implements the same thing as VoiceOver, any screen reader does about the same thing, but it is less functional, less convenient, more complicated to set up.

The third solution for Windows is the JAWS paid screen reader. A cool, functional, powerful thing, just as customizable as VoiceOver, but you have to pay for it.

Just talking about screen readers makes little sense. We need to see how they work, to understand what it is. Therefore, I will now demonstrate, with the example of VoiceOver, how a screen reader can read your site.

The screen reader settings in macOS are in the Accessability or “Universal Access” tab, there is a VoiceOver section. Click on the “Enable VoiceOver” checkbox or the Cmd + F5 combination. I am sure who uses poppies, I did this many times by chance, then I looked for a long time where to turn it off. Push and go.

Welcome to macOS. The screen reader turns on, immediately starts talking. All that he says, can be seen in the black rectangle below. Turn this menu, go to the browser and click on the tab to get to the first item on the page.

This is the main Yandex. We get to the first element on the page. Immediately note that the focus ring is redefined by default, it is in Yandex style. What do we see when we hit this element?

First, the screen reader said it was a link. He pronounced the title of this link. In the second line, he showed which element this link belongs to. It belongs to the block with the role of complimentary, it is an additional block on the page. The number 2 says that in addition to this link there is still some element, that is, there are two of them. Press tab and get into the second element of this block.

Got into the setup menu. The screen reader read the correct role - this is 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 spacebar. Press the space:

Status has changed, move on.

We went through all the links in this popup. Please note that about the viewed links, he says that it was viewed. We remember about focus management. We said that in such elements it is cool if the focus did not fall out on the outside, but walked around in them cyclically. No sooner said than done. In this element we can’t get out of focus, it's cool and comfortable.

We return to the settings, go on the page further.

We hit the news block. Judging by the type, this is a tablist, it is selected, it has the desired status. Expectedly, we expect him to move around the other tabs with the help of arrows. And indeed, clicking on the arrows, we will walk on the tags.

Go inside.

We hit the list. Immediately read out the number of elements in the group. This is convenient, people understand how many elements are in a group, how far you can go. Read the title link itself. We go further on the links.

We fall into the button, which has an alternative text. If it were not there, we simply would not understand what it is, there is an icon. But a person with a screen reader does not see this icon, so an alternative text. Obvious roles and condition that this pop-up button and so on.

The popup has opened, 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 it may be so clear.

Go ahead, because the order of the elements is not confused, by pressing the tab, we go on the markup.

But if the page is large, walking with tab or shift + tab is not very convenient. Therefore, screen readers often provide convenient functionality for navigating your site. In VoiceOver, such a tool is called a rotor, it opens by pressing Ctrl + Cmd + U.

Here is a menu that contains various types of entities on the page. Here were the first landmarks. These are the same landmarks, special roles.

This provides the user with a convenient way to go directly to the block of interest. In addition to the landmarks, there are also controls, buttons, tabs, everything you can click on, which will trigger actions on the page.

These are headlines. We talked about the importance of headlines. Here are all the headlines of the first level, but they allow you to conveniently go, for example, to traffic jams or TV shows. Links are the same.

The rotor, like VoiceOver, is very customizable; many other entities can be added here.

For those who want to try the tool in business, useful keyboard shortcuts.

Let's designate what you should pay special attention to in ensuring the availability of the site, when checking the site for accessibility. Let's start with the elements on the page, layout and semantics. Layout must be valid and correct from the point of view of semantics and microsemantics of your elements, macroselements of your entire page. Images and media content should be accessible, as well as forms and your custom components. You have seen that the screen reader often uses roles and states, and thanks in large part to the roles it is possible to understand what is happening on the page now. The main thing is that your site is readable for anyone with a poor monitor or poor eyesight. It is necessary to engage in competent design elements. Well, the consistency. The site should be convenient to navigate using Tab or Shift + Tab. All interactive elements must be reachable.

Let us examine what will help us in the audit of the site for accessibility. Screen readers. You have seen that if you want to ensure accessibility or check it on some site and simply open it with a screen reader, you will immediately understand how this site can be heard and understood by people who do not see it.

Accessibility Inspector. With its help, it is convenient to watch what is under the hood of the site, what is the semantics of your typesetting.

Audits tab in DevTools. In my opinion, it appeared with the 60th Chrome. It is convenient to watch, and it tells you what is wrong on the site, what can be corrected and in what place.

Stuck, similar to Audits, - tab Ax. This is a set of tools that allows you to conduct an automated test of the availability of your site. In its simplest form, it is available as a browser extension. You simply download it, open the desired site and see the following picture. You have a list of problems, a description of the problem, where it is located and, possibly, a way to solve it.

Ax is also presented as a web driver for Selenium. If you want to make a test of accessibility part of your test infrastructure, please use. Customize quickly and conveniently. Ax CLI - in fact, the same as the browser extension, only in your terminal. Under the hood there is a Phantom JS.

Here are four additional study materials. If the topic of accessibility seemed to you interesting, you can read.

-Tutorial from Mozilla;
- Website Webline with tips on accessibility in Russian, very cool designed;
- A11ycast - a video on YouTube from the guys from Google, a podcast, there is a lot of cool information;
- Inclusive components is interesting in terms of how the available components are specifically implemented. On this site there are various articles that step by step show how to implement the various design components we are used to.

I hope you understand that accessibility is an important topic, that you need to deal with accessibility on your websites. Only you can make the lives of people with disabilities easier.

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

Also popular now: