- From: Charles McCathieNevile <chaals@opera.com>
- Date: Thu, 19 Mar 2009 16:34:52 +0100
- To: "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>
Hi John, thanks for this proposal. I have some serious changes to suggest, so details inline... On Tue, 17 Mar 2009 08:00:56 +0100, John Foliot - WATS.ca <foliot@wats.ca> wrote: > Requirement: > When authors use the canvas element, they must also provide content > that [...] conveys essentially the same function [...] > [source: http://dev.w3.org/html5/spec/Overview.html#the-canvas-element] > > But what, exactly, should content authors include as their fallback > content? > ... Finally, Well, you explain the attributes below so this isn't final ;) > I propose that > any instance of <canvas> that lacks at a minimum the 2 proposed mandatory > values be non-conformant and not render on screen. The inclusion of this > information should not be left to chance - the specification requires > that some fallback content exist - and if it does not exist then the > <canvas> element is incomplete, thus it should simply fail all users... 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. However the rest of the proposal is worth looking at: > ... the 2 mandatory attributes are so basic in nature that it is > unlikely that they will be 'gamed' or misused/abused. I am not so sure. But I am glad to see this issue recognised as important in determining whether a proposal will work. > Finally, due to the > 'consistency' factor, authoring tools could be programmed to collect and > insert this data with little overhead or intrusion to the content author. This is likewise an important issue. > The proposed attributes are: > > Title: > [mandatory] A brief description or name of the canvas content. Think > along the lines of @alt - tell the user of a user-agent that does not > support canvas what is in this region: its purpose or function. This is > not to be verbose! > Examples: > * Dynamic chart of this week's votes from American Idol > * A 3-dimensional shooter game > * Bespin - A dynamic on-screen editing tool This is easy enough to game. Spamming systems that simply added a random bit of real text could be adapted to do it here as well in about 5 seconds. Making title mandatory would be inconsistent with the use of title all over HTML. 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. > 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. > 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. > Examples: > * "The FOX Broadcasting Company's popular American Idol television > program allows viewers to vote on their favorite performer each week. > This on-screen application creates a visual representation of the weekly > votes cast using a common bar graph, with updates posted every 60 > seconds." [etc] 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). > Alternate: > [optional] Borrowing from the idea of @longdesc, this would be an > URI that points to an alternative rendering of the content/concept that > the canvas region is delivering. For example, in the case of the dynamic > bar-graph, the data driving the bar-graph could also be represented in a > tabular (<table>) format. [...] 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... > Notes: > [optional] A catch all attribute which would be open for use to the > content developer to use as desired. The content of Notes would be text > only, and might include items such as change-log data or version number, > or other developer commentary as required. Again, I think that this is probably information that can be added to a description, and thus covered by the content/@title/@aria-describedBy > It is important to state that this is just an opening proposal... Sure, and I appreciate it as such. cheers, your friend Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Thursday, 19 March 2009 15:35:47 UTC