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

ok. I will separte them out.

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Maciej Stachowiak <mjs@apple.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	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, Sam Ruby
            <rubys@intertwingly.net>, jonas@sicking.cc, chuck@jumis.com,
            Cynthia Shelly <cyns@microsoft.com>, jbrewer@w3.org,
            janina@rednote.net, mike@w3.org
Date:	07/22/2011 11:39 AM
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 Jul 22, 2011, at 7:24 AM, Richard Schwerdtfeger wrote:



      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().



Thank you.




      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



Those two bugs seem outside the scope of ISSUE-131 and are not even
resolved yet, so please do not mix them into this proposal.




      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

      <graycol.gif>Maciej Stachowiak ---07/21/2011 02:39:34 AM---Hi Rich,
      The Chairs discussed your reopen request. In order to properly
      evaluate your request to reo

      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
            >