Availability of “custom html controls for blind users

The purpose of this post, on the one hand, is to demonstrate how blind users are difficult, and sometimes impossible to work with html controls that do not implement accessibility requirements, and on the other, to show that these requirements are not difficult to implement.

Here, on Habré, there have already been articles describing ways to achieve site accessibility, however, the accessibility issues of non-native html controls were addressed in the most general way, whereas I am sure that this is the main factor affecting web accessibility.

By custom or non-native html controls here are understood to be controls represented by, for example, standard tags like:

<button> </button> 

And just block elements with the appropriate visual design and event handlers of the type:
')

 <div class="button" onclick"..."> </div> 

I want to note that this article does not pretend to be a comprehensive guide to accessibility, it is intended only to give a general understanding and convey the importance of following the recommendations of wai-aria when using its own controls.

Through one of the accessibility api supported by the browser, IAccessible2, windows automation and other assistive technologies, in this case the screen reader, obtains all the necessary information about the controls in the document being processed, but only when it is present.

This is true for native elements like:

 <button> </button> 

Or

 <input type=”checkbox”> </input> 

By default, they support all the necessary roles, properties, control keys and implement the corresponding logic.

However, if the control is represented by a usual diva, with a corresponding visual design, then for the screen reader, and therefore for the user, this is just a div and nothing else.

For example, this is what the screen reader will tell the blind user if they meet the standard checkbox: “check me not checked”, that is, it will tell you the type of the element and its state, and if it does:

 <div class=" checkbox on _settings_access " id=" settings_a11y" onclick="checkbox(this); Settings.accessCheck(isChecked(this));"> </div> 

(real piece of layout located on the settings page vk.com ) then the screen reader will sound like this: “Special features clickable” (i.e., no information). A blind user will not be able to determine not only the state of the element, but also its type. In some cases, this element will be activated extremely unstable, and since the user cannot find out his current status, it becomes very difficult to use this option.

This is what causes non-compliance with accessibility requirements. Meanwhile, to comply with these requirements is extremely simple. For example, in this particular case, it is enough just to do the following: assign the corresponding value to the role attribute;

 <div class=" checkbox on _settings_access " id=" settings_a11y" onclick="checkbox(this); Settings.accessCheck(isChecked(this));" role="checkbox"> </div> 

And now the screen reader recognizes the item as a checkbox;

To process not only the onclick event, but also onkeydown, to allow users to activate the checkbox using the “space” key

 <div onkeydown”toggleCheckbox(evend)”> </div> 

 Function toggleCheckbox(evend) { If (event.keyCode === 32){ … } } 

Add logic for changing aria-checked property to event handling code js. Something like this:

 var state = node.getAttribute('aria-checked').toLowerCase() if (state === 'true') { node.setAttribute('aria-checked', 'true') } else { node.setAttribute('aria-checked', 'false') } 

And that's all. A small edit in the layout, a few lines of code and the element becomes fully accessible. Of course, for other elements there may be a little more code, for example, a radiobutton, since it is necessary to prescribe a bit more logic and process more keys, but in the end it’s still simple enough.

On the page: WAI-ARIA Authoring Practices A large number of examples of the implementation of various controls are presented.

Summary

The greatest problems for blind users are the inaccessibility of various controls. Whenever possible, you should use specialized html tags, they are available by default and the maximum that is required is to install aria-label; However, if this is not possible, then you should visit WAI-ARIA Authoring Practices and see how it is recommended to implement this or that widget.