Problems with allowed roles for iframe, embed and object elements

[jcsteh]

The allowed roles for the iframe, embed and object elements are either not supported in multiple browsers, are exposed inconsistently or break the embedded content completely with common browser/assistive technology combinations. In particular:

1. The presentation/none role is not supported on these elements by either Firefox or Chrome and this would be difficult (if not infeasible) to fix.
   • These elements are focusable, so it can't be presentational. -Firefox at least needs this Accessible in the tree because it bridges between the inner and outer documents.
   • For these two reasons, Firefox ignores presentation/none on these elements altogether.
   • Chrome continues to expose the element, but gives it a role of group. I assume (but haven't verified) that this is due to similar implementation concerns to Firefox.
2. According to the ARIA spec, the img role should make children presentational, but neither Firefox or Chrome support this. The document continues to be exposed within the img.
3. The document role on these elements makes the embedded content invisible to Firefox + NVDA.

Some of these issues might be fixable in specs/browsers/ATs, while others might not. Either way, the current situation is pretty broken.

Given these issues and considering that authors may be relying on conformance tools implementing this specification to determine whether their code is accessible, I think that no ARIA roles should be allowed on these elements at this point. Of course, this guidance could be reinstated if/when these issues are addressed.

[stevefaulkner]

@jcsteh works for me, @scottaohara?

[scottaohara]

agreed as well. making a PR for these updates.

[pkra]

Related: https://github.com/w3c/aria/issues/879 (iframe and role parity)

[jnurthen]

@jcsteh A common issue is where page authors want to make the iframe itself be essentially invisible to all users. To the sighted user the content of the iframe is indistinguishable from the base page but is presented in an iframe for sandboxing reasons. What is the best way with firefox to accomplish this? IMO many of the attempts to use roles are trying to accomplish this (I've certainly been down this path before abandoning it). If we can present one single technique for this requirement which works across browsers and AT it would be very helpful to authors.

[scottaohara]

New todo for this issue is to create 3 separate PRs for each of the elements discussed mentioned here.

The major push back to the proposed changes was concerning presentation and none. Those are likely to remain in the proposed changes, but a note will be added to indicate the lack of support and that checkers may want to surface that to authors.

more info will be in the resulting PRs

[jcsteh]

@jcsteh A common issue is where page authors want to make the iframe itself be essentially invisible to all users. To the sighted user the content of the iframe is indistinguishable from the base page but is presented in an iframe for sandboxing reasons. What is the best way with firefox to accomplish this?

Sorry; I missed this question. In Firefox, the best you could do is role="group". That hides the fact that it's an iframe, but it's still not indistinguishable.

Note that this is what Chromium exposes if you put role="presentation" on an iframe. For implementation reasons, it's very difficult to completely remove the iframe element from the a11y tree, especially for browsers that support site isolation (currently Firefox and Chromium).

What we could do is expose a node with a generic role for the iframe. Strictly speaking, that's a spec violation for role="presentation" because the spec says that role="presentation" should be pruned from the tree completely. Pragmatically speaking, that would achieve what authors want because it would remove any semantics from the node.

The question is how to balance the implementation constraints here without causing spec violations.