Focus management

[Heydon]

It's not clear from the documentation that focus management is supported. That is, when jumping to a selector, this element would be focused so that keyboard interaction is localized to the newly "jumped to" element.

If this is not supported, I suggest there is an accessibility issue for keyboard and AT users and would be happy to answer any questions you might have about addressing it.

Thanks!

[callmecavs]

the library doesn't currently do anything to manage the focus. in terms of addressing accessibility, and focusing the target after the jump is complete, is it as simple as calling .focus() on the element that's been scrolled to? i'm a bit naive when it comes to accessibility so I'd appreciate your input.

in the case of scrolling a fixed pixel amount, rather than to an element, is there anything in particular that should be focused in that case? or is it best to just retain focus on what was previously focused?

[callmecavs]

ping @Heydon

[Heydon]

Hey Michael. Yeah, the element that is animated to should be focused at the
end of the animation (callback function, maybe?) The element should be made
programmatically focusable by giving it tabindex="-1" before you use the
focus() method on it. Hope that helps. Ask if you need anything more :-)

[callmecavs]

sounds good, i'll take a shot at implementing this in the _end() method. this is the method that fires the callback, at the end of the jump

[Heydon]

Oh, that sounds perfect. Nice one!

[callmecavs]

does -1 or 0 make more sense for the tabindex? looking at this, it seems as though 0 may be the better choice, because a negative value means the element would be otherwise unreachable by keyboard navigation

[Heydon]

-1 means focusable but only programmatically. This is suitable because
you're only focusing the element to move the user into the right area. 0
would mean the element is permanently focusable, which would not be
suitable because (typically) it would not be an interactive element like a
link or button; just a container. Does that make sense?

[callmecavs]

makes perfect sense. thanks for the great explanation. really happy you raised this issue. admittedly im not an expert on accessibility support - knowing i can add something like this to provide it is awesome

[callmecavs]

@Heydon running into a problem with adding a tabindex and calling focus() on the element - browsers draw a blue outline around the element, like they would a form element, as seen in the screenshot below. is there any way you know of to avoid this?

[callmecavs]

the code for this is on the focus branch if you want to play around with it: https://github.com/callmecavs/jump.js/tree/focus

[ZoeBijl]

There are a few ways around this. The absolute worst—how do I stress this further?—thing to do is to disable the outline:

element:focus { outline: none }

A better way to do it is to animate that outline into oblivion on focus:

element:focus {
  animation: outline 2s;
}

@keyframes outline {
  to {
    outline-color: transparent;
  }
}

Another option that involves animation, but allows you to “make things prettier”: you can animate anything you want on focus. So you could disable the outline—contradicting what I said earlier; the important thing is that focus is visible—on the focused element, but animate the background from a noticeable different colour—say yellow—to the original colour—say white—and thus make it clear where focus went on the page.

You could of course also drop the animation and make focus noticeable permanently, but that is a design choice.

[Heydon]

I actually disagree here. Tabindex="-1" programmatically focused elements
don't necessarily need a focus style. That the element / area is pulled
into view is enough. You can, however, get creative with animated focus
styles. Perhaps this should be communicated to potential authors?

[ZoeBijl]

After thinking about it for a bit, that makes sense. I use animated focus styles for skip links, but not consistently it seems. I thought I read a WebAIM article on it once, but can only find one that advises to use animation to keep (hidden) skip links visible for a short period after you've focused them.

It would be good to add this to the documentation. Maybe something like:

Focus management

To aid keyboard and assistive technologies (AT) users; it is important that focus is moved to the scrolled to element. Jump.js does this automagically. By default visual aids of focus are disabled. Authors are free to enable such aids via CSS.

What would happen if an author uses Jump.js to scroll to an interactive element?

[callmecavs]

my preference would be to include as little CSS in the library as possible. im happy to set outline: none on the element that's jumped to from the JS, but don't want to make a stylesheet required to use the library.

i'm leaning towards the solution above - adding the tabindex, calling focus(), disabling the outline, and mentioning accessibility in the README. that seems to be in line with both of your thinking - does this seem like a reasonable solution?