Friday, February 26, 2016

Can JavaScript set a Sequential Focus Navigation Starting Point?

This is a follow-up from my last blog post. Should a web author be able to explicitly set a Sequential Focus Navigation Starting Point using JavaScript?

There are several reasons why the answer should be "yes."

It can improve user experience in some cases

Today, for accessibility it's often necessary to set focus on a div or static text. If browsers and assistive technologies will provide a consistent experience for anchor links, then instead of setting focus on non-actionable content, it would be more like native browser behavior to set a Sequential Focus Navigation Starting Point. In such cases users would expect to see the element in the viewport, so the author should also use Element.scrollIntoView().

Less often, this same technique can solve a usability problem when JavaScript sets focus on a text input. In devices with virtual keyboards (iOS Safari at least), input.focus() causes the virtual keyboard to appear. This is appropriate in some cases, where the design intent is to strongly prompt the user to enter something. But what if the intent is only to start the user at a logical spot in the form? For example, after the user cancels out of a modal dialog. In this case using JavaScript to set a Sequential Focus Navigation Starting Point would provide a better experience.

It conforms to WCAG 2.0 as well as anchor links do

I've never heard of failing Success Criterion 2.4.3 Focus Order or 2.4.7 Focus Visible because of the browser-default behavior of anchor links. This JavaScript technique would do the same thing.

There are good technical precedents

Setting window.location.href creates the same effect as a user clicking a link to a new page.

In most browsers, Element.focus() creates the same effect as a user clicking an anchor link to land on a focusable element.

So if JavaScript can create the effect of an anchor link landing on a non-focusable element, it would be very consistent with those existing capabilities.

It might already work

When an element has focus, then the expected behavior of Element.blur() -- after Chromium issue 454172 -- is to create a Sequential Focus Navigation Starting Point.

So what should happen if the author invokes Element.blur() on an element that does not currently have focus? The logical consequence would be for this element to become the Sequential Focus Navigation Starting Point.

I could live with this counterintuitive behavior of Element.blur(), like we've all learned to live with tabindex="-1". I'm also open to adding a more aptly named method to browser-native JavaScript.

No comments: