New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Focus fixup rule one" not very clear, possibly wrong #1972

Closed
rodneyrehm opened this Issue Oct 25, 2016 · 6 comments

Comments

2 participants
@rodneyrehm
Copy link

rodneyrehm commented Oct 25, 2016

I have difficulties understanding Focus fixup rule one. My simplified interpretation is »in case the focused element is no longer focusable, the first focusable element in that document should receive focus.«

I've run a simple test mutating the active element so that it isn't focusable anymore and the results are quite uniform, but far away from the interpretation of focus fixup rule one.

In IRC @zcorpan agreed with my interpretation and raised the question if the specification should be altered to reflect reality.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 1, 2016

Sorry for the delay in this.

Your interpretation of focus fixup rule one is missing that the focused area is in general the viewport, not an element. As such, your results don't seem to call the spec into question. It just looks like browsers have a few edge cases where they don't follow the spec well.

In particular:

  • Chrome follows the spec in all cases
  • Safari, Firefox, and Edge get it right for removing but not for hiding, disabling, or changing tabindex
    • Safari/Firefox disagree with Edge on disabling
    • All three agree with each other (but disagree with Chrome/the spec) for hiding/changing tabindex

The only thing that we might change in the spec is to go with the majority for hiding and changing tabindex, but even then I don't think that would be an improvement. It'd be better to just file some browser bugs.

What do you think?

@rodneyrehm

This comment has been minimized.

Copy link

rodneyrehm commented Nov 1, 2016

It just looks like browsers have a few edge cases where they don't follow the spec well.

Could you please point out where the spec defines this behavior precisely? The focus fixup rule one is the only thing that I could find resembling anything like disabling/hiding the active element.

Safari/Firefox disagree with Edge on disabling

I assume that Edge's (IE-inherited) behavior of focusing the next focusable ancestor element predates the sequential focus navigation starting point and was trying to achieve something similar.

All three agree with each other (but disagree with Chrome/the spec) for hiding/changing tabindex

To be honest, I have no idea what the use case for hiding the active element is. To my mind there are two desired behaviors:

  • retain focus on the active element when it's disabled or the tabindex attribute is removed, since the element should still be exposed in the accessibility tree.
  • shift focus to <body> (and set the sequential focus navigation starting point) when the active element is hidden or removed, since the element is no longer exposed in the accessibility tree.

But since most browsers retain focus on the element when it's hidden, I'd probably just roll with that.

The only thing that we might change in the spec is to go with the majority for hiding and changing tabindex, but even then I don't think that would be an improvement.

Why would that not be an improvement?

It'd be better to just file some browser bugs.

What do you think?

As a developer I'd prefer these things to be specified. I believe plugging these little holes improves interoperability not only for browsers but in this particular case also for tools like screen readers.


The original question I was trying to answer was: is it a good idea to disable a button upon click to prevent double execution due to double-clicks [1] or impatient users [2].

[1] I see way too many people double-click links, buttons, … Every time we do user testing we have to go back and add a gazillion forgotten debounce handlers.
[2] people will repeatedly click on buttons if their associated actions aren't executed fast enough.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 1, 2016

Could you please point out where the spec defines this behavior precisely? The focus fixup rule one is the only thing that I could find resembling anything like disabling/hiding the active element.

What is imprecise about focus fixup rule one? What scenario do you think it does not cover? All the ones you list are covered; I can explain why if that's not clear.

Why would that not be an improvement?

Because it's inconsistent with the other ways that things become not focusable, such as disabling or removing. It seems much better to have a uniform rule for what happens when something becomes not focusable, than several different ones depending on the way in which that happens. And we already have proof that this uniform rule is web-compatible, with Chrome.

As a developer I'd prefer these things to be specified. I believe plugging these little holes improves interoperability not only for browsers but in this particular case also for tools like screen readers.

100% agree! I think it's already specified though, so what remains is to drive implementations toward it. We can certainly help write web platform tests and such.

The original question I was trying to answer was: is it a good idea to disable a button upon click to prevent double execution due to double-clicks [1] or impatient users [2].

Hmm, I'm not sure how this is related to the OP, but it seems like a reasonable thing to do to me!

@rodneyrehm

This comment has been minimized.

Copy link

rodneyrehm commented Nov 1, 2016

What is imprecise about focus fixup rule one? What scenario do you think it does not cover?

If all the cases are covered, I'm afraid I don't understand that paragraph. Is it possible to rewrite that section so it becomes easier to grasp?

Hmm, I'm not sure how this is related to the OP, but it seems like a reasonable thing to do to me!

With focus not remaining on the button, I'm not sure screen readers will keep their virtual focus (or cursor) on the element. VoiceOver (with Chrome) does, but I'm not sure what other SRs will do the same. I guess I'm looking for an easy way out of having to actually test them all. Maybe I'm overthinking this?

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 1, 2016

If all the cases are covered, I'm afraid I don't understand that paragraph. Is it possible to rewrite that section so it becomes easier to grasp?

That's kind of a big ask. In general the focus section is fairly complex as it deals with a layer of abstraction above the DOM. Without some concrete suggestions besides "rewrite everything", I don't think there's much we can do here.

With focus not remaining on the button, I'm not sure screen readers will keep their virtual focus (or cursor) on the element. VoiceOver (with Chrome) does, but I'm not sure what other SRs will do the same. I guess I'm looking for an easy way out of having to actually test them all. Maybe I'm overthinking this?

I can't really say. Certainly the sequential focus starting point should stay on that element, per spec; that isn't modified when the focused area changes. Hopefully screen readers use that. But as you've seen implementations are uneven around all this stuff.

domenic added a commit that referenced this issue Nov 2, 2016

Clarify and add some examples around focus
Closes #1972. Notable changes:

- Merges the two definitions of "expressly inert" for dialogs and other elements; they were equivalent.
- Regroups some sentences in the "Data model" section so that related concepts stay together, separated by <hr>s.
- Add examples for what "expressly disabled" means.
- Add an example of "focus fixup rule one"
- Fixed "focus fixup rule one" to talk correctly about "focusable areas", not "focused areas".
@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 2, 2016

Haven't been able to test on Safari yet due to w3c-test.org being down, but will file that when I can.

@zcorpan zcorpan closed this in #2008 Nov 3, 2016

zcorpan added a commit that referenced this issue Nov 3, 2016

Clarify and add some examples around focus
Closes #1972. Notable changes:

- Merges the two definitions of "expressly inert" for dialogs and other elements; they were equivalent.
- Regroups some sentences in the "Data model" section so that related concepts stay together, separated by <hr>s.
- Add examples for what "expressly disabled" means.
- Add an example of "focus fixup rule one"
- Fixed "focus fixup rule one" to talk correctly about "focusable areas", not "focused areas".

alice added a commit to alice/html that referenced this issue Jan 8, 2019

Clarify and add some examples around focus
Closes whatwg#1972. Notable changes:

- Merges the two definitions of "expressly inert" for dialogs and other elements; they were equivalent.
- Regroups some sentences in the "Data model" section so that related concepts stay together, separated by <hr>s.
- Add examples for what "expressly disabled" means.
- Add an example of "focus fixup rule one"
- Fixed "focus fixup rule one" to talk correctly about "focusable areas", not "focused areas".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment