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

Thank you for the feedback Maciej. I will create a change based on the new
version of the specification. I will work to address the focus ring
concerns the chairs stated per the last decision. This will also take into
account what Ian has written in the WhatWG spec. for FocusRing().

In the interest of not having to generate multiple change proposals on
canvas, may I also include changes to address these two bugs I logged or
must that also be a separate change proposal?

These are the bugs:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13181
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176

Jonas Sicking has a proposal is close to what I had been asking for on the
list. I would like to work with Jonas to incorporate what he is changing
into the same change proposal:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html

In parallel, I am working with Doug Schepers and the SVG working group to
advance SVG accessibility.

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Maciej Stachowiak <mjs@apple.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Sam Ruby <rubys@intertwingly.net>, 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, public-html-a11y-request@w3.org
Date:	07/21/2011 02:39 AM
Subject:	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
      >