Focus management about jump.js HOT 25 CLOSED

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?

from jump.js.

ping @Heydon

from jump.js.

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 :-)

from jump.js.

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

from jump.js.

Oh, that sounds perfect. Nice one!

from jump.js.

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

from jump.js.

-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?

from jump.js.

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

from jump.js.

@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?

from jump.js.

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

from jump.js.

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.

from jump.js.

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?

from jump.js.

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?

from jump.js.

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?

from jump.js.

If there was something that prevented the outline being disabled on interactive elements; I would agree to that resolution.

CSS could look something like this—probably forgot a couple:

[tabindex="-1"]:not(a, input, button, textarea, select, [role*="button"]) {
  outline: none;
}

This is compliant with Jump.js' browser support.

from jump.js.

I only want to use CSS that I can control from JS, using the style prop on the element nodes. that rule requires getting more than just the element scrolled to, and injecting into the <head>, etc

much easier and cleaner to just do target.style.outline = 'none' and then make a note about it in the README

from jump.js.

Fair enough. It would be possible to check against the same list in JavaScript right? Some automation is desirable I think.

from jump.js.

@Heydon are thoughts on focusing the target element, and setting outline: none on it?

also, congrats on getting into the collective with your flexbox writeup, Jump is in it this week as well 🍻

from jump.js.

@MichielBijl if users are jumping to a form element, they can restore the outline in the callback function. rather than disable the outline for everything in that selector with JS, it'd be easier to just disable it on the target, and let the user re-enable it in the callback if necessary. what're your thoughts on that?

from jump.js.

Oh, thanks! What's the collective?

I think I would personally just leave it to the author to remove that
outline if they so wished. That saves you from having to dirty your hands
with js/css.

from jump.js.

I'm with Heydon on this; some documentation or a reference to this issue, could help authors with understanding the issue with focus outlines. If that is a no go for what ever reason, target.style.outline = 'none' should do fine with a clear warning in the documentation.

from jump.js.

@Heydon Tympanus/Codrops does it - it's a weekly roundup of web design and development projects. here's the link to this weeks (that we're both in): http://tympanus.net/codrops/collective/collective-197/

@Heydon @MichielBijl okay, i guess I'll take a stab at not touching the outline and letting people handle it themselves. feel like it may lead to a lot of questions tho

from jump.js.

@Heydon will be included in v1, behind a flag. the only reason for me disabling it by default is because it requires a CSS change to prevent the blue outline

from jump.js.

Okay, thanks for letting me know!

from jump.js.

@Heydon thanks for bringing it up, and hashing it out with me. my apologies for it taking so long to add

from jump.js.