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

Your text:

>  > 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 HTML.next.  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.

You refer to rolling back to the "hit testing" proposal. Issue 131 has to
do with caret/selection processing and not hit testing.

We should not roll back the hit testing proposal, Ted, Frank, and I agreed
on, until html.next. We need these changes in HTML5. Frank and I both
agreed to defer the caret/selection proposal for later discussion in
html.next.

You may have inadvertently put the two together. The hit testing proposal
refers to Issue 201. I was trying to clarify the two for the chairs.


Rich Schwerdtfeger



From:	Sam Ruby <rubys@intertwingly.net>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc:	Frank Olivier <Frank.Olivier@microsoft.com>,
            "public-html@w3.org WG" <public-html@w3.org>,
            "public-html-a11y@w3.org" <public-html-a11y@w3.org>,
            jbrewer@w3.org, janina@rednote.net
Date:	08/31/2012 11:59 AM
Subject:	Re: CfC: Close ISSUE-131: caret-location-api by Amicable
            Resolution



I'm confused.  I'll quote what the subject of this call for consensus
was on (the same text appears later in the very note that you forwarded):

>> On 08/02/2012 12:59 PM, Richard Schwerdtfeger wrote:
>>
>>> */For these reasons I would ask that the chairs move issue 131 to
>>> HTML.next

- Sam Ruby

On 08/31/2012 12:09 PM, Richard Schwerdtfeger wrote:
> Chairs -
>
> I object to moving the hit testing proposal, we agreed on, until
> html.next. 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 html.next.
>
> I hope the reason for my objection is clear and that the chairs now
> understand why the two issues must be separated.
>
> Rich Schwerdtfeger
>
> Inactive hide details for Sam Ruby ---08/31/2012 07:04:10 AM---On
> 08/22/2012 09:07 AM, Sam Ruby wrote: > On 08/02/2012 12:59 PMSam Ruby
> ---08/31/2012 07:04:10 AM---On 08/22/2012 09:07 AM, Sam Ruby wrote: > On
> 08/02/2012 12:59 PM, Richard Schwerdtfeger wrote:
>
> From: Sam Ruby <rubys@intertwingly.net>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS, "public-html@w3.org WG"
> <public-html@w3.org>,
> Cc: Frank Olivier <Frank.Olivier@microsoft.com>,
> "public-html-a11y@w3.org" <public-html-a11y@w3.org>
> Date: 08/31/2012 07:04 AM
> Subject: Re: CfC: Close ISSUE-131: caret-location-api by Amicable
Resolution
>
> ------------------------------------------------------------------------
>
>
>
> 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
>  >> HTML.next and save proposal
>
>> /*http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised*/
>  >> 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:
>  >
>  > http://lists.w3.org/Archives/Public/public-html/2011Dec/0059.html
>  >
>  > Now Richard is asking that we effectively consider his proposal
>  > withdrawn for the HTML5 time frame.  Frank has also agreed to postpone
>  > this to HTML.next:
>  >
>  > http://www.w3.org/2012/08/16-html-wg-minutes.html#item09
>  >
>  > 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 HTML.next.  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 HTML.next 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
>
>
>