Re: Please vote on the canvas accessibility proposal

Hi Richard,

On Sat, Feb 27, 2010 at 8:14 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>
>> > I need you and Ian to point me to the text in the proposal that makes
>> > the
>> > claim you are both making.
>>
>> I am not making any claims. I am asking questions and making logical
>> deductions from the answers I am getting.
>>
>
> It would be better if you had read the proposal and not the Ian chatter.

I am listening to everyone, I have read everything that related to the
proposal since we were asked to vote on it, and I am making my own
conclusions independent of anyone else's opinion.

But you may be referring to the point in the discussion where I made
up my mind that @adom is not a good idea, namely when I asked a simple
question and the only one who gave me a plain answer was Ian. Assuming
that his answer was in agreement with everyone else's since there was
no other answer coming, I placed my conclusion.

Here is another chance for you to answer the question and clarify my
understanding:

It seems we are saying that accessibility markup inside the <canvas>
is always also fallback markup for legacy browsers.
Are we also saying that fallback inside the <canvas> should always
function as accessibility markup?

The answer, if I understood it correctly, was an in-principle "yes".
The declarative markup inside the <canvas> was always regarded as
fallback markup, which was rendered when the browser does not support
the <canvas> element. When the <canvas> element was, however,
supported, the <canvas> developer had the opportunity to decide
whether that fallback markup was sufficient as accessibility markup or
whether some better markup had to be given using JavaScript to provide
for accessibility. A user agent that understands <canvas> will take
whatever it gets inside the <canvas> element as its accessibility
markup.

Based on this answer I deducted that the @adom attribute on the
<canvas> element would have no effect since the UA will always take
what it gets inside the <canvas> element as accessibility markup and
that would also be exposed to AT, no matter whether it is good or bad
quality markup from an accessibility POV.


>> Honestly, do provide some example markups that show the difference
>> that the element makes. Thus far it's all theoretical and one cannot
>> have factual discussions about theories, only theological ones.
>>
> There are examples on the canvas api discussion list posted by Apple,
> Microsoft, IBM, and the University of Illinois.
> If you would read those you would not be making assumptions about the basis
> for peoples statements.

That being the case, I would expect those examples to be made
available together with the material that we are to vote on. If we are
asked inside the Task Force to make an informed decision, all the
information should be available to us at the time where we are
supposed to make the decision. Otherwise we are not doing our job and
we will run into exactly the same discussion again when taking a
half-baked change proposal to the full working group for a decision.

If you really still want to pursue the @adom change proposal, could
you please make a proper change proposal with examples and full
explanations as to why such an attribute is necessary. Laura also
points out in her comments on the vote that she would prefer such a
change proposal and has in fact provided you with a template at
http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165 .
I am just trying to make your/our lives easier before it all goes to
the HTML WG, since without good arguments, reasons and examples, such
a proposal will just get slashed there.

Best Regards,
Silvia.

Received on Saturday, 27 February 2010 03:14:15 UTC