Re: describedBy and longdesc

Charles McCathieNevile, Tue, 29 Mar 2011 15:38:43 +0200:
> On Sun, 27 Mar 2011 07:14:53 +0200, John Foliot :
>> Leif Halvard Silli wrote:
>>> Charles McCathieNevile, Sat, 26 Mar 2011 11:23:07 -0400:
>>>> On Fri, 25 Mar 2011 22:34:27 -0400, Jonas Sicking wrote:
>>>>> On Fri, Mar 25, 2011 at 6:57 PM, Laura Carlson :

>>>> aria-describedBy, if fixed,

>> SETTING THE STAGE:
>> 
>> 	"ARIA is intended to only affect accessibility API mappings (and
>> thus ATs). Features such as alt="", however, are relevant far beyond AT
>> users, [...]

> Agree, and this is something that is wrong with ARIA as currently specified.

Fixing ARIA vs fixing aria-describedby are different debates. In the 
former, then @aria-describedAT *do* belong.

>>> I for my part agree with Laura that the @aria-describedAT proposal is
>>> an acknowledgement of @longdesc's unique features. I think we need
>>> accurately specified A11Y features. Allowing too much freedom soon ends
>>> up like a - ah - certain lottery. Thus it doesn't seem like the right
>>> approach is to overload @aria-describedby - or any other ARIA attribute
>>> - with multiple semantics.
>> 
>> +1
> 
> I think that longdesc is, but only for images, what aria-describedBy 
> tries to be more generally. 

I doubt that I could have signed that statement.

> There is a benefit in the specification 
> of aria-describedBy that is explicitly enables identification of the 
> description, not just where it begins (which is all longdesc does by 
> specification).

The format of long descriptions is an interesting subject:

a) @aria-describedby doesn't present the markup to the user. That's the 
*very reason* why it is so simple to just limit aria-describedby to the 
element(s) that aria-describedby point(s) to: AT simply stops reading 
when <element id=foo> is finished. (That's probably also one of the 
reasons why aria-describedby can take more than a single idref.) Not so 
with mark-up - for mark-up, the user must himself/herself decide when 
to stop.

b) We have every opportunity to describe the format of long 
descriptions, now. In fact, the input that I have made that @longdesc 
should point to a fragment, is a start. 

c) We *could* say that it *must* identify the entire description etc. 
For markup, we must also suggest user of elements, such as headings 
and/or <figure> or <article>, so that it identifies a description even 
when human beings parse it! Do you join me in suggesting this to Laura?

>> Yet one of the complaints we've repeatedly heard is that the text
>> contained in the page pointed to by @longdesc might be useful for sighted
>> users as well...
> 
> No reason longdesc can't do that already

Speaking about the long description, perhaps we should say that the 
long description should contain the described image? A kind of 
microformat?

  Example: 

   Document: document_with_a_diagram.html             |
  See this diagram:                                   |
  <img alt=Diagram src=diagram.jpeg                   |
  longdesc=long_description_of_diagram.html#fragment> |
  """"""""""""""""""""""""""""""""""""""""""""""""""""

   Document: long_description_of_the_diagram.html|
  <figure id=fragment>                           |
  Description of diagram image:                  |
  <dfn><img alt=Diagram ></dfn>                  |
  Lorem ipsum dolor sit amet                     |
  </figure>                                      |
  """""""""""""""""""""""""""""""""""""""""""""""

>> ...because there is no visual indication that @longdesc content exists...
> 
> That's just because implementations are bad, and can be fixed in any 
> modern browser in about 30 minutes of work.

According to Laura's CP, @longdesc does not need to be "visualized".
 
>> This ...line of discussion is ... suggesting to re-open a Candidate
>> Recommendation (ARIA 1.0) to either re-work an existing attribute, or
>> introduce a new one. It is breaking backward compatibility with an
>> existing 12 year old specification. It dogmatically rejects an existing
>> attribute in favor or creating a new attribute that does exactly what the
>> old attribute did.
> 
> Given that we have the old attribute, and understand some of the 
> things wrong (and right) with it, I believe we are throwing it away 
> too early.

The "too early to delete it" argument will hardly be successful with 
our chairs. 

Are the wrong things that we now udnderstand, such as the thing that 
@longdesc should identify the entire decription containe, expressed in 
Laura's change proposal?

> If we fix aria-describedBy, then we simply have redundant 
> syntax (which is a trivial issue), and if we discover that one or the 
> other is broken in some unanticipated way then we can expect them to 
> wither and die when they are really dropped - accessibility 
> attributes seem unlikely to live on beyond their usefulness.

This line of thought hardly goes home with our chairs. Arguments of the 
type "it is no big danger to include it", has so far not been 
successful in adding/keeping anything in HTML5.

Also, it seems like a false dilemma: Aria-describedby is hardly going 
to be dropped just because @longdesc is successful.

The situation we have is this: some claim to have discovered that we 
are past @longdesc's usefulness.

The task at hand is thus @longdesc. Not ARIA. Positive ideas about what 
positive @longdesc could do in HTML5, is what is needed.

> In the long run aria-describedBy matches a whole set of things I 
> expect to be used, and since its functionality in principle overlaps 
> that of longdesc I expect it to become capable of doing that in 
> practice.

Fortunately, I also believe that our chairs will ignore arguments about 
what @aria-foo *hypothetically* could do.

> At which point longdesc becomes obsolete - replaced by 
> another attribute with a more popular name, that does the same 
> things. That's fine.

In principle yes. But our task is to define @longdesc so well, that we 
really feel that it hurts if it falls out of use.

> When the new attribute can do the important 
> things that the old one did. Which is not yet.

And may be never. If we do a good job now, with @longdesc, then perhaps 
@aria-describedAT (or aria-whatever) could learn - something - from 
@longdesc.
-- 
leif halvard silli

Received on Tuesday, 29 March 2011 21:08:21 UTC