W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

08 Sep 2014

See also: IRC log

Attendees

Present
Rich_Schwerdtfeger, Sam, MarkS, cabanier, jaymunro
Regrets
Chair
Sam Ruby
Scribe
MarkS

Contents


<trackbot> Date: 08 September 2014

<rubys> Meeting: Canvas Task Force

<scribe> scribe: MarkS

Testing Status

<rubys> http://lists.w3.org/Archives/Public/public-canvas-api/2014JulSep/0027.html

JM: assembled these items from recent emails
... have drawFocus tests. Some may need to be updated.
... don't know if there are any tests for Hit Regions
... Rich gave a great list of methods for testing.

RS: mark, how many tests do we have

MS: no tests since the new features were added

RS: what do we have?

<jaymunro> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-drawfocusifneeded

From PLH:

From what I understand hit regions to be about, those are adding

information on mouse events (region) and can make routings events to DOM

elements automatic. Since we don't retarget, the target of a click event

in within a hit region in a canvas is still the canvas element. No where

in those steps do we talk about informing the user by the way.

Btw, regarding step 4 of drawFocusIfNeeded, it currently says:

[[

4. Inform the user of the location given by the path. The full location

of the corresponding fallback element is passed to the accessibility

API, if supported. User agents may wait until the next time the event

loop reaches its "update the rendering" step to inform the user.

Note: "Inform the user", as used in this section, could mean calling a

system accessibility API, which would notify assistive technologies such

as magnification tools. To properly drive magnification based on a focus

change, a system accessibility API driving a screen magnifier needs the

bounds for the newly focused object. The methods above are intended to

enable this by allowing the user agent to report the bounding box of the

path used to render the focus outline as the bounds of the element

element passed as an argument, if that element is focused, and the

bounding box of the area to which the user agent is scrolling as the

bounding box of the current selection.

]]

Should the step 4 read instead, since you want to given the location the

current path used for the focus ring, and NOT the location of the

fallback element:

[[

4. Inform the user of the location given by the current path. The full

location of the corresponding current path is passed to the

accessibility API, if supported. User agents may wait until the next

time the event loop reaches its "update the rendering" step to inform

the user.

RS: When you do the association of the path with the fallback element, that gives the fallback element a new location

RC: yes

MS: That makes sense

RC: If this is not working correctly in FF, file a bug, send me a file and I'll take a look

RS: The issue is that the location was being reported for the fallback element, not the path

<scribe> ACTION: for MarkS to create a test file and send to Rik for debugging [recorded in http://www.w3.org/2014/09/08-html-a11y-minutes.html#action01]

<trackbot> Error finding 'for'. You can review and register nicknames at <http://www.w3.org/WAI/PF/HTML/track/users>.

<scribe> ACTION: MarkS to create a test file and send to Rik for debugging [recorded in http://www.w3.org/2014/09/08-html-a11y-minutes.html#action02]

<trackbot> Created ACTION-283 - Create a test file and send to rik for debugging [on Mark Sadecki - due 2014-09-15].

RC: create a bugzilla bug, is better

RS: Mark in your test file you have two hit regions. We need to test that multiple hit regions are supported. Can use the same test file for multiple tests. We need to test a div with aria markup.
... need to make sure those location values can be overridden
... I can run tests here

MS: I've had success creating demos, they just need to be converted into simple test cases

RS: How many test cases do we want?
... need tests for scrolling and moving the window

MS: I would love to have a list of testable statements that need tests written

RS: I can get started on that
... maybe post them on the wiki

<jaymunro> https://www.w3.org/wiki/HTML/Canvas_Task_Force/Work_Statement (one area)

<jaymunro> https://www.w3.org/wiki/HTML/Canvas_Task_Force/ (root)

"The methods above are intended to enable this by allowing the user agent to report the bounding box of the path used to render the focus outline as the bounds of the element element passed as an argument, if that element is focused, and the bounding box of the area to which the user agent is scrolling as the bounding box of the current selection."

"If the focus area is not on the screen, then scroll the focus outline into view by aligning it to the top when it receives focus.

RS: Firefox doesn't currently scroll to the top of the page
... will need a test file with a lot of space before the canvas to test this

<richardschwerdtfeger> https://www.w3.org/wiki/HTML/Canvas_Task_Force/CR-Test

SR: Do we have any dates for getting this work done?

RS: lets aim to get this done by the end of the month

SR: All tests will be written and run by the end of the month

RS: We can record results there as well

Implementations Update

MS: I've had success with these features in Firefox Nightly and Chrome Canary
... based on preliminary testing, we have support in those two browsers

RC: Anyone test in Safari 8?
... I recently added support for drawFocus

RS: do they have any issues with Hit Regions?

RC: no, it just hasn't been implemented yet

Level 1 CR

JM: I think the only thing that is holding up progress is testing

SR: That is also my understanding

Heartbeat Level 2

SR: I think the plan is to switch to ReSpec?

JM: I haven't heard that, but its possible

RC: I think that is true for HTML (moving to respec) but I don't know about canvas

JM: since canvas is part of that same document, then perhaps canvas will go the same route

SR: no need for a heartbeat then

Next Meeting

SR: we should at least change the IRC channel
... also would appreciate a different time slot

RC: two hours earlier?

MS: WFM

RS: i can only do an hour earlier

JM: I can also do 1 hour earlier or 90 minutes earlier
... should we consider a different day?
... tuesday and friday work well for me

RS: I can do Friday afternoon 2Central

MS: WFM

JM: same

SR: 9/26 for next meeting?
... bi-weekly

MS: #canvas-api for channel name?

[agreement]

Next meeting will be 9/26 in #canvas-api

Summary of Action Items

[NEW] ACTION: for MarkS to create a test file and send to Rik for debugging [recorded in http://www.w3.org/2014/09/08-html-a11y-minutes.html#action01]
[NEW] ACTION: MarkS to create a test file and send to Rik for debugging [recorded in http://www.w3.org/2014/09/08-html-a11y-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-09-08 22:46:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: MarkS
Inferring ScribeNick: MarkS
Default Present: Rich_Schwerdtfeger, Sam, MarkS, cabanier, jaymunro
Present: Rich_Schwerdtfeger Sam MarkS cabanier jaymunro
Found Date: 08 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/08-html-a11y-minutes.html
People with action items: for marks

[End of scribe.perl diagnostic output]