HTML Accessibility Task Force Teleconference

14 Feb 2011

See also: IRC log




<trackbot> Date: 14 February 2011

Hi David, can you join the canvas accessibility call?

Revisions to Caret/Selection Pos



<Downchuck> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0067.html

<Downchuck> http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0067/HTML_Canvas_2DContext20110214.html

Chuck: I made some editorial changes. Otherwise I am happy with it

Rich: At this point we have enough for a proposal.

<Downchuck> I haven't seen much positive feedback re: issue 131

Should we move caret/selection pos to a higher level so that SVG can use it.

<Downchuck> I suspect role="caret" will be used in SVG when ARIA examines HTML5

Rich: I would like to not drop what we have until we are told to move it to a higher level to supprt SVG

Chuck: I agree. I want to see that people agree it is a valid use case.
... no issues with blink rate

<Downchuck> Apple has reasonably demonstrated several a11y visualizations; I'm just trying to recreate them

Chuck: I get shot down that any use case for a caret is invalid. The responses I am getting are absurd.

Rich: I agree.

Chuck: It is the programming part of it. I brought up the term scene graph.
... they are used for 3D themes, etc.

welcome Frank

<frankolivier> (Not able to phone in, my apologies)

<frankolivier> Hello all

<Downchuck> Hi frank

Frank, can you call in?


<Downchuck> Frank: Is there any position on caret tracking itself?

Rich: putting rich text editing aside

<Downchuck> This is in relation to telling the AT where the caret is on the screen, for the sake of the magnifier and visualization aides

Rich: Just being able to track the caret

Please see the link: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0067/HTML_Canvas_2DContext20110214.html

Rich: the programming is trivial

Rich to Frank: We just want to know if you accept the change to the spec. I will write a change proposal update this week.

<frankolivier> We support the concept of telling the UA where (canvas) UI elements are on the screen

Rich: Yes but that is not the caret position

<Downchuck> For purposes of magnification?

just for magnification

<Downchuck> the caret is a sub-position.

<frankolivier> Yes, for magnification; if you have other UI (checkboxes, links, etc) in your canvas element, you should be able to set the x,y,w,z of the canvas subtree elements


Just take a quick look at the change to the 2D API spec.

<frankolivier> What does the .setCaretSelectionRect APi get you in addition to that concept?

It tells the underlying OS to generate a caret position change event, like setCaretPos in Windows.

<Downchuck> http://www.w3.org/html/wg/tracker/issues/131

I could get JAWS to make the change for IE 9 in the next major Magic release

or IE9+

<Downchuck> I'm trying to get a "Yes". This is used in OS.X voiceover and magnification

for some OS platforms there is additional information (bounding rectangle and the element that are passed to the call to assist the AT in centering the zoom around the object)

<Downchuck> http://msdn.microsoft.com/en-us/library/ms648399(v=vs.85).aspx

for example, if you has the IAccessible associated with the element you could assess type of object and places the zoom position where the caret is at the center or at the left of the zoom area

<frankolivier> Sure, but in the IE case we report the x,y,w,h of the canvas acc tree elements to the screen reader; setting these attributes for any UI under the canvas tree woudl achieve that goal

Frank: A caret width and height is only a couple pixels. We are not talking about the bounding rectangle of an object
... you could be in the middle of a text field and the bounding rectangle is the HTML 5 input control for type="text" but the caret position is somewhere within that text field
... Am I making sense?
... this is positional information relative to the screen that the screen magnifier ultimately sees
... There is no question we need to know where the UI element is on the screen but that is not Issue 131.

<frankolivier> Yes, I get the concept; this is the case where you are recreating text input in canvas - and our position here is that this is better served by text entry outside the canvas element

Frank: so you are saying that nobody should be able to have a caret anywhere in canvas?
... forget rich text editing

<frankolivier> (calling in)

<Downchuck> Text-to-speech allows a user to focus on a button, then use hot keys to read the letters of that button opposed to the entire text; highlighting the character as it moves

<Downchuck> entirely based on navigation, low-vision use, not related to actual character input

frank: I think we are getting to a hybrid model in canvas where we have a DOM and procedural information.

Rich: The caret position API is separate from traditional Accessibility API. Ultimately (spoke to freedom scientific) and they would like the API associated with the object.


<Downchuck> whatwg standard: drawFocusRing(element, x, y, [canDrawCustom])

<Downchuck> revised: drawFocusRing(element); setCaretSelectionRect(element, x,y,w,h);

<Downchuck> "ISSUE-131: Should we add a caret location API to canvas, or is the focus API sufficient?"

Frank: I will review section 11 with a fine tooth comb for this week

Should we restrict HTML elements in the canvas subtree?

Rich: It looked like people did not want restrictions

Frank: I am going to ask people whether other people think of Maciej's and Ian's response

Rich: Should we make the proposal?


Chuck: asked on WhatWG whether all things should be initialized in canvas subtree and the answer was yes

Resolution: Delete canvas element change proposal on initializing content

Rich: At some point we may be asked to move the caret/selection API to a higher level

Frank: has svg expressed interest

Rich: heard this from Ben. Hawkes-Lewis, not sure if he is affiliated with SVG

Chuck having made changes to Chrome for focus ring or caret/selection

Chuck: waiting for dominic's changes

Resolution: bug 11238 is closed as is a duplicate

Bug 11239


Resolution: duplicate of issue 131 so is closed

Bug 11240

<scribe> Closed: this is a duplicate of Issue 131: http://www.w3.org/html/wg/tracker/issues/131

<Downchuck> I ran through these here: http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0066.html

Bug 11241

Duplicate of Issue 131: So closed

Bug 11242

Resolution: Closed as are not going to restrict canvas subtree content


Bug 11238

Correction 11328

Bug 11328

Rich: Leave open for now

Bug 11329

Reassigned to to web apps. working group

leave open

rich: leave open


Leave Open. Frank. Please look at this defect. Ian tried to close it


Frank: the text metrics change is in the 2DAPI change proposal.

Chuck: With out it we have diffculties positioning either the caret, selection, or focus ring around any type of text

<Downchuck> CanvasRenderingContext2D::drawTextInternal

<scribe> meeting: HTML 5 Canvas Accessibility Working Group

<Downchuck> that's where in webkit the code for baseline is

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/02/14 21:10:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: richardschwerdtfe
Inferring Scribes: richardschwerdtfe

WARNING: No "Present: ... " found!
Possibly Present: CanvasRenderingContext2D Chuck Closed Downchuck Frank Microsoft Rich aaaa frankolivier html-a11y joined revised silvia trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Found Date: 14 Feb 2011
Guessing minutes URL: http://www.w3.org/2011/02/14-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]