You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
...(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.
The text was updated successfully, but these errors were encountered: