W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: change proposal - Provide a method for canvas subtree to be hidden from all users

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Wed, 17 Mar 2010 22:25:07 -0400
Message-ID: <55687cf81003171925p7de3fbe5nfed816b97c57e65b@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
it would also be useful if you provided feedback on the other aspect
of the proposal, namely the additon of the following to the spec:

"To support accessibility in the navigable sub-tree the author MUST:

MUST synchronize the accessible sub-tree elements, semantics, and
structure with the canvas rendering.
MUST render and maintain visible focus of the canvas subtree element
on the rendered canvas.
MUST render and maintain the keyboard caret insertion cursor of the
canvas subtree element on the rendered canvas."

regards
stevef

On 17 March 2010 22:20, Steven Faulkner <faulkner.steve@gmail.com> wrote:
>
> hi ian,
> >They should be added because they're essential.
> could you define the criteria by which a feature is considered to be essential?
>
> regards
> stevef
> On 17 March 2010 21:49, Ian Hickson <ian@hixie.ch> wrote:
>>
>> On Wed, 17 Mar 2010, Maciej Stachowiak wrote:
>> > On Mar 17, 2010, at 6:25 PM, Ian Hickson wrote:
>> > > On Wed, 17 Mar 2010, Maciej Stachowiak wrote:
>> > > >
>> > > > Well even in that case you are saved one line of script to
>> > > > conditionally clear the canvas fallback.
>> > >
>> > > Why would it be conditional?
>> >
>> > Because you don't want to clear the fallback in browsers where canvas is
>> > not supported. (You also don't want to do any canvas drawing in that
>> > case, but you *do* still want to provide alternate content, even if it
>> > is generated dynamically).
>>
>> That conditional is already there, though -- you need it to draw the
>> canvas.
>>
>>
>> > I'm still not sure it is a hugely compelling feature, but it does not
>> > seem problematic in the same way as prior proposals (like the adom=""
>> > proposal or the <accessible> proposal). So while I do not strongly
>> > support it, I also cannot find a reason to object.
>>
>> The reason to object is that it isn't necessary. We must have a minimum
>> bar of usefulness for features we add, otherwise the language would
>> quadruple in size with lots of minor redundant features. Features
>> shouldn't be added because they're harmless. They should be added because
>> they're essential.
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG Europe
> Director - Web Accessibility Tools Consortium
>
> www.paciellogroup.com | www.wat-c.org
> Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html



--
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Thursday, 18 March 2010 02:26:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:06 GMT