Re: Adopting the media accessibility requirements

On Sun, Oct 31, 2010 at 6:55 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Oct 30, 2010 at 8:24 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>>> Henri: if somebody told you they need a table element and they need to
>>> be able to have a header text that flies in from the left, makes some
>>> circles while turning the text orientation 360 degrees and is placed
>>> into its spot after that, continuing to blink, would you also tell
>>> them that that cannot be a "must" requirement?
>>
>> Yes.
>
> I had the same reaction as Henri here.

What if it actually is? You don't outright tell a person that their
requirement is crap - you ask them to explain why and try to work
through it. And you don't doubt the process through which the
requirement has been created. At least not in my world of dealing with
customers - or I have immediately lost one.


> What is being unclear to me in this whole discussion, possibly because
> different people have different interpretations, is what "must" and
> "may" etc mean in this context.
>
> When the accessibility requirements document says that something is a
> "must" level requirement, does this mean:
>
> 1) That some user has said: I must have this feature.
> 2) That some user has said: I must have this feature in order for a
> HTML5 document to be as accessible to me as it is for people that
> doesn't have the disability X that I have.
> 3) The TF says: We must have this feature in order to ship HTML5.


It's number 2) plus the addition of needs by the media accessibility
ecosystem - "I am a creator of media accessibility content and in
order for our industry to work we need this feature."


> In other words, if we "adopt these requirements", does it mean:
>
> 1) We believe the TF when it says that a user has requested the feature.
> 2) We believe the TF when it says that a user has requested the
> feature in order to make a HTML5 documents as accessible to people
> with disability X as to people without it.
> 3) We can't ship HTML5 without this feature.
>


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

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.

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.

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).

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 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". This document is targeted at the design process
of HTML5 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:".

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.

Cheers,
Silvia.

Received on Saturday, 30 October 2010 22:40:49 UTC