This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per Issue 74, we need an API that will let a magnifer be notified of caret screen location changes in response to editable text form elements in the Canvas DOM sub tree.
This seems to be covered by http://www.w3.org/html/wg/tracker/issues/131
Bug triage sub-team thinks this bug is providing additional details on 10964, which was raised just at the Last Call cutoff deadline with the understanding that more precise information would be filed later. This bug constitutes part of that information and therefore we think this should be considered a pre-LC bug. Also note that this bug relates to ISSUE-131 http://www.w3.org/html/wg/tracker/issues/131 and arguably ISSUE-74 http://www.w3.org/html/wg/tracker/issues/74.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: no spec change Rationale: As far as I can tell drawFocusRing() already does this.
Ian, the spec. merges caret and focus ring. We don't want that for reasons stated. The group needs to reach consensus on the revision which it has not done. Yet, you keep closing it and wasting our time. Give the canvas subteam a chance to send in the revised proposal. Let it be reviewed by the working group before closing this. We can only move this to tracker request when we have a final proposal on the table. Seriously, if you want to participate in the discussion we have meetings every Monday.
Richard, it seems this bug is already covered by ISSUE-131: http://www.w3.org/html/wg/tracker/issues/131 More generally, if the editor has given a disposition and someone else wants to provide new information in the future, it's correct for the bug to stay resolved in the meantime. For these reasons, I'm making the following changes: 1) Moving bug back to RESOLVED/WORKSFORME 2) Adding TrackerIssue keyword 3) Moving to pre-LC component, since this is covered by a pre-LC issue resulting from older bugs
(In reply to comment #3) > Rationale: As far as I can tell drawFocusRing() already does this. drawFocusRing does not include line height attributes for caret tracking; it only includes an x, y position. Caret height is used by some AT software to better indicate the position of the caret. For example, arrows may be positioned above and below the caret height to better indicate the current position of the caret. This is not covered by drawFocusRing. For caret tracking, it's unnecessary to redraw the focus path each time that the x, y position of caret needs to be updated. I'm not sure what the consensus is on Issue #131 Is the editor supportive of that issue?
I would add that in all accessibility services layers caret is separated from a focus ring or rectangle in an object. Placing an X, Y coordinate for the caret position in the focus ring is confusing. We have a change proposal to canvas that we are working on that eliminates the X,Y coordinate from drawFocusRing(). Also, we have a new caret/selection position API modification to the canvas2DDrawingAPI. We are trying to decide if this is the best place for this API as we will also need this functionality for SVG.
Charles: the status of issue 131 is that it is awaiting proposals: http://lists.w3.org/Archives/Public/public-html/2011Jan/0200.html Please feel free to submit one. Meanwhile, please do NOT reopen bugs that have already been escalated as an issue.
(In reply to comment #9) > Please feel free to submit one. Meanwhile, please do NOT reopen bugs that have > already been escalated as an issue. Is "WORKSFORME" an appropriate sub-status? I may be picking nits here, but it seems like "DUPLICATE" is a better fit. I re-opened specifically because of the WORKSFORME status as stated by the editor.
OK. duplicate of Issue 131
Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html
(In reply to comment #12) > Working Group Decision: In relation to this decision: * The change to add baseline to the TextMetric interface is not adopted. "... noted the editor's question 'which baseline?'" Naseline properties are defined by the textBaseline section of the existing specification. When an author sets textBaseline to a value, that is the baseline which would be used for the TextMetric.baseline property. Such information is easily accessible to implementers, see for example, drawTextInternal http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp The value is calculated from a combination of the ascent, descent and font height metrics. In relation to this decision: * The change to remove the canDrawCustom parameter from drawFocusRing is not adopted. It's my understanding that such a parameter would be specified via CSS, such as the css outline property, as is done on other HTML elements when they are focused. As in HTML, authors are not guaranteed that the UA/AT will "skip" drawing focus indicators. canDrawCustom seems only to duplicate the already existing semantics CSS provides.
I'm not sure I fully understand this decision. How am I intended to apply the exceptions? For example, what is the return value of drawFocusRing()?
No changes need to be made. The function, in its entirety, is broken. Please see my post for clarification: http://lists.w3.org/Archives/Public/public-html/2011Apr/0394.html
> In relation to this decision: > * The change to remove the canDrawCustom parameter from drawFocusRing > is not adopted. > > It's my understanding that such a parameter would be specified via CSS, such as > the css outline property, as is done on other HTML elements when they are Richard reminded me that the author can simply change the strokeStyle if they do not want the UA to draw a [visible] focus ring. Ian, is there a question about that?
I don't understand comment 15 and comment 16.
(In reply to comment #17) > I don't understand comment 15 and comment 16. "The drawFocusRing(element) method, when invoked, must run the following steps: ... If the user has configured the operating system to draw focus rings in a certain way (e.g. high-contrast focus rings), then the user agent should draw a focus ring of the appropriate style along the drawing path otherwise the user agent must draw the focus ring based on the canvas line drawing settings along the current drawing path."
(In reply to comment #13) > (In reply to comment #12) > > Working Group Decision: > > In relation to this decision: > * The change to add baseline to the TextMetric interface is not adopted. > "... noted the editor's question 'which baseline?'" Implementing TextMetric baseline in Mozilla: https://hg.mozilla.org/mozilla-central/file/ec809c159ad2/content/canvas/src/nsCanvasRenderingContext2D.cpp DrawOrMeasureText gfxFloat anchorY Lines 2745 through 2767. TextMetrics.baseline returns anchorY.
(In reply to comment #14) > I'm not sure I fully understand this decision. How am I intended to apply the > exceptions? For example, what is the return value of drawFocusRing()? In general, if you are in doubt about how to correctly apply the decision, the recommended approach would be to post a diff to the WG for review. You have pointed outelswhere that there is both a list of bullet point changes and spec text, and it's not necessarily clear which takes priority, so there could understandably be ambiguity. Informally, on this specific issue, I think the reasonable thing to do is to treat the return value as tied to the canDrawFocusRing parameter, since that seems to be the case on a technical level. But in any case, posting a diff up front should ensure that there is no misunderstanding.
So I started doing as suggested in comment 20, and basically guess at what changes I had to make, but I still couldn't do it. There are a number of changes in [1] that are simply unsupported by the CP and not mentioned by the decision [2], and which seem to me to be either unintentional mistakes or simply nonsensical. For example: - The new API fails to handle magnification for interactive graphics that don't have a caret or selection, e.g. check boxes. Magnification only seems to occur if the script calls setCaretSelectionRect(). - drawFocusRing() is described sometimes as only working if the focused element is what is passed to the method, and sometimes as working even if the element passed to the method has a focused ancestor, even if the ancestor is also an ancestor of the <canvas> itself (e.g. <body>). - caretBlinkRate() is defined to return a rate in milliseconds, which doesn't make sense. - caretBlinkRate() is required to return a non-specified negative value in certain cases. This is an interoperability nightmare. - The example is far bigger than could possibly be useful. - The example in the proposed text is explicitly marked as needing changes! - The proposed spec text uses terms like "rectangular left edge" which are meaningless (a side's edge can't be rectangular, by definition). - The "selection position" term's definition doesn't handle bidi. - The caret API isn't sufficient for addressing modern accessibility and internationalisation needs, because it requires that the caret blinking be drawn by the app, which means it can't support Windows accessibility wide carets, bidi carets, or indeed anything other than what the author draws (e.g. on RISCOS an app wouldn't follow the platform-specific caret convention). - The entire caret aspect of this API simply won't work, because it doesn't do anything useful for authors who aren't trying to address accessibility issues. We know this is a problem, just look at longdesc. - The RFC2119 requirements make no sense. For example, there is a "must" requirement on what authors are to render! I've tried to get answers about these things from the chairs, but without much luck. At one point Maciej even said "I guess I should have read the text". It is simply absurd that decisions would be made by people who are not even reading the proposals. I cannot in good faith make this edit. It's not that I disagree with the decision, it's that the decision makes no sense. (For the record, there's also some issues that I disagree with and that I think are poor design, but that aren't nonsensical: - caretBlinkRate() is a method, not an attribute. - caretBlinkRate() only returns one number, whereas a blinking behaviour needs two numbers to be fully described, and that's assuming simple blinking carets. - The "caret position" term clashes with an existing term in the HTML spec. These wouldn't stop me making the edit, though; I'd just file bugs on them or put up with them, as I have with some of the other decisions.) [1] http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0657/canvascarseldecision20110426.html#dom-context-2d-setCaretSelectionRect [2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html
Blink rates on all OS platforms return a rate in milliseconds. They do not return two values. A negative number is means there is no setting in the OS applied. What is the problem?
(In reply to comment #22) > Blink rates on all OS platforms return a rate in milliseconds. They do not > return two values. A time in milliseconds is not a rate. It's an interval. Rates are in Hertz (or some other unit with dimension [1/T]). The proposal doesn't say what the return value is other than to say it must be a rate and must be in milliseconds, which is self-contradictory and leaves the reader wondering what the number means: the complete period, a half period, the time the caret is on, the time the caret is off, the frequency? It's simply not defined well enough to be interoperably implementable. > A negative number is means there is no setting in the OS applied. What is the > problem? Which negative number? We can't leave things undefined. It's not 1995 any more. (Also, how can the OS not have a blink rate? Do you have an example of such an OS?)
(In reply to comment #23) > (In reply to comment #22) > > Blink rates on all OS platforms return a rate in milliseconds. They do not > > return two values. > > A time in milliseconds is not a rate. It's an interval. Rates are in Hertz (or > some other unit with dimension [1/T]). The proposal doesn't say what the return > value is other than to say it must be a rate and must be in milliseconds, which > is self-contradictory and leaves the reader wondering what the number means: > the complete period, a half period, the time the caret is on, the time the > caret is off, the frequency? It's simply not defined well enough to be > interoperably implementable. > For what it's worth, the relevant setting on Mac OS X is called NSTextInsertionPointBlinkPeriod and on Windows it's called CursorBlinkRate. There are also APIs that call it "CaretBlinkTime". This seems to be informally referred to as the "caret blink rate" in developer docs, even though logically that may be a misnomer. Though no one objected on the basis of interval vs. rate, if you and Rich agree that the property should be named something with Time, Period or Interval rather than Rate, then I don't foresee a problem with that.
Ian, I don't have a problem with calling it caretBlinkInterval or caretBlinkPeriod. Ian, you are welcome to choose one of the two names. We will just need to educate authors on the new name as neither is similar to existing OS settings.
Created attachment 979 [details] attempt at applying decision
Per Ian's comments, the drawFocusRing example should be updated. The example provided has additional arguments and other content designed for compatibility and testing in existing implementations and can be simplified when targeting the CP.
Created attachment 980 [details] attempt at applying decision
Created attachment 981 [details] attempt at applying decision
- I accept the changes for caretBlinkPeriod. - I have not tried the code change the editor has made, when I see the full change I will try it out. We had found defects in the prior code which did not run and we added commments. Please refer to the change request adapted for the chairs decision at it: http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html If the editor could adapt his changes to our code it would run and pick up the performance issues addressed by the editor. The changes to drawFocusRing are still inaccurate for these reasons: - DrawFocusRing must be able to draw a focus ring around an element with focus or descendant of an element with focus. Often, in rich internet applications an element with focus will managed visual rendering of focus for its children. Examples of this are grids, radio groups, listboxes, and tree widgets. See the text in: http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html A note to the editor: In the canvas subtree authors can use aria-activedescendant on one of these element to convey the focus location of a descendant to an assistive technology. example: <table role="grid" aria-activedescendant="foo"> ... <tr role="row"> <td role="gridcell" id="foo"> ... </tr> ... </table> - caretSelectionPos still has some problems. I don't have an issue with the name change or the use of a path to produce the rectangle -- The accessibility API mapping must step must be provided. -- The text does not address when the user agent window is moved or resized Please see the steps in the change proposal: http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0657/canvascarseldecision20110426.html#caret-selection
Ian, can you provide a revised diff that addresses these comments? (In reply to comment #30) > - I accept the changes for caretBlinkPeriod. > - I have not tried the code change the editor has made, when I see the full > change I will try it out. We had found defects in the prior code which did not > run and we added commments. Please refer to the change request adapted for the > chairs decision at it: > http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html > If the editor could adapt his changes to our code it would run and pick up the > performance issues addressed by the editor. > > The changes to drawFocusRing are still inaccurate for these reasons: > > - DrawFocusRing must be able to draw a focus ring around an element with focus > or descendant of an element with focus. Often, in rich internet applications an > element with focus will managed visual rendering of focus for its children. > Examples of this are grids, radio groups, listboxes, and tree widgets. > > See the text in: > http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html > > A note to the editor: > In the canvas subtree authors can use aria-activedescendant on one of these > element to convey the focus location of a descendant to an assistive > technology. > > example: > <table role="grid" aria-activedescendant="foo"> > ... > <tr role="row"> > <td role="gridcell" id="foo"> ... </tr> > ... > </table> > > - caretSelectionPos still has some problems. I don't have an issue with the > name change or the use of a path to produce the rectangle > -- The accessibility API mapping must step must be provided. > -- The text does not address when the user agent window is moved or resized > > Please see the steps in the change proposal: > http://lists.w3.org/Archives/Public/public-html/2011Apr/att-0657/canvascarseldecision20110426.html#caret-selection
(In reply to comment #30) > - I have not tried the code change the editor has made, when I see the full > change I will try it out. We had found defects in the prior code which did not > run and we added commments. Please refer to the change request adapted for the > chairs decision at it: > http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html > If the editor could adapt his changes to our code it would run and pick up the > performance issues addressed by the editor. Could you be more specific? The code in the CP has multiple problems (as it in fact admits up-front), as does the code in the spec; the code in the patch is an attempt to address both sets of problems. > - DrawFocusRing must be able to draw a focus ring around an element with focus > or descendant of an element with focus. That makes no sense (it would mean that multiple elements would be rendered as having focus if, e.g., the <body> had focus), and is not supported by the CP. I don't think we should be making changes unsupported by the CP, and I don't think we should be making changes that break the API. > Often, in rich internet applications an > element with focus will managed visual rendering of focus for its children. Before I go through the examples, let me just say up front that trying to create any of these using <canvas> is simply inappropriate and that we should absolutely be pushing back on authors who try to do such things. We should not be promoting bad practices. > Examples of this are grids, In a grid, it is individual cells that would be focused, not the whole grid, when you want the focus ring around a single cell. This is already supported. > radio groups, Radio groups aren't focused, radio buttons are. This is already supported. > listboxes, In a list box, the focus ring is drawn around the list box, not the options, so this is already supported. > and tree widgets. I don't understand why tree widgets would be a problem here. If you want the focus ring around the whole tree widget, and you just focus the whole tree widget, that's what you would pass as an argument. If you have a tree widget where individual subparts get focus rings, then those are what get focused and those should be the ones you pass in. It again seems quite well supported. > A note to the editor: > In the canvas subtree authors can use aria-activedescendant on one of these > element to convey the focus location of a descendant to an assistive > technology. > > example: > <table role="grid" aria-activedescendant="foo"> > ... > <tr role="row"> > <td role="gridcell" id="foo"> ... </tr> > ... > </table> There's no need to use something as complicated as ARIA for this kind of thing. You can just use tabindex. > - caretSelectionPos still has some problems. I don't have an issue with the > name change or the use of a path to produce the rectangle > -- The accessibility API mapping must step must be provided. I strongly disagree. This is neither supported by the CP nor necessary. We should not be defining precise UI. > -- The text does not address when the user agent window is moved or resized It is unnecessary to even mention that windows exist. This is a UI implementation issue. It's only a problem in the spec if we make the text say how to implement UI, which we shouldn't in the first place.
(In reply to comment #32) > (In reply to comment #30) > > - DrawFocusRing must be able to draw a focus ring around an element with focus > > or descendant of an element with focus. > > That makes no sense (it would mean that multiple elements would be rendered as > having focus if, e.g., the <body> had focus), and is not supported by the CP. I > don't think we should be making changes unsupported by the CP, and I don't > think we should be making changes that break the API. I've seen this objection multiple times: what on earth are you referring to? Focus is restricted to the shadow dom, and can only be used when the canvas element or a descendant is in focus. Is there ambiguous wording in the CP? There's been no change (from what I recall) in that shadow+focus dynamic from the existing spec. It's implemented and tested by one vendor (MS) with WebKit slowly coming on board. > > Often, in rich internet applications an > > element with focus will managed visual rendering of focus for its children. > > Before I go through the examples, let me just say up front that trying to > create any of these using <canvas> is simply inappropriate and that we should > absolutely be pushing back on authors who try to do such things. We should not > be promoting bad practices. Your position of authority does not extend so far as to declare the <canvas> tag should not be used for visual rendering of children. This statement seems to discount the very purpose of the canvas shadow dom and drawFocusRing. I'm baffled by both of these replies, as you were clearly on board with drawFocusRing in your prior drafts of HTML Living. We're trying to promote GOOD practices, per WCAG 2.0. It'd be nice to have you on board with that intention. > Radio groups aren't focused, radio buttons are. This is already supported. > ... > In a list box, the focus ring is drawn around the list box, not the options, so > this is already supported. ... > I don't understand why tree widgets would be a problem here. If you want the > focus ring around the whole tree widget, and you just focus the whole tree > widget, that's what you would pass as an argument. If you have a tree widget > where individual subparts get focus rings, then those are what get focused and > those should be the ones you pass in. It again seems quite well supported. This seems to be an extension of the misunderstanding about the language in the CP regarding "focus" on descendants of the canvas element. Yes, it's quite well supported, and it is not a feature that the CP attempts to change. Perhaps this is just my misunderstanding of the situation, but it seems that both you and Richard are arguing the same point. > > > > A note to the editor: > > In the canvas subtree authors can use aria-activedescendant on one of these > > element to convey the focus location of a descendant to an assistive > > technology. > > > > example: > > <table role="grid" aria-activedescendant="foo"> > > ... > > <tr role="row"> > > <td role="gridcell" id="foo"> ... </tr> > > ... > > </table> > > There's no need to use something as complicated as ARIA for this kind of thing. > You can just use tabindex. That's absurd -- this grid example is widely used in ARIA docs -- the purpose is to allow a user to press arrow keys on their keyboard, to change focus. There's little reason for the merits of ARIA itself to be challenged in this post. > > -- The accessibility API mapping must step must be provided. > > I strongly disagree. This is neither supported by the CP nor necessary. We > should not be defining precise UI. Are you disagreeing with this latter point? > > -- The text does not address when the user agent window is moved or resized > > It is unnecessary to even mention that windows exist. This is a UI > implementation issue. It's only a problem in the spec if we make the text say > how to implement UI, which we shouldn't in the first place. Again, you are challenging the purpose of ARIA itself, and related, WCAG standards. These are required by U.S. law, and their absence is an active attempt at stifling competition. I appreciate your intent, and your role in the community, but you are unwittingly misusing your authority as the only editor of the HTML5 spec. Again, I'm willing to say that I may be misunderstanding the situation -- but by and large, these implementation mentions are directly related to accessibility -- the primary purpose of the CP. Universal design requires active participation from the author -- a point you seem to disagree with. Where are your credentials in accessibility, to back these statements? At present, your hope that the entirety of a11y can be handled without active author involvement is misguided and arguably, under-informed.
(In reply to comment #33) > > > > Before I go through the examples, let me just say up front that trying to > > create any of these using <canvas> is simply inappropriate and that we should > > absolutely be pushing back on authors who try to do such things. We should not > > be promoting bad practices. > > Your position of authority does not extend so far as to declare the <canvas> > tag should not be used for visual rendering of children. This statement seems > to discount the very purpose of the canvas shadow dom and drawFocusRing. I'm > baffled by both of these replies, as you were clearly on board with > drawFocusRing in your prior drafts of HTML Living. drawFocusRing() is fine for things like buttons, which one could legitimately expect to see on a canvas. But UI beyond anything as simple as a button quickly becomes highly inappropriate. <canvas> isn't supposed to replace HTML. I really don't understand why anyone who considers themselves to be advocates of accessibility would even remotely want to encourage authoring practices such as implementing entire tree widgets, grids, text editors, or list boxes inside <canvas>. > We're trying to promote GOOD practices, per WCAG 2.0. It'd be nice to have you > on board with that intention. I'm trying to promote GOOD practices too. It'd be really nice to have _you_ on board with that intention. Apparently we disagree about what is a good practice.
(In reply to comment #34) > drawFocusRing() is fine for things like buttons, which one could legitimately > expect to see on a canvas. But UI beyond anything as simple as a button quickly > becomes highly inappropriate. What standard are you following in these claims? The HTML Forms select element is quite commonly re-implemented by other methods, such as div tags mixed with ARIA attributes. Your claim comes with no sources nor technical reasoning, nor is it particularly on the topic of the change proposal. > <canvas> isn't supposed to replace HTML. I really don't understand why anyone > who considers themselves to be advocates of accessibility would even remotely > want to encourage authoring practices such as implementing entire tree widgets, > grids, text editors, or list boxes inside <canvas>. The grid example uses HTML. Canvas is an HTML tag. Advocates of accessibility engage in the ARIA standard and the WCAG document, by definition. If you would like to understand, I recommend reviewing WAI documents. Whatever motivations that accessibility vendors, and general web app vendors have for using canvas as a method for progressive enhancement, is really not under your purview. An example I often bring up: When Mozilla decides to castigate its Bespin authors, that's an internal decision. If they take that policy further, and "push back" against other entities, it's an act of hegemony. > > > We're trying to promote GOOD practices, per WCAG 2.0. It'd be nice to have you > > on board with that intention. > > I'm trying to promote GOOD practices too. It'd be really nice to have _you_ on > board with that intention. Apparently we disagree about what is a good > practice. I've put citations forward in my arguments; you have not. Regardless, we're trying to accomplish the items outlined in this CP, for the sake of assistive technology. You've often claimed that such support can be handled automatically. I disagree. It must be handled with intent. Your opinions about authors creating complex widgets, interaction with ATs and the ARIA spec, are lacking authority. Please provide citations, lest you under-serve the community and the arguments we've been carrying for a good part of the last twelve months.
Ian, I am not going to go point by point with you and waste another hour of my day on what was already agreed upon by the chairs. It is a common practice to have Rich Internet Application components manage the visual focus for the descendants they manage. The intent of drawFocusRing is to allow elements that have focus to show visible focus and for those elements to show the visual focus around the child that they manage. This happens in UI component libraries, like Dojo. To illustrate further, while I understand that keyboard focus is on a tree widget the visual focus should be on the descendant that it manages. When you operate a tree widget you are not visually operating on the container yet the author has given a visual point of regard on the managed descendant. This is indeed consistent with WCAG 2. Authors can then use aria-activedescendant to notify the assistive technology what child is the one they should operate on with focus. This works and it works in Chrome, Firefox, Safari, and IE. I can provide you numerous code examples from the Open Ajax Alliance that we will be using for browser testing for ARIA. There is nothing wrong with this authoring practice and it is used extensively throughout the Web. Since the canvas subtree is being used to generate the accessibility API mapping in browsers and these are common and accepted authoring practices that are also accessible and supported accessibly on multiple browsers then canvas's drawFocusRing must support this functionality. Now, if your concern is over the name "focus" in drawFocusRing I would support a name change or some clarity in its description. If this is unacceptable you are welcome to open a defect post last call but the capability to support drawing of a visible focus ring or point of regard must be supported for accessibility. For the record, my job is not to promote idealistic authoring practices. My job is to ensure that authors have the tools to produce accessible solutions as consistent with their development goals as is technically possible.
Hi Rich, (In reply to comment #36) > Ian, > > I am not going to go point by point with you and waste another hour of my day > on what was already agreed upon by the chairs. > > It is a common practice to have Rich Internet Application components manage the > visual focus for the descendants they manage. The intent of drawFocusRing is to > allow elements that have focus to show visible focus and for those elements to > show the visual focus around the child that they manage. This happens in UI > component libraries, like Dojo. > > To illustrate further, while I understand that keyboard focus is on a tree > widget the visual focus should be on the descendant that it manages. When you > operate a tree widget you are not visually operating on the container yet the > author has given a visual point of regard on the managed descendant. This is > indeed consistent with WCAG 2. Authors can then use aria-activedescendant to > notify the assistive technology what child is the one they should operate on > with focus. This works and it works in Chrome, Firefox, Safari, and IE. I can > provide you numerous code examples from the Open Ajax Alliance that we will be > using for browser testing for ARIA. It is indeed the case that complex widgets often have a "point of regard" that is more fine-grained than the element with focus. However, on operating systems I am familiar with, it is not normal to draw a focus ring with the standard system look in such a case. For example, on Mac OS X, the keyboard-active item in a tree view is drawn selected, not with the blue glowing focus ring that represents focus. Perhaps a new API is needed is needed for this use car, since using drawFocusRing to indicate focus of an individual tree or grid item would result in visually wrong behavior. > > There is nothing wrong with this authoring practice and it is used extensively > throughout the Web. Since the canvas subtree is being used to generate the > accessibility API mapping in browsers and these are common and accepted > authoring practices that are also accessible and supported accessibly on > multiple browsers then canvas's drawFocusRing must support this functionality. > > Now, if your concern is over the name "focus" in drawFocusRing I would support > a name change or some clarity in its description. I think the problem is not just the name, but the behavior. It is actually specified to draw a focused appearance. That is not done for aria-activedescendant type point-of-regard items, either in Web content or in native apps. Drawing focus rings around two separate items would violate the Mac OS X HI guidelines. Do you agree that this is an issue? If so, can we agree on a separate mechanism to identify a "point of regard" that is not actually meant to be drawn with focused appearance? If not, then I guess we will have to address it via a Last Call comment.
(In reply to comment #37) > Hi Rich, > > > I think the problem is not just the name, but the behavior. It is actually > specified to draw a focused appearance. That is not done for > aria-activedescendant type point-of-regard items, either in Web content or in > native apps. Drawing focus rings around two separate items would violate the > Mac OS X HI guidelines. > > Do you agree that this is an issue? If so, can we agree on a separate mechanism > to identify a "point of regard" that is not actually meant to be drawn with > focused appearance? If not, then I guess we will have to address it via a Last > Call comment. Another thing to note: the setCaretSelection API can already be used to identify a magnifier-relevant point of regard without drawing a focus ring or changing focus, so despite the name, it seems like it would address the aria-activedescendant use case. What do you think?
I noticed that the Change Proposals says that the Accessibility API Mappings document should give the full details of how selection and focus are mapped to accessibility APIs. I filed the following bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12604 It seems like details of connecting to accessibility APIs are more in scope for the Accessibility API Mappings document. Would it make sense to ask Steve to add them there?
Created attachment 982 [details] attempt at applying decision
To illustrate what I'm attaching two examples of a focused Mac OS X table view with a sub-item as the current "point of regard". When nothing is selected for editing, the table view has focus. When a cell is selected for editing, the cell has focus. At no time do two different things have focus.
Created attachment 983 [details] Table view - cells selected but not focused
Created attachment 984 [details] Table view - cell focused for editing
Hi Maciej, Incidentally, I am at Apple this week if you would like to discuss this in person we can do that. How aria-activdescendant works is that aria-activedescendant sends a focus change to the assistive technology. This focus does not match DOM focus and perhaps there is some of the confusion. This notifies the AT of the point of regard. The proposal specifies that the focus ring be drawn consistent with the element type. So, if an element (menu item), does not support operating system conventions for focus ring then, as in my proposal, would use the drawing ring they provided in the drawing path. An example of this might be the Mac system menu whereby when the menu is dropped a focus ring is not drawn for the menu item. If you see a flaw in this we could put together a point of regard function. As for the caret selection function solving the activedescendant problem. Magnifiers are not accustomed to using it for that purpose. The semantics don't quite match in that a magnifier will position the magnification point based on: - they type of element (which they will get) - the state the element is in - the type of event being generated (caret/selection/focus) - the dimensions of the caret/selection. ... but they might be able to make this work for these reasons: - they have the element and thus the corresponding semantics (role) - they have the states of the element (selected, checked, etc.) - the dimensions (as we do provide a rectangle) - logical caret/selection/focus events are generated from the accessibility API The two challenges/changes we would need to have are: - We will not know if the rectangle being passed is a bounding rectangle or caret/selection position. We would need to add another parameter to the call and change the name. Something like: setPointofRegard(x, y, w, h, element, type); type = caretpos/selectionpos/bounds - Since this is canvas we will need the author to be able to draw different shapes than rectangles. So, we would need to set up the draw path like we do for drawFocusRing().
A major I have with Ian's latest patch is that it removes notification of the point of regard for managed descendants of the focused element that was provided for in the chair's decision. After meeting with Maciej, the general issue is that although the proposed changes to drawFocusRing() would work for both focused elements and activedescendants (managed descendents) for drawing the "point of regard" it would be clearer to separate the functionality of drawing a the active descendant into a separate method. This, for example, would be clearer to Mac developers. This issue, combined with the fact that there are issues raised with canDrawCustom that prevents a magnifier from being notified that I have raised to the chairs (http://lists.w3.org/Archives/Public/public-html/2011Apr/0394.html), that if we were to apply the new method now and the changes Ian's changes to drawFocusRing that it would obfuscate the issues we are having with canDrawCustom. I would like to note that I have added clarity on the points I made to the decision in the change proposal as seen here: http://lists.w3.org/Archives/Public/public-html/2011Apr/0423.html Therefore, I would ask that: - Ian apply the deltas described in http://lists.w3.org/Archives/Public/public-html/2011Apr/0657.html to drawFocusRing and setCaretSelectionPos - Maciej open a separate bug on drawFocusRing to separate out rendering of the activedescendant point of regard.I will develop a change proposal and review it with Maciej. I am OK with Ian's changes to acquiring the blink period.
(In reply to comment #45) > A major I have with Ian's latest patch is that it removes notification of the > point of regard for managed descendants of the focused element that was > provided for in the chair's decision. The normative text in my diff in this regard is the same as in your proposed text, and is consistent with the CP details list (which is what the chairs decided on the chairs have stated they did not read your proposed diff text prior to the decision). I strenuously object to this retroactive attempt at changing the decision. > This issue, combined with the fact that there are issues raised with > canDrawCustom that prevents a magnifier from being notified I think you misunderstand how the API works. I'm happy to try to clarify it, but I really don't understand how you think the API works so it's not easy for me to clarify it for you.
Let me explain. When you removed the point in the process that allowed a ring to be wrong when it was not a descendant of the focused element things broke. Here is why it is broken: <div role="grid" tabindex="0" aria-activedescendant="idz"> ... <div role="row"> ... <span id="idz" role="gridcell"> ... </div> </div> In this scenario the container grid managed the visual point of regard for the descendant gridcell. DOM focus is on the grid and the active descendant is the gridcell. When the id of the activedescendant changes a system focus change is sent to the assistive technology which processes the new active descendant. This is very similar to desktop applications. Now, an author could also implement a roving tabindex on gridcells in which case what you have would mostly work. Now, in general active children (managed children) do not always use system conventions for drawing a focus (Maciej's earlier point) and it would be more intuitive to separate out this function. So, to separate them out we would enter a separate bug against the chairs decision which would remove limit drawFocusRing to only drawing rings on focus elements and create a separate function that is something like drawPointofRegard or drawNonFocusRing that only deals with managed children. I don't want to start separating them out now, by making your change to eliminate the active descendant on drawFocusRing, as it would obfuscate the error in the next paragraph. The other problem we have and which I have asked the chairs to review is the issue with canDrawCustom. If the system does not provide a setting for drawing focus rings in a certain way and the author sets the canCrawCustom flag then drawFocusRing does nothing to allow the author to draw the custom ring. However, doing nothing also means that the magnifier is not notified where the point of regard is and the low vision user will be unable to track their location. Our change proposal required an author to configure the drawing path and the style before drawFocusRing was called. If the system did not have a feature that drew focus rings for the element type in a certain way then the custom ring would be drawn and the magnifier would be notified. If the OS did have a feature that was applied to draw a focus ring a certain way then the user agent would apply that styling instead. Does that help? If we still have a disconnect then sure I would be happy to talk.
(In reply to comment #47) > Let me explain. When you removed the point in the process that allowed a ring > to be wrong when it was not a descendant of the focused element things broke. I didn't remove any such thing, it was never there. Neither your diff's normatice text nor the CP nor the chair decision do anything that allows you to pass a descendant of the focused element to drawFocusRing(). > Here is why it is broken: > > <div role="grid" tabindex="0" aria-activedescendant="idz"> > ... > <div role="row"> > ... <span id="idz" role="gridcell"> > ... > </div> > </div> > > In this scenario the container grid managed the visual point of regard for the > descendant gridcell. And this works fine with the spec as written. You draw the path around the grid, then call drawFocusRing() to render the focus ring around the grid (as seen in attachment 983 [details]), and then you use setCaretSelectionPos() and give it the x,y,w,h of the rectangle that is the "visual point of regard". In both cases, the element you pass is the focused grid element. > So, to separate them out we would enter a separate bug against the chairs > decision which would remove limit drawFocusRing to only drawing rings on focus > elements and create a separate function that is something like > drawPointofRegard or drawNonFocusRing that only deals with managed children. That's exactly what this decision did. It provides drawFocusRing() for the focus, and setCaretSelectionPos() for the "visual point of regard". > The other problem we have and which I have asked the chairs to review is the > issue with canDrawCustom. If the system does not provide a setting for drawing > focus rings in a certain way and the author sets the canCrawCustom flag then > drawFocusRing does nothing to allow the author to draw the custom ring. It doesn't do nothing. It still notifies the accessibility API. That's the entire point of the API! > Our change proposal required an author to configure the drawing path and the > style before drawFocusRing was called. If the system did not have a feature > that drew focus rings for the element type in a certain way then the custom > ring would be drawn [...] Which is a huge problem, because it only handles custom focus rings that can be drawn with a single stroke() call, which is completely inadequate. Custom focus might be handled by just drawing the text in a different font size, by using a variety of colours, by drawing an arrow, any number of different techniques. The whole point of the method is that it lets you draw the focus indicator as you want.
(In reply to comment #47) >> Let me explain. When you removed the point in the process that allowed a ring >> to be wrong when it was not a descendant of the focused element things broke. > >I didn't remove any such thing, it was never there. Neither your diff's >normatice text nor the CP nor the chair decision do anything that allows you to >pass a descendant of the focused element to drawFocusRing(). If you review my change proposal you will see that I allowed a focused element or a descendant of it to pass drawing the focus ring. The chairs did not exclude this from the decision. >> Here is why it is broken: >> >> <div role="grid" tabindex="0" aria-activedescendant="idz"> >> ... >> <div role="row"> >> ... <span id="idz" role="gridcell"> >> ... >> </div> >> </div> >> >> In this scenario the container grid managed the visual point of regard for the >> descendant gridcell. >And this works fine with the spec as written. You draw the path around the >grid, then call drawFocusRing() to render the focus ring around the grid (as >seen in attachment 983 [details]), and then you use setCaretSelectionPos() and >give it >the x,y,w,h of the rectangle that is the "visual point of regard". In both >cases, the element you pass is the focused grid element. OK. So, I discussed that with Maciej and we agreed that overloading something that drew a caret and selection position was a problem for authors. The second problem with this is that you were limiting the drawing of the focus rings to a rectangle was wrong. This was a comment that you and Josh Graham both told me would be a problem and that we should use a drawing path. The author might want a circle for all we know. I would prefer to create a separate function that allows for this and this would be part of a separate change proposal when we file a bug. This is what I thought Maciej and I agreed to in Cupertino last Friday. >> So, to separate them out we would enter a separate bug against the chairs >> decision which would remove limit drawFocusRing to only drawing rings on focus >> elements and create a separate function that is something like >> drawPointofRegard or drawNonFocusRing that only deals with managed children. > >That's exactly what this decision did. It provides drawFocusRing() for the >focus, and setCaretSelectionPos() for the "visual point of regard". Please see my point above. We are actually in violent agreement. The only difference is that we need to do this with a function that does not limit the drawing to a rectangle. >> The other problem we have and which I have asked the chairs to review is the >> issue with canDrawCustom. If the system does not provide a setting for drawing >> focus rings in a certain way and the author sets the canCrawCustom flag then >> drawFocusRing does nothing to allow the author to draw the custom ring. > >It doesn't do nothing. It still notifies the accessibility API. That's the >entire point of the API! But, that is not accurate. The author could say canDrawCustom, the function returns without drawing the focus ring and the author could create and draw an entirely new path that does not fit the one passed to the magnifier. Is that incorrect? >> Our change proposal required an author to configure the drawing path and the >> style before drawFocusRing was called. If the system did not have a feature >> that drew focus rings for the element type in a certain way then the custom >> ring would be drawn [...] > >Which is a huge problem, because it only handles custom focus rings that can be >drawn with a single stroke() call, which is completely inadequate. Custom focus >might be handled by just drawing the text in a different font size, by using a >variety of colours, by drawing an arrow, any number of different techniques. >The whole point of the method is that it lets you draw the focus indicator as >you want. Having a text be a different size is not a focus "ring". This sounds like a new requirement. Ian, the problem I want to avoid is dropping out of the function and allowing an author to then draw a custom ring that does not match the one generated in drawFocusRing().
The Chairs have issued their final decision on ISSUE-131 and this bug. Please see: http://lists.w3.org/Archives/Public/public-html/2011May/0138.html /paulc
> If you review my change proposal you will see that I allowed a focused element > or a descendant of it to pass drawing the focus ring. The chairs did not > exclude this from the decision. You really didn't. You might think you did, but that isn't what the diff's normative text said, and it's not what the "details" section of the CP said. > OK. So, I discussed that with Maciej and we agreed that overloading something > that drew a caret and selection position was a problem for authors. setCaretSelectionPos() doesn't draw a caret. All it does, in both your text and mine, is move the magnifier. > The second > problem with this is that you were limiting the drawing of the focus rings to a > rectangle was wrong. This was a comment that you and Josh Graham both told me > would be a problem and that we should use a drawing path. The author might want > a circle for all we know. I have no idea what you're referring to here. No version of drawFocusRing() has ever been limited to rectangles. > Please see my point above. We are actually in violent agreement. The only > difference is that we need to do this with a function that does not limit the > drawing to a rectangle. There is nothing limiting anything to a rectangle except the function that moves the magnifier (which is a rectangle purely because that's what accessibility tools _do_, there's not much point trying to magnify a circle or whatnot if the magnifiers don't do that). > But, that is not accurate. The author could say canDrawCustom, the function > returns without drawing the focus ring and the author could create and draw an > entirely new path that does not fit the one passed to the magnifier. Is that > incorrect? It would be a pointless use of the function. The whole point of the function is to indicate to the accessibility APIs what area is going to be focused, and allow users who need special focus rings to get their focus rings, while other users can get the author's preferred look. > Having a text be a different size is not a focus "ring". This sounds like a new > requirement. Yet it's how many games (the main use case for canvas) draw focus when the user doesn't need custom focus rings. > Ian, the problem I want to avoid is dropping out of the function > and allowing an author to then draw a custom ring that does not match the one > generated in drawFocusRing(). That makes no sense. The whole point of the API is to allow that.
Marking FIXED since chair decision was applied.