Visual buttons in web applications and how to tag them
When working on a modern web application, a developer has an array of choices for visual buttons. The choices you make may work fine for some users, but lead to trouble when it comes to accessibility and semantically correct HTML.
What is the smart choice then?
The worst practice: non-interactive elements
You can, should you wish so, write something like this:
If you click on “Do something” it will call doSomething-function just fine and produce the expected result. But what if you are a keyboard user? Well, browsers will ignore this element when you tab through your page. To correct this, you might want to add the tabindex-attribute, like so:
Now “Do something” will get focus when you tab and with some CSS applied you can even indicate that this element is active, but what about screen readers used by people with disabilities? Well, since the screen just sees this as just a plain span element, it will not list this element as a button.
You can go even further and add a role-attribute:
Now some screen readers will be convinced that it is a button. But you won’t be able to activate it with Enter- or the Space-key. To be able to do so you will have to assign Event Listeners to Enter or Space and fire the doSomething.
To save all that trouble you could just make this element to what it is – a button:
The browser will know right away that it should focus on this element when you are using keyboard and it should call doSomething when you press Enter or Space.
The best practice: Button and Anchor elements (<a>)
There are still frameworks and libraries which use buttons and anchors, or a-elements, interchangeably. You may often see something like this for a button:
Well, if you see # as a value for href-attribute, then you are not using anchor-element correctly. The href-attribute should indicate a link target, either URL or URL fragment (have a look at specification here). If it is an action then it should be a button element:
With a great number of Single Page Applications out there, it might be confusing to decide whether to use a button or anchor element for actions. Some libraries and frameworks use routing mechanisms to change views without actually going to a new http location.
I believe that, semantically, it is still correct to use anchor tag (<a>) when you are loading a new view, for example going from app/index.html to app/index.html/#/phones.
For screen readers, the anchor element will appear in the list over links indicating that a new page will be loaded (in traditional understanding of hyperlinks) and this is exactly what is happening from the user perspective, even though http address is the same.
To sum it up:
- Avoid using non-interactive elements like DIV’s and SPAN’s for actions.
- Choose carefully when to use Anchor- and Button-elements.
- Be consistent in using Anchor- and Button-elements.
- Always test how your elements work with keyboard navigation.
- Test if your interaction semantics make any sense for screen readers.
On Macs you can toggle in-built screen reader called VoiceOver by pressing command key + F5 (cmdF5). For Windows machines you can refer to Microsoft accessibility guide here.
In the next blog I will talk about popular icon-fonts, such as Font Awesome, compared to using Scalable Vector Graphics (SVG).