W3C

HTML Accessibility Task Force Canvas Sub Group

16 Dec 2013

See also: IRC log

Attendees

Present
Rich Schwerdtfeger, Mark Sadecki, Jay Munro, Rik Cabanier, Jatinder Mann
Regrets
Chair
Rich S
Scribe
MarkS

Contents


<trackbot> Date: 16 December 2013

<scribe> Meeting: HTML Accessibility Task Force Canvas Sub Group

<scribe> scribe: MarkS

Should work on drawCustomFocusRing go to L2?

Should work on drawCustomFocusRing go to L2?

RS: We have Firefox and Microsoft and have had contact with Dominic from Chrome
... Paul Cotton left if up to the group to move customFocusRing to L2. Do we have consensus on this or do we need further discussion?

RC: If everyone is Ok with moving it to L2, I think that is a good idea

RS: We were almost there, but really need Media Queries/User Context to deal with the high contrast issue. So we should probably wait.

JMann: If we feel like something later on will help us do that, then I think we should wait.

RS: I'm fine either way

JMann: lets start with systemFocusRing but still talk about customFocusRing when relevant.
... what about the CfC from the TF

<JatinderMann> Mark those last comments came from me (JMann)

RS: Paul Cotton left it up to this group in the last TF call.

Walk through existing Canvas 2D Accessibility bugs

<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23978

<JatinderMann> All bugs are listed here: http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0011.html

RS: Informing the user shouldn't be optional
... this had to do with informing the user that the location has changed for the current focused element. This is for the Assistive Technology. This was phrased like this because some platforms might not have an accessibility infrastructure.

JMann: If we say it is a requirement, and a platform doesn't support it, isn't that the same as supporting this feature.

RS: Notifying would be an additional step. This piece would be optional.

JMann: What they really wanted was a bounding box. Notifying the AT is a goal of the feature.

RC: agreed

JMann: I think it should be a requirement

RS: I agree, do you want to take "optionally" out?

JMann: Was Ian's concern that an accessibility feature must be enabled in order to fire that event?

RS: I think it was more for older mobile phones who don't have an integrated AT, they could still draw the focus ring, but not inform the location
... in all the AAPI you have rectangle, X,Y Width and Height. You would expose that to the AAPI for the bounding box.

JMann: my concern was that is said optional at all, it makes it seem like its not that important. However, I would think that this would be the actual feature.
... i think we should make it a requirement and clarify what the feature is for.
... a preamble that describes what this feature is meant to do.

RS: so remove the word optionally, and add a note that explains the feature.

JMunro: I'm looking at the spec and it doesn't say explicitly that its informing the AAPI. It could be a dialog box or anything. So to clarify its for AAPI would help.

<richardschwerdtfeger> Note: This is intended to provide inform the user of the location of the element on canvas to support accessibility services. For user agents that are implemented on platforms that don't provide such services this feature cannot be implemented.

<richardschwerdtfeger> This is intended to provide inform the user of the location of the element on canvas to support accessibility services.

JMann: If a platform didn't have native accessibility support, it should be clear that it would be beneficial to at least draw the ring, even though you can't report the location.

RS: who will make the edit?

JMunro: I can make the edit if you provide the text.

<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23979

RESOLUTION: 23978 closed

<richardschwerdtfeger> The differences between drawSystemFocusRing and drawCustomFocusRing should be better highlighted in the specification:

<richardschwerdtfeger> * Using drawCustomFocusRing means that the web app intention is to draw the focus itself, unless the user has requested a particular focus ring. Its purpose is to help the web app preserves the user setting

<richardschwerdtfeger> * Using drawSystemFocusRing means that the web app wishes to delegate the drawing of focus ring to the user agent

RS: PLH has presented recommended text

JMann: I support this bug, it took me awhile to understand the difference between system and custom focus ring

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

RS: If we move this to L2, we can pass on this one.

JMann: would it help to add a note to describe what drawSystemFocusRing() does?

<JatinderMann> If the given element is focused, draws a focus ring around the current default path or hte given path, following the platform conventions for focus rings.

RS: there is no given path
... so we should make this clearer?

JMann: Draw the focus ring around the current default path. should we put something in there so developers understand what the purpose of this function is

RS: Do we want to change it to drawSystemFocus?

JMann: when we say system, we really mean User Agent, right?

RS: which is based on the Operating System

JMann: In IE its a dotted line, in FF its a reddish-orangish line

<richardschwerdtfeger> The purpose of this function is draw a focus ring in a way that conforms to the way a user agent draws focus.

<richardschwerdtfeger> The purpose of this function is draw a focus ring in a way that conforms to the way a user agent draws focus and to inform assistive technologies of the location of the bounds of the focus as applied to an element.

JMann: its useful to come up with some ideas right now, but we may want to continue to work on the exact wording.
... important that other implementers not on this call, or web developers, understand what this is for.
... confusion around what the system is (UA) and what this method does or is important for.

<richardschwerdtfeger> The purpose of this function is draw a focus ring in a way that conforms to the way a user agent draws focus and to inform assistive technologies of the location of the bounds of the focus as applied to an element. User agents often implement focus drawing following system conventions.

JMann: I wonder if its worth not saying "ring"
... canvas allows you to draw any path, so ring is confusing.

RS: outline is OK with me

JMann: not everyone does an outline, so maybe just focus path?

JMunro: Path has another meaning

<richardschwerdtfeger> The purpose of this function is draw a focus in a way that conforms to the way a user agent draws focus and to inform assistive technologies of the location of the bounds of the focus as applied to an element. User agents often implement focus drawing following system conventions.

JMunro: I think we should talk about working and terminology more. Outline is a possibility, I'm thinking of focus.

JMann: we can take the actual working and discuss it on the list

MS: is the word "indicator" too vague

JMann: no, thats actually what it is. that is interesting

RC: would we have to change chrome and FF to match?

JMann: is it prefixed?

RC: no, its not prefixed, but its behind a flag

JMann: this is just the note, nothing normative
... sounds like we are all in agreement that we can make it better and we should probably do that on list.

<richardschwerdtfeger> The purpose of this function is draw a focus indicator in a way that conforms to the way a user agent draws focus and to inform assistive technologies of the location of the bounds of the focus as applied to an element. User agents often implement focus drawing following system conventions.

JMann: you still want to say if the given element is focused.

RS: Because we don't have any path capability right now, if its not focused, it doesn't draw the ring, but it does provide the location.
... Magnifiers want to allow users to zoom to a location on the canvas. If the element doesn't have focus, they still want to be able to drive the magnifier there.

RC: that has nothing to do with Path API, its just how its currently designed.
... you don't inform the AAPI unless it has focus.

RS: Dominic *does* inform that AAPI of the location's object, even though the spec doesn't say that. it is a way around hit testing.
... this wouldn't be necessary if we had hit testing.
... because fallback canvas aren't rendered to the glass, they don't have a location. One way to deal with this is to use dSFR method to draw the ring and indicate location. The same function could be used to indicate location, without drawing the focus ring if they are not in focus.

JMann: so the AAPI won't know where the elements are until they are in focus.
... if I want to move the magnifier, I would move focus to...

RS: HTML outside of canvas, the layout engine provides the location of each element to a corresponding accessible object. A magnifier or SR maintains a view of all the objects rendered on the screen can speak or zoom to all elements. A user can zoom to any element using that location info

JMann: does it make sense to have a separate focus location mapping API

RS: we actually had something like that, but Ian wanted to have one function to encourage people to write to the function.

JMann: do we all agree that we should inform the aapi of location? if so, we should open a bug.

<richardschwerdtfeger> ACTION: Rich Open bug against 2D Canvas for drawSystemFocusRing to inform assistive technologies of the location event when it does not have focus [recorded in http://www.w3.org/2013/12/16-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-224 - Open bug against 2d canvas for drawsystemfocusring to inform assistive technologies of the location event when it does not have focus [on Richard Schwerdtfeger - due 2013-12-23].

JMann: so every time that method is called, I inform the AAPI of the location of all elements.
... Maybe just moving sCFR to L2 will make this work easier.

<richardschwerdtfeger> RESOLUTION: Move drawCustomFocusRing to L2

JMunro: its already in L2 now, so I will make changes to both were appropriate.

<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23979

RS: should bug 23979 be moved to L2?

JMann: we could open another bug regarding the note text.

<richardschwerdtfeger> RESOLUTION: move defect 23979 to L2 in line with the resolution to move drawCustomFocusRing to L2

next meeting date

Next meeting will be Monday Jan 6

Should scrollPathIntoView refer to fallback elements rather than "notional children" having a defined location?

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-canvas-api/2013OctDec/0045.html

RS: I like the term descendent
... do you want to change both of those?

JMunro: I would like to change to descendent, but the implementers should chime in.

JMann: notional child doesn't mean anything to me

RC: whatever language we use here needs to be copied to dCFR

RS: need to create a defect/bug to do that.

JMunro: I can do that.

RS: we'll talk about the scrolling issue at our next meeting.

Summary of Action Items

[NEW] ACTION: Rich Open bug against 2D Canvas for drawSystemFocusRing to inform assistive technologies of the location event when it does not have focus [recorded in http://www.w3.org/2013/12/16-html-a11y-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/12/17 00:13:37 $