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:

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

Received on Wednesday, 15 February 2012 16:25:37 UTC