- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 30 Jan 2012 20:47:14 -0800
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: 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, Jan 26, 2012 at 5:47 AM, Laura Carlson <laura.lee.carlson@gmail.com> wrote: > Hi Silvia, > > The change directly implements half of Jonas' longdesc proposal. > > Best Regards, > Laura That seems like a terrible reason to request a change to be reverted. Instead we should look like if the change was a good one. I.e. is it good for the web and is it good for accessibility. To me the answer is a clear "yes" on both. Also note that this change is almost completely orthogonal to the longdesc debate as I will show below. The reason that I have given to Hixie when discussing this with him is that allowing putting @hidden on things pointed to by aria-* simply codifies in spec something that people will inevitably do no matter what. If and author has a description, summary, label or otherwise that I only want to display to AT users, something that has been brought up multiple times on this list as an important accessibility use case, what is the first action that author is likely to take: A. Go read the aria specification? B. Go read the HTML specification? C. Search for best-practices documentation? D. Try to find another website which does the same and then use view-source? E. Try something to see if it works? I would put my money on E simply because this is the smallest amount of effort. This is also my experience based on bugs filed against firefox. People simply do the craziest things, simply because it happens to work. I think the best thing we can do for accessibility is to make 5 work as intuitively as possible, this is because otherwise I think that people might not choose any of the above and instead go with F. Not bother. That option is clearly the worst for the web and for accessibility. So what is the most intuitive way to add a hidden description/summary/label? I would think "create a description/summary/label and then make it hidden". I.e. you'd write markup like: <label for=myinput>Label here</label><input id=myinput> and then hide the stuff that you want to only expose to AT: <label hidden for=myinput>Label here</label><input id=myinput> Similarly: <table aria-describedby="desc">...</table> <div hidden id=desc>Description here</div> and <img longdesc="#desc" src="..."> <div hidden id=desc>Description here</div> This will work in all browsers. It works today. Forbidding this in the HTML 5 spec will only affect the people who chose A above, which I'm willing to bet is a very small number of people. Possibly it'll also affect some people that choose C if we can get some popular best-practices documents to describe how to accomplish this without using @hidden. So what if we do choose to forbid aria and other similar features from linking to hidden elements. What alternative are we proposing to people that want to have content which is only displayed to AT users? My impression is that we're suggesting that they use various attributes and methods that allow linking to external documents. This seems like a very poor solution compared to using @hidden. Most likely we'll end up with people choosing the "Don't bother" option, or end up with out-of-date external documents. Now, there are problems with using @hidden. As John Foliot often points out, including in this thread, 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. It should be to envision the technology which will produce the best and most accessible web and then codify that into a specification. If implementations complain that this is too hard to implement then of course we might need to reconsider, but so far this has not happened. So let's instead write the specification that will create the most accessible web once implemented, and not be locked down to what todays browsers do. That's how we move the web forward. / Jonas
Received on Tuesday, 31 January 2012 04:48:23 UTC