This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18385 - Programmatic association of a page element to a 'description' text in a different uri
Summary: Programmatic association of a page element to a 'description' text in a diffe...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 enhancement
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_text-alt
Depends on:
Blocks:
 
Reported: 2012-07-24 16:24 UTC by Devarshi Pant
Modified: 2016-04-14 14:24 UTC (History)
11 users (show)

See Also:


Attachments

Description Devarshi Pant 2012-07-24 16:24:00 UTC
First of all, let me know if this is even feasible. If it is, this is how I see it working:
Programmatically associate a control with a glossary term (brief description) in a different uri. For example, a developer creates a page called www.foo.gov/glossary.html and then ties a piece of text, say, 'glossary#1' to a control in www.foo.gov/pagexyz.html. This could be helpful in numerous situations:
1. Where the describedby text need not be visible on the same page.
2. When an image needs a description.
3. Link needs additional description.
4. Form control needs additional explanation.
5. When a superscript needs to be associated.

-Devarshi
Comment 1 Laura Carlson 2012-07-24 17:19:12 UTC
(In reply to comment #0)
> First of all, let me know if this is even feasible. If it is, this is how I see
> it working:
> Programmatically associate a control with a glossary term (brief description)
> in a different uri. For example, a developer creates a page called
> www.foo.gov/glossary.html and then ties a piece of text, say, 'glossary#1' to a
> control in www.foo.gov/pagexyz.html. This could be helpful in numerous
> situations:
> 1. Where the describedby text need not be visible on the same page.
> 2. When an image needs a description.
> 3. Link needs additional description.
> 4. Form control needs additional explanation.
> 5. When a superscript needs to be associated.

It will be feasible after the longdesc is reinstated in HTML5. It is ISSUE-30.
Comment 2 Laura Carlson 2012-07-24 17:39:10 UTC
> It will be feasible after the longdesc is reinstated in HTML5. It is ISSUE-30.

That could happen in Last Call 2 and not have to wait for HTML.next.
Comment 3 Laura Carlson 2012-07-24 17:41:02 UTC
(In reply to comment #2)
> > It will be feasible after the longdesc is reinstated in HTML5. It is ISSUE-30.
> 
> That could happen in Last Call 2 and not have to wait for HTML.next.

Reference:
http://lists.w3.org/Archives/Public/public-html/2012Apr/0211.html
Comment 4 Devarshi Pant 2012-07-24 23:24:35 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > > It will be feasible after the longdesc is reinstated in HTML5. It is ISSUE-30.
> > 
> > That could happen in Last Call 2 and not have to wait for HTML.next.
> 
> Reference:
> http://lists.w3.org/Archives/Public/public-html/2012Apr/0211.html

I was not aware of this. BTW, the reference states "expanding longdesc to other attributes in the HTML5 time frame." It does not specify what those attributes are. 

If this bug is redundant, please close it.

-Devarshi
Comment 5 Laura Carlson 2012-07-25 11:47:23 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > > It will be feasible after the longdesc is reinstated in HTML5. It is ISSUE-30.
> > > 
> > > That could happen in Last Call 2 and not have to wait for HTML.next.
> > 
> > Reference:
> > http://lists.w3.org/Archives/Public/public-html/2012Apr/0211.html
> 
> I was not aware of this. BTW, the reference states "expanding longdesc to other
> attributes in the HTML5 time frame." It does not specify what those attributes
> are. 
> 
> If this bug is redundant, please close it.

Hi Devarshi,

This bug isn't redundant. If ISSUE-30 [1] is resolved successfully, discussion of expanding longdesc in Last Call 2 can take place. In the mean time documenting use cases is useful preparation. Further elaboration on which elements you feel longdesc would be useful on and why would be appreciated.

Thank you.

[1] http://www.w3.org/html/wg/tracker/issues/30
Comment 6 Devarshi Pant 2012-07-25 20:39:21 UTC
I thought of some:
1.	Image Element: longdesc attribute on this element should behave exactly the way it does with a screen reader, i.e., it first announces the alt attribute, and then concatenates the word “press enter for long description.” Important: The alt text cannot be an empty string forit to work (tested with JAWS 10 / IE 7 / Vista). However, a major difference with its interaction with other user groups (sighted keyboard only / magnifier), will be that this image would receive keyboard focus and be selectable. Activating this image (containing the longdesc attribute) would open the pop up, which opens when using the screen reader. In short, it will behave like an image link.
2.	Links: Complimentary info on links generally works using title attributes. However, some links may need more than title attributes. For example, links placed deep down within complex tables with nested header levels are difficult to comprehend. Understanding this can be hard for sighted keyboard only, magnifier, and non-disabled users. It may not be that difficult for screen reader users as they can use table navigation to further probe table header- cell relationships. Here using the longdesc approach can be extended to include keyboard only users as well. This means that selecting the link will open a pop up window.
3.	For table header cell superscripts and footnotes: Until now, I have not seen accessible implementations of superscripts and footnote. Refer to 2 above for proposed resolution.

-Devarshi
Comment 7 Laura Carlson 2012-07-26 12:33:14 UTC
(In reply to comment #6)

> I thought of some:

Thanks Devarshi!
Comment 8 Joshue O Connor 2012-09-07 08:43:43 UTC
Has there been any more work done on this? Both Devarshi and Laura raise some very interesting points. Are the chairs considering a CP at this point? Will @longdesc be likely reinstated which would help to address the OP concerns or is it likely to be in a future version of ARIA or HTML.next?

(In reply to comment #7)
> (In reply to comment #6)
> 
> > I thought of some:
> 
> Thanks Devarshi!
Comment 9 Benjamin Hawkes-Lewis 2012-09-09 22:07:55 UTC
(In reply to comment #0)
> Programmatically associate a control with a glossary term (brief description)
> in a different uri. For example, a developer creates a page called
> www.foo.gov/glossary.html and then ties a piece of text, say, 'glossary#1' to a
> control in www.foo.gov/pagexyz.html. This could be helpful in numerous
> situations:
> 1. Where the describedby text need not be visible on the same page.
> 2. When an image needs a description.
> 3. Link needs additional description.
> 4. Form control needs additional explanation.

In all these cases, if the description works as plain text, you can just hide the referenced describing element using @hidden. You can reference an iframe if you want to reuse the text elsewhere.

> 5. When a superscript needs to be associated.

What's wrong with an ordinary link here?

<th abbr="2013 estimate">2013 estimate<a href=note-5 rel=help><sup>5</sup</a></th>
Comment 10 Devarshi Pant 2012-09-10 14:12:57 UTC
(In reply to comment #9)
> In all these cases, if the description works as plain text, you can just hide
> the referenced describing element using @hidden. You can reference an iframe if you want to reuse the text elsewhere.

How would sighted keyboard users (even non-disabled users) access this information if we use @hidden? Also, based on the response from Laura, longdesc could be a viable alternative here -- it is accessible to everyone.

> What's wrong with an ordinary link here?
> <th abbr="2013 estimate">2013 estimate<a href=note-5
> rel=help><sup>5</sup</a></th>

Nothing is wrong with your suggestion, but table navigation with screen reader is burdensome when keyboard focus shifts because the target (footnote) is outside the table. For large tables that reference footnotes from within <td> or even <th>, managing focus for most user groups can be diffcult. Here longdesc, when used, can be helpful.
Comment 11 Benjamin Hawkes-Lewis 2012-09-10 22:38:35 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > In all these cases, if the description works as plain text, you can just hide
> > the referenced describing element using @hidden. You can reference an iframe if you want to reuse the text elsewhere.
> 
> How would sighted keyboard users (even non-disabled users) access this
> information if we use @hidden?

If you want a visible description, make it visible and point at it with aria-describedby.

(Requiring sighted keyboard users to use a secondary action on a control just to get additional explanation seems like terrible UI by the way.)

> Also, based on the response from Laura, longdesc
> could be a viable alternative here -- it is accessible to everyone.

Subject to implementation.

Mozilla, Microsoft, and Apple seem uninterested in adding default UI for @longdesc even for images in their browsers, so I'm not holding my breath.

> > What's wrong with an ordinary link here?
> > <th abbr="2013 estimate">2013 estimate<a href=note-5
> > rel=help><sup>5</sup</a></th>
> 
> Nothing is wrong with your suggestion, but table navigation with screen reader
> is burdensome when keyboard focus shifts because the target (footnote) is
> outside the table. For large tables that reference footnotes from within <td>
> or even <th>, managing focus for most user groups can be diffcult. Here
> longdesc, when used, can be helpful.

I don't get how @longdesc would help here given the target of @longdesc would be outside the table too.
Comment 12 Devarshi Pant 2012-09-11 14:08:21 UTC
> If you want a visible description, make it visible and point at it with
> aria-describedby.
> (Requiring sighted keyboard users to use a secondary action on a control just
> to get additional explanation seems like terrible UI by the way.)

Your point is taken, but I disagree, there is no terrible UI when content is accessible. If aria-describedby points to visible text, how does a sighted user or a magnifier user track focus to the visible description. It will depend on how aria-describedby is implemented here, like any other technique.

> I don't get how @longdesc would help here given the target of @longdesc would
> be outside the table too.

Well, using longddesc, the keyboard focus will land on the link that was selected once the target dialog is closed, thus preserving focus. Technically, I do not see any issue there, unless implementers have UI issues.
Comment 13 Benjamin Hawkes-Lewis 2012-09-11 14:30:36 UTC
(In reply to comment #12)
> > If you want a visible description, make it visible and point at it with
> > aria-describedby.
> > (Requiring sighted keyboard users to use a secondary action on a control just
> > to get additional explanation seems like terrible UI by the way.)
> 
> Your point is taken, but I disagree, there is no terrible UI when content is
> accessible.

It's easy to make content and functionality available to an accessibility API but still hard to use, people do that all the time.

> If aria-describedby points to visible text, how does a sighted user
> or a magnifier user track focus to the visible description.

Same way as content focus is normally tracked? I don't understand the problem here.

> > I don't get how @longdesc would help here given the target of @longdesc would
> > be outside the table too.
> 
> Well, using longddesc, the keyboard focus will land on the link that was
> selected once the target dialog is closed, thus preserving focus.

If you navigate a same-page link, then navigate back, keyboard focus should land on the same-page link. (There may be client software where that doesn't happen, however that's a clear usability defect.)

Users have the option to open the footnote link in a new window, which should provide the same experience as an AT triggering opening @longdesc in a new window.

Authors have the option of linking to notes on other pages, or suggesting the opening of a new window with @target=_blank.

Client software has the option of developing specific behaviors around @rel=help such as always opening help links in a new window.
Comment 14 Benjamin Hawkes-Lewis 2012-09-11 14:50:58 UTC
With respect to the original use case of "table header cell superscripts and footnotes", it might make for better hypermedia practice to convert notes on table headers into progressively disclosed inline details. For example:

  <th abbr=Population>
    <details>
      <summary>Population</summary>
      2008 figures from CIA World Factbook.
      </details> 
  </th>
Comment 15 Devarshi Pant 2012-09-11 15:21:06 UTC
> > If aria-describedby points to visible text, how does a sighted user
> > or a magnifier user track focus to the visible description.
> Same way as content focus is normally tracked? I don't understand the problem
> here.

The problem I have is with sending the focus away and then navigating back when more than link needs to be described. On a complex UI with many links, navigating back and forth from focusable targets (visible) is not something I would want to experience as a user. 

> > Well, using longddesc, the keyboard focus will land on the link that was
> > selected once the target dialog is closed, thus preserving focus.
> If you navigate a same-page link, then navigate back, keyboard focus should
> land on the same-page link. (There may be client software where that doesn't
> happen, however that's a clear usability defect.)
> Users have the option to open the footnote link in a new window, which should
> provide the same experience as an AT triggering opening @longdesc in a new
> window.
> Authors have the option of linking to notes on other pages, or suggesting the
> opening of a new window with @target=_blank.
> Client software has the option of developing specific behaviors around
> @rel=help such as always opening help links in a new window.

Extending the longdesc attribute (however far-fetched) might also include setting properties of the new window to simulate lightboxes and other display types.
Comment 16 Devarshi Pant 2012-09-11 15:38:09 UTC
(In reply to comment #14)
> With respect to the original use case of "table header cell superscripts and
> footnotes", it might make for better hypermedia practice to convert notes on
> table headers into progressively disclosed inline details. For example:
>   <th abbr=Population>
>     <details>
>       <summary>Population</summary>
>       2008 figures from CIA World Factbook.
>       </details> 
>   </th>

Good suggestion. I just hope that the table navigation does not get verbose when inline details are set to 'open.'
Comment 17 Robin Berjon 2013-01-21 15:58:01 UTC
Mass move to "HTML WG"
Comment 18 Robin Berjon 2013-01-21 16:00:48 UTC
Mass move to "HTML WG"
Comment 19 Charles McCathieNevile 2015-06-12 14:29:23 UTC
This is a generalised case of longdesc, for things other than images. Contextual help for forms, glossary entries, etc.

It probably takes a bunch of fixes for this, although longdesc solves at least one part of it...
Comment 20 Michael[tm] Smith 2015-06-16 11:59:50 UTC
Per comment 19 this looks like it should just be resolved as being covered by longdesc.
Comment 21 Léonie Watson 2015-06-16 13:12:48 UTC
(In reply to Michael[tm] Smith from comment #20)
> Per comment 19 this looks like it should just be resolved as being covered
> by longdesc.

Only for the use case concerning <img>. That said, I'm not convinced the other use cases are strong enough to warrant extending the capability of @longdesc to be applied to other elements.
Comment 22 Devarshi Pant 2015-06-16 13:36:13 UTC
Hi All,

I think longdesc has its own use and this suggestion goes beyond describing images and would include page elements that receive keyboard focus (using both tabbing and arrow keys navigation modalities). I am hoping that we would either extend aria-describedby (labelledby) by incorporating this suggestion, or create a new feature (say, "aria-extlabelledby").

Thanks,
Devarshi
Comment 23 John Foliot 2015-06-16 18:24:47 UTC
(In reply to Devarshi Pant from comment #22)
> Hi All,
> 
> I think longdesc has its own use and this suggestion goes beyond describing
> images and would include page elements that receive keyboard focus (using
> both tabbing and arrow keys navigation modalities). I am hoping that we
> would either extend aria-describedby (labelledby) by incorporating this
> suggestion, or create a new feature (say, "aria-extlabelledby").
> 
> Thanks,
> Devarshi

Hi Devarshi,

I think that the proposed aria-describedat attribute (ARIA 1.1) will also go a long way to addressing the core issue described by you. 
See: http://www.w3.org/TR/2013/WD-wai-aria-1.1-20130926/states_and_properties#aria-describedat

(see the code example included with the above - is this what you are envisioning?)

While I agree that HTML5 *should* have a native equivalent, I'm not sure at this time whether one will come forward.

HTH
Comment 24 Devarshi Pant 2015-06-16 20:19:51 UTC
Hi John,

This is a good example. It will be interesting to see how screen readers parse content identifiers outside the page.

So, besides aria-describedat:

1. would it justify using a new attribute to refer external content (description) at this point? 

2. can this be part of native HTML5, like title or alt?

3. can this be extended to websites with IDs pointing to content in another website?

Thanks,
Devarshi
Comment 25 Léonie Watson 2015-06-17 08:40:43 UTC
(In reply to Devarshi Pant from comment #24)
> So, besides aria-describedat:
> 
> 1. would it justify using a new attribute to refer external content
> (description) at this point? 

No, I don't believe there is a good use case for introducing a new attribute or extending the capability of @longdesc. To take the use cases you mentioned originally...

1. Where the describedby text need not be visible on the same page.
5. When a superscript needs to be associated.

A link would seem to be a good way to accomplish this without any new HTML attribute.

2. When an image needs a description.

@longdesc exists and is intended for this.

3. Link needs additional description.

If a link requires additional description, it is arguably not doing its job as a signpost to a resource properly. The exception might be an extended image description, but @longdesc is there for this.

4. Form control needs additional explanation.

If a form control requires additional explanation, sending someone to an external resource is not good UX. Form state is often temporary (until the form is submitted), so sending someone to an external resource would either require that the form state be made persistent, that a new browser window/tab was opened, or that a dialogue/lightbox widget was used. Keeping such additional information in-line using aria-describedby is a better (and more universal) option.

So in short, it seems that the ability to solve each of the use cases already exists within the HTML and/or ARIA specs.
Comment 26 Charles McCathieNevile 2015-06-17 21:12:48 UTC
(In reply to Léonie Watson from comment #25)
> (In reply to Devarshi Pant from comment #24)
> > So, besides aria-describedat:
> > 
> > 1. would it justify using a new attribute to refer external content
> > (description) at this point? 
> 
> No, I don't believe there is a good use case for introducing a new attribute

There may be, but we need to have clear use cases, with intent to implement.

> or extending the capability of @longdesc.

I would be surprised if there is much appetite for doing this. I'm certainly unconvinced that it is worth pursuing in general…

> To take the use cases you
> mentioned originally...
> 
> 1. Where the describedby text need not be visible on the same page.

This is what describedAt is meant to do, if you mean "the text must not be visible on the same page - but will be on a different one".

> 5. When a superscript needs to be associated.

I don't actually understand the use case, unless it is ruby text which is already covered.

> A link would seem to be a good way to accomplish this without any new HTML
> attribute.
> 
> 2. When an image needs a description.
> 
> @longdesc exists and is intended for this.

Agreed
 
> 3. Link needs additional description.
> 
> If a link requires additional description, it is arguably not doing its job
> as a signpost to a resource properly. The exception might be an extended
> image description, but @longdesc is there for this.

This is a case where there might be something worth considering. But I think we should have clear real-world examples to understand how important this is.
 
> 4. Form control needs additional explanation.
> 
> If a form control requires additional explanation, sending someone to an
> external resource is not good UX. Form state is often temporary (until the
> form is submitted), so sending someone to an external resource would either
> require that the form state be made persistent, that a new browser
> window/tab was opened, or that a dialogue/lightbox widget was used. Keeping
> such additional information in-line using aria-describedby is a better (and
> more universal) option.

aria-describeBy has a bunch of problems. First, it is theoretically only expected to be available to people using assistive technologies, and in practice only for those using screen readers, which is a pretty long way from being universal. This is one of the major problems with ARIA in general.

Second, aria-describedBy only allows a text string - no rich content whatsoever - which further reduces its value.
 
> So in short, it seems that the ability to solve each of the use cases
> already exists within the HTML and/or ARIA specs.

I am not so sure that is the case. That said, I also haven't seen the justification for actually changing the specifications to meet the use cases.
Comment 27 Léonie Watson 2015-06-17 22:37:23 UTC
(In reply to Charles McCathieNevile from comment #26)
> (In reply to Léonie Watson from comment #25)
> > 4. Form control needs additional explanation.
> > 
> > If a form control requires additional explanation, sending someone to an
> > external resource is not good UX. Form state is often temporary (until the
> > form is submitted), so sending someone to an external resource would either
> > require that the form state be made persistent, that a new browser
> > window/tab was opened, or that a dialogue/lightbox widget was used. Keeping
> > such additional information in-line using aria-describedby is a better (and
> > more universal) option.
> 
> aria-describeBy has a bunch of problems. First, it is theoretically only
> expected to be available to people using assistive technologies, and in
> practice only for those using screen readers, which is a pretty long way
> from being universal. This is one of the major problems with ARIA in general.

It is a problem for ARIA in general, yes. In this case , the common pattern is to use ARIA to duplicate a relationship that is already available to everyone else though.

Conventional form design places additional hint information close to the field it relates to, establishing a visual relationship between the two. In this instance ARIA makes that association available to screen reader users in addition to everyone else, rather than to the exclusion of everyone else.

> 
> Second, aria-describedBy only allows a text string - no rich content
> whatsoever - which further reduces its value.

Only to the extent that a screen reader will reduce structured content to a string when the element it describes receives focus. But the descriptive content itself can be structured 

The drawback is that @aria-describedby doesn't establish a navigable association between the element and its description. The proposed @aria-describedat attribute would provide that navigable relationship I believe.
Comment 28 Devarshi Pant 2015-10-28 16:40:43 UTC
(In reply to Léonie Watson from comment #27)
> (In reply to Charles McCathieNevile from comment #26)
> > (In reply to Léonie Watson from comment #25)
> > > 4. Form control needs additional explanation.
> > > 
> > > If a form control requires additional explanation, sending someone to an
> > > external resource is not good UX. 

Hi Leonie,
Sorry if I wasn’t clear enough, but what I meant was to call in the content from an external source while the user stays in the same location - not send someone over. Maybe form fields are not a good example. 
Another example: A typical Wikipedia page on well-known topics is chock-full of links targeting other wiki pages. Let us consider a URL - https://en.wikipedia.org/wiki/Carl_Sagan. Also, please note that my intent is to make it easier for screen reader users to get information without hunting for information.
So, in the traditional sense using the above mentioned example, a user is expected to click every link on the page to get the required info, say astronomer, then cosmologist, etc. A possible downside is that whenever the user backs up to get to the parent page, the keyboard focus is on the address bar. Some power users may get around it, but I am not certain regarding others.
Now coming to what I was referring to using the new (modified) attribute:
** A user is on the specific wiki page (or any page with numerous links), and as and when they interact with the link, a brief description of the first few lines that reside in the target page gets enunciated. JAWS or any other screen reader , when on the link, would speak- "astronomer link, contains described text - press [modifier key] to read..."

-Devarshi

> > > Form state is often temporary (until the form is submitted), so sending someone to an external resource would either
> > > require that the form state be made persistent, that a new browser
> > > window/tab was opened, or that a dialogue/lightbox widget was used. Keeping
> > > such additional information in-line using aria-describedby is a better (and
> > > more universal) option.
> > 
> > aria-describeBy has a bunch of problems. First, it is theoretically only
> > expected to be available to people using assistive technologies, and in
> > practice only for those using screen readers, which is a pretty long way
> > from being universal. This is one of the major problems with ARIA in general.
> 
> It is a problem for ARIA in general, yes. In this case , the common pattern
> is to use ARIA to duplicate a relationship that is already available to
> everyone else though.
> 
> Conventional form design places additional hint information close to the
> field it relates to, establishing a visual relationship between the two. In
> this instance ARIA makes that association available to screen reader users
> in addition to everyone else, rather than to the exclusion of everyone else.
> 
> > 
> > Second, aria-describedBy only allows a text string - no rich content
> > whatsoever - which further reduces its value.
> 
> Only to the extent that a screen reader will reduce structured content to a
> string when the element it describes receives focus. But the descriptive
> content itself can be structured 
> 
> The drawback is that @aria-describedby doesn't establish a navigable
> association between the element and its description. The proposed
> @aria-describedat attribute would provide that navigable relationship I
> believe.
Comment 29 Charles McCathieNevile 2016-04-14 14:24:00 UTC
There are some specific types of linking, like longdesc, rel={some things}, which provide this functionality, and some other elements like summary/details that can enable the relevant functionality for various cases. But there has been consistent disagreement that we need a single generic mechanism for "description" of elements.

This seems unlikely to happen.