See also: IRC log
<trackbot> Date: 16 December 2013
<scribe> Meeting: HTML Accessibility Task Force Canvas Sub Group
<scribe> scribe: MarkS
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.
<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 will be Monday Jan 6
<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.