Re: Proposal for <canvas src> to allow images with structured fallback by Tab Atkins Jr.

Steve Faulkner, Thu, 10 Mar 2011 13:47:13 +0000:
> Hi Leif,
> 
>>Viable solution to which problem?
> What I think is important is that a robust , programmatic method for 
> providing structured text alternatives for non text content is 
> provided in HTML5.

+1 This is important. And <canvas> have potential as a solution.

> Whether that is via longdesc or some other mechanism is immaterial. 
> If longdesc is included in HTML5 but fails to be specced/implemented 
> to be useful and robust then it will be a failure.

This is all good. And on a purely theoretical level, I agree a 100%.

But @longdesc doesn't offer "structured text alternatives" - it offers 
a link. 

Of course, hypertext bites its tail: structured text could be a link, 
and link could be structured text (if it is a data URI). But 
nevertheless, they're different concepts. Perhaps structured text will 
outperform the link. However, think of alternative content inside 
<object>: authors don't do it and screenreaders don't support it. That 
'structured text alternatives' have been a greater success than 
@longdesc is thus not clear. An, I can add: neither has there been very 
much interest, to my mind, in this working group's accessibility 
community, in making sure that <object> *can* be easily used for such 
purposes.

An example of what the accessibility community has shown little 
interest in, is that HTML5 says about canvas, as well as about object, 
the following:

]] Conformance checkers may warn authors of cases where they have 
paragraphs that overlap each other (this can happen with object, video, 
audio, and canvas elements, and indirectly through elements in other 
namespaces that allow HTML to be further embedded therein, like svg or 
math).[[

Hence, this does not validate:

   <p>Look at this diagram:
      <canvas id=diagram ><table><tr><td>Alt</tr></table></canvas> 
   </p>

Shouldn't it validate, if it is meant to be as simple to use as <img>?

> your wrote:
> "But, once again, which @role would the canvas@src in Tab's example get?
> 
> <canvas src="complex-chart.png">
>  <table>
>    -data that the chart represents-
>  </table>
> </canvas>"
> 
> Why do you have this obsession with what the role of canvas should 
> be?

This is were I'm coming from:

1) For <object data=image> there is a widespread tendency to treat it 
as having role=img, even when it contains markup. This, again, makes 
fallback inaccessible.

2) In the discussion we had about whether <img> should default to 
role=img. If the <img> does not have role=img, then the user - if I 
have gotten it right - might loose ability for instance save the image 
- or perceive it at all.

3) I wonder what the correct thing to do is. For example, for <object 
data=diagram >, if it contains a <table> in the fallback, would it be 
be correct to, for instance, do this: <object role=presentation 
data=diagram > ? If yes: what about the user's ability to perceive that 
it is in fact an image? (For @longdesc, this seems like an advantage: 
the <img> can keep is role=img, which means that the AT user can BOTH 
download the image as well as visit the link.)

With regard to 3), then I note that HTML5 says about object's role 
this: "If specified, role must be either application, document, or 
img". Plus that the general "except that the presentation role may 
always be used" also applies.

> I think the role will depend entirely on the context it is used in.

OK. But isn't it more important what context it _contains_ compared to 
the context it is is used in?

> Note that HTML5  like HTML 4 etc has many elements are not mappable 
> to specific ARIA roles or accessibility API roles and ARIA itself 
> only covers a subset of existing accessibility API roles.

I have no desire to map <canvas> to a role if it is better to not do 
so. But, looking at http://dev.w3.org/html5/html-api-map/overview.html, 
I note that you have question marks on both <canvas> and <object>. So 
it looks as if you, as I, see them as very related. But, real life is 
that <object data=image> seems to be given role=img by UAs/AT and that 
this negates the advantage of using <object data=image> over <img>: 
fallback becomes inaccessible.

> canvas itself has no defined default ARIA role in HTML5 and it may 
> well be that it is appropriate to not have a defined role for it. Or 
> it may be given a generic grouping roles or a role of animation or a 
> role of img by browsers when they map it to accessibility APIs, what 
> IS importanat is that there is uniformity in how it is mapped.

I don't get 'role of img by browsers' to match with 'structured text 
alternatives'. But perhaps you meant to explain that below.

> As to the img roles children being presentational, this is a 
> requirement from ARIA, it does not follow that it is a requirement on 
> the roles that ARIA maps to in accessibility APIs.

But it seems to be what happens, by default, for <object data=image 
type="image/gif" >.

> In other words, 
> when the ARIA role="img" is explicitly set on an element
> 
> <div role=img></div> the requirement stands.
> 
> when an element is mapped to the MSAA ROLE_SYSTEM_GRAPHIC by browsers 
> it does not mean that all required children have to be 
> presentational. 

Well, it seems necessary to emphasize/explain/clarify this. Are there 
examples of UAs/AT which don't do what I claim they do?

> In the example above if the content represented in the canvas is 
> wholely provided in the structured content alternative, then the 
> canvas itself could be left out of the accessible tree.

Which means that the user wouldn't perceive there is an image? He/she 
would only perceive the text?

It seems noteworthy to consider how <object data=not-an-image > does 
not default to role=img. Therefore, unless care is taken, I predict 
that we will see that <canvas src=image > will be mapped to role=img, 
with the same, sad consequences that it is typical to see for <object 
data=image > And, perhaps there is reason to worry that a scripted 
<canvas> will work different (not be given role=img) from <canvas 
src=image >.

It is better to think about it from the start, if <canvas src=image > 
is supposed to become any better than <object data=image>.
-- 
leif halvard silli

Received on Thursday, 10 March 2011 17:29:42 UTC