We can perform accessibility testing in different ways. [highlight dark=”no”]Good accessibility rates are the basis for performing proper software testing[/highlight].

Users can not only use specialized software but also work with such simple tools as a computer mouse and the “Tab” button. Further, we’ll talk about the latter in detail.

The “Tab” button is really “magical” and multi-functional.

Testing the focus styles

By clicking on this button, a user can check if a web element is properly highlighted. If not, he/she should write a ticket on this and assign it to developers as soon as possible. For example, he/she can suggest using the following styles  :focus{ }, :focus-within{ } to properly stylize the selected elements on a web page.

We can also analyze the variations of stylization on third-party resources, to have numerous options to choose from.

For example:

https://cariefisher.com/

https://css-tricks.com/focusing-on-focus-styles/

https://github.com/WICG/focus-visible

Verification of interactive elements

Now we can proceed with testing — is a user able to access interactive elements (various links, buttons, videos) or not? If not, we should search for the bug inside the HTML tree. We may tell developers that they should use not simply <div>, <svg>, <span> attributes but also <button> attribute.

We should never use the <div> attribute for clickable elements. Since the data of a false button will be inaccessible for users who use a keyboard or screen readers.

Here is the link to read more: https://www.youtube.com/watch?v=8XjwDq9zG4I (this can be extremely helpful for executing multiple functional tests).

Using real buttons

If nothing happens after clicking on the “Space” or “Enter” buttons, then there is an incorrect <button> attribute.

We can operate false buttons with the help of the “Tab” button but real events will be accessible only for real buttons by default.

An example of a correct structure:

<button class=”btn”>
Send
</button>

Read more here: https://www.youtube.com/watch?v=CZGqnp06DnI

Work of skip links

This attribute is not mandatory for each website but we should make switching to a necessary element easier, not needing to view the entire interface of a web page.

An example of good implementation of skip links: https://tatianamac.com/

More information here: https://webaim.org/techniques/skipnav/

Work with focus and infinite scrolling

A user clicked on the selected button and saw a modal dialog box? Is he/she able to switch directly to an element? If not, the bug is that we need to switch a focus from a button to the opened box.

You can read the following useful resource to understand how to test this: https://medium.com/@matuzo/writing-javascript-with-accessibility-in-mind-a1f6a5f467b9#7a0c

As for scrolling, if a user can’t switch to footer elements by pressing the “Tab” button, he/she should write a ticket that there is infinite scrolling on a website. This should be fixed as soon as possible.

Conclusion

To conclude, we’d like to say that the “Tab” button is really a universal tool for software testing, that helps to test web accessibility.

Accessibility is very important, therefore, we should pay a lot of attention to testing its functionality so that the quality of web development in a QA lab will be as efficient as possible.