Re: Split Issue 30?

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