Skip to main content

Pushing Buttons

Published by Michael Spellacy (Spell) on

Understanding Roles

While it may not have great bearing on visual users, those who use assistive technology (AT) greatly benefit from the correct choices we make with our mark-up. All rendered HTML elements have an inherent role assigned to them.

You can access these roles with your favorite browser development tool.

Screenshot of the Accessibility inspector in Chrome DevTools. In it, we are highlighting the role of the target element.

These roles are often read back to AT users. For example, landing on a button labeled "Search Jobs" with the NVDA screen reader, will announce:

"Search Jobs, button..."

Understanding that this interaction point is a button, helps improve the perception of the element and the action to expect when an element is interacted with. Now seems as good a time to suggest getting better acquainted with a WCAG concept known as POUR (Perceivable, Operable, Understandable, and Robust), so read up!

Buttons do things; hyperlinks navigate.

When we use links where buttons should be used (and vice versa), we break this expectation.

Table of Contents

Keyboard Benefits

Using the right element for the job has other benefits, too. For example, keyboard users will expect both the return and space keys to initiate an action. When you use the button element, there will be no need to code a second event for keypress, as the single click event will work with both of these keys. Efficient!

Table of Contents


The best solution, and the one you should probably push for amongst stakeholders, is to simply allow anchors to work as they inherently do. Leave the fancy scrolls and risks that come with suppression, behind. This solves all three issues previously mentioned. However, I do live in the real world and understand that you may be required to implement a smooth scrolling behavior, so let's take a look at an uncommon approach. Again, while JavaScript is usually the de facto method for controlling scroll behavior, I think CSS offers a far more elegant solution:

html {
scroll-behavior: smooth;

Using scroll-behavior: smooth not only allows us to include the obvious behavior for all anchors across our site, but also allows us to retain our URL hashes without the nasty jump. The focus issue is also solved, since the native behavior for anchors is to apply focus to their target elements. But what about sensory concerns?

@media (prefers-reduced-motion: reduce) {

  html {
  scroll-behavior: auto;


By using the prefers-reduced-motion media query, we can honor a user's operating system settings to disallow animations. This may not be perfect for all use cases, like people with temporary disabilities (migraines, etc.), but it is a step in the right direction.

Table of Contents


You can check out an example of this behavior on this very page! As an added bonus and to keep it all in the CSS family, using scroll-behavior and prefers-reduced-motion with the :target selector, helps us to create a very seamless and accessible user experience. Look ma, no JavaScript!

Table of Contents


Support for scroll-behavior is very good across the board. I personally see no harm in using it and to allow the anchors to fall back to their default behavior if CSS support is not present in an older browser. Progressive enhancement at its best. However, if full support is what you require, then you'll have to find a polyfill or just roll the same behavior using JavaScript, but please do not forget to include support for all the issues mentioned here.

The prefers-reduced-motion media query also enjoys wide support, so be sure to include it in any animation work you may produce.

Table of Contents