-
Notifications
You must be signed in to change notification settings - Fork 70
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
What does it actually mean to be part of sequential focus navigation? (cae760) #1170
Comments
The relevant bit from Alfa, for reference: https://github.com/Siteimprove/alfa/blob/a9134d5b388342fc9fa1aff5b5fd8bb3c451c535/packages/alfa-rules/src/common/predicate/is-tabbable.ts#L28-L36 |
This is a tricky one. Looks like frame focus behaviour is more complicated then I thought it was :( So, the reason I think frames most definitely need an accessible name, is because in Firefox frames are focusable by default. I thought that putting tabindex=0 on a frame would make them focusable for other browsers too. If memory serves me right, that used to be the case. But it isn't anymore. I think the only thing that does is make the assumption a little less likely. Basically, in Firefox it definitely needs a name, and for other browsers it's a little unclear. It depends on how exactly you want to define "UI component". We're not taking a strong stance on that in this rule. |
I didn't know Firefox wasn't following the spec on this, that's definitely interesting! Trying out my examples in Firefox does indeed yield different behaviour from both Chrome and Safari. With that in mind, I do think it makes sense to clarify what we mean by "part of sequential focus navigation", as it should then likely be closer to "can be reached by sequential focus navigation". Then it comes down to a difference in browser behaviour, which is something we can work with. |
Fine by me. Would you like to put in a PR? |
Sort of, yes. |
@WilcoFiers assigning you this one also since you're handling w3c/wcag-act#473 |
Running through the test cases changed in #1102, I took note of failed example 7:
This is supposed to fail the rule and this I'm absolutely on board with; the contents of the
<iframe>
can still be tabbed to and so one would need to name the<iframe>
. However, Alfa doesn't fail this case because it interprets "part of sequential focus navigation" to mean "elements returned from the sequential navigation search algorithm". This algorithm is used for determining what should happen when a user presses the tab button on their keyboard; given their current position and a direction, what should the next active focusable area be? Per this algorithm, browsing context containers, which<iframe>
elements are, redirect focus to their contents, and are therefore never themselves returned from this algorithm. To see the effect of this, try tabbing to the button named "First" in this document and then hit tab:You'll notice that the next active element becomes the button named "Second" and not the
<iframe>
element itself. This holds true even if we attempt to add something liketabindex="0"
to the<iframe>
element; the sequential navigation search algorithm doesn't care.However,
<iframe>
elements are focusable areas and are actually even listed of examples as such. This can be verified by doing this:If you run that code on the document above, you'll also notice that upon pressing tab, the button named "Second" will indeed become the next active element.
So, while a user cannot ever tab directly to an
<iframe>
element, we can programmatically move focus to it. As such, Alfa does not consider it part of sequential focus navigation. However, one could argue that an<iframe>
element is still part of sequential focus navigation as it is a focusable area that unless it has a negative tab index will be in the sequential focus navigation order.What are peoples thoughts on this? At the very least, there's clearly an ambiguity that needs to be resolved.
The text was updated successfully, but these errors were encountered: