Re: providing a long description using the summary and details elements.

Steven,

Steven Faulkner, Wed, 25 Aug 2010 11:47:11 +0100:

>> you wrote:
>> "We have been here before ... The ARIA 1.0 definition of role="img" is
>> "container": “A container for a collection of elements that form an
>> image.” There is nothing here which says that one of the elements
>> inside the container cannot be a button.
>> 
>> That said, if you have your concrete example in mind, then perhaps you
>> would like to suggest a better role than "img"? The image contains a
>> diagram, what's the appropriate role for a diagram?"
> 
> ARIA  should not and most likely will not be used for native 
> implementations of user interface elements in browsers, for example 
> <button> or any other of the host of natively implemented elements in 
> HTML are NOT mapped to ARIA by they browser they are mapped directly 
> to the supported accessibility APIs (MSAA, IA2, etc).

HTML5 does let you (choose from a list of roles to) override the role 
of <details/>. So apparently, it does not fall into the same bowl as 
<button> do.
 
> The long text alternative is NOT an image it is a text alternative 
> for an image.
> If your thinking was carried through to current longdesc then the 
> page targeted by the longdesc URL should be considered as having a 
> role="img".

No it would not. ;-) Take a look ARIA 1.0 code example that I quoted: 
The _container_ has role="img". But the children of the container has 
different (sub) roles. Nothing in what I said implied that if you e.g 
move the caption - or any other feature - of an role="img" element, 
then it still - outside the role="img" container - is to be considered 
an image.

>> "A double meaning then? HTML5-compatible UAs see it as a boolean
>> attribute, even when it contains a URL, while HTML5-incompatible UAs
>> see it as a link?"
> 
> yes that was my thinking
> 
>> "And your example keeps the <img> in the
>> <summary/>, and thus I don't understand what a boolean @longdesc then
>> can add - compatible user agents already know that the content of
>> <details/> is some kind of long description of the summary inside
>< <summary/>."
> 
> The idea of the longdesc as a flag is to provide user agents with  
> way to distinguish between the specific case of the details/summary 
> being used for an image/long description so they can provide the user 
> with specific instructions for use, which may be different than for 
> the default interaction behaviour for details/summary (expected 
> default behaviour is as disclosure widget 
> http://en.wikipedia.org/wiki/Disclosure_widget)

OK. I think I see. Well, I do *not* support that longdesc is valid 
unless it has a proper URL. But I guess that a double meaning could be 
acceptable, as long as it is also is valid as a traditional @longdesc. 
But I wonder if it is not more logical to link such a behavior change 
to an attribute directly on <details> (or <summary>)? (My understanding 
was that you only talk about <img@longdesc> used inside <summary>)

>>Perhaps, what you suggest, is that we shall have two categories of
>><details/> elements: those which are used for "normal" interaction. And
>>those where the content contains a long description of the <summary/>?
>>What kind of benefits would such a division in two categories provide?
> 
> one of the cited required behaviours is to provide access to an 
> external long description, specifying a particular use would provide 
> the opportunity to make this behaviour available.

OK. I think I see. However, if this change of behavior of <details> is 
linked to @longdesc, then only <img> elements can be described that way 
... Would it not be better to say that the presence of some attribute 
on details element itself had such an effect?

>>Before I can comment more on that, I need to know the answer to why
>>such a re-interpreation of @longdesc should be needed. THe problem I
>>have is that new, HTML5 compatible clients will understand <details>
>>and <summmary>. Thuse these user agents doesn't need an additional
>>boolean longdesc.
> 
> they may understand <details>and <summmary>, but the semantics and 
> interaction may be different.
> 
> for example, when JAWS encounters a longdesc on an image it announces:
> "press enter for long description"
>  
> When asummary and details is not being used for the purpose of 
> providing a long description for an image, but the summary does 
> contain an image (example image of text), it would not be desirable 
> for an AT to announce the above, because the content won't be a long 
> description of the image in the summary.

OK. Well, what you say here only make it more logical to me that that 
kind of details element, should be possible to perceive as an element 
with role="img". ;-)
  
>>So, are you saying that <details/>, unlike a <figure/> cannot
>>technically be presented as an element with role="img"?
> I think the two are quite different beasts, figure/figcaption is not 
> by default an interactive composite control, details/summary is.

So, perhaps it is really better to use a <figure> rather than 
<details>, if it is important to convey that it is an img?
  
> your example:
>  
> <figure role="img" aria-labelledby="caption">
>  <figcaption id="caption">
>    A visible text caption labeling the image.
>   <img src="example.png" role="presentation" alt="">
> </figcaption>
> </figure>
>  
> I like this and can see where your coming from.
>  
> but when you turn turn the example into using details/summary I don't 
> agree as there are default interaction semantics asscoiated with it 
> that you have not taken into account.

OK. It is true that I see figure/deteails as twins. (I do feel that the 
"longdesc attribute signal" that you want to use to signal that 
<details> contains a long description etc, make it the such a details 
element more similar to a figure element - the become more twins, in 
mine eyes, that way.)

>>Coming back to your proposal to use <iframe> as the conten of a
>><details> element: I doubt that it will become generally acceptable, if
>>the the purpose is to provide a long description of of something
>>summarized in <summary/>, if the iframe  content is provided primarliy
>>for AT users, as I belive many developers will consider it quite
>>"expensive" to load an external page  - to all users - for that
>>purpose. A (longdesc) link would then be considered cheaper.
>  
> it is not necessary to load the page unless details is exapanded, 
> also we are not talking many bytes...

Sure - it will often be acceptable. But perhaps not always.
-- 
leif halvard silli

Received on Wednesday, 25 August 2010 12:28:38 UTC