Re: Split Issue 30?

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.


-Charles

Received on Sunday, 12 February 2012 21:21:18 UTC