- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 31 Aug 2012 11:09:59 -0500
- To: Sam Ruby <rubys@intertwingly.net>
- 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
- Message-ID: <OF9D1699D5.F9C45F11-ON86257A6B.0056FF3F-86257A6B.0058CD6E@us.ibm.com>
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 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
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 31 August 2012 16:10:47 UTC