W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Wed, 20 Jan 2010 14:58:23 +0000
Message-ID: <55687cf81001200658o2b2cc9f0vd525c4083902af8@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Ian Hickson <ian@hixie.ch>, Maciej Stachowiak <mjs@apple.com>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
hi henri,
ok sounds like sound reasoning. it was a suggestion arising from my lack of
understanding of the intricacies of this stuff.
>It *might* make sense to make drawfocus(element, ...) call element.focus()
unconditionally. However, keeping drawfocus() as focus() distinct would seem
to >be more fitting to a low level API as far as separation of concerns
goes. At the very least, repeated calls to drawfocus(element, ) with the
same element >shouldn't cause element to refocus every time but to focus the
first time and then remain focused if drawfocus() is called again without
focusing something >else in between.

currently the spec [
http://dev.w3.org/html5/2dcontext/Overview.html#focus-management] says:
> If element is not focused or is not a descendant of the element with whose
context the method is associated, then return false and abort these steps.

So whenever  drawfocus() is called, the location of current focus is
checked, so it should be easy enough to not refocus if the element
referenced has focus.

this could be changed to:

 If element is not a descendant of the element with whose context the method
is associated, then return false and abort these steps.

 If the element is a descendant of the element with whose context the method
is associated and is not focused move focus to the element.

this i think would save work for the developer and make it more attractive
to provide interaction through a subdom of HTML elements for all users,
which will provide benefits for users with disabilities, while minimising
the provision of of additional requirements.



regards
stevef
2010/1/20 Henri Sivonen <hsivonen@iki.fi>

> On Jan 20, 2010, at 16:14, Steven Faulkner wrote:
>
> >> Do you mean that the UA should check if a 'click' event handler is on
> the call stack when drawfocus() is called?
> >
> > Forgive my ignorance, but i don't understand what you are talking about.
>
> I mean call stack in this sense:
> http://en.wikipedia.org/wiki/Call_stack
>
> > what i mean is when a region of the canvas is being monitored for clicks
> and the response to a click is to call the drawfocus() method, this method
> includes a reference to an element,
>
> I take that as affirmative answer to my question.
>
> > then the calling of the drawfocus() method should cause the focus to move
> to the referenced element.
>
> What if the call to drawfocus() is not in response to a click?
>
> > rather than  the developer having to manually move focus to the element
> via scripting.
>
> It would be exceedingly weird API design to make drawfocus(element, ...)
> also call element.focus() but only if drawfocus() was called in response to
> a click (i.e. there's a 'click' event handler on the call stack). I wouldn't
> support that (exceeding weirdness of API behavior depending on the call
> stack being the reason).
>
> It *might* make sense to make drawfocus(element, ...) call element.focus()
> unconditionally. However, keeping drawfocus() as focus() distinct would seem
> to be more fitting to a low level API as far as separation of concerns goes.
> At the very least, repeated calls to drawfocus(element, ) with the same
> element shouldn't cause element to refocus every time but to focus the first
> time and then remain focused if drawfocus() is called again without focusing
> something else in between.
>
> --
>  Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>


-- 
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 Wednesday, 20 January 2010 14:59:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 January 2010 14:59:17 GMT