Re: Please vote on the canvas accessibility proposal

hi ian,

>The one <canvas> I use on a regular basis (not a demo) has accessible
>fallback and no adom="" attribute. Which is more common is essentially
>impossible to tell from purely anecdotal evidence.

 > http://www.whatwg.org/issues/data.html?period=1

Poblem is it doesn't as the fallback inside the canvas is neither accessible
to users of browsers that support AT, nor accessible to users that don't.
For Example in IE i get the text "You need canvas support for this page.".

If you choose a sample of 1...

>I didn't say the probability was equal.

i have no expertise in probability, i took this "equally a possibility" to
mean the same thing.

> does any data support that attribute use follows this pattern of 50%
> inappropriate use?

Actually data for similar attributes -- longdesc="" and summary="" come to
mind -- show that the attributes are misused vastly more often than 50% of
the time.
Its not a similar attribute, the misuse of these attributes comes from not
providing appropriate content (text or a link to alternative content).
Please provide data that shows that boolean attributes are "misused vastly
more often than 50%"

In fact this data illustrates the great probability that the content of the
canvas subtree will not be usable content in the vast majority of cases, so
having to set an attribute to make it available will improve the situation
even it is set correctly only 10% of the time.

>In demos. It's unclear what the right fallback would be when the whole
>point of the canvas is to show off the canvas for its own sake. Demos are
>not really representative here. (Arguably, "you don't have canvas" is
>actually the right thing to say in this case, in fact.)

Sorry, at least an attempt at a  description of what is shown on the canvas
would be the right thing to do.
telling a user who cannot access the canvas content due to a disability you
don't have canvas does them nothing but a dis-service.
>In this case, if canvas is available, then the author can trivially just
>remove the contents of the canvas in one line of code. adom="" isn't
>useful for hiding this text.

so we now are relying on authors who can't be bothered set an attribute
correctly to write javavscript code correctly to remove the text. your
argument doesn't add up

>adom="" isn't useful for hiding this text.

you haven't yet explained why not.

regards
stevef

On 24 February 2010 10:06, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 24 Feb 2010, Steven Faulkner wrote:
> >
> > do you have any evidence to the contrary?
>
> The one <canvas> I use on a regular basis (not a demo) has accessible
> fallback and no adom="" attribute. Which is more common is essentially
> impossible to tell from purely anecdotal evidence.
>
>   http://www.whatwg.org/issues/data.html?period=1
>
>
> > >The point is that if the author doesn't care about conformance, there's
> > >the possibility that the author will specify adom="" even if the
> > >content is inappropriate for ATs, and equally a possibility that the
> > >author will _not_ specify adom="" even if the content _is_ appropriate
> > >for ATs.
> >
> > how is the probability equal?
>
> I didn't say the probability was equal.
>
>
> > does any data support that attribute use follows this pattern of 50%
> > inappropriate use?
>
> Actually data for similar attributes -- longdesc="" and summary="" come to
> mind -- show that the attributes are misused vastly more often than 50% of
> the time.
>
>
> > there is data available to show that provision of accessible fallback
> > for canvas is pretty much zero.
>
> In demos. It's unclear what the right fallback would be when the whole
> point of the canvas is to show off the canvas for its own sake. Demos are
> not really representative here. (Arguably, "you don't have canvas" is
> actually the right thing to say in this case, in fact.)
>
>
> > >So adom="" is either redundant, or possibly inaccurate.
> >
> > how so?
>
> It's possibly inaccurate for authors who don't follow the spec, and it's
> unnecessary for those who do (since they can just make the page do the
> right thing in both cases).
>
>
> > I can foresee instances where the developer provides an accessible
> > alternative outside of the canvas (currently conforming no?) and wants to
> > tell users of browsers that don't support canvas that they are missing
> > something:
> >
> > <canvas> you cannot see the graph because your browser does not support
> > canvas </canvas>
> > <!-- table containing data represented in graph -->
>
> In this case, if canvas is available, then the author can trivially just
> remove the contents of the canvas in one line of code. adom="" isn't
> useful for hiding this text.
>
> --
>  Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html