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:

http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation

>> * 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT