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/30http://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