- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 22 Jul 2011 11:55:20 -0500
- To: public-html-a11y@w3.org, public-canvas-api@w3.org
- Cc: jbrewer@w3.org, chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>, david.bolter@gmail.com, faulkner.steve@gmail.com, jbrewer@w3.org
- Message-ID: <OFF8133199.53C178F6-ON862578D5.005CB147-862578D5.005CF4E6@us.ibm.com>
So, this is where we will go next on canvas. By take into account
(FocusRing) I am referring to considering what Ian has done. I have not
looked at the latest draft.
Rich
Rich Schwerdtfeger
CTO Accessibility Software Group
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/22/2011 11:52 AM
-----
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
>
Received on Friday, 22 July 2011 16:55:52 UTC