[Bug 18385] Programmatic association of a page element to a 'description' text in a different uri

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18385

Charles McCathieNevile <chaals@yandex-team.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |devarshipant@gmail.com
              Flags|                            |needinfo?(devarshipant@gmai
                   |                            |l.com)

--- Comment #26 from Charles McCathieNevile <chaals@yandex-team.ru> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 17 June 2015 21:12:51 UTC