- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Thu, 2 Feb 2012 07:48:29 +0000
- 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 UTC