If the context method for canvas returns null it means that the browser
does not support canvas. The sub dom can be rendered in this scenario and
can in fact be different for non-supporting user agents.
Although I am very dubious that any device user agent will not be
supporting the full HTML spec. going forward and expect to stay in
business.
Rich Schwerdtfeger
CTO Accessibility Software Group
From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Frank Olivier <Frank.Olivier@microsoft.com>, Richard
Schwerdtfeger/Austin/IBM@IBMUS, "Mike@w3.org" <Mike@w3.org>,
"david.bolter@gmail.com" <david.bolter@gmail.com>, Cynthia
Shelly <cyns@microsoft.com>, "public-canvas-api@w3.org"
<public-canvas-api@w3.org>, "public-html-a11y@w3.org"
<public-html-a11y@w3.org>, "public-html@w3.org"
<public-html@w3.org>
Date: 06/21/2011 01:21 AM
Subject: Re: hit testing and retained graphics
On Mon, Jun 20, 2011 at 5:07 PM, Charles Pritchard <chuck@jumis.com> wrote:
> I've concerns about this approach. It would mean the sub-tree is no
longer
> separably viewable -- though not implemented at the moment, it is still
an
> option.
I strongly agree that preventing the sub-tree being separably viewable
is problematic, indeed to the point of it being a non-starter. The
sub-tree was intended to act as an alternative for canvas like @alt is
for "img". Making it nonsensical in complex cases would discourage UAs
from making it viewable. This would prevent, for example, a user with
at least some sight and images and canvas disabled from getting access
to consistent text equivalents. This would break the specified use of
"canvas" as a dynamic
version of "img".
> A clickable area is more like an SVG path, not a CSS box.
Also true.
--
Benjamin Hawkes-Lewis
