Re: CfC: Close ISSUE-131: caret-location-api by Amicable Resolution

Chairs -

I object to moving the hit testing proposal, we agreed on, until
While there is not sufficient use of rich text editing on canvas today, low
vision users MUST be able to zoom to any drawing object on a canvas as at
large magnification levels a low vision user will not be able to zoom to
these drawing objects, as they are off screen, without knowledge of their
location. Users must be able to do this without moving they keyboard focus
much the same way you and I visually browse a web page. This problem is
exacerbated if the user also has a mobility impairment as their alternative
input assistive technology must be able to locate the objects to move to
them. Furthermore, a screen reader user uses this information to construct
their virtual model of the screen for browsing and it is essential in order
to construct a Braille user interface. The provision of screen location
information of objects is a fundamental feature of accessibility API on
every operating system platform. Not having this feature severely harm a
low vision users ability to access canvas.

This change also meets the need to provide an a mainstream value add
without additional accessibility API work required by the author.

Although the chairs seemingly have tied the two issues together they are
indeed separate.

Issue 131 has to do with caret tracking and selecting of rich text content,
by a magnifier, while a low vision person is editing text to be able to
zoom around the point of regard. Given the limited used of rich text
editing in canvas it was acceptable to move this to

I hope the reason for my objection is clear and that the chairs now
understand why the two issues must be separated.

Rich Schwerdtfeger

From:	Sam Ruby <>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS, " WG"
Cc:	Frank Olivier <>,
            "" <>
Date:	08/31/2012 07:04 AM
Subject:	Re: CfC: Close ISSUE-131: caret-location-api by Amicable

On 08/22/2012 09:07 AM, Sam Ruby wrote:
> On 08/02/2012 12:59 PM, Richard Schwerdtfeger wrote:
>> */For these reasons I would ask that the chairs move issue 131 to
>> and save proposal
>> /**/
>> for
>> review at that time. This will give more time for canvas,
>> contenteditable, web-based IME support, and cross-cutting accessibility
>> support to develop and mature. If the chairs agree to then I would
>> support the chairs decision for HTML5 as a temporary one requiring
>> greater view in the next version, otherwise I will need to formally
>> object to the chairs decision.
> We previously vacated the original issue 131 decision, reopened the
> issue, and allowed changes to be made:
> Now Richard is asking that we effectively consider his proposal
> withdrawn for the HTML5 time frame.  Frank has also agreed to postpone
> this to
> Given that no active proposals remain, the chairs are now asking if
> there is consensus to roll back the hit testing proposal and to defer
> the feature to  If anybody would like to raise an objection
> during this time, we will require them to accompany their objection with
> a concrete and complete change proposal.
> If no objections are raised to this call by August 30th, 2012, we will
> direct the editors to make the proposed change, and will only consider
> subsequently reopening this issue based on new information and a
> complete change proposal based on the spec's contents as it exists after
> this change is applied.
> - Sam Ruby
> Note: while the process for has not been determined, people
> are welcome to publish proposals for what the spec should look like, and
> should any Working Group member chose to do so, we will make provisions
> to publish same on the W3C site (alongside any other proposals that may
> be made)

Hearing no objections, this call passes.  Issue 131 will now be closed.

- Sam Ruby

Received on Friday, 31 August 2012 16:10:47 UTC