[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

Devarshi Pant <devarshipant@gmail.com> changed:

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

--- Comment #28 from Devarshi Pant <devarshipant@gmail.com> ---
(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.

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

Received on Wednesday, 28 October 2015 16:40:48 UTC