Re: Call for Consensus (CfC): Comments on the MSE CR (Revised)

> On Dec 11, 2015, at 11:04 AM, janina@rednote.net wrote:
> 
> Colleagues:
> 
> Resending (with apologies) to correct editorial issues flagged by
> Charles and Katie. If you've already submitted your opinion on this CfC,
> you needn't resend.  Voting responses previously received WILL be counted.
> 
> However, if you responded to the effort to re-argue longdesc in this
> CfC, but did not directly indicate whether you agree, or disagree with
> this CfC, your response cannot be counted because it requires a
> judgement call. Therefore, please be clear on whether you support, or do
> not support this CfC. Comments are OK, but specific responses are needed
> in order to judge whether this CfC does, or does not represent
> consensus. It's clear it will not be a unanimous consensus, should we
> achieve consensus.
> 
> 
> ***What
> 
> This is a Call for Consensus (CfC) to the Accessible Platform
> Architectures (APA) Working Group (still functioning as the Protocols
> and Formats Working Group), and to the HTML-A11Y Task Force to test
> whether we have group consensus on the following comments on the MSE
> Candidate Recommendation published at:
> 
> http://www.w3.org/TR/2015/CR-media-source-20151112/
> 
> 
> ***Background Information
> 
> The comments proposed below are the result of several conversations
> including:
> 
> APA's Action-1742:
> http://lists.w3.org/Archives/Public/public-pfwg/2015Nov/0281.html
> 
> The APA/PF regular teleconference meeting of 9 December:
>                http://www.w3.org/2015/12/09-pf-minutes.html#item04
> 
> The HTML-A11Y Task Force regular teleconference meeting of 10 December:
> http://www.w3.org/2015/12/10-html-a11y-minutes.html#item03
> 
> 
> ***Proposed Comments
> 
> The Accessible Platform Architectures (APA) Working Group and the
> HTML-A11Y Task Force offer the following accessibility related comments
> on the MSE Candidate Recommendation (URI above):
> 
> 1.)	The diagram in this document should have a longdesc. If
> possible, the diagram itself should also be created using accessible SVG
> markup. We offer our assistance on this point.

I suggest changing this to:

1.) The diagram in this document should be made accessible. There are a number of ways you may achieve this, including accessible vector graphics with SVG, a link to an external description (standard <a href> or @longdesc), or an in-page description of the graphical content.

And adding:
1a.) The diagram does not convey its content clearly and should be redesigned. Reconsider what you're trying to convey and determine if there is a more intuitive way to present the data. Clearly label your switches, connector endpoints, and relationships between. What are the three dots under the video decoders? Are all the audio decoder switches open or is that a drawing error? What is the green circled X that the audio decoders are pointing to? What are the triangles? What is the meaning of the different colors of SourceBuffers? What is the viewer expected to learn from this diagram?

James 


> 2.)	We would request greater use of prose to describe what the API
> is doing. This is needed both to help the reader understand what is
> being specified, but also to test whether the proposed API actually
> meets its intended purpose.
> 
> 3.)	We believe the MSE is not the appropriate specification to show
> how multiple media objects, such as the primary video plus a
> sign-language translation video plus captions plus described video are
> unencrypted (EME) and synchronized, even when each comes from a
> different server.
> 
> 	However, we believe the W3C needs an high-level overview of how
> 	our various specifications fit together to deliver the total
> 	user experience defined by HTML and by the Media Accessibility
> 	User Requirements (MAUR) note[1]. We request your assistance in
> 	creating this high-level overview document, and in using
> 	alternative media examples where appropriate across W3C media
> 	specifications in ourder to illustrate for authors and user
> 	agent developers how W3C specifications work together to meet
> 	the widest possible assortment of user needs.
> 
> 
> ***ACTION TO TAKE
> 
> According to agreed Consensus Procedures, this CfC is now open for
> objection, comment, as well as statements of support via email. Silence
> will be interpreted as support, though messages of support are certainly
> welcome.
> 
> If you object to this proposed action, or have comments concerning this
> proposal, please respond by replying on list to this message no later
> than 23:59 (Midnight) Boston Time, Thursday 17 December.
> 
> Janina
> 
> [1] http://www.w3.org/TR/media-accessibility-reqs/
> 
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 			sip:janina@asterisk.rednote.net
> 		Email:	janina@rednote.net
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:	http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
> 
>

Received on Saturday, 12 December 2015 10:13:18 UTC