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

On Sun, 30 May 2010 08:05:59 +0200, Philip Jägenstedt <philipj@opera.com>  
wrote:

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

> For example, I would imagine it is absolutely critical that captions be  
> delivered in a text format as opposed to bitmaps, while it is not nearly  
> as important that one can direct a particular soundtrack to headphones  
> only.

For example.

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

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.

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

cheers

chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Monday, 31 May 2010 09:30:14 UTC