- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 20 Nov 2009 09:15:50 -0600
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: Frank Olivier <franko@microsoft.com>, James Craig <jcraig@apple.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-canvas-api-request@w3.org" <public-canvas-api-request@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
- Message-ID: <OF237CAFBD.D4221122-ON86257674.0052402E-86257674.0053D83F@us.ibm.com>
Steve,
Steve,
If canvas is not supported then any one of a set of fallbacks should be
used based on a user preference. What I am working on is a collection of
accessible alternatives based on the user's preferences. I am trying to
weave in a Media query approach in line with David Singer's audio/video tag
proposal. We will see how that works.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Steven Faulkner
<faulkner.steve@g
mail.com> To
Richard
11/20/2009 05:11 Schwerdtfeger/Austin/IBM@IBMUS
AM cc
Frank Olivier
<franko@microsoft.com>, James Craig
<jcraig@apple.com>,
"public-canvas-api@w3.org"
<public-canvas-api@w3.org>,
"public-canvas-api-request@w3.org"
<public-canvas-api-request@w3.org>,
Alexander Surkov
<surkov.alexander@gmail.com>
Subject
Re: handling focus
does the proposed solution mean that a method to hide 'fallback' will be
required?
<canvas>
shadow dom elements
<fallback>
your browser does not support canvas
</fallback>
</canvas>
regards>
steve
2009/11/19 Richard Schwerdtfeger <schwer@us.ibm.com>
yep. I got all that.
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Inactive hide details for Frank Olivier ---11/19/2009 11:50:17 AM---We
discussed this at the HTML 5 Canvas accessibility breakoFrank Olivier
---11/19/2009 11:50:17 AM---We discussed this at the HTML 5 Canvas
accessibility breakout session. The two main reasons for creating a way
to draw an ‘OS
Frank Olivier <
franko@microsoft.com
>
Sent by:
public-canvas-api-re To
quest@w3.org
Richard Schwerdtfeger/Austin/IBM@IBMUS,
Steven Faulkner <ﾅfaulkner.steve@gmail.com>
11/19/2009 11:47 AM
cc
James Craig <ﾅjcraig@apple.com>, "ﾅ
public-canvas-api@w3.org" <
public-canvas-api@w3.org>, "ﾅ
public-canvas-api-request@w3.org" <
public-canvas-api-request@w3.org>,
Alexander Surkov <
surkov.alexander@gmail.com>
Subject
RE: handling focus
We discussed this at the HTML 5 Canvas accessibility breakout session.
The two main reasons for creating a way to draw an ‘OS styled’ focus
rectangle was:
(1) The user gets to see the focus rectangle drawn in the correct ‘big
yellow border/high contrast’ style (if the user set their display to be
in black-on-white/white-on-black/big yellow focus rectangle high contrast
mode)
(2) If the user is zooming the screen using a magnifier, the user agent
can tell the OS where focus is inside the canvas; the magnifier can then
pan to the correct location on the screen.
From: public-canvas-api-request@w3.org [
mailto:public-canvas-api-request@w3.org.] On Behalf Of Richard
Schwerdtfeger
Sent: Tuesday, November 17, 2009 5:57 AM.
To: Steven Faulkner
Cc: James Craig; public-canvas-api@w3.org;
public-canvas-api-request@w3.org; Alexander Surkov
Subject: Re: handling focus
Steve,
Excellent point. So what you really want is the ability to set the focus
location in the visual canvas which then translates to an accessibility
API mapping. I was concerned that you were going to try and effect the
drawing on the visual canvas. That would not work as the developer would
not appreciate it.
The only way to do this would be to bind a rectangle to the shadow DOM
object. ATs will be doing an objectFromPoint, etc. on the focusable
object. We would need some script to set the "visible" rectangle on the
Shadow DOM object. Where the visible rectangle actually refers to the
object in the canvas with focus.
Rich
Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Inactive hide details for Steven Faulkner ---11/17/2009 04:57:20 AM---Hi
James,Steven Faulkner ---11/17/2009 04:57:20 AM---Hi James,
Steven Faulkner <faulkner.steve@gmail.com>
Sent by: public-canvas-api-request@w3.org
To
11/17/2009 04:56 AM
James Craig
<ﾅ
jcraig@apple
.com>
cc
public-canva
s-api@w3.org
Subject
Re: handling
focus
Hi James,
>In the shadow DOM proof of concept I developed, I just drew the focus
ring with the canvas. I don't see any need to have a native focus ring
drawn on top of >the canvas. I'd say, leave a custom view like canvas for
the author to manage.
How do AT such as screen magnifiers provide focus highlighting of
interactive parts of the canvas if native focus is not provided?
How are they able to follow and bring currently focused elements into the
viewport if there focus is not programmatically exposed provided?
I consider a solution that does not satisfy the following section 508
criteria [1] as inadequate and have yet to see any proposal that
satisfies this:
§ 1194.21 Software applications and operating systems.
(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes. The focus shall be programmatically exposed so that
assistive technology can track focus and focus changes.
[1] http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software
regards
Stevef
2009/11/16 James Craig <jcraig@apple.com>
On Nov 16, 2009, at 5:27 AM, Steven Faulkner wrote:
> at TPAC the provision of a method to draw focus rectangles
on a canvas was discussed, and it appeared that this was
considered necessary,
In the shadow DOM proof of concept I developed, I just drew
the focus ring with the canvas. I don't see any need to have
a native focus ring drawn on top of the canvas. I'd say,
leave a custom view like canvas for the author to manage.
> how does this fit in with the use of active-descendent to
track focus in a shadow DOM?
Only using 'active-descendant' would allow for a shadow DOM
as deep as one managed focus widget. This is fine, but a
standard focus model inside the shadow DOM is necessary, too.
Otherwise you'd need to render a separate canvas element for
every complex widget, so something as complex as Bespin could
never be achieved by using a single active descendant.
--
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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic14313.gif
- image/gif attachment: ecblank.gif
- image/jpeg attachment: 0A779336.jpg
- image/jpeg attachment: 0A906072.jpg
Received on Friday, 20 November 2009 15:16:51 UTC