Re: From the HTML-WG about aria-hidden

Joseph Scheuhammer <clown@alum.mit.edu> wrote on 02/15/2012 10:25:06 AM:

> From: Joseph Scheuhammer <clown@alum.mit.edu>
> To: "wai-xtech@w3.org" <wai-xtech@w3.org>,
> Cc: Janina Sajka <janina@rednote.net>
> Date: 02/15/2012 10:27 AM
> Subject: Re:  From the HTML-WG about aria-hidden
>
> Janina asked me to re-post this to the wai-xtech (this) list.  To give
> context, she had advised the PFWG regarding the HTML-WG's  take on
> aria-hidden:
>
> > Subject:
> > HTML-ISSUE-204 (aria-hidden): Excempt ARIA attributes from the rule
> > that prohibits reference to hidden elements [HTML 5 spec]
> > From:
> > HTML Weekly Issue Tracker <sysbot+tracker@w3.org>
> > Date:
> > 12-02-14 7:38 AM
> >
> > To:
> > <public-html-wg-issue-tracking@w3.org>
> >
> >
> > HTML-ISSUE-204 (aria-hidden): Excempt ARIA attributes from the
> rule that prohibits reference to hidden elements [HTML 5 spec]
> >
> > http://www.w3.org/html/wg/tracker/issues/204
> >
> > Raised by: Sam Ruby
> > On product: HTML 5 spec
> >
> > This issue was split off of issue-30 and is intended to cover the
> change originally proposed in the details section of:
> >
> >
http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc#Details
> >
> >
>
> To which I replied:
> > This issue was split off of issue-30 and is intended to cover the
> > change originally proposed in the details section of:
> >
> >
http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc#Details
>
> With respect to aria-describedby the above proposes that
> aria-describedby trumps aria-hidden, and forces the rendering of the
> hidden element.  It goes further, and requires that elements hidden via
> CSS must be exposed if they are referenced by some aria-* attribute:
>

I doubt CSS is going to change that any time soon. However, if this goes
through it will break a lot of code where the text is *intentionally*
hidden where CSS is used to hide content. For example, companies do provide
additional help text for form entries and other forms of interactive
components to assist in performing a task. This is there to help people
with disabilities but the author does NOT want to that help information to
be visually exposed such that it clutters up the user interface.


> > Note: Implementations are encouraged to follow the recommendation in
> > ARIA specification and expose the full semantics of any HTML elements
> > linked to by aria attributes. For example if an aria-describedby
> > attribute points to a <a> element or a <table> element, then it is
> > recommended that implementations expose the full semantics of those
> > elements rather than for example just their textual contents. This
> > applies even if those elements aren't rendered, for example due to CSS
>
> This is the opposite of where we landed at yesterday's telecon.  We
> concluded that CSS hiding and aria-hidden trumps aria-describedby.  (The
> rationale being that there is no accessible in the a11y tree for the
> hidden element, so there is nothing to point to via describedby, and
> users cannot navigate to something that isn't rendered).
>
> Which is correct?  The possibilities are:
>
> 1. If an author uses one element to reference another (e.g.,
> aria-describedby, aria-owns, etc.), then user agents must ignore any
> @hidden, @aria-hidden, css visibility:hidden, and display:none. The a11y
> tree exposes both elements, and exposes the relationship between them
> (e.g., described-by/description-for).
>
> 2. If an author uses one element to reference another, but that second
> element is "hidden", then the a11y tree does not contain an accessible
> for the hidden element, and the relationship is not exposed.
>
> The UAIG implies (1) in section "5.1.1 Including Elements in the
> Accessibility Tree" [1], specifically the last bullet:
>
> > * Elements that have an ID which is referenced by another element via
> > a WAI-ARIA relation (aria-controls, aria-describedby, aria-flowto,
> > aria-labelledby or aria-owns) and do not have a role of presentation
> > directly or inherited from an owning element.
>
> Note the escape clause regarding presentation:   if the referenced
> element has role of presentation, then the element is not included,
> regardless of any specified relationship (again, presumably because
> presentation elements are not exposed in the tree).  Easily fixed to add
> another escape with respect to hidden, if we decide that is the way to
go.
>
> Related question:  what happens in a tabbed pane where a tab
> aria-controls a tab panel, but that panel is currently hidden because
> some other tab is selected?  (Assumption: CSS display:none is used to
> hide all the non-selected tab panels).  This is the same issue, but with
> a different relationship.  Does the relationship  possibly shape the
> policy?  Or does hidden always hide the relationship?  My guess is that
> if hidden elements are not exposed, then no relationship can exist.
> Still, it seems odd for the tab panel case; after all, the controlled
> panel still exists; it's just not rendered (i.e, still wrapping my head
> around this).
>
> [1] http://www.w3.org/WAI/PF/aria-implementation/#include_elements
>
> --
> ;;;;joseph.
>
>
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>               - J. D. Klaun -
>
>