Accessibility & A11y

Basically, accessibility deals with the question of enabling users with disabilities to access apps (and, generally speaking, technologies). For information, here is a great article by Uri Shaked about the concept of accessibility :

Of course, building apps accessible to disabled audiences is (luckily) not a core concern for a developer, but actually, the idea has been now extended to the broader question of how to improve accessibility beyond the regular mouse/screen interaction, and in particular of how to include keyboard events in our web apps.

For example, when a user opens a form, it might be convenient to get the first field already selected and ready to be filled (instead of having to click on it first). Or, it might be comfortable to let our user navigate through the form fields with keyboard arrows (instead of having to select it manually). Etc.

Read more: Mexican pokemon cards

So this is what brings us to the purpose of the Accessibility CDK feature, and its A11y package : giving tools to developers to easily implement a smooth and comfortable keyboard interaction between the user and your app.

The code !

Enough talking — let’s try to dig into some code.

Even though the code is annotated, it might be worth few explanations.

Read more: Meryl streep devil wears prada haircut

We are mainly using two elements:

• The FocusTrapFactory service, which instantiates the focus trap in the form. For information, trapping focus on a web page in an element means that, on the DOM, temporarily only a single node receives focus. This is often the case for modal pop-ups : when the pop-up is open, usually the rest of the page is blurred and inaccessible (for example, if the modal displays a form, hitting the tab key will let the user cycle through the popup form fields, but will not let him access the rest of the page). Here is a great article on focus traps : https://hiddedevries.nl/en/blog/2017-01-29-using-javascript-to-trap-focus-in-an-elementWe simply call the create() method of the service, with a template reference as parameter, to create a focus trap. So now, once the form open, the user can go through all focusable elements of the form using the tab key without leaving the form.
• The FocusMonitor service and the ListKeyManager class to enable interaction with the keyboard arrows. For this, we need to listen to the keyboard events, and to call: – the ListKeyManager.onKeydown(event) method, which sets any focusable element selected by keyboard as ‘active’- the FocusMonitor.focusVia(…) method, which puts focus on an element selected by the method passed as second argument (‘keyboard’ here)For information, active and focused elements are not related with each other (an active element won’t be automatically focused, and vice versa), therefore it seems we have to do the two operations. This is also the reason why we need to differentiate the case where the user uses keyboard arrows (which updates the active element automatically via the onKeyDown method) and when the user hits tab (which doesn’t update the active element). This is so far the best solution I found, not sure it is the smartest one — any improvement would be very welcome.

So now, we should have a very basic form, which is nicely working with our keyboard arrows.

FocusTrap related directives :

The FocusTrap CDK also provides us a convenient directive, which might be worth mentioning.

Read more: Pooja jain generation investment management

The cdkTrapFocus directive creates a focus trap region, without needing using the FocusTrapFactory service, for example :

Nb: The cdkFocusRegionStart and cdkFocusRegionEnd directives are also convenient, but it seems there is currently something wrong with the RegionEnd directive (or at least, I could not let it work correctly).

But, before using the directive, we need to keep in mind that it doesn’t initialize any FocusTrap instance (contrary to the service), which prevents from using any method or property available on the FocusTrap class (such as focusInitialElement(), etc). For example, in the example above, we can’t set the focus in the FocusTrap region dynamically (excepted by using the plain javascript method focus() on the #element ElementRef). Therefore, using the FocusTrapFactory service provides more possibilities and flexibility than using the directive.