Re: Request to re-open issue 131

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).

regards
Stevef

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
>>>
>>>
>>
>>
>>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Saturday, 10 December 2011 20:23:18 UTC