Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ally.is.focusRelevant] clean up <embed> mess #82

Closed
rodneyrehm opened this issue Dec 1, 2015 · 0 comments
Closed

[ally.is.focusRelevant] clean up <embed> mess #82

rodneyrehm opened this issue Dec 1, 2015 · 0 comments

Comments

@rodneyrehm
Copy link
Member

By now we know that properly supporting the <embed> element means to understand every file type in every browser - as video/mp4 is treated differently than video/ogv than image/svg+xml, than $insertRandomMimeType.

ally 1.0.x made an ill-advised effort to accommodate the different types. After examining the current tests and running a few more I have to admit that ally isn't doing a good job with this element and there is no easy fix.

I'd like to demote <embed> to the following fixed state, regardless of content type:

{
  focusRelevant: true,
  focusable: false,
  tabbable: false,
  onlyTabbable: false,
}

By considering <embed> focus-relevant we're making sure that ally.maintain.disabled (by way of ally.query.focusable({ strategy: "all" })) can still disabled any <embed>, whilst any other strategy ("quick" and "strict") will not return any <embed> elements anymore.

Authors should be embedding SVGs inline or via <object>. SWF is embedded via <object>. Videos and audio files should be embedded via <video> and <audio>. That leaves <embed> for obscure plugins that we wouldn't understand anyway.

@marcysutton any objections to "killing <embed>"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant