Re: Microsoft IE bug regarding aria-describedby and the accessibility tree Description property

FYI this is the response i received from microsoft on the bug I filed about
this issue back in 2010:

As we evaluated this bug report and the repro page, we found that the test
> cases failed because of three different issues:
>
> 1.    When presented with multiple labeledby and describedBy elements IE
> did not concatenate the values from those elements into the MSAA name or
> description.
>
> 2.    When an element contained a native accessibility attribute (title
> or alt) the aria-labeledBy and describedBy attributes did not take
> precedence over the native attributes.
>
> 3.    The value of the elements pointed at by the aria-labeledby and
> describedby is only available to the accessibility properties if the
> elements themselves are accessible objects.  Not all IE elements are
> accessible objects as is described here:
> http://msdn.microsoft.com/en-us/library/ms528445(v=VS.85).aspx#acc_elements
> (*Note - I have asked Cullen to check this documentation as I’m not sure
> how accurate it is but it was the best I could find.  It doesn’t mention
> that adding an aria-role to an element also makes it accessible.)
>
>
>
> We fixed the first two issues. IE9 will now concatenate the value of
> multiple labeledby/describedby elements and use labeledby/described by to
> trump native accessibility attributes if the labeledby/describedby elements
> are accessible objects.  The list of elements which are automatically
> accessible objects is here:
> http://msdn.microsoft.com/en-us/library/ms528445(v=VS.85).aspx#acc_elements
> and you can easily make any other element an accessible object by adding a
> tabindex or an aria role to it.
>
>
>
> While we investigated fixes for the third issue, it will not be resolved
> in IE9.  However, we will revisit this in the future.  Since the test
> page requires all three issues to be fixed, you won’t see the expected
> behavior on that page.  The workaround is to add a role=’tooltip’
> attribute on elements l1, l2, l3, d1 and d2 on the test page then you will
> see all the tests working.
>
Regards, The Microsoft Connect Team.
>



--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 7 June 2014 18:51, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
wrote:

> Steve Faulkner wrote:
>
> "it’s an implementation detail and authoring issue, suggest filing bugs
> against the ARIA implementation guide and authoring practices docs."
>
>
>
> Are you saying that the spec text should be changed for both
> aria-labelledby and aria-describedby?
>
>
>
> E.G
>
>
>
> 'Authors MUST include tabindex="-1" on any container referenced by
> aria-describedby.'
>
>
>
> Just because it doesn't work in Internet Explorer?
>
>
>
>
The aria implementation guide does not make normative  requirements on
authors, neither does the authoring practices guide. So no.




>
>
>
>
> >How would developers ever know this is required for one browser but not
> others?
>
> "by telling them"
>
>
>
> Every time a developer follows the current ARIA spec as they have already
> been doing for years?
>
>
>
> >And why should there be a difference?
>
> "it’s a limitation of IE's implementation."
>
>
>
> I agree, which suggests that this is an IE bug and not an ARIA spec bug.
>

As I stated previously this is not a bug in the ARIA specification itself.
And yes its a bug in IE that Microsoft has stated they can't/won't fix.
That's why I have been telling people how to work around it. I also believe
if there are long standing bugs in implementations or lack of
implementation of specified features that it is useful for specs to provide
information about them, so authors are made aware.



>
>
> I don't know why it was ignored previously, but I don't see that as a
> reason to stop pursuing it.
>

nobody said stop pursuing it, but until it is fixed it is useful
information for authors to be aware of.


>
>
> One thing that has come up many times recently in the PF calls, is that it
> would be great to get ATs to use the accessibility tree and not rely so
> heavily on the DOM as screen readers like JAWS does currently.
>

I can but only agree.

>
>
> If secret caveats like this exist, where the accessibility tree only works
> properly in one browser if you add something that isn't in the ARIA spec,
> which you would only know about if somebody told you, I don't see why AT
> venders would want to use the accessibility tree, because it won't be
> reliable across browsers.
>

caveats will always exist unfortunately


>
>
>
>
> *From:* Steve Faulkner [mailto:faulkner.steve@gmail.com]
> *Sent:* Saturday, June 07, 2014 12:50 AM
>
> *To:* Bryan Garaventa
> *Cc:* PF
> *Subject:* Re: Microsoft IE bug regarding aria-describedby and the
> accessibility tree Description property
>
>
>
>
>
> On 6 June 2014 18:44, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> wrote:
>
> Interesting, there is no mention of this in the spec…
>
> http://rawgit.com/w3c/aria/master/spec/aria.html#aria-describedby
>
>
>
> its an implementation detail and authoring issue, suggest filing bugs
> against the ARIA implementation guide and authoring practices docs.
>
>
>
> How would developers ever know this is required for one browser but not
> others?
>
>
>
> by telling them
>
>
>
> And why should there be a difference?
>
>
>
> its a limitation of IE's implementation.
>
>
>
> I  first reported this back in 2010
>
> http://lists.w3.org/Archives/Public/www-archive/2010Jul/0003.html. At the
> time microsoft wontfixed, then decided to fix, but constrained by the
> limitation I described.
>
>
>
> Unfortunately the related IE bug [1] is no longer available to view. In it
> microsoft responded with pretty much the information I provided about the
> need to use tabindex=-1 etc
>
>
>
>
>
> [1] https://connect.microsoft.com/IE/feedback/details/555280/ie-platform-preview-does-not-support-multiple-values-in-aria-labelledby-and-does-not-support-aria-describedby
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Regards
>
> SteveF
>
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>