paper-toast focus state issue about paper-toast HOT 12 CLOSED

Note: the contents of the toast are currently being announced, but delegating focus to actionable items (like buttons) inside the paper-toast is still not resolved

from paper-toast.

/cc @valdrinkoshi

from paper-toast.

paper-toast doesn't steal the focus by design (it should just announce the text). If we want to change this behavior, then we need the toast to return the focus wherever it was once closed.

Currently, the user will open the toast through the button, hear the text via the announcer; when he hits TAB the action button inside the toast will be focused.
If we set autofocus attribute to the child button of paper-toast, this will cause the announcer to stop announcing the text, and the button label will be read.
http://jsbin.com/ciyola/2/

The closest ARIA role suited for paper-toast is marquee, which doesn't mention stealing of the focus.

@lpalmaro WDYT?

from paper-toast.

cc/ @alice

from paper-toast.

I think there may be a couple of issues getting confused here.

I think @lpalmaro was referring to (I may be mistaken) the visual style of the buttons (in the demo) when they are focused. I believe this has improved since last April.

There is then the issue of the correct role. Looks like it currently has a role of status, which seems right to me.

The issue @notwaldorf mentions sounds like a legitimate issue, though: how do you handle the case where there are actionable items (like the "retry" button, for example) inside the toast? @valdrinkoshi mentioned that the action button will be focused if the user hits 'tab', but I don't see this behaviour in the demo - is that proposed behaviour or is the demo just out of date?

from paper-toast.

@alice this is not implemented. I think the focusability of the button depends on its action. E.g.
If a toast contains a button that closes it, even if the visually impaired user cannot reach the button via swipe it should not be a problem, right? (the toast can be closed by clicking ESC)
If the action button does something different than only closing the toast (e.g. "could not send email" & button is "retry", or "message sent" and button is "undo"), then it should be reachable via swipe.
That requires the Polymer user to properly set the tabindex of the paper-toast (so that it can "steal" the focus).
We don't have something like this in our demo, because I think this is in conflict with the nature of a paper-toast, which should not steal the focus and just notify the user with a message.
We could add a toast that shows this use case: a "send email" button that opens "email sent" toast with "undo" button inside it (in other words, like this http://jsbin.com/coxetux/2). WDYT?

from paper-toast.

@valdrinkoshi Sorry, what are you referring to by "this is not implemented"? I agree paper-toast should not steal focus. I outlined above what I believe the issues are.

[Edit] Oh, I see now what you mean. Will have a think about it.

from paper-toast.

I referred to "the action button will be focused when the user hits TAB", this is not implemented because it requires the setting of tabindex on the paper-toast. If we set it, we steal the focus :/

from paper-toast.

Uhm, I think I found a solution for this. paper-toast should have no-auto-focus set to true. Like this, the tabbing will follow the order of appearance on the dom 😁 http://jsbin.com/coxetux/3/edit?html,output
Will fix!

from paper-toast.

That solution looks good!

I'm curious about what types of usage will lead to the toast opening - obviously the demo is quite an artificial example, since you're not going to typically have an "open toast" button. The reason I ask is that if the toast closes while something within it has focus, it would be nice to move focus back to the thing which opened the toast rather than simply blur and need to start again from the top of the page.

from paper-toast.

That might require saving a reference to whatever has focus when the toast opens, and then returning focus there during the close handler (_openChanged I guess?).

from paper-toast.

iron-overlay-behavior provides a property that returns the focus wherever it was, restoreFocusOnClose. We could set that property to true as well and have something like this: http://jsbin.com/coxetux/4/edit?html,output Notice that there is a limitation: if you click elsewhere while the toast is opened, the focus will still be restored to the Send email. I will fix this on iron-overlay-behavior Tried it and is not quickly fixable. I'd let to the Polymer user the freedom to choose if the focus should be returned or not (by setting restore-focus-on-close). Also, since paper-toast will never steal the focus, it should not be accountable for returning it, right?

from paper-toast.