Re: Adopting the media accessibility requirements

On Sun, Oct 31, 2010 at 11:28 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Oct 30, 2010 at 3:39 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> 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.
>
> I would tell the person "I see your need, it makes sense to me that
> you want it, however due to the limited time we have to develop HTML5,
> we'll not be able to support it at least in this version of HTML. You
> might also want to look at these here CSS specifications which at
> least partially address your need".

Excellent, that's exactly what we should do. :-)

>
> It is very similar to what I tell people all the time about firefox:
> "I see your need, it makes sense to me that you want it, however due
> to the limited time we have to develop Firefox 4, we'll not be able to
> support it at least in this version of Firefox. You might also want to
> look at these here addons which at least partially address your need"
>
> It is a fact that we won't be able to satisfy every persons "must"
> requirements for any given release, so we might as well be open and
> honest about it.

I couldn't agree more. What I reacted to was the statement that the
process was broken and that many of the requirements on the list do
not represent a real need. I agree that we need to propose existing
techniques for solving needs first and see where technologies are
missing and see whether we can come up with a roadmap to satisfy them.
I've proposed the next steps and every step will take us closer to it.


>>> 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.
> [snip]
>> In my personal understanding it was never meant to become a "legally
>> binding contract".
>
> Traditionally I believe W3C "requirement" docs have been treated as
> "legally binding". I.e. the specification had to implement the
> requirements in order to ship. This might be the source of some of the
> disconnect here.
>
> As long as "adopting" these requirements simply mean "we believe that
> users working with media and media accessibility have requested these
> features", and that fact is made clear, I have no problems adopting
> them.
>
> Though like I said, I'm not sure how much weight that carries since we
> won't be able to satisfy every persons requirements for any given
> version of HTML, even if we restrict it to peoples "must" requirements
> and even if we restrict it to requirements around a given topic like
> media accessibility.

What I heard was that some core requirements on media accessibility
will need to be satisfied before Last Call. In my opinion the core
requirements are time-synchronized text (captions, subtitles, text
descriptions, chapters - the latter for navigation purposes),
multitrack media (audio descriptions, sign language - may even satisfy
the clear audio need), and the hierarchical navigation (which I think
we may be able to do with chapters that allow for multiple levels of
markup). Transcripts are already supported. So, from my point of view,
first (even if incomplete) versions for all the alternative content
technologies requirements can be achieved - maybe with some delays on
the LC. Lots of the System Requirements are not actually for HTML, but
for systems surrounding it. Several features will be left for future
improvements, which is probably acceptable given the involved
timelines, but the broad areas will be there. Also note that I assume
that LC means that the specs are there, but not necessarily
implemented in all browsers.

I'm optimistic, but I have to be, because I want to see progress in
this space. Indeed, Web developers in the US will have a need to
satisfy online media accessibility requirements that have just gone
through the Congress as the "21st Century  Communications and Video
Accessibility Act", see
http://thomas.loc.gov/cgi-bin/query/z?c111:h3101: .

In any case, we should add some text to the top of the document that
explains the intent better and how it is being accepted by the HTML
WG. In particular we might need to state that it's not meant as a
requirements document to Web developers and refer to WCAG/UUAG for
that. Also state that it's input into the HTML development process,
just to be clear. Then let's indeed look at all the concerns that
people here have on features in the list and make sure they are
understood, clarified, or changed as we accept it as a HTML WG
document into the process here.

Cheers,
Silvia.

Received on Sunday, 31 October 2010 01:00:58 UTC