RE: Adopting the media accessibility requirements

Silvia Pfeiffer wrote:
> 
> 
> I think you are right: I think there is a clarification necessary of
> what the document will be used for.

+1, although I think you have done a great job articulating it below. If
we need to more formalize it, then let's discuss how to do so.

> 
> It is my understanding that this document has no "legal" binding. We
> started the media subgroup in the accessibility TF to come up with
> specifications for accessibility users. Captions were the obvious
> need, so we proposed a technical solution to the WG early on. But it
> was fairly unclear what other functionality would be required.
> 
> Thus the media subgroup of the a11y TF went out to create a document
> that would collect from all aspects of the existing media a11y
> ecosystem - including producers of alternative content technologies
> (e.g. caption producers, which is incidentally where the need for
> metadata like copyright comes from). We analysed the requirements that
> were put to us and structured them into different larger topics with
> individual features inside the topics. These requirements were meant
> to give us an indication of what the users need which should help us
> create technical solutions.

Agreed.

> 
> In my personal understanding it was never meant to become a "legally
> binding contract". Instead, I look at it as the result of a process
> during which I learnt a lot about what is currently already possible
> with other technology, about what is legally required by some nations'
> laws (e.g. the UK requires audio descriptions on prime-time TV), and
> about what would be useful extra features that are possible with
> online technology (and often have been experimented with through SMIL)
> that were not possible beforehand in limited technologies such as TV.

My personal understanding and yours are completely in sync. I'll even go
further and suggest that for the active members of the TF media sub-team
we would likely all concur, as it has been something that we have actively
discussed in the past. 


> 
> To me the list is a collection of user requirements where the broad
> areas seem to be absolutely necessary to implement (which is what John
> is defending), but the individual features inside these broad areas
> are an indication of what is necessary, sometimes incomplete,
> sometimes more disputable - they should find input into the
> discussions for when technical solutions are created and may need to
> be questioned further then (and it is good that some of this is
> starting now already). The checklist gives an indication which of
> these features are perceived as more important than others.
> 
> The request that has come to this list was, in my understanding, one
> that asked about the completeness of this document to make sure
> nothing was forgotten and to ask for input on the individual features
> - Henri and others have given good input that should help improve the
> document (I think we'll do a feedback compendium as Ian does, though
> it might be useful to go into detailed discussions).

+1

> 
> I personally wouldn't want to see this document 'as is' be used as a
> "contract" - I would strip out a lot of detail if such a "contract"
> was required - it should certainly not become a WCAG requirements
> document, since it clearly was developed as input into the development
> process for HTML5. I can imagine the broad areas becoming part of a
> WCAG document with levels of required support - in fact some of them
> already are in WCAG, which is what the checklist analysed.

I think the only "contract" this document seeks or implies is that
accessibility of media in HTML5 is significantly more than "captions", and
that for success we need to address all aspects of the accessibility
equation in the creation of HTML5. I would hope that this statement is
neither controversial nor problematic in endorsing.


> 
> I may be naive in where I see this document being used. And there may
> be diverging opinions in the TF. But my understanding was that the
> "contract" already exists with the WCAG levels, so there is no need
> for a new "contract".

I would only add that UAAG is/was also a factor in the creation of this
list, as the interoperability of the user-agents with the different pieces
of alternative content is also an important 'contract' which we must
account for as we move forward assessing technologies and potential
solutions.

> This document is targeted at the design process
> of HTML5 

Agreed.

> and not at Web developers or people writing laws about what
> level of support has to be provided on a Webpage. This is why the
> document says: "Systems supporting <blah> must:" and does not say "All
> systems have to support <blah> and for <blah> these features:".

Again, agreed.

> 
> So, this indeed has to be clarified and made clear what it means that
> the HTML WG "adopt it as the requirements document for media
> accessibility". I don't even think it's the task of the TF to define
> what the WG decides what it does with this document. The TF has done
> this work for this WG and the WG has to put the right label and the
> right communication around this document in place.

At the risk of setting the all time record of writing the word Agreed in a
response to this mailing list, I must state that Silvia has indeed
accurately captured the intent and goal of this first document, which we
spent considerable time and effort on. Within the sub-team, we all
understood why we were creating this document, and further how this
document was going to be of use to not only the sub-team, but the larger
Working Group as well, as we now start to try and hammer out specific
solutions: we have our needs and guiding principles in place - we have a
shared understanding of what and where we want to arrive at, as well as a
better understanding of what the big challenges are. 

JF

Received on Saturday, 30 October 2010 23:34:39 UTC