See also: IRC log
<trackbot> Date: 07 February 2011
<scribe> meeting: W3C HTML Canvas Accessibility Working Group
<scribe> scribe: Rich
Rich: We should finish the spec as is before we decide on moving caret selection
Chuck: I think that that leaving
it as a rectangle is fine.
... CSS has a scale command but it has to be mapped to the old coordinate space for the mouse
... I think what we have is fine. We can say we use the current transformation matrix
... We need to transform the width and height based on the current transformation matrix
... I think adding w, and h to the transformation of the caret is fine
... I need to prototype it
... Dominic (Google) will implement it in Chrome
Rich: It looks like Benjamin
wants us to move caret and selection position to a normative
definition in the spec.
... I will do that and send it out for review
... anything else on caret blink rate?
Chuck: This does not help in and and by itself
Rich: I will add text in blink rate to refer to WCAG 2 requirements on flashing
Chuck: there can really be so much animation and movement going on that caret seems inadequate but putting text underneath blink rate that refers to WCAG 2 seems like a good move
Rich: Will add a note that generalizes on flashing wrt. caret and general canvas updates
<Downchuck> was considering removing the actual caretBlink method and just having the note there
Rich: we need to expose blink rate somehow
Chuck: most display caret by a more stable cursor
ZoomText: sets a non-blinking caret
Rich: yes, but they probably do
that in the system.
... If an AT changes the blink rate and we don't respond to the blink rate in canvas apps we have a problem.
... update canvas blink rate with note and run by Zoomtext team
Rich: Did Hixie respond to your text extent?
Chuck: He now understands what we are asking and I am waiting to hear back.
Chuck: Browser manufacturers do not want to limit content in the canvas shadow DOM.
Frank: Do you agree with this?
to Frank Olivier: Do you agree with this?
<frankolivier> I agree
<frankolivier> It would be good to have a discussion with all browser implementors on this topic (in the html5 wg)
<frankolivier> ...as we are creating a new non-visual 'mode' for all element
Resolution: Do not want to limit canvas subtree in this group
To Frank: How do you propose we raise this question?
To Frank: Want me to have Janina raise this?
<frankolivier> I think a mail on this topic to html-wg should be sufficient
To Frank: I can her raise this on the next HTML call Thursday
<frankolivier> we need dom experts to weigh in here
To Frank: Do you want to post the question?
<frankolivier> Sure, will do
<scribe> ACTION: Olivier: Post question to HTML working group on whether to limit HTML elements in non-visible content such as the Canvas fallback content [recorded in http://www.w3.org/2011/02/07-html-a11y-minutes.html#action01]
<trackbot> Created ACTION-104 - Post question to HTML working group on whether to limit HTML elements in non-visible content such as the Canvas fallback content [on Frank Olivier - due 2011-02-14].
Chuck: WhatWG squashed it over the concern over Rich Text Editing. This was raised by Japan engineers
Rich: We can use the HTML selection methods across the browsers
Chuck: Webkit does not allow disconnected selections
<Downchuck> <div>node A</div><div>node C</div><div>node B</div>
<Downchuck> if for whatever reason it was in that format, and A & B were to be selected, but not C
<Downchuck> re: "- Positioning information of content is required - per AISquared feedback"
Rich: We could a caret using <mark aria-selected="true"></mark> if needed in the content but would need to make aria-selected a global attribute
<Downchuck> We only need to respond to a subset of the dom
Rich: Other than aria-selected I
don't see any blocking items
... for us
To Frank: We need to be able to populate the bounding rectangles for MSAA.
To Frank: Have you given any thoughts to this?
<frankolivier> Our current approach is to report the boudnign rectangle of the cnavas element
Rich: yes but all the fallback content can't be in the same place
<Downchuck> drawFocusRing reports the live bounding rectangle; <div aria-live="polite">Text to display</div> reports the content
we could take x,y coordinates from area maps and apply it to elements - worst case?
<frankolivier> ...that seems like an ok approach...
<frankolivier> we'd need top, left, width, height
<frankolivier> ...or we could have the author set those on the actual elements
<frankolivier> i getelementbyid on the fake checkbox, set the t, l, w, h
<frankolivier> that seems like a better approach and will fix our architecture a bit better
Rich: Could be a lot of IDs but it would work
Chuck: I have some thoughts. I
will show an example for next week
... I will show how this will work in a live application for next week
Chuck: We can get MSAA data/events sent over the pipe
To Frank: Have you thought about doing this for Windows VNCs?
<Downchuck> remote desktop
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 Found Scribe: Rich WARNING: No "Present: ... " found! Possibly Present: Chuck Downchuck Frank Rich ZoomText frankolivier html-a11y joined left trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 07 Feb 2011 Guessing minutes URL: http://www.w3.org/2011/02/07-html-a11y-minutes.html People with action items: olivier WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]