Re: additional sentence for 204

Maciej Stachowiak, Tue, 18 Sep 2012 09:57:28 -0700:
> On Sep 18, 2012, at 9:28 AM, Laura Carlson wrote:

>> On Tue, Sep 18, 2012 at 9:36 AM, Janina Sajka <janina@rednote.net> wrote:
>> 
>>> The intention of the language we're looking for is to allow software to
>>> identify which hidden conten can be revealed to users at their request,
>>> and which content cannot. If the id and href approach is insufficient
>>> for that, then we would need a different approach. But, the approach
>>> must be one that software can reliably use to distinguish between the
>>> two use cases of hidden content.
>> 
>> Here is an idea: add a discoverable attribute. @discoverable or 
>> @nothiddenfromAT
> 
> Would it mean something different than aria-hidden=false?

Currently, aria-hidden=true is a boolean attribute value. Thus 
aria-hidden=false is only informative. I saw that James proposed that 
aria-hidden=false should have an effect. And I suppose @discoverable 
would be no different from aria-hidden=false if James' much sensible 
idea goes through.

It is not important to myself that there is no ARIA interdependence. 
But I thought the purpose of the solution that was put in the spec, was 
to solve the hidden-but-discoverable issue purely from within HTML5, 
without ARIA. This in order to not thread on the toes of ARIA. Because, 
logically, if aria-hidden=false would be necessary in the @usemap/@name 
case, then it would make sense to have the same rule for, for example, 
the @headers/@id case too. And thus, as result, there would be no 
ARIA-free solution in the spec.

From another angle, however, it might not be very important to save the 
independence from ARIA as I believe that we thread on no-ones toes if 
A11Y APIs *do* unhide everything with aria-hidden=false.
-- 
leif halvard silli

Received on Tuesday, 18 September 2012 20:43:23 UTC