Re: Revert Request

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