Re: Drop longdesc, get aria-describedat?

Hi John,

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

yes I think you are wrong.

IE's implemenation does nothing to improve the user experience or to aid
AT's in a useful way.

Firefox also implements longdesc, their implementaion while limited is at
least on  the right track and not a kludge that breaks other stuff.

Firefox exposes an accessible action via IA2, when the action (you can test
it with accprobe and firefox) is invoked the longdesc url is opened ina new
tab/window.

I say this is limited as it suffers from the limitations of the AT
implementations i.e.  only opens the URL in a new window.

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

i guess what you mean is why push it into the realm of AAPI support only,
without other general UI support.


regards
Stevef


On 14 March 2012 16:22, John Foliot <john@foliot.ca> wrote:

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


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html