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

So, we discussed this on the html accessibility call today.

The concern about using canvas to do this is that for canvas accessibility
we have a one for one mapping between the fallback content and the
corresponding visual renderings on the physical canvas. It sounds like what
people are asking for is the ability to associate rich descriptive content
for an image. If we were to use that as the fallback content we would
totally hose ATs who expect the content to be a one for one mapping.

One of the things we did in XHTML 2 was to use the fallback content of
<img> and <object> to provide this augmented content. Here you would use
the fallback content to provide the equivalent of a long description.
Something on the order of:

<img src="eiffeltower.jpg">

This is a picture of the Eiffel tower. The tower is composed of ... The
tower is open from ...

<h1>Entrance Fees</h1>
The tower entrance fees are as follows:

<table>
 <th> ....

</table>
</img>

Is this what you were thinking of? I mean, we could do this for <img> and
<obj>

This would also allow you to preserve image maps. User agents could
actually take and render the fallback content in an IFrame. One concern is
having to download a lot of content if it is not going to be used. Another
is that many people have alternative content on other pages today
(longdesc).

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
To:	Steve Faulkner <faulkner.steve@gmail.com>
Cc:	Laura Carlson <laura.lee.carlson@gmail.com>, HTML WG LIST
            <public-html@w3.org>, HTML Accessibility Task Force
            <public-html-a11y@w3.org>, "jackalmage@gmail.com"
            <jackalmage@gmail.com>
Date:	03/10/2011 11:31 AM
Subject:	Re: Proposal for <canvas src> to allow images with structured
            fallback by Tab Atkins Jr.
Sent by:	public-html-request@w3.org



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