Re: From the HTML-WG about aria-hidden

Some comments, to - perhaps - clarify that we are on the same page in 
this dbate - see below.

Richard Schwerdtfeger, Wed, 15 Feb 2012 15:59:04 -0600:
> Joseph Scheuhammer wrote on 02/15/2012 10:25:06 AM:

>> With respect to aria-describedby the above proposes that
>> aria-describedby trumps aria-hidden,

It is ARIA 1.0 that causes aria-hidden to be trumped:

'Skip hidden elements unless the author specifies to use them
 via an aria-labelledby or aria-describedby.'

>> and forces the rendering of the hidden element.

No. Not rendering. It is just included in the 'accessible name' - like 
@alt text. ISSUE-204 is about making it possible to 'render' it as a 
shadow DOM 'thingy' to AT. It would be hidden to AT too, except when 
the AT presents an element's ARIA-describedby references to the user.

>> It goes further, and requires that elements hidden via
>> CSS must be exposed if they are referenced by some aria-* attribute:

In ARIA 1.0, 'hidden' covers 'hidden via CSS'

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

Rich, before you conclude: ISSUE-204 does not touch the way in which 
aria-describedby 'trumps aria-hidden'. *That* is described in ARIA 
1.0.  ISSUE-204 is instead about HTML5's @hidden. And even though 
@hidden implies @aria-hidden, they are different things.

First and foremost - whether the idea is good or bad - the intention is 
*not* that @hidden content gets 'rendered' - to all users, in a visual 
way. The idea is only that, instead of being presented as a text string 
- to AT  [as *required* by ARIA] - the @hidden content is instead 
presented to AT with *full semantics [as *recommended* by ARIA].

ISSUE-204 in a summary:  @aria-describedby 'flattens' semantics such as 
links. @longdesc does not have this problem. Jonas Sicking is therefore 
suggesting that when aria-describedby points to content that has the 
HTML5 @hidden attribute, *then* its content will be 'rendered' with 
full semantics - to the AT user and AT users alone. That way, @longdesc 
will loose this advantage. And the case for deprecation of @longdesc 
gets - to put it bluntly - stronger. [At least to the degree that the 
chairs is looking for @longdesc to be very different from 

Of course, I think that Jonas' motivation is not deprecation in itself, 
but to improve the AT presentation. And Maciej hinted in one of his 
letters last week, that making @hidden content visible to AT users in 
this way, is technically similar to making the shadow DOM of <canvas> 

Here is hoping that we, in the same go, could make AT read the fallback 
of <object> - which AT currently has problems with. 

So, when aria-describedby points to an aria-hidden=true section, then 
ISSUE-204 promises the following:

* When the aria-hidden=true section is visually visible [as permitted
  with a MAY by ARIA 1.0], then it sounds simple to render it with 
  'full semantics', if the AT is capable of doing that.

* When the aria-hidden=true section has display:none, then it looks
  like ISSUE-204 has nothing to offer - it seems likely that the 
  @aria-describedby content in that case will be presented as string.

* When the aria-hidden=true is implied via the presence of @hidden, 
  *then* ISSUE-204 suggest that the the UA should render some kind
  of accessible shadow down [see the link to Macie's letter above].

So, there is nothing in ISSUE-204 that would make anything visible *to 
Leif Halvard Silli

Received on Thursday, 16 February 2012 00:32:37 UTC