W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2015

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

From: James Craig <jcraig@apple.com>
Date: Sat, 12 Dec 2015 01:58:22 -0800
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Message-Id: <9ED41C36-8935-4714-8C18-28E6B232017B@apple.com>
To: John Foliot <john.foliot@deque.com>, Janina Sajka <janina@rednote.net>

> On Dec 11, 2015, at 10:05 AM, John Foliot <john.foliot@deque.com> wrote:
> James Craig [mailto:jcraig@apple.com] wrote:
>>> 1.)	The diagram in this document should have a longdesc.
>> -1. This is why we can't have nice things.
> I object to this statement. You can have all the nice you want, just make
> sure it is accessible to all. 
> The graphic in question requires a long description. Period. 

That's not true, but even if it were, it would be a better recommendation than, "document should have a longdesc [attribute]."

> How the W3C chooses to deliver that long description is secondary to that
> requirement, but I will state that the solution MUST work with existing
> user-agents today - multiple combinations of screen readers and browsers, on
> multiple OSes. The solution must also be implementable in the W3C TR
> publishing space (which I suspect, but cannot confirm, rules out applying
> polyfills, etc.)
>> Neither @longdesc nor SVG is a requirement for accessibility.
> Nor, we should note, are they off the table either

I never implied they were. The point of my comment was to change the recommendation to something more like this:

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 perhaps @longdesc), or an in-page description of the graphical content.

While we're on the subject of the diagram, here's additional feedback to include in the comments.

2) 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?


Received on Saturday, 12 December 2015 09:58:54 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 12 December 2015 09:58:55 UTC