Skip to content
New issue

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

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

Already on GitHub? # to your account

Accessibility Review and a Question #177

Open
johnfoliot opened this issue Apr 20, 2021 · 1 comment
Open

Accessibility Review and a Question #177

johnfoliot opened this issue Apr 20, 2021 · 1 comment
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on.
Milestone

Comments

@johnfoliot
Copy link

The APA WG (Accessible Platform Architecture Working Group) has been asked to review your Draft Specification.

On behalf of the APA I have reviewed it, and while normally we are mostly concerned with UI issues (as opposed to APIs), we (I) have an outstanding question: we know that support files (captions, audio descriptions) can be linked to video content in HTML externally (using the <track> element), however we also know that those supplemental files can also be furnished 'in-band', contained within the .MP4 wrapper.

Based on that, it would seem that a Media Capabilities API should also have the ability to query whether the media content has either or both of those secondary but critical support files present:

 hasCaptions="T/F"
 has AudioDescriptions="T/F"

...(or something similar) so that user-agents can both query and extract that information (and presumably do something useful with it :-) )

Was this something you previously discussed? Is this appropriate for the proposed API, or have I completely misunderstood the intent here? If I am understanding correctly, do you anticipate this feature to be added to the API (and if yes, under what timeline?)

From a Security and Privacy Considerations (and we wish it were Accessibility, Security and Privacy Considerations) IF this capability is (or should be) part of the API, we'd expect that the API not be able to track whether any individual user accessed either or both of those support files: a) it could be used to finger-print and track potential users with disabilities, but also b) not all users who avail themselves to captions or audio descriptions have a disability - some users may activate these features for any number of non-accessibility related reasons, and so we're equally concerned that developers might use a query such as that to deliver "accessibility" content (a well-intended but usually ill-advised pursuit). Treat it rather as "additional" content that any or all users MAY find useful.

Happy to respond to any follow-up questions.

@michael-n-cooper michael-n-cooper added the a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on. label Apr 21, 2021
@chrisn
Copy link
Member

chrisn commented Dec 13, 2023

Related issues: #157 and #99.

@chrisn chrisn added this to the V2 milestone Dec 13, 2023
@chrisn chrisn mentioned this issue Aug 27, 2024
5 tasks
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on.
Projects
None yet
Development

No branches or pull requests

3 participants