WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Thoughts towards an accessible <canvas>

for

From: John Foliot
Date: Mar 20, 2009 7:20PM

Charles McCathieNevile wrote:
>
> I think that this is a non-starter. As explained in a narrower follow-
> up,
> the penalty to browsers who do this means that mainstream browsers
> simply won't, in all probability.

I will note your comment, and likely return to it in a subsequent follow-up

> >
> > Title:
> > [mandatory] A brief description or name of the canvas content.
>
> If we want alt, we could add it. I think there may be value in that,
> even
> though I expect it to be misused a lot (I don't see that as
> overwhelmingly
> harmful). The use case is for a quick functional explanation of what
> you
> are missing, or not perceiving as clearly as needed to make sense of
> it,
> right? So it would help make a decision about whether to zoom the
> canvas,
> look inside for the alternative content, or just skip it and get to the
> thing you were looking for.

Yes, thanks for re-stating the use-case. This is exactly what I am
suggesting. If re-purposing @alt here makes more sense then +1 for that


> > Author:
> > [mandatory] The owner or creator of the widget. May be an
> individual
> > or entity, and may also include the anchor element to another URI
> > Examples:
> > * <a href=http://www.fox.com>;The FOX Broadcasting Company </a>
> > * Joe Blough for My Web Developer Company LLC
> > * Mozilla Labs Project - Dion Almaer, on behalf of the Bespin
> > development team
>
> I am not sure why this should be mandatory. It's also the sort of thing
> I
> would see as being more generally useful (e.g. for anything that is
> aria-role="application"), and I think it is the kind of use case that
> RDFa
> might more effectively deal with.

Re: methodology - sure, open to any and all ideas. Thought RDFa was still
"contentious" in HTML5, but that seems reasonable.

Re: why. Honest response - social engineering. When someone signs their
name to something, they tend to take the time to do it right - it's their
name after all. So it's a check and balance thing - are you comfortable
putting your name to this widget? Willing to concede that it is
non-technical, but often so am I <grin>.

> > Description:
> > [optional] A more detailed explanation, expanding upon the Title.
> We
> > cannot presume that all users want a verbose explanation of the
> canvas
> > 'widget', however there are times when some might, and providing this
> > information would be of great use.
>
> Putting this in an attribute seriously reduces its utility - you have a
> big pile of text that cannot include markup. If there is a description
> elsewhere (be it on the page or on another page) then referring to it
> with
> aria-describedBy seems to make more sense. Otherwise, if it is useful
> then
> having it in the content of the element (which should be made
> available,
> as per UAAG [1]) seems more appropriate, since that can at least allow
> for
> markup (and links, etc).

Once again, methodology is open to what works best. Key point is a
separation of terse description and verbose description - there is a need
for both, but also a significant enough difference that both should exist.

>
> > Alternate:
>
> I think that given we are developing a new thing, the aria-describedBy
> should be used for this (it is in fact analagous to longdesc, just
> applicable to more elements). I also think that this should be the
> primary role of the content of the canvas element.
>
> One issue that hasn't been articulated anywhere I can think of is what
> to
> do where you have multiple alternatives. Since most of the examples of
> canvas I have seen don't provide any meaningful alternative at all,
> this
> may be a use case based on wishful thinking, but in principle it is at
> least a reasonable thing to do...

+1 for that

>
> > Notes:
>
> Again, I think that this is probably information that can be added to a
> description, and thus covered by the content/@title/@aria-describedBy
>

Fair enough, I was thinking more along the lines of a catch-all container -
version info or change-log data, text stuff like that. Non-critical data,
but this was just a vague thought anyway.

With a reworking of "titles", there is also a need to think through the
actual pattern of this data as it would be included inside the opening and
closing <canvas> 'tags'. I had thought of a definition list as being the
most 'semantic' container, but is there another pattern container that would
make more sense? Feedback/discussion encouraged.

Cheers!

JF