We’re fast approaching Christmas, and I have a gift for you. You can shape the future direction of this newsletter by filling in my survey! It would really help me to understand what you like or don’t like, which subjects you’d like to read more about, all that lovely stuff. All I Want for Christmas is You(r) thoughts on my newsletter – please fill it in! 🎄 Now on with the show…

A Guide To Keyboard Accessibility: JavaScript (Part 2)

In this second part of a two-part series, we move away from HTML and CSS and take a closer look at JavaScript.

The click event listener listens for a mouse click, but is also triggered by the Enter key (on buttons and links) and the Space key on buttons only. For other keys, you’d need to use the keydown event. This is often used for things like enabling the Esc key to close a modal. You can use keycode.info to find out which key code corresponds to the key you’re listening for.

Another important event is blur, which indicates that the element has lost focus. Combined with the keydown event, you can use this to add and remove a class on the given element, so that the state is wiped clean on each interaction and you can (for example) continually open and close a modal.

Next, we learn about the focus() method, which allows you to bring the keyboard focus to a particular element. It can be used with the preventScroll argument to ensure the browser doesn’t scroll as part of the interaction. There’s also a new focusVisible argument, which would prevent the focussed element from displaying its focus styling, but this currently only works in Firefox.

There’s a section on “roving tabindex“ which looks interesting – check out the demo. Sadly, the role="tab" and role="tabpanel" attributes are left unexplained, but there’s lots of detail about the actual JavaScript implementation.

The inert attribute mentioned in dai11y 15/12/2022 (intended for things like modals) gets a second showing here: the author talks us through how we should implement a modal at the moment (with inert not yet supported). We give it a role="dialog" and aria-modal="true" for screen reader, and a tabindex="-1" to make it programmatically focussable. Then, we create a function to open the modal, but need to keep track of which element opened it, as we’ll need to return focus to that element when closing the modal. The code looks something like:

let focusedElementBeforeModal;
const modal = document.querySelector("[role='dialog']");

const openModal = () => {
  focusedElementBeforeModal = document.activeElement;
  modal.hidden = false;
  modal.focus();
};

There’s some more detail about modals / focus traps and how to use the new inert attribute, towards the end of the article.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.