Re: Request to re-open issue 131

Hi SAm

you wrote:

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

I think it is fair to assume that this information is relevant to:

ISSUE-182: Advice in spec about annotations promotes inaccessible content
http://www.w3.org/html/wg/tracker/issues/182

ISSUE-190: Replace poor coding example for figure with multiple images
http://www.w3.org/html/wg/tracker/issues/190

ISSUE-192: title attribute definition does not match reality
http://www.w3.org/html/wg/tracker/issues/192

and the request to re-open Issue 80 (in regards to title/alt attribute
conformance
http://www.w3.org/html/wg/wiki/ChangeProposals/notitle

regards
Stevef

On 10 December 2011 21:57, Sam Ruby <rubys@intertwingly.net> wrote:
> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 
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 22:24:22 UTC