Consider tabindex in iframe has acc name #1102
Conversation
WilcoFiers
requested review from
kasperisager,
Jym77,
jeeyyy,
ShadowBB and
maryjom
| @@ -30,18 +31,18 @@ Each target element has an [accessible name][] that is not empty (`""`). | |||
|
|
|||
| ## Assumptions | |||
|
|
|||
| - The rule assumes that the target `iframe` is used as a [user interface component](https://www.w3.org/TR/WCAG21/#dfn-user-interface-components). | |||
| If an `iframe` is not perceived by the user as a single control, it does not qualify as a [user interface component][] under WCAG 2. In such a scenario, failing this rule would not fail [success criterion 4.1.2](https://www.w3.org/TR/WCAG21/#name-role-value). Unless the `iframe` is both removed from the accessibility tree and removed from [sequential focus navigation][], they usually are considered to be [user interface components][user interface component]. | |||
There was a problem hiding this comment.
I had the impression that we usually start the assumptions by "this rule assumes that".
Not a big deal, but uniformity helps.
There was a problem hiding this comment.
I know we have quite a few rules that do, but I don't think that's a good thing. Assumptions should explain edge cases the rule does not consider, and the interpretation that is used for the requirements.
| @@ -132,10 +133,10 @@ Usage of `alt` attribute to describe content is not valid. | |||
|
|
|||
| #### Failed Example 7 | |||
|
|
|||
| [Accessible name][] is empty. | |||
| This `iframe` that is part of [sequential focus navigation][] has an empty [Accessible name][]. | |||
There was a problem hiding this comment.
We need a similar Passed Example (not in the accessibility tree, in sequential focus order, has an accessible name).
There was a problem hiding this comment.
I don't think that's necessary.
| @@ -150,12 +151,22 @@ Does not apply to non `iframe` element. | |||
|
|
|||
| #### Inapplicable Example 2 | |||
|
|
|||
| `iframe` is not [included in the accessibility tree][]. | |||
| This `iframe` is not part of [sequential focus navigation][], nor [included in the accessibility tree][] because of `display: none;`. | |||
There was a problem hiding this comment.
As far as I understand, browsers that "force push" iframes in sequential navigation won't do it here because of the display:none, which is fine.
The description, however, looks a bit like the "because of display:none is related only to the second part (not in the accessibility tree) rather than to both.
But I don't really have any idea to improve it…
There was a problem hiding this comment.
OK, leaving it as is, since it got 2 approvals.
|
|
||
| ```html | ||
| <iframe style="display:none;" src="/test-assets/SC4-1-2-frame-doc.html"> </iframe> | ||
| ``` | ||
|
|
||
| #### Inapplicable Example 3 | ||
|
|
||
| This `iframe` is not part of [sequential focus navigation][] because it has `tabindex="-1"` and not [included in the accessibility tree][] because of `role="presentation"` |
There was a problem hiding this comment.
| This `iframe` is not part of [sequential focus navigation][] because it has `tabindex="-1"` and not [included in the accessibility tree][] because of `role="presentation"` | |
| This `iframe` is neither part of [sequential focus navigation][] (because it has `tabindex="-1"`) nor ([included in the accessibility tree][] because of `role="presentation"`). |
There was a problem hiding this comment.
I don't know what this is for, seems unnecessary.
Should there be a generic rule like "element in tab order has accessible name"? |
Co-Authored-By: Jean-Yves Moyen <[email protected]>
Consider whether or not iframes are in the sequential focus navigation when dealing with accessible names. This resolves a few comments from the ACT Task Force, including #1092.
Need for Final Call: 1 week