Re: Issues the chairs overlooked in their review of the canvas accessibility API proposal for Issue 131

Hi Rich,

The Chairs discussed your reopen request. In order to properly evaluate your request to reopen based on new information, we need to see an updated Change Proposal. In particular, looking at the Change Proposal at <http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection>, we believe the following changes are necessary:

1) The Change Proposal needs to be written relative to a baseline of the current HTML Canvas 2D Context draft, not relative to the old specification. The Details section, both the prose description and the spec diffs, appear to be relative to the old spec. This makes it impossible for the Chairs or the Working Group to evaluate specifically the additional changes being proposed.

2) The Change Proposal needs to clearly identify what material is new information. It is not possible to tell from reading it which aspects are new information.

3) Any information contained in the response below needs to be folded into the Change Proposal as well.


Additionally, and as purely advisory notes at this time, I make the following suggestions:

4) The fact that Details are provided *both* as exact spec diffs *and* as a numbered list, and the fact that the two don't quite match, was a serious problem in the last round for this issue. Please consider providing only one of these, or if you must provide both, be very clear about which is normative and which is advisory, and make very sure that the two match exactly in all details. If your Change Proposal is found to have sufficient information to reopen the issue, it is very likely that this double description of the changes will be a focus for future review.

5) Full text of the spec with <ZZZ> inline markers is a format that makes it very hard to see specifically what changed, and which cannot be reviewed at a glance. If you must provide spec text diffs, consider using a format such as unified diff or side-by-side diff so the actual changes can be seen clearly.

6) I was unable to follow your responses below on the inconsistency and driving magnification. If you incorporate text along those lines into a Change Proposal, it is unlikely to make a compelling argument unless it is adjusted. Specifically:

    6.a) On the consistency issue, there doesn't seem to be any support for the statement, "this is consistent". The claimed inconsistency was that there is no way to draw a native-style selection or caret, while drawing native-style is forced for the focus ring. You reiterate these points, and then claim it is consistent. Why is this consistent? You may want to clarify this explanation when incorporating into the updated Change Proposal/

    6.b) On the matter of clarifying how your Change Proposal makes it impossible to draw focus without driving magnification, your response explains how the current spec makes this possible, but does not appear to explain why it would be impossible under your proposal. To a cursory review it seems completely possible. 

7) Your reference to section 508 would be stronger if you provided a link and/or a reference to a specific section. As things stand, it would be difficult for anyone to check the reference to verify what section 508 says for themselves.

Regards,
Maciej


On Apr 20, 2011, at 10:41 AM, Richard Schwerdtfeger wrote:

> 
> 
> Rich Schwerdtfeger
> CTO Accessibility Software Group
> 
> public-html-a11y-request@w3.org wrote on 04/18/2011 04:03:26 PM:
> 
> > From: Sam Ruby <rubys@intertwingly.net>
> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> > Cc: Maciej Stachowiak <mjs@apple.com>, Paul Cotton 
> > <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-
> > canvas-api-request@w3.org, public-html@w3.org, public-html-a11y@w3.org
> > Date: 04/18/2011 04:10 PM
> > Subject: Re: Issues the chairs overlooked in their review of the 
> > canvas accessibility API proposal for Issue 131
> > Sent by: public-html-a11y-request@w3.org
> > 
> > On 04/15/2011 04:01 PM, Richard Schwerdtfeger wrote:
> > > Hi Maciej,
> > >
> > > We have updated the original change request for Issue 131
> > > (http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection) include:
> > >
> > > - to include the 508 Rationale, etc.
> > > - to include a clarification the text baseline request. Note: in bug
> > > report 11239 we made a reference to Webkit code to see how the change
> > > would apply (Charles Pritchard on 4/13)
> > > - changed the return value for blink rate from an int to a WebIDL long.
> > > Ian had mentioned this to be an oversight on one of the discussion groups.
> > >
> > > Hopefully, that will address the chairs' concerns.
> > 
> > Looking at the decision, there is two remaining comments that have not 
> > been addressed:
> > 
> > > In addition, another objection to this aspect of the "Modify existing
> > > Canvas 2D API caret and focus ring support" was that it makes focus
> > > handling and caret selection inconsistent in an undesirable way;
> > > authors cannot go with all native-style drawing or all custom-drawing
> > > but would be forced to use a mix
> > 
> > We would like to request that the Change Proposal be updated to either 
> > showing that there is no inconsistency, or by giving the justification 
> > for the inconsistency.
> > 
> The current specification of drawFocusRing will draw the system focus ring if a system style is set and that a magnifier's zoom location can be driven by the call. However, if a system style for the focus ring is not set and canDrawCustom is passed the function returns with nothing is drawn and the magnifier is not notified of the focus ring to zoom to. The function returns and a custom ring is then drawn by the author without the ability to drive the magnifier. 
> 
> With the change proposal, the author is responsible for setting up the ring drawing style, for the path, prior to the drawFocusRing call. If the author uses drawFocusRing() as specified in the change proposal the user agent will draw the system style focus ring if such a setting exists, otherwise it will draw the custom focus ring configured before the call. Regardless of which styling is used along the drawing path the magnifier zoom will be driven by this call and the user agent will consistently use the system styling for focus ring if one exists (such as high contrast styling) and if such system setting does not exist the user agent will draw the focus ring styling specified by the author prior to the call. If there is no native styling then all custom drawing will be supported by the call and the magnifier will be able to track the user. 
> 
> As for caret tracking, neither the current specification or the change proposal effects the drawing of a caret or a selection position. This is consistent.
> 
> I will make sure these points are made in the change proposal.
> 
> > Additionally, the following was not found to make its case:
> > 
> > > DrawFocusRing does not ensure that the focus ring, drawn, allows
> > > the browser to follow focus ring conventions for the OS platform
> > > that may also reflect user's preferences
> > 
> > Can you clarify why the "Modify existing Canvas 2D API caret and focus 
> > ring support proposal" makes it impossible to draw focus without driving
> > magnification?
> > 
> Yes, that is made clear in the change proposal in Rationale bullet 2: "If the author sets canDrawCustom to true and the operating system has not specified out a focus ring is to be drawn, that drawing is turned over to the author. Therefore the specification allows the author to draw focus without driving magnification. "
> 
> Ordinary path drawing functions in canvas do not drive the magnifier and drawFocusRing can't drive a magnifier in the situation where it does not actually draw the focus ring as the author could actually draw the path elsewhere and magnification could not accurately follow the new location.
> 
> I will update the change proposal with this added text.
> 
> > - Sam Ruby
> > 
>