Mitch11's Celebration Blog

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 th...

Both from a user perspective and from a technical perspective, I like the way Chromium is formalizing the "sequential focus navigation starting point" . A few highlights of this change: If a navigation to a url with fragment identifier happened, an element pointed by the fragment is set as sequential focus navigation starting point. In other words, anchor links like #skip_to_main will now work for keyboard users, without any JavaScript. We've only been  waiting for this since 1990 ! If the element pointed by sequential focus navigation starting point is removed from the document tree, a point where there was the element at would be the starting point. This is good for accessibility in modern web sites, such as single-page apps. We'll first need to see some follow-on improvements in browsers and assistive technologies, but eventually this might allow web authors to simplify focus management, as DOM elements are removed and changed. Implementation: Sequential ...