Iframe accessible name rule - Inapplicable Example 4 should be a failure

[dd8]

There are problems with Inapplicable Example 4 in the Iframe element has non-empty accessible name rule. This looks like it should be a failure due to presentational role conflict because iframes are focusable.

This iframe element has an [explicit semantic role][] of none.

<iframe src="/test-assets/SC4-1-2-frame-doc.html" role="none"> </iframe>

https://www.w3.org/WAI/standards-guidelines/act/rules/cae760/proposed/#inapplicable-example-4

In Firefox iframes are focusable, so presentation role conflict is applied, meaning role=none is ignored (confirmed in Firefox a11y inspector).

In Edge/Chrome iframes are also focusable (to allow the user can scroll the iframe using the arrow keys) but the focus indicator is hidden and role=none is applied (the role becomes IframePresentational in the devtools a11y inspector). In spite of this you can see the focused element being set to the iframe as you tab around using a live expression for document.activeElement: https://developer.chrome.com/docs/devtools/accessibility/focus/

In Safari iframes are also focusable but the user agent stylesheet has an explicit rule hiding the focus indicator:

html:focus, body:focus, input[readonly]:focus, applet:focus, embed:focus, iframe:focus, object:focus {
outline-style: none;
}

The behaviour in Firefox looks correct and the behaviour in Chrome/Edge looks like a bug (since the frame is focusable, which is needed to scroll the iframe with the arrow keys)

[dd8]

There's discussion of presentational role conflict in this ARIA issue: https://github.com/w3c/aria/issues/1192#issuecomment-583252413

The intent in the comment above is anything natively focusable (like iframe) or with a tabindex attribute triggers role conflict.

This raises the question - is there any way to make an iframe presentational?

Edit: the behaviour in Chrome was intentional, but was implemented in 2014 before presentational role conflict was specified in ARIA 1.1 in 2017: https://codereview.chromium.org/755173004/

Edit: this ARIA issue talks about the spec issues and implementation problems regarding use role=presentation on iframes: https://github.com/w3c/html-aria/issues/368

[Jym77]

Looking at Accessibility Support and Background, it seems that at some point the handling of iframe and focus was inconsistent. If that has changed (especially if the conflict is consistently triggered), we should indeed update the Applicability and replace the "(not) marked as decorative" condition.

[dd8]

We've added a few iframe test cases for role=presentation and tabindex to our screen reader tests, and should have those complete by the end of October.

[dd8]

Of note: the DoJ Peapod settlement agreement included the phrase "frames are not named or identified" and the remedy was to comply with WCAG 2.0 AA

For example, individuals who are blind or have low vision and use screen reader software cannot fully participate in and benefit from the various goods, services, privileges, advantages, and accommodations provided through www.peapod.com because (1) images, buttons, and form fields are unlabeled or have inaccurate alternative text; (2) pop-up modal windows are not reported to screen readers; (3) frames are not named or identified; (4) tables are missing header information and proper mark-ups; and (5) boldface type is used to show which fields are required.

https://www.justice.gov/opa/pr/justice-department-enters-settlement-agreement-peapod-ensure-peapod-grocery-delivery-website