Re: Request to re-open issue 131

On 12/10/2011 03:22 PM, Steve Faulkner wrote:
> Hi Sam,
>
> just for the record, there are currently NO implementors that have
> made a commitment to provide input device independent access to title
> attribute content and 2 implementors have publicly stated that the
> have no plans to, while the other 2 have declined to provide details
> of future implementations. There has been no public change to the
> implementor's stated positions or changes to implementations in the
> last 9 months (same level of implementation as the past 10 years).

Is it fair to assume that this information is relevant to Issue 192?

> regards
> Stevef

- Sam Ruby

> On 10 December 2011 14:09, Sam Ruby<rubys@intertwingly.net>  wrote:
>> On 12/10/2011 08:38 AM, Steve Faulkner wrote:
>>>
>>> Hi Sam,
>>> on a  somewhat related issue:
>>>
>>> I am trying to understand how the chairs come up with their criteria,
>>> for canvas you are now asking for ' testimonials' from 2 implementors,
>>> meanwhile responses in the negative (no commitment) from 4
>>> implementors did not appear to be good enough in regards to the title
>>> attribute issue[1], rather it was suggested that I need to obtain
>>>
>>> "statements where browser vendors say on the record that they
>>> absolutely won't implement, or believe it is not possible to do."
>>>
>>> is the objective criteria used in the 2 cases the same?
>>>
>>> [1] http://www.w3.org/html/wg/wiki/ChangeProposals/notitle
>>> [2] http://lists.w3.org/Archives/Public/public-html/2011May/0192.html
>>
>>
>> I'll be totally transparent here: the material difference here is that we
>> have people who purport to represent implementors who are affirmatively
>> stating that not only that they won't implement what is the W3C Working
>> Draft[1], and furthermore have stated that they intend to implement what is
>> in the current editors draft[2].
>>
>> To date, we have seen neither change proposals from those implementors nor
>> statements from (other?) implementors that they will implement what is in
>> the Working Draft.  Am I happy about this situation?  Absolutely not.
>>
>> However, I do have a job to do.  From where I sit, here's how I see it: in
>> order to complete HTML5 on anything resembling a reasonable schedule, we
>> need to force the issue and obtain at least one of the two.
>>
>>> regards
>>> stevef
>>
>>
>> [1] http://www.w3.org/TR/2dcontext/
>> [2] http://dev.w3.org/html5/2dcontext/Overview.html
>>
>>
>>> On 10 December 2011 12:23, Sam Ruby<rubys@intertwingly.net>    wrote:
>>>>
>>>> While I am forwarding this to the list (Charles: care to join the HTML
>>>> WG?
>>>>   See: http://www.w3.org/html/wg/#join), I am not going to comment further
>>>> as
>>>> it neither provides the implementor testimonials requested nor pursues
>>>> the
>>>> process question with PLH.
>>>>
>>>> - Sam Ruby
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: Request to re-open issue 131
>>>> Date: Fri, 09 Dec 2011 23:12:09 -0800
>>>> From: Charles Pritchard<chuck@jumis.com>
>>>> To: Sam Ruby<rubys@intertwingly.net>
>>>> CC: Richard Schwerdtfeger<schwer@us.ibm.com>,        Cynthia Shelly
>>>> <cyns@microsoft.com>, dbolter@mozilla.com,        franko@microsoft.com,
>>>> Maciej Stachowiak<mjs@apple.com>,        Paul Cotton
>>>> <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org,
>>>> public-html@w3.org,
>>>> public-html-a11y@w3.org
>>>>
>>>> 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 22:04:51 UTC