[Bug 18744] drop WAI-ARIA scope restriction in the text adopted in ISSUE-204

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744

--- Comment #29 from James Craig <jcraig@apple.com> 2012-09-11 17:19:29 UTC ---
(In reply to comment #28)
> (In reply to comment #26 and comment #27)
> > I don't necessarily agree with that design pattern
> 
> This is something I expected authors to try, because authors have for years
> tried to hide/show error messages for all modalities using "display: none".
> This is one of the use-cases @irrelevant/@hidden was supposed to address, back
> in the day.
> 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Mar/0173.html
> 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2008Aug/0479.html
> 
> >, but there is a potential
> > here to have a more explicit way for users to switch this explicitly for the
> > example you describe.
> > 
> >   aria-hidden="true"
> > 
> > Hides from accessibility APIs no matter if the content is shown or hidden.
> 
> If an element with @aria-hidden=true is referenced by @aria-describedby it
> still contributes to the computed accessible description.
> 
> http://www.w3.org/WAI.new/PF/aria/roles#namecalculation
> 
> http://www.w3.org/WAI.new/PF/aria/terms#def_hidden
> 
> Therefore it's not hidden from accessibility APIs … right?

Yes and no. The hidden node is completely hidden from the accessibility API,
but the calculated label/desc of the element referencing it is exposed as a
string property on the visible element. This bug, and Issue 204 is about
encouraging APIs to allow exposing the semantic of hidden elements in a way
that makes programmatic introspection of the structure possible, while still
clearly marking them as hidden so that AT doesn't stumble upon that content at
inappropriate times.

> The only way for the author to do what he was trying to do is add/remove the
> referenced element from the DOM or to add/remove the id from @aria-describedby.

Currently, yes.

> > think aria-hidden should override hidden="" in all cases, regardless of
> > modality. The flipside applies, too: 
> > 
> >   <div hidden aria-hidden="false">…</div>
> > 
> > That is, specifically hidden from mainstream interfaces, but overridden so that
> > that the structure is available in Accessibility APIs. 
> 
> That does seem to be what the main spec says:
> http://www.w3.org/WAI.new/PF/aria/states_and_properties#aria-hidden
> 
> FWIW the text in the UA implementation guide seems to be saying "host language
> semantics" like CSS "display: none" ("host language"? "semantics"?) win here
> however:
> 
> http://www.w3.org/WAI.new/PF/aria-implementation/#exclude_elements2
> 
> > (Disclaimer: to my
> > knowledge, no Users Agents currently expose hidden content this way.)
> 
> I'm surprised this wasn't cited as a "feature at risk".
> PFWG will wait for implementations of that before letting it pass CR … right?

You raise a good point which I will escalate in PFWG. The aria-hidden property
has been most useful for marking visible elements as hidden, but there are
certainly some good use cases for the flip side, too.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 11 September 2012 17:19:31 UTC