[Role Parity] What do we do about embed?

[joanmarie]

No description provided.

[jnurthen]

As detailed at https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#no-consensus-yet-will-do-for-1-3 moving to 1.3

[joanmarie]

Tentative consensus: New embeddedobject role. Largely a generic herebedragons container to preserve exposure via platform accessibility APIs.

[scottaohara]

also noting the created role should handle both object and embed.

[scottaohara]

So an update on this...

In drafting up a potential definition for this role, and re-reviewing what object and embed are meant to represent, I'm wondering if this might be similar to generic in that this role is more meant for implementors rather than authors.

Being that these elements largely embed content that could be considered graphics or other media (videos/audio), nested browsing contexts (application or document roles) or plugins like flash, i'm unsure why we'd want authors to use this role when it'd be more straight forward to use other roles that better represent the embedded content.

I think we could still use this role specifically for role parity and giving object and embed an ARIA role to map to. But presently I'm not thinking this is a role for authors.

Differing thoughts here?

thanks

[scottaohara]

I've been doing a bunch of testing and review of embed, object and iframe due to inconsistencies in support, as well as some pretty bad behaviors, for what happens when using certain ARIA roles on these elements.

For each, I've included a baseline vanilla element for comparative purposes. Often, the element itself is ignored entirely and instead is merely represented by the content it renders. In other cases, iframe behavior (where a 'frame' or announcement to indicate a sub-document has been encountered) is made.

Essentially, it has strengthened my previous thought that if a role is made for parity with these elements, that it would need to be another generic-like role. This wouldn't be a role for authors, but more for attempting to make consistency with browsers/AT in handling these different HTML elements.... and arguably the best thing to do for much of what they can be used to represent, is to just expose nothing and let users interact with the content they are used to render, instead.

This is all, of course, directly related to #879 as well. I actually think that we could probably combine these different issues, since the object and embed elements behave similarly to iframe in that depending on what they render (e.g., an html document) they are essentially different ways to create a nested 'frame' in a document.

Right now this issue is marked as low priority, but the iframe issue is marked as high priority. I'd submit they should be the same.

[pkra]

+1. I've added the agenda label so we can revisit this on a call.

[cookiecrook]

Somewhat related to #529. Ideas from that applied to this context would be that the engines might return "html:embed" or "host-embed" as the computedRole.

[scottaohara]

removing my assignment for now. happy to work on this in the future, but seems we need to talk about it more in context of 529.

[jnurthen]

lets close this - no need for role parity for embed. we can use #529 for elements like these