- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 12 Feb 2012 15:42:35 -0800
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
On Sun, Feb 12, 2012 at 1:20 PM, Charles Pritchard <chuck@jumis.com> wrote: > On 2/12/2012 5:04 AM, Jonas Sicking wrote: >> >> On Fri, Feb 10, 2012 at 11:13 AM, Charles Pritchard<chuck@jumis.com> >> wrote: >>> >>> On 2/10/2012 10:57 AM, Maciej Stachowiak wrote: >>>> >>>> On Feb 10, 2012, at 8:23 AM, Laura Carlson wrote: >>>> >>>>> Hi Sam, >>>>> >>>>>> I dislike this characterization and the innuendo that people may be >>>>>> playing >>>>>> tricks. >>>>> >>>>> I am sorry you dislike it. But re-ordering issues to strengthen one >>>>> proposal over another is not equitable. >>>> >>>> I think that the key consideration for the Working Group should be to >>>> ensure that every issue and every proposal gets fair consideration. This >>>> needs to take priority over considerations of which proposal benefits. >>>> >>>> It seems to me that your argument is purely based on giving a tactical >>>> advantage to the "Instate Longdesc" Change Proposal, not on making sure >>>> that >>>> *all* proposals get a fair hearing, with all possible information on >>>> the >>>> table. I can understand why you would feel that way; it's natural to >>>> want to >>>> advocate for your preferred proposal. But I think it is unlikely that >>>> the >>>> Chairs would give a lot of weight to that type of argument, because our >>>> job >>>> is to ensure that the process is fair to everyone, not to help a >>>> particular >>>> side win. >>>> >>>> While the Chairs rarely order issues for the sake of dependencies, I >>>> have >>>> to agree with Sam that the last thing we want is for ISSUE-30 to get >>>> reopened yet another time. >>> >>> >>> Laura has repeatedly addressed the other two change proposals, as well as >>> thoroughly documenting her reasons for asking that longdesc be maintained >>> as >>> a web standard. >>> >>> Jonas, the author of one of the proposals has stated that his proposal is >>> not directly intended for longdesc. But, he is hoping that it can >>> eventually >>> lead to longdesc being obsoleted. >> >> Please don't put words in my mouth. > > > I don't think that's a fair representation of what I wrote -- I did not use > quotation marks. > You've framed your proposal as a means to obsolete longdesc. > > You've repeatedly stated that "the aria-describedby attribute" is a "better > alternative" and that longdesc should be kept out of the HTML5 spec. > > > >> I added the part about changes to the @hidden attribute since I felt >> that it was something that clearly and obviously improve accessibility >> on the web, both with regards to descriptions (long and short, for >> elements that support longdesc and for elements that don't) as well as >> for other features that ARIA adds. >> >> Hence I felt this was a good way to "meet in the middle" since many >> people had said that we shouldn't remove longdesc until we have >> something that can replace it. > > > This meet in the middle strategy does not replace longdesc. It's been four > years since the issue was raised. > http://www.w3.org/html/wg/tracker/issues/30 > http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results > > > Gregory Rosmaita wrote about the two semantic qualities of longdesc that are > unmatched: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=10853 > > 1. A direct, reusable programmatic determinable mechanism to a > long description of an image without a forced visual > encumbrance or default visual indicator. > > 2. A method to reference a longer description of an image, without > including the content in the main flow of a page. > > > The @hidden attribute meets in the middle -- it handles #1 but breaks > compatibility with existing browsers and ATs. > > >> I'm still eagerly waiting for the explanation of why the change Hixie >> made was bad for accessibility (modulo the obvious spec-bug that the >> description was specified to be completely empty when aria-describedby >> points to a hidden element, something I've now fixed in my change >> proposal). > > > > As John Foliot writes: > "What is at issue is what happens to content not visible on screen: the > Accessibility APIs flatten the content to string text... Hidden content, > whether referenced by ARIA attributes or not, cannot (should not) support > focusable content." > http://lists.w3.org/Archives/Public/public-html/2012Feb/0089.html > > Mozilla, Google and Apple do not support older hardware. I have a perfectly > functioning laptop that will only run Firefox 3.x. This is a real concern > for me and many millions of users. We can't simply tell people to meter > 20megs of bandwidth to upgrade their browser. Some of us over-achievers may > still use off-screen positioning via CSS. It really depends on the context > and content. > > We have a disconnect here that can't truly be resolved: "browsers today have > problems if the @hidden contents contains 'rich content'. But that's > browsers today. Our goal for the HTML5 spec shouldn't be to document best > practices for todays browsers." > Jonas: > http://lists.w3.org/Archives/Public/public-html/2012Jan/0199.html > Charles: > http://lists.w3.org/Archives/Public/public-html/2012Feb/0017.html > > This is disconnected from the computer re-use practices of most of the > world, as well as WCAG and the principles that the UAAG put forward. > > Silvia did try to find a middle ground here, suggesting that > aria-hidden="false" have more meaning: > http://lists.w3.org/Archives/Public/public-html/2012Jan/0157.html > > But that breaks the boundaries of ARIA -- that it should not affect the way > in which the UA operates. > > The problem with changing focus semantics on @hidden is that it "breaks the > web", to borrow the lingo often used by your team. The problem with dropping > @longdesc is that it breaks compatibility, without an available superset > semantic, a hypernym. > > VHA Section 508 Office chimed in: > http://lists.w3.org/Archives/Public/public-html-comments/2011Aug/0008.html > > The Association of American Publishers commented on the issue: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461 > > In the AAP post, I explored aria-describedby and aria-flowto as possible > long term mechanisms. > That's the thread where my mind finally turned, and I saw that @longdesc > should not be deprecated. > > I fully support the ARIA mechanisms for long term use. > > I can't support deprecating @longdesc. There is far too much evidence that > it should remain a supported feature for <img> in HTML. There's far too much > support behind it. The arguments are on the table; and for most of the > arguments against longdesc, I'd simply say: "Hey, you should use some ARIA > while you're at it." > > Now if you want to aim for HTML6, that's fine. SVG2 is likely to completely > break compatibility. Let's allow that with HTML6 as well. In the meantime, > lets get HTML5 published in the near future. That's not what the HTML editor > is looking to do, but a lot of WG participants are. > > I'd imagine the chairs actually intend to publish an HTML5. > > And as for putting words in the HTML editor's mouth; I did not use quotation > marks, and he has repeatedly stated that he is working on a living document, > that he does not approve of the publishing process, and he moved away from > the term HTML5 in response to the W3C using the term in publicity. There is > sufficient public record on this issue. My statement about the HTML5 editor > is not libelous. He has a different perspective, and that's OK, but it is > different. > > Jonas, you have a different perspective too. That's OK, too. Multiple > viewpoints are a good thing. We are fleshing out real issues in this > process. It sounds like your only objection to allowing aria-describedby to point to @hidden elements is that it will delay publishing a finalized HTML5 spec. That is certainly an understandable argument, though given the extreme inertia for changing semantics of existing features, I'd rather spec the @hidden attribute correction from the beginning, than wait to fix it in HTML6. Additionally, it seems like we're going to have a poll on it either way, so it wouldn't seem to affect the schedule. As for deprecating @longdesc. Please note that the HTML5 spec has *always* made it a MUST requirement for browsers to support it. So no the web won't break. And people that want to support down-level browsers can still do so. This might not be a good enough requirement to you, but it is to me since otherwise I don't think we'd ever move the web forward, something that I'm quite eager to do. / Jonas
Received on Sunday, 12 February 2012 23:43:34 UTC