- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 1 Feb 2012 23:02:06 -0800
- To: John Foliot <john@foliot.ca>
- Cc: 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 Wed, Feb 1, 2012 at 9:19 PM, John Foliot <john@foliot.ca> wrote: > Charles Pritchard wrote: >> To: Jonas Sicking >> >> > Hence, the parties that we are asking to be changed here is not AT >> > software but rather browsers. So far I have not heard browser claim >> > that this is a too hard change to make. >> >> Yeah, you're hearing the claim from authors and a11y experts instead. >> There's a reason for that. > > One of the reasons is that a significant part of the problem is at the OS / > Accessibility API level. What do you have to back up that claim? Given that we in Firefox already expose rich content for aria-describedby when the content is not hidden, i see no reason we couldn't when the content is hidden. With no changes to Accessibility APIs or OSs. >> > All I hear is people trying to keep status quo and worried about >> > suggesting any changes to any software, rather than see what solution >> > would lead to the best accessibility. >> >> I assure you, the a11y experts commenting on this thread have been >> working in accessibility for a long time. >> Yes, they are conservative, trying to keep some things the same. That's >> because there is structure around those things. > > FWIW, as one active member is this thread, (and also one of those long-time > accessibility folk) I am less focused on new versus old (status quo) and > more on user needs and interaction patterns. As I concluded in my response > to Jonas' Change Proposal (http://www.w3.org/wiki/A11yTF/longdescresponse): > > "For Jonas' Proposal to truly solve the problem at hand the Browsers would > have to address the core issues identified - this is not a mark-up problem, > this is a User Agent problem. > > * 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. > * 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. > * For any Proposal to succeed, the Browsers must preserve the HTML richness > of the longer textual description content. Currently with aria-describedby > the only way to do this is to visibly render the text on screen, and thus a > browser requirement. This is not indicated anywhere in Jonas' Change > Proposal. Yes it is. My proposal says that this is something that browsers should change. > 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>? > 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? / Jonas
Received on Thursday, 2 February 2012 07:03:04 UTC