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

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

Received on Tuesday, 10 June 2014 13:02:37 UTC