Re: Microsoft IE bug regarding aria-describedby and the accessibility tree Description property from Steve Faulkner on 2014-06-09 (public-pfwg@w3.org from June 2014)

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Mon, 9 Jun 2014 22:27:20 +0100
To: Cynthia Shelly <cyns@microsoft.com>
Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, PF <public-pfwg@w3.org>
Message-ID: <CA+ri+VkTEXiY=V6FrW+Mwc2QFM-uekjej5Lw5EtCpp5j+7JMZw@mail.gmail.com>
>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 Monday, 9 June 2014 21:28:27 UTC