Re: Adopting the media accessibility requirements

On Fri, Oct 29, 2010 at 6:10 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 10:03 AM, Philip Jägenstedt <philipj@opera.com> wrote:
>> Since the two groups involved here (browser implementors and
>> accessibility experts) have obvious issues communicating with each other, it
>> would be helpful if we were all involved in the discussions as they happen,
>> rather than communicating via requirements lists.
>
> I agree with this general point.  It seems like right now, task forces
> are formed, discuss things amongst themselves at length, and only at
> the very end present their findings to implementers and spec editors.
> The latter are then forced to either accept the findings on the basis
> of authority, or demand detailed explanation of the rationale for
> every finding before they accept it.  The latter is usually what
> happens in practice except for very minor or obvious changes, and in
> that case, it would make much more sense if the implementers/spec
> editors were involved in the discussions from the beginning.  Or
> alternatively, that task force findings be written in a persuasive
> rather than authoritative manner, and present the evidence and
> reasoning for their decisions in a form that will convince people who
> aren't domain experts.
>
> In the end, the implementers are the ones who have to make the
> judgment on what features they'll implement.  When a proposed
> accessibility, internationalization, or other feature requires a
> tradeoff of some kind, it's impossible for them to make that tradeoff
> intelligently unless they're given the full background on why the
> feature is needed, as Henri says.  We aren't going to get anywhere if
> we have the stone wall of a task force separating experts on some
> particular matter from everyone else, with only limited communication
> over the wall.  It would be to everyone's benefit if all concerned
> parties were involved from the start.  Hopefully that way implementers
> will learn more about accessibility, accessibility experts will learn
> more about implementation, and more workable proposals can be crafted
> from the get-go.
>
>

Sorry, but the notion that implementers were not involved in creating
this list is simply not true. Several implementers are subscribed on
the accessibility TF list and feedback has been contributed. Lots of
discussion happened in phone conferences and implementers were more
than welcome to participate there, too. Also, there have been multiple
emails requesting input into the process to this list, most of which
have not resulted in any reaction. To say that "only at
the very end present their findings to implementers and spec editors"
is simply wrong. Everyone was invited to participate but choices were
made not to and to just wait until the process is finished before
providing input. I don't regard that as a problem though - there is
still time and probably more productively now.

In any case, I have a pragmatic view of this list. Every list like
that is always going to be some kind of compromise. It's not about
getting all the technical details right for implementers - it is about
giving users the possibility to voice their needs and sometimes also
their opinions and ideas for solutions. I do not believe it is
possible to create a user requirements list that is acceptable to
implementers. Ever. In industry practice you get a customer specifying
all sorts of things that they want their product to do. As an
implementer you always have to deal with an imperfect situation. It's
about listening to the intention not to the exact words and then it's
about communicating from there on, making alternative proposals for
technical solution that are more appropriate than the first idea that
came to the user's mind, working with the user towards implementing a
solution that is acceptable and probably better than the user had
originally thought.

Your email is much more an email that creates walls than breaking down
walls. The users have offered their experience and opinions in an open
document and even asked for feedback from technical people to improve
the wording of their document. They are fully aware that the
implementers are the ones who will make the judgement on what features
they will implement, but they keep being told that they need to spell
out their needs. But when they do, they either get no feedback - or at
the end hear a statement like yours that there is a "stone wall".
Sorry, but you are the one creating the stone wall and refusing to
actually participate in the process and contribute intelligently. When
you take the time to address the document and provide detailed
feedback on individual points and where they are wrong or need more
explanation, that's when I believe that the communication will become
productive.

Enough ranting. Let's make this a constructive feedback process.

Regards,
Silvia.

Received on Thursday, 28 October 2010 21:09:58 UTC