RE: Please Read (was RE: Survey on Media Accessibility Requirements)

> > While a wishlist is useful on the long-term and as a primer for
> people
> > like me on what accessibility folks think is important,
>
> Actually, it is also helpful if implementors can explain to
> accessibility
> folks which things are easy and which are hard. Because we tend to make
> educated guesses, but from time to time we get them seriously wrong.
>
> > I get the feeling that some of the requirements are more important
> than
> > others.
>
> Absolutely.

I will echo that as well; the purpose of this exercise is to ensure we have 
a complete list of needs and wants, without yet attaching any priority or 
degree of difficulty at this time - this work of course also needs to be 
done, but first let's ensure we have all the requirements listed first.


>
> > I would like to see a list of requirements which are truly critical
> for
> > accessibility, avoids trivial requirements which are going to be
> > fulfilled regardless (e.g. that a text format be used) and avoids
> things
> > which are already required by the spec.
>
> I would like to see something slightly different - a list "prioritised"
> in
> terms of impact. This information is multidimensional - some things
> have a
> lower impact for a higher number of people, other things have very high
> impact for fewer people.
>
> Proiritising what eventually gets done needs to take into account both
> of
> these things, as well as real implementation implications.

Exactly, however again, before we start prioritizing from both the 
accessibility and engineering perspectives, let's ensure the list is 
complete.


> So there
> needs
> to be some feedback towards accessibility folks too. And we need to
> remember that we don't really know what is easy and hard - if
> accessibility people start mixing their idea of what implementors know
> into their prioritisation scheme, they risk not getting something that
> would have been trivial if only they had explained the reason for it.
> (Or not...)
>
> > I would also really like to see more direct feedback on the actual
> > direction the spec is going with <track>, WebSRT, etc. After browsers
> > start implementing and shipping, it may already be too late.
>
> I would hate people to understand this as "we're only going to do the
> easy
> stuff anyway, people who have more complicated problems will simply
> lose
> out". That isn't what is being said. But we need to look at what we are
> building, and what the design choices we are making mean in terms of
> the
> overall set of known requirements, because if we close something off
> then
> it will be more expensive to go back later.

Which is why a complete list is critical at the on-set. I think everyone 
appreciates both the fact that this is ongoing work that engineers are 
working on now (complete with internal deadlines, etc.), but assuming that 
anything (such as WebSRT) is a done deal at this time might be premature: 
with a complete list of requirements it might turn out that a bit of extra 
effort at the early stages will deliver significantly more 'win' in terms of 
longer-range requirements, and conversely understanding the engineering 
issues to deliver a specific requirement may very well impact on its 'need' 
in the shorter run, whilst still keeping that requirement in focus and 'on 
the list'. (For example, Eric's note regarding audio chips used in many 
modern cell phones and the fact that it is impossible to decode and play 
more than one stream of digital audio data at a time is both useful and 
important; however, with set-top boxes etc. 'optimizing' for video delivery 
to large-screen units, this suggests to me that we need to have a mechanism 
that prioritizes streams when required, but that it is not a binary will or 
won't scenario - so we have a new 'need', likely without a concrete solution 
at this time.)

This is going to be a tricky balancing act, there is no doubt. But as Chaals 
notes, missing something at this time may very well be extremely 
difficult/expensive down the road, so we need to avoid taking short-cuts 
now, no matter how difficult and perplexing it might seem today.


>
> At the same time, we should be sticking to known requirements. "Maybe
> have
> the ability to..." isn't a statement of requirement - if thing is
> necessary then it should be clear why and for whom, and if it is just a
> good idea then I expect implementors to happily ignore it unless it
> turns
> out to be trivially easy to include for some other reason.

Language clarity (and/or lack of) has already been noted, both in technical 
terms, but also in terms of using proper terminology when it comes to the 
various needs and disabled communities - work that Judy is looking at now.

This WBS survey does not seek to finalize things, but rather is an airing of 
what we have so far in terms of requirements, and is there so that the 
larger Task Force can give feedback to ensure that nothing is missing (so 
that we can start on the prioritization). Getting this right is hugely 
important.

>
> (I'm quite possibly restating a bunch of what Silvia already said)

Some, but no harm in ensuring that we are in agreement with were we are at 
this point in time.

JF

Received on Monday, 31 May 2010 22:46:36 UTC