Re: Thoughts towards an accessible <canvas>

On Sat, 21 Mar 2009 02:19:23 +0100, John Foliot <jfoliot@stanford.edu>  
wrote:

> 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

Fair enough.

>> > 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.

OK, it is important to note this. Some motivators - people who have some  
vision but not 100% (John, that includes us as we get older - I've seen  
your glasses ;) ).

>  If re-purposing @alt here makes more sense then +1 for that

Well, I am not prejudging the possible solutions. But things that are  
familiar and consistent have a benefit over introducing a new thing (as  
well as a cost in that you can't make a clean break. Most times, such as  
XHTML2 or HTML5, the familiar thing is overwhelmingly simpler to get  
adopted).

>> > Author:
>> >  [mandatory] The owner or creator of the widget.
...
>> 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.

I don't care if it "contentious" - it is something that deals with a raft  
of use cases and this is one such. But again, it isn't the only one. There  
are many common ways of including such information in binary image files,  
and some common ones are RDF-based and therefore should be readily RDFa  
compatible. But let's get the goals clearer before we invest too much in  
the tools to reach them...

> 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>.

Hmmm. Interesting point. I think it has merit - but I would hardly be  
willing to stop displaying a canvas just because it is unsigned.

With aria-role="application" there is some clearer rationale, since that  
can identify a bit of inline code that behaves as an external applet  
(specifically to allow for special handling by tools, where that would be  
helpful).

However, for now I think we should note that an application should be able  
to have author metadata (and various other kinds) available, and drop this  
attribute from the present discussion since the need is not specific to  
canvas. John, can you raise an issue on that more general thought? It  
might be clearest to the PF folks, who developed aria-role="application".

>> > Description:
>> >  [optional] A more detailed explanation, expanding upon the Title.
...
>>
>> 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.

I agree. I think this is a key point (and plays into ISSUE-30 which is  
substantially the same question, plus an extra 'keep something or ivent  
something new' aspect). It is not clear to me that there is consensus in  
the working group that this distinction is important, but I hope there is.

It boils down to the difference between what I want to hear when skimming,  
and what I want available if I am looking in detail at the content - just  
like a search results page doesn't present a whole page, but a simple  
snippet, whereas the whole page is what you want if you go to it.

However, it seems that aria-describedBy (which is already available for  
canvas) would happily handle this use case, so there is no change required  
to canvas to make this possible.

>> > 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

See below.

>> > 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.

So that part of the idea essentially folds into the issue I raise above of  
being able to attach generic metadata to things that are applications  
(this was clear enough that images do it already, and lots of tools use  
that data). If there is an issue on doing that in general, this doesn't  
need to be specific to canvas, but canvas needs to be noted as a use case.

> 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.

I would think that it is much less clear, and all kinds of things could be  
used.

To take a concrete example, in Opera's "state of the mobile web" report,  
we start with a table of data. By default, we replace that with an image  
(from memory it is SVG, but the principle doesn't change), but the table  
content is there - and since browsers *don't* provide good ways to get at  
fallback information, we include a button to do it. See  
http://www.opera.com/smw/2009/01 for what I mean.

Another example would be a canvas used as a captcha, with some text-based  
captcha inside it as an alternative. Another would be the multimedia  
version of an online course I am currently doing, which has a "section 508  
compliant" version - if the course were shown using canvas (it isn't but  
other things I have done in my career as a student could easily be) then  
all kinds of things are imaginable as content.

Which brings us back to the issue of being able to idenitfy multiple  
alternates. I guess a simple approach is to link to several things from  
inside the canvas, although that requires a more complex site structure  
since you have to start maintaining parallel versions, which is generally  
a bad choice to have them up to date (the principle of visible metadata).  
So the question is whether that is sufficient - and given the paucity of  
current implementation of fallbacks, perhaps it is. You can always use the  
existing object element to cascade inside the content too. I don't know -  
I don't think that was ever satisfactorily solved for HTML. Maybe looking  
at how multilingual content is handled would give us more interesting  
source material to try and interpret.

cheers

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 Saturday, 21 March 2009 04:04:13 UTC