Re: Request to re-open issue 131

TL;DR: The set of methods approved by a chair decision earlier this year 
were reverted by the HTML5 editor and subsumed by new methods. These 
were done without discussion, but as there are no implementations, the 
decision was easily vacated.

http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html

drawFocusRing(element, canDrawCustom) was moved into two methods, 
instead of an optional boolean argument.
setCaretSelectionRect was moved into scrollPathIntoView, with some minor 
tweaks.
caretBlinkRate() was removed.

The only stable consensus at this point is that the checkbox in the 
following example should be reachable by .focus() and tab navigation.

<canvas><legend for="checkbox">Checkbox Item<legend><input id="checkbox" 
type="checkbox" tabindex="0" /></canvas>

This focusability has been in the HTML5 standard for quite some time, 
but was likely overlooked by implementers thinking the fallback content 
for <canvas> was irrelevant to implementations where <canvas> is supported.


Rest of reply is in thread.


On 12/9/11 8:08 PM, Sam Ruby wrote:
> On 12/09/2011 10:46 PM, Charles Pritchard wrote:
>> On 12/9/11 7:25 PM, Sam Ruby wrote:
>>> On 12/09/2011 05:42 PM, Richard Schwerdtfeger wrote:
>>>> I see Ian replaced the entire Canvas 2D API spec. without a formal
>>>> proposal:
>>>>
>>>> http://dev.w3.org/html5/2dcontext/
>>>
>>> Should a formal proposal not be forthcoming, and should you be able to
>>> obtain testimonials from at least two major implementors that that
>>> they would be willing to implement your proposal should it be adopted,
>>> then you have nothing to worry about. If you need to modify your
>>> Change Proposal(s) in order to obtain these testimonials, you have the
>>> opportunity to do so. We've not established a deadline yet for this,
>>> but the earliest deadline we would impose would be late January by
>>> this point. It could possibly even be later.
>>
>> I'm not intimately familiar with W3C processes -- but I must ask -- why
>> do you claim this action is "nothing to worry about"? The latest
>> revision reverts changes made by the chair decision "applied no later
>> than the end of day on the Thu 12th of May [2011]".
>> http://lists.w3.org/Archives/Public/public-html/2011May/0138.html
>
> The issue is now reopened, you can verify that status yourself:
>
> http://www.w3.org/html/wg/tracker/issues/131
>
> If, as I stated above, if there is no formal proposal that covers the 
> changes the editor has elected to make, and we obtain testimonials 
> that the changes that were previously proposed and were adopted would 
> be implemented, then I see absolutely no reason to believe that the 
> next time we close issue 131 that we will come to the same decision.
>
> Meanwhile, there is an opportunity to address one or both of the 
> exclusions.

I'm having a hard time parsing your syntax, I can't figure out which of 
the two subjects you are referring to.

There is the determination of the Chairs to "Modify existing Canvas 2D 
API caret and focus ring support to drive screen magnification":
http://lists.w3.org/Archives/Public/public-html/2011Apr/0271.html
http://www.w3.org/2002/09/wbs/40318/issue-131-objection-poll/results#xkeepnew

And there is the minor part of that decision where more clarification 
was needed:
"The change to add baseline to the TextMetric interface is not 
adopted... Proposals to add baseline measurement support can be 
considered if sufficient detail is provided"
http://lists.w3.org/Archives/Public/public-html/2011May/0351.html

The first subject involved several added methods to the Canvas 2d API 
including a caret position method and blink rate information. The second 
subject involves the addition of one property to the TextMetrics API. 
They are two very different subjects.

The deficiency of the TextMetrics API does not need to be expressed in 
the terms of Issue 131, it clearly stands on its own. It affects a 
variety of things, not just accessibility. One very simple example is 
that it's absurdly difficult to reproduce the following graphic in 
Canvas, as it does not currently report baseline offsets:
http://www.whatwg.org/specs/web-apps/current-work/images/baselines.png

And here's the issue:
http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline

That's quite a different document than the one the representing the 
issue the Chairs made a final decision upon:
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection


I'm coming to the conclusion that you're referring to them together.


>> The proposal Richard has been floating recently simply covers
>> TextMetrics and has little-to-nothing to do with the chair decision from
>> May. It was requested that the issue remain separate from the May action
>> by the chairs.
>
> That's not what was said.  What was said was "Proposals to add 
> baseline measurement support can be considered if sufficient detail is 
> provided."
>

A separate bug report was to be filed, and the issue treated with a 
separate Change Proposal.

Instead of addressing item #7 on the "accepted" Change Proposal, the 
entire CP has been reverted and the chair decision apparently reversed.
http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection


>> I'm thoroughly confused as to what the subject is, when you are
>> referring to "your proposal". What weight or authority does the decision
>> from May have? The patch was applied by W3C staff as the editor would
>> not apply it himself. The editor recently reverted the change, and
>> neither the chairs nor editor have provided an explanation.
>
> We vacated that decision for the reasons specified.  If you are 
> unhappy with the chairs action in this matter, I encourage you to take 
> this matter up with PLH.  However I will again state that from my 
> perspective if you can't get implementers lined up, it doesn't much 
> matter.  And if you can get implementers lined up and nobody follows 
> through to prepare a suitable proposal to match the edits that Ian has 
> made, then you have nothing to worry about.
>

Is one reason being that six months have passed without implementation? 
Is the other reason being that issue #7 on the CP is being re-evaluated? 
Is the third reason being the disclaimer entered into the CVS, and the 
ease in which the document can be forked?

I'm well aware that implementers must deliver a working product for a 
specification to be meaningful.

The unstable, opaque process at work here is counter-productive toward 
that goal.
Take Mozilla's bug report for example, on focus rings:
https://bugzilla.mozilla.org/show_bug.cgi?id=540456

What name should they have used? From the prior chair decision, it was 
drawFocusRing(element, canDrawCustom)
Now there are two methods, and there has been no public discussion as to 
why there are two methods.

I've got no idea why there are two methods.

I'm concerned about trying to hit a moving target. The instability in 
that Mozilla bug report, undermines my ability to get work done with 
vendors, and it devalues my time and contributions to this process. I 
sought public review and cooperation from the W3C and followed 
procedure. I'm hearing that the time should have been spent coding 
implementations.

Vendors, including the two I could easily submit patches to, Mozilla and 
Webkit, tend to follow the specifications authored in this process. So 
if I go and start sending them patches that aren't reflected in w3c 
documentations, they're likely to reject those patches. I understood my 
involvement with W3C procedure to be a precursor to implementation.


>>>> Could you please clarify how this is consistent with the HTML working
>>>> groups decision policy or with the process you refer to below?
>>> ...
>>> Obviously, I would encourage you to focus on obtaining implementer
>>> testimonials instead of taking that path, but the choice is yours.
>>
>> I think we all understand that the existence of an implemented API
>> across two independent implementations is an often used and accepted
>> measure for writing the standard. Many implementers are hesitant to put
>> in such implementations in relation to accessibility until there's some
>> guidance from the w3c. We seem to be in a catch-22 here.
>
> It's not a catch 22.  The text that you cited has been in place for 
> over six months.  If you have implementations to point to, I encourage 
> you to do so.

It's only been six months. Six months is a very short amount of time to 
introduce new methods into multiple implementations.

If I had implementations to point to, they'd now be out of spec and 
their associated vendors would have pie in their face.

I get it though, implementations first, W3C procedure can follow. I'll 
adjust my attention accordingly.


>>> In any case, if for any reason these bugs aren't resolved to your
>>> satisfaction by December 31st 2011[1], you will have the opportunity
>>> to escalate the bugs and propose your own resolutions in the form of
>>> concrete Change Proposals.
>>
>> They've been escalated as far as I'm aware.
>
> Since you haven't specified a bug number, I can't verify this.  The 
> bugs that are current escalated can be found here:
>
> http://dev.w3.org/html5/status/issue-status.html
>
> If the bug that you are thinking of is not on that list, I again 
> encourage you to read the resolution text that is provided in the bug 
> report itself.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
https://www.w3.org/Bugs/Public/show_bug.cgi?id=11342

There's no push-back on the TextMetrics proposal, I'm not too concerned.

I suppose this has to be re-opened in light of setCaretSelectionRect 
being subsumed by the editor's scrollPathIntoView
https://www.w3.org/Bugs/Public/show_bug.cgi?id=11240



>> The HTML editor continues to assert that interactive Canvas
>> accessibility is not an issue as Canvas should not be used for
>> interactive components, beyond an arbitrary set of button, checkbox and
>> radio. This is reflected on the whatwg specification.
>>
>> We're in a bit of a bind here.
>>
>> I'm sure vendors will move forward, regardless, as they have real-world
>> commitments to accessibility. The chairs previously put forward a
>> decision which has now been circumvented by the HTML editor. It seems
>> odd to submit Change Proposals under such circumstances. Why go through
>> the process if it holds no authority?
>
> That text has been in place for six months.  We've had explicit 
> statements to the contrary from implementors.  What's different about 
> this go around is that we are asking for the statements from 
> implementors up front.


I did not intend to suggest they would move forward with the old change 
proposal. I meant to say they will move forward with improving Canvas 
accessibility.
Canvas works quite fine for authoring widgets in its present state, it 
merely lacks wide support for the sub-tree as the concept of fallback 
content has only recently evolved into what amounts to a live 
alternative view.


>
>>>> I am leaving for vacation in an hour and will be unavailable for 
>>>> mostly
>>>> through the end of the year. I look forward to your reply.
>>>
>>> Unfortunately, I wasn't around to respond within the hour. Hopefully
>>> you will see this when you return.
>>
>> Cute.
>
> Nothing cute intended by that statement.  In the interest of full 
> disclosure, I live in Raleigh.  Take a look at the timestamp of 
> Richard's email.  By the time I saw it, I was out to dinner.  They my 
> wife and I, our daughter and a friend of hers went to see a play:
>
> http://rltvolunteers.org/rltphotos/yearbook/cinderella.html

It that's not cute, I don't know what is.

> I responded as soon as I got home.  I will also note that as I 
> continue to be in Raleigh, should you respond further tonight, I will 
> likely not see it until the morning.

I don't expect same hour nor same day response, but I do appreciate your 
level of attentiveness.

As you've noted, there's no rush here. I don't think anyone expects you 
to be around to respond within the hour.


> While I have responded, what I am requesting is that those interested 
> in pursuing this either post vendor testimonials or get with PLH.  
> There still will be plenty of opportunity to obtain and provide these 
> in at least the first part of January, so there is no need to rush to 
> obtain these before everybody else disappears.

I'm fine waiting on this. The TextMetrics issue is a trivial patch and 
the subsequent changes by the HTML5 editors aren't relevant until 
implementers catch up to simply supporting focus on sub-tree elements. 
Those patches are not as simple, but in a nutshell, involve changing 
HTMLCanvasElement to behave more like a form control, where it currently 
behaves like a simple rendering block.

We'll see some new patches in January and go from there.


-Charles

Received on Saturday, 10 December 2011 07:12:38 UTC