Spoiler: if our web solution works with keyboard – if everything we can do with mouse or touch can be done with the keyboard – then we are on a really good way to accessible product.
That’s a fact, because keyboard interface can be either used in combination with screen reader or Braille keyboard or even any other special keyboard-like device. Some variations of these devices come in one-hand only keyboards, or maybe a keyboard that can be controlled with a stick, a single button version, or maybe even just an actual straw that a human can use for input to computer with just air pressure by sipping and puffing into the straw (opens in new window).
Therefore we must make sure that all of the content and all of the elements, even some custom, special ones are working well with keyboard only.
How do we test if everything works with keyboard?
Well, it looks complicated maybe, but it is actually very easy:
- Read about your computer keyboard shortcuts as Operating Systems differ a bit first.
- Set your mouse aside, or disable your touch-pad and try to use keyboard only. You do not need to start at scratch, you can open a browser and go to a webpage or application you would like to test and then set the mouse aside.
- If on windows, you can “tab” through the active elements on the page – so you can tab to links, input fields in a form, buttons,…
- Some elements, for example radio buttons, check-boxes and drop-downs need also arrow keys to navigate them. When in a group, for example, if using “tab” key you can not navigate inside the group
- To trigger buttons, follow links – just use a “enter” key, for some inputs also “space”.
So this is the easiest possible test (“tab”, “enter” and “space” are MS Windows keys, please check your keys if you use another Operating System).
OK, but how do I know that everything is working well?
Well, it depends on the element/widget that you are testing.
The easiest tests are done on native HTML elements. Those have the accessibility built in and will work as they should in practically every main-stream browser. The older the element the better support.
Newer elements can be difficult though. Some haven’t made it to all browsers or are just not working as they supposed to. All elements are defined by the W3C and then browser vendors take some time to implement them. So for example “dialog” native element still waits to be supported in some browsers.
You can easily check for support on the “Can I Use” webpage (opens in new window) and there you can get all sorts of information about the support. Let’s check the “dialog” support on today’s date;
So information on https://caniuse.com/#search=dialog is as follows:
- Full support only on Edge (v. 79-83), Chrome (v. 37-83), Opera (v. 24-69), Android browser (v.81), Chrome for Android (v.81) and some other browsers.
- Internet Explorer, Safari and iOS Safari no not support it at all.
- Firefox can support it if you tweak the settings.
“So – what to do – modals are so common, there are for sure solutions” – you may ask.
And you are right. Modals have been around for quite some time but the semantics and user experience had to be made from scratch. And although looking very simple at first sight – not all modals are accessible. They have to adhere to special rules so that they work well with keyboard and screen-readers.
Accessibility experts from W3C have defined some common best practices that every developer and tester should really study before making some custom elements. And modal, missing the native support for all browsers, is no exception.
Let’s look at what we have to do to have a really accessible modal dialog, according to the w3C accessibility experts:
- We click on a trigger – button or some other element to open the dialog,
- When a dialog opens, focus moves to an element inside the dialog,
- When we press the “tab” again, focus moves to next tabbable element inside the dialog,
- If focus is on the last tabbable element inside the dialog, then focus moves to the first tabbable element in the dialog.
- If we close the modal (for example by using the “escape” key) then the focus must land on the last element that was focused before the modal was opened – the trigger.
So – it is not enough to just make a div with some absolute or fixed positioning and overlay and we are done. No, not at all; we must control the “focus flow” in a way that limits the focus inside the modal when the modal is opened and does not allow the focus to “escape” the modal while modal is opened.
That is a major accessibility requirement and must be fulfilled. And no – we are not done with this – you can read about all other modal dialog requirements here (opens in a new window).
Every feature, every widget, every control should also be operable with keyboard – this is a major accessibility requirement and we must always make sure we test with keyboard.
me, standing on the shoulders of giants.
