See also: IRC log
<trackbot> Date: 14 February 2011
Hi David, can you join the canvas accessibility call?
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0066.html
<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
<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?
k
<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
great.
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
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?
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0065/HTML_Canvas_Element.html
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: waiting for dominic's changes
Resolution: bug 11238 is closed as is a duplicate
http://lists.w3.org/Archives/Public/public-html/2011Jan/0200.html
Resolution: duplicate of issue 131 so is closed
<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
Duplicate of Issue 131: So closed
Resolution: Closed as are not going to restrict canvas subtree content
Correction 11328
Rich: Leave open for now
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11342
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
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]