W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

Re: Conflicting inclusion/exclusion criteria for elements in the accessibility tree (Was: Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group)

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Wed, 9 Mar 2016 15:26:05 -0700
Message-ID: <CAFDDJ7xCPHPScgv902jcaOkRevCnS_77fFspKnZSGv8hs7Vf+g@mail.gmail.com>
To: Fred Esch <fesch@us.ibm.com>
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>
It's not quite as simple as you like, Fred, but I think we can break it
down to a 2-step requirement.

To remove an entire sub-branch of content from the accessibility tree, you
need to:

   - Hide it, using native language mechanisms, CSS, or aria-hidden="true"
   - Ensure it cannot receive user focus.
   Note that if you "hide" the element in a way such that it is not
   rendered (e.g., CSS display: none), it will also not receive focus.


To exclude structural mark-up from the accessibility tree because it has no
semantic meaning (while still allowing child content to be processed), you
need to:

   - Give it a role of presentation/none if it does not default to that
   role based on native language semantics
   - Ensure it cannot receive user focus

____________________________

The inconsistent implementation of aria-hidden="false" is a separate
matter.  It relates to using the aria property to *reveal* content to ATs
that would normally be considered hidden by native language mechanisms or
CSS.

Based on Bryan Garaventa & Stefan Schnabel's responses on the other thread,
there seems to be an expectation that aria-hidden="false" can override
"display: none", which I hadn't realized.  I hadn't factored that in to my
priority list, but the change is straightforward.

If there is implementer support for allowing non-rendered content to be
represented in the accessibility tree, it might be possible to allow
structured content (but not interactive content) in SVG <desc> to be
included as browsable nodes in the accessibility tree.  We may want to
revisit this in the SVG-A11y task force once the Core-AAM issues are
settled.


It looks like the discussion of the core issues will happen at the Tuesday
15 March call of the User Agent Implementation (UAI) Task Force, since that
group has responsibility for Core-AAM.  I'll try to be on that call.


On 9 March 2016 at 08:58, Fred Esch <fesch@us.ibm.com> wrote:

> Jumping to Amelia's thread.
>
> I would appreciate as simple as possible methods to determine whether
> something should be included in the accessibility tree or not. Bryan and
> Stefan bring up complications with aria-hidden and CSS display:none, Joseph
> points brings up events as forcing inclusion in the accessibility tree. The
> Note in ARIA 1.1 is disturbing "At the time of this writing, *aria-hidden*
> <https://www.w3.org/TR/wai-aria-1.1/#aria-hidden>="false" is known to
> work inconsistently in browsers. As future implementations improve, use
> caution and test thoroughly before relying on this approach."
>
> We have too complicated a system. How can we give authors guidance if even
> browsers can't agree on what the behavior is.
>
>
Received on Wednesday, 9 March 2016 22:26:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:22 UTC