"Focus fixup rule one" not very clear, possibly wrong #1972
Comments
|
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:
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? |
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.
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.
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:
But since most browsers retain focus on the element when it's hidden, I'd probably just roll with that.
Why would that not be an improvement?
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. |
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.
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.
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.
Hmm, I'm not sure how this is related to the OP, but it seems like a reasonable thing to do to me! |
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?
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? |
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.
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. |
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".
Haven't been able to test on Safari yet due to w3c-test.org being down, but will file that when I can. |
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".
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".
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.
The text was updated successfully, but these errors were encountered: