W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Revert Request

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Thu, 2 Feb 2012 07:48:29 +0000
Message-ID: <CAEhSh3cXyOL_5VCkvfqjmh4V3J3vmFx=4VzfnzW2FBJHEGEW+A@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: John Foliot <john@foliot.ca>, Charles Pritchard <chuck@jumis.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On Thu, Feb 2, 2012 at 7:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> * For any Proposal to succeed, the Browsers must address the discoverability
>> problem for all users. This is not indicated anywhere in Jonas' Change
>> Proposal.
> Does any other proposal? If so, could you provide a link.

I don't think so. In general, the proposals abide by the general
principle that we cannot dictate UI.

But note the implementation evidence for browser discoverability
collected by Laura's proposal:


>> * For any Proposal to succeed, the Browsers must natively support the
>> user-choice of consuming or not consuming the longer textual description.
>> This is not indicated anywhere in Jonas' Change Proposal.
> Does any other proposal? If so, could you provide a link.

This is a recurrent them in Laura's @longdesc proposal. See especially:

Use cases: http://www.d.umn.edu/~lcarlson/research/ld.html#uc
Conclusion: http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion

>> Jonas indicates that none of the browsers vendors have said they can't
>> address these problems, but we've seen no indication that they are prepared
>> to do so.
> Why are you more concerned about this part of the HTML5/ARIA specs
> than, say, the willingness to implement <input type=date>?

Maybe because input type="date" degrades gracefully to a text input,
or can replace a custom date picker widget when support is sniffed
with JS?

>> Meanwhile, the existing technique (using @longdesc) *does* address those
>> problems, at least for the core user-group that require longer textual
>> descriptions.
> How does longdesc address any of the problems you raise above?

1. @longdesc provides a simple semantic hook around which any UA can
make long descriptions discoverable using the browser chrome, but we
should not mandate any particular UI.

2. No current UA/AT presents the content referenced by @longdesc
automatically, so the content is accessible by user choice. (Typically
screenreaders present @longdesc as a link after the image description
the user can choose to follow, while browsers present @longdesc as a
context menu option on the image.)

3. When authors want to hide a long description, they can place it on
an external page where it is visible. The code and UI patterns for how
to navigate to an external page are well-established (and used for
example by JAWS and Opera) whereas the patterns for how to present
users with hidden content on the same page are not established at all.

Benjamin Hawkes-Lewis
Received on Thursday, 2 February 2012 07:48:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:20 UTC