Correction: revise allowed roles for iframe, object, embed #370
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -854,18 +854,14 @@ <h2 id="docconformance"> | |
| <a>No corresponding role</a> | ||
| </td> | ||
| <td> | ||
|
There was a problem hiding this comment. There are legit use cases for using frames or objects to load images. For example loading in an SVG that needs to use scripts, or that loads external fonts. I don't think this should be changed. There was a problem hiding this comment. again, not ready will full results. but initial findings do make me think that under certain circumstances |
||
|
Comment on lines
-958
to
-959
There was a problem hiding this comment. I don't think this is a good change. Role=none on iframes serves a very important function for VoiceOver. It's a way to have iframe content treated as part of the same page, rather than a completely isolated context. There was a problem hiding this comment. @WilcoFiers did you see the discussion at #368 ? There was a problem hiding this comment. these work with webkit, for now... ignored with firefox (because iframes are focusable). even if they suppress the iframe discoverability in the primary document, once navigating into the contents i'm finding that 'frame' is still announced. will post more results later, but really the only major benefit here is obscuring iframes from macOS webkit / VO users. There was a problem hiding this comment. I seem to recall this being advertised as a best practice when ARIA first came out. There was a lot of misunderstanding of what role=presentation meant on an iframe, but ultimately, it does have an intended purpose - to communicate to the browser and AT that the content of the frame should be treated as part of the parent page and not as a sub-page. The fact that some browsers and ATs don't support this doesn't change the fact that the spec intended for the browsers to support this scenario. I think ARIA and the browser vendors need to determine who's going to budge, but as it stands now, this is perfectly valid and meaningful to put in your code. There was a problem hiding this comment. See #370 (comment). I'm not saying the ARIA spec should be changed. But this spec is primarily targeted at conformance checkers. It seems pretty bad to have conformance checkers telling authors something is conformant when it doesn't work across multiple browsers. Yes, we should figure out a path forward on that, but until then, isn't it better to avoid user pain by advising authors to avoid doing things which don't work across browsers? There was a problem hiding this comment. agree with @jcsteh. i'm sorry i haven't gotten around to compiling all my test data yet. it's coming... just have to work through other things first. There was a problem hiding this comment. That depends on the intent of your checker. If checkers only made decisions based on broad browser support, every checker would have flagged any use of ARIA as a failure when ARIA was first released since basically only one browser supported it at the time. Some checkers focus more on technical specifications whereas others look more at best practices - there's a spectrum. This issue feels like it falls somewhat inbetween, and this PR feels like it's trying to deprecate these scenarios and codify it into technical specification based on what's in the wild rather than on whether or not it makes sense to do so. The unfortunately bit with this particular case is that this was heavily advertised in the early days as an intended pattern. Wilco's note that there exists an implementation that meets that pattern reinforces that. So, it's hard to say it can't be done when it has obviously been done. So far, I haven't seen a discussion as to whether this pattern makes sense or not - just some notes that it's not easy to support it. |
||
| <div class="proposed correction"> | ||
| <p> | ||
| <strong class="nosupport">No `role`</strong> | ||
| </p> | ||
| <p> | ||
| <a data-cite="wai-aria-1.1#global_states">Global `aria-*` attributes</a> | ||
| </p> | ||
| </div> | ||
| </td> | ||
| </tr> | ||
| <tr id="el-fieldset" tabindex="-1"> | ||
|
|
@@ -1146,18 +1142,14 @@ <h2 id="docconformance"> | |
| <a>No corresponding role</a> | ||
| </td> | ||
| <td> | ||
| <div class="proposed correction"> | ||
| <p> | ||
| <strong class="nosupport">No `role`</strong> | ||
| </p> | ||
| <p> | ||
| <a data-cite="wai-aria-1.1#global_states">Global `aria-*` attributes</a> | ||
| </p> | ||
| </div> | ||
| </td> | ||
| </tr> | ||
| <tr id="el-img" tabindex="-1"> | ||
|
|
@@ -1938,16 +1930,14 @@ <h2 id="docconformance"> | |
| <a>No corresponding role</a> | ||
| </td> | ||
| <td> | ||
| <div class="proposed correction"> | ||
| <p> | ||
| <strong class="nosupport">No `role`</strong> | ||
| </p> | ||
| <p> | ||
| <a data-cite="wai-aria-1.1#global_states">Global `aria-*` attributes</a> | ||
| </p> | ||
| </div> | ||
| </td> | ||
| </tr> | ||
| <tr id="el-ol" tabindex="-1"> | ||
|
|
@@ -4169,7 +4159,7 @@ <h2>Conformance checking requirements</h2> | |
| A conformance checker MAY define their own terminology, and level or levels of | ||
| severity, when surfacing document failures to conform to this specification. | ||
| </p> | ||
| </section> | ||
| <section id="priv-sec" class="informative"> | ||
| <h2> | ||
| Privacy and security considerations | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What could possibly be wrong with these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no positive benefit so far. can break access to content.