Re: Drop longdesc, get aria-describedat?

Quoting Richard Schwerdtfeger <schwer@us.ibm.com>:

> We need to separate out what ARIA specifies and how IE or other browser
> handle longdesc. First formal longdesc mappings to accessibility API was
> never done by industry. Consequently implementations vary. As I understand
> it IE maps the URL string to a description which to me is of little value.
> Imagine asking for the help text and hearing "http://www... ". Yuck.

While I do not disagree with the "Yuck-factor", based on how the AAPIs  
and the ARIA implementation guide explains how "hidden" content is  
processed, we can't argue with how they are processing the hidden  
content today - or am I wrong?
(Perhaps they should have mapped it to ROLE_SYSTEM_LINK?)


> The
> reason they may have done this because MSAA was very limited when it
> released and its use was not well documented. So, developers did the best
> they could and they would stick information into the limited property set
> available. The IE folks probably thought "accDescription, it take a string.
> Put it there." It is what it is. We can do better.

Absolutely! What I continue to question is why we are hell-bent on  
pushing this into the realm of the Accessibility APIs?


>
> What longdesc should be for is referencing rich content that can be seen in
> a browser or accessed by and AT for browsing the content.

See my previous question/point. If the goal is that the "rich content"  
can be "seen" by all users, relying on the Accessibility APIs to  
deliver that means that many non-AAPI-using consumers (i.e. anyone  
consuming web content with tools that are not AAPI aware) are left in  
the cold. As far as I know today, pretty much the only tools that  
*are* AAPI-aware are the class of tools we call "screen readers". What  
of my Dad, who has nothing more than a browser on his Windows XP  
machine?  How does he get to that additional rich content?

Thus I can only surmise that the browsers need to become significantly  
more AAPI/ARIA aware or we spec out a mechanism that does not rely on  
the AAPI to deliver useful functionality to *all* users.


> Stuffing a string
> with a URL does not achieve that.
>
> aria-describedby was designed to reference local content that can be seen
> and reviewed by a user unless it is hidden to the user in which case the
> content being pointed to is provided a human speakable help string in the
> accessibility API.

Yup, got that. If "on screen" then it is referenced. If "not visible"  
then is rendered as help string (with emphasis on "string"). In fact  
(and I need to do more testing) even if rendered on screen, I do not  
think that the semantic markup is fully conveyed by screen readers as  
part of the describedby functionality (off to write a test-case...)


>
> These are different use case. Steve and I are working on an ARIA placement
> for longdesc that we intent to be better specified to meet the use case.
> Example use case: User walks into a museum and sees a kiosk with images
> that indicate more information is available.

At the risk of harping on a particular point (a trait I am aware I  
have), I want to once-again point out Rich's use of the word "sees".  
Any replacement that emerges, whether in the ARIA family or in the  
HTML (attribute) family will require that the additional rich content  
be rendered ON SCREEN if we are to achieve success for all users. This  
is very much a User Agent problem!

And if the GUI User Agents cannot or will not support that user  
requirement, then today @longdesc and some non-GUI user agents  
(notably the market leading JAWS screen reader) *DOES* deliver on the  
functionality to their clients.


> The user commands the user
> agent to render rich content related to that object in the form of HTML
> content in the context at which they are operating. When done, that content
> goes away and returns the user to where they left off on the original page.
> This is different from aria-describedby that only reference content on the
> local page.

Sure, which means that the pattern will require, at it's base, something like:

  aria-NewAttribute="URI_string"

...which will likely need to map to the ROLE_SYSTEM_LINK (instead of  
the default AccDescription that describedby is currently producing)  
*PLUS* the GUI-based User Agents will need to deliver something useful  
to their clients.

As Chaals pointed out almost 3 years ago, we can go through the whole  
process to emerge at the end with something that is essentially what  
@longdesc is today, but with a shiny new name.

If that is what this Working Group thinks is the best path forward,  
then let's get at it - and I am happy to role up my sleeves and assist.

While we are doing that however, @longdesc needs to remain conforming  
in HTML5.

JF

Received on Wednesday, 14 March 2012 16:22:58 UTC