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

I also wrote a blog post about the issue:
http://blog.paciellogroup.com/2014/06/aria-labelledby-aria-describedby-support-popular-windows-browsers/

--

Regards

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


On 10 June 2014 14:01, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> bug filed
> https://connect.microsoft.com/IE/feedback/details/893109/limited-support-for-aria-labelledby-and-aria-describedby-in-ie
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>
>
> On 9 June 2014 22:27, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
>> >Please resubmit the bug.  A lot has changed since 2010.
>>
>> will do, am just finishing off some updates tests for the issue.
>>
>> --
>>
>> Regards
>>
>> SteveF
>> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>>
>>
>> On 9 June 2014 22:24, Cynthia Shelly <cyns@microsoft.com> wrote:
>>
>>>  Please resubmit the bug.  A lot has changed since 2010.
>>>
>>>
>>>
>>> *From:* Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
>>> *Sent:* Monday, June 9, 2014 2:13 PM
>>>
>>> *To:* 'Steve Faulkner'
>>> *Cc:* 'PF'
>>> *Subject:* RE: Microsoft IE bug regarding aria-describedby and the
>>> accessibility tree Description property
>>>
>>>
>>>
>>> Thanks, that is really bizarre.
>>>
>>>
>>>
>>> According to the link referenced:
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/ms528445(v=VS.85).aspx#acc_elements
>>>
>>>
>>>
>>> Accessible elements include only the following:
>>>
>>>
>>>
>>> ·         a
>>> <http://msdn.microsoft.com/en-us/library/ms535173(v=vs.85).aspx>
>>>
>>> ·         applet
>>> <http://msdn.microsoft.com/en-us/library/ms535183(v=vs.85).aspx>
>>>
>>> ·         area
>>> <http://msdn.microsoft.com/en-us/library/ms535185(v=vs.85).aspx>
>>>
>>> ·         body
>>> <http://msdn.microsoft.com/en-us/library/ms535205(v=vs.85).aspx>
>>>
>>> ·         button
>>> <http://msdn.microsoft.com/en-us/library/ms535211(v=vs.85).aspx>
>>>
>>> ·         document
>>> <http://msdn.microsoft.com/en-us/library/ms531073(v=vs.85).aspx>
>>>
>>> ·         embed
>>> <http://msdn.microsoft.com/en-us/library/ms535245(v=vs.85).aspx>
>>>
>>> ·         frame
>>> <http://msdn.microsoft.com/en-us/library/ms535250(v=vs.85).aspx>
>>>
>>> ·         frameSet
>>> <http://msdn.microsoft.com/en-us/library/ms535251(v=vs.85).aspx>
>>>
>>> ·         iframe
>>> <http://msdn.microsoft.com/en-us/library/ms535258(v=vs.85).aspx>
>>>
>>> ·         img
>>> <http://msdn.microsoft.com/en-us/library/ms535259(v=vs.85).aspx>
>>>
>>> ·         input
>>> <http://msdn.microsoft.com/en-us/library/ms535260(v=vs.85).aspx>
>>>
>>> ·         marquee
>>> <http://msdn.microsoft.com/en-us/library/ms535851(v=vs.85).aspx>
>>>
>>> ·         object
>>> <http://msdn.microsoft.com/en-us/library/ms535859(v=vs.85).aspx>
>>>
>>> ·         select
>>> <http://msdn.microsoft.com/en-us/library/ms535893(v=vs.85).aspx>
>>>
>>> ·         table
>>> <http://msdn.microsoft.com/en-us/library/ms535901(v=vs.85).aspx>
>>>
>>> ·         td
>>> <http://msdn.microsoft.com/en-us/library/ms535903(v=vs.85).aspx>
>>>
>>> ·         textArea
>>> <http://msdn.microsoft.com/en-us/library/ms535904(v=vs.85).aspx>
>>>
>>> ·         TextRange
>>> <http://msdn.microsoft.com/en-us/library/ms535872(v=vs.85).aspx>
>>>
>>> ·         th
>>> <http://msdn.microsoft.com/en-us/library/ms535908(v=vs.85).aspx>
>>>
>>> ·         window
>>> <http://msdn.microsoft.com/en-us/library/ms535873(v=vs.85).aspx>
>>>
>>>
>>>
>>> Then the following is stated:
>>>
>>>
>>>
>>> The following elements are nonaccessible:
>>>
>>>
>>>
>>> ·         b
>>> <http://msdn.microsoft.com/en-us/library/ms535189(v=vs.85).aspx>
>>>
>>> ·         div
>>> <http://msdn.microsoft.com/en-us/library/ms535240(v=vs.85).aspx>
>>>
>>> ·         i
>>> <http://msdn.microsoft.com/en-us/library/ms535257(v=vs.85).aspx>
>>>
>>> ·         span
>>> <http://msdn.microsoft.com/en-us/library/ms535895(v=vs.85).aspx>
>>>
>>> ·         u
>>> <http://msdn.microsoft.com/en-us/library/ms535913(v=vs.85).aspx>
>>>
>>> ·         Any custom elements that are not part of the HTML standard.
>>>
>>>
>>>
>>> The only thing that defines what is meant by an element that is ‘not
>>> accessible’, is this at the beginning:
>>>
>>>
>>>
>>> Some HTML elements—images, text, and links—are accessible, and some are
>>> not. Each accessible element (tag) in an HTML document is represented in
>>> the document's accessibility hierarchy. For more information about the
>>> accessibility hierarchy, see About Active Accessibility Support
>>> <http://msdn.microsoft.com/en-us/library/ms528415(v=vs.85).aspx>.
>>>
>>>
>>>
>>> Does anybody know what is meant by an element not being accessible? This
>>> is confusing me because it doesn’t appear to be a matter of active versus
>>> non-active elements, since TABLE, TD, and THs are supported, but other
>>> static element container types are not.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Steve Faulkner [mailto:faulkner.steve@gmail.com
>>> <faulkner.steve@gmail.com>]
>>> *Sent:* Monday, June 09, 2014 9:06 AM
>>> *To:* Bryan Garaventa
>>> *Cc:* PF
>>> *Subject:* 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/>
>>>
>>>
>>>
>>
>>
>