W3C home > Mailing lists > Public > public-html@w3.org > March 2009

RE: Thoughts towards an accessible <canvas>

From: John Foliot <jfoliot@stanford.edu>
Date: Fri, 20 Mar 2009 18:19:23 -0700 (PDT)
To: "'Charles McCathieNevile'" <chaals@opera.com>, "'John Foliot - WATS.ca'" <foliot@wats.ca>, "'Wai-Ig'" <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>, "'HTMLWG'" <public-html@w3.org>
Cc: "'WebAIM Discussion List'" <webaim-forum@list.webaim.org>, "'Gawds_Discuss'" <gawds_discuss@yahoogroups.com>
Message-ID: <007a01c9a9c3$0fb29b10$2f17d130$@edu>
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.


Received on Saturday, 21 March 2009 01:20:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC