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

hi leif,

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).

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".


"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)

>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.


>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.

>> As i said I don't agree that the details element should have a
role="img".

>In your concrete example? Or in general?

 neither.

>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.

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.

>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...

regards
stevef

2010/8/24 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

> Steven Faulkner, Tue, 24 Aug 2010 16:04:09 +0100:
> > Hi Leif,
> >
> >>I would add <details role="img"> as a requirement, whenever <details>
> >>is used to represent an image. Justification below.
> >
> > it's not being used to represent an image its being used as a
> > container for a long text alternative.
>
> 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?
>
> >>Making @longdesc a boolean like that, does not make sense to me, for
> >>several reasons. One thing is that it would go against how it is
> >>currently specced (and what about those bogus @longdescs out there?).
> >>But just as imporant: to rely on @longdesc like that, would be to not
> >>take advantage of <details role="img">,
> >
> > i have suggested that
> > " longdesc attribute with URL value (longdesc="URL") provided for
> > backwards compatibility (suggest deprecated in HTML5)"
>
> 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?
>
> > also
> > ">    - use of longdesc attribute on image provides indication to
> browser/AT
> >>    that details/summary is being used for the specific purpose of
> >>    providing a long description."
> >
> > how many bogus longdesc are there to be found in <summary> elements?
>
> I know. But I don't think it is smart to introduce one interpretation
> inside <summary/> and another elsewhere. Plus that old UAs probably
> would see an empty, boolean longdesc as equivalent to longdesc="",
> which they - again - would interpret as a link to the current page.
>
> However, before we resolve whether such a reuse of @longdesc could
> acceptable, it is important to know why a @longdesc of the boolean
> kind, should be is needed.? In <details/> there is already a relation
> between <summary/> and content. 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/>.
>
> 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 thing is that it would go against how it is currently specced
> >
> > how is that an argument?
>
> 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.
>
> >>But just as imporant: to rely on @longdesc like that, would be to not
> >>take advantage of <details role="img">,
> >
> > I was trying to provide a native HTML5 method without recourse to
> > ARIA, besides i don't agree that it should be role="img".
>
> Again: What @role do you suggest, in your concrete example, then?
>
> >>If the <details/> element has role="img", then everything outside the
> >><summary/> element naturally becomes the long description of what is
> >>summarized in the <summary/> element. Hence, there would be no reason
> >>to introduce @longdesc as some kind of boolean signal - such a thing
> >>would only be redundant. (And sometimes even incorrect - imaging if
> >>both @alt and text outside the @alt makes up the <summary/> text.)
> >
> > As i said I don't agree that the details element should have a
> role="img".
>
> In your concrete example? Or in general?
>
> > your code example:
> > <details role="img">
> >  <summary><img longdesc="link" alt="Short desc"></summary>
> >  <a href="link">long desc link</a>
> > </details>
> >
> > problem with this is that everything inside the details element is
> > guven a role="img"
> > so the summary element, which will probablyu be exposed as a button
> > to AT will become an image, so will the link.
>
> So, are you saying that <details/>, unlike a <figure/> cannot
> technically be presented as an element with role="img"?
>
> My code example is otherwise "thought up" in analogy to the generic
> example in ARIA 1.0: [1]
>
> ]]
> <div role="img" aria-labelledby="caption">
>  <img src="example.png" role="presentation" alt="">
>  <p id="caption">
>   A visible text caption labeling the image.</p>
> </div>
> [[
>
> The above ARIA example is, from AT user's angle, equivalent to this:
>
> <div role="img" aria-labelledby="caption">
>  <p id="caption">
>   A visible text caption labeling the image.
>   <img src="example.png" role="presentation" alt="">
> </p>
> </div>
>
> Which is equivalent (for AT users) to this:
>
> <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>
>
> When it comes to <details>, then we give increased attention to the
> caption element for _all_ users (not only to AT users). Thus the above
> <figure/> example can be turned into a <details> element with a "long
> descripton", like this:
>
> <details role="img" aria-labelledby="caption">
>  <summary id="caption">
>    A visible text caption labeling the image.
>   <img src="example.png" role="presentation" alt=""
>    longdesc="detailsbody">
>  </summary>
> <p id="detailsbody">
>  Long description text of image ...
> </p>
> </details>
>
> (PS: I hope the above example can help illustrate why it is unhelpful
> to not have the same caption element for both <details/> and <figure/>,
> as it is often useful to switch from <figure/> to <details/> and
> vice-versa.)
>
> >>Suggestion: the ARIA equivalent of role="iframe".
> > there is none, and again I would like to see a native solution,
> > rather than one that requires the addition of ARIA.
>
> I would not describe ARIA roles as an addition but merely as an
> description. An ARIA role is an ARIA representation of something in the
> host language. ARIA 1.0 has (at least) this to say about frames:
>
> ]]
> Superclass Role: section
> Subclass Roles: alert, article, grid, landmark, list, log, status,
> tabpanel
> Related Concepts: HTML Frame [ snip ]
> [[
>
> >>One of the @longdesc use cases in
> > HTML4, is providing information about an iframe element.
> >
> > this may have been useful in the earley days when AT did not support
> > <iframes>, to be honest I have never had cause to recommend using
> > longdesc on an iframe.
>
> OK.
>
> 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.
>
> [1] http://www.w3.org/TR/wai-aria/complete#presentation
> --
> leif halvard silli
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html