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

Caption files embedded inside the media wrapper should not fail #816

Closed
johnfoliot opened this issue Mar 30, 2018 · 6 comments
Closed

Caption files embedded inside the media wrapper should not fail #816

johnfoliot opened this issue Mar 30, 2018 · 6 comments
Labels
fix Bug fixes rules Issue or false result from an axe-core rule

Comments

@johnfoliot
Copy link

Currently it appears that aXe-core is only looking for the presence of the element to deliver caption files, but there is a second method of doing so: place the h.265 encoded video and the AAC encoded audio AND the Vtt/TTML file all inside of the media wrapper (traditionally either .mp4 or .mkv files).

There is an existing API that "looks inside" the wrapper when being rendered onscreen, which looks for those files to deliver the captioning. Ideally, aXe-core would use a similar method to detect whether the time-stamped file is bundled inside of the media wrapper, as a second test (after checking for the presence of as it does today)

@marcysutton
Copy link
Contributor

marcysutton commented Mar 30, 2018

@johnfoliot what is this "existing API" – do you have any examples or references? Can we even look inside of those media wrappers with client-side Javascript?

Also IIRC that rule is returned as "needs review", and can be marked as "not an issue". Not that it solves y/our use case, but it does explain why we don't mark it as a clear violation (it's too hard to tell for certain).

@johnfoliot
Copy link
Author

I believe what you seek can be found here: www.w3.org/TR/media-source.

This specification was designed with the following goals in mind:

  • Allow JavaScript to construct media streams independent of how the media is fetched.

At this point, it is operating a a level higher than my tech skills allow, but if the right info you seek isn't there, let me know and I can reach out to some folks who may have a clearer indication.

@WilcoFiers
Copy link
Contributor

@johnfoliot Do you have any cases where we've seen this get used?

@WilcoFiers
Copy link
Contributor

As for the false positive, I believe you're right. It looks like both for caption and description we make it needs review if there are no track elements at all, and we fail it if there are track elements but none of them are description (or caption). Given how many ways there are to provide a caption / description, this probably should never fail. At best we can tell that we couldn't figure out where you put it.

@WilcoFiers WilcoFiers added the fix Bug fixes label Apr 17, 2018
@WilcoFiers WilcoFiers changed the title Caption files embedded inside the media wrapper = FALSE POSITIVE Caption files embedded inside the media wrapper should not fail Apr 17, 2018
WilcoFiers added a commit that referenced this issue Aug 23, 2018
Do not require media captions / descriptions
Closes #816 

## Reviewer checks

**Required fields, to be filled out by PR reviewer(s)**
- [x] Follows the commit message policy, appropriate for next version
- [x] Has documentation updated, a DU ticket, or requires no documentation change
- [x] Includes new tests, or was unnecessary
- [x] Code is reviewed for security by: @JKODU
@johnfoliot
Copy link
Author

Wilco, sorry i didn't see your questions earlier...

Is this of any use?
https://www.w3.org/TR/2011/WD-html5-20110113/video.html#sourcing-in-band-text-tracks

@WilcoFiers
Copy link
Contributor

Thanks John. I think we've got it covered :)

@WilcoFiers WilcoFiers added the rules Issue or false result from an axe-core rule label Oct 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix Bug fixes rules Issue or false result from an axe-core rule
Projects
None yet
Development

No branches or pull requests

3 participants