W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Re: additional sentence for 204

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Wed, 19 Sep 2012 06:00:49 -0500
Message-ID: <CAOavpvcAbs3__rVKx7dXPeV_jZrHZPhKPJhhP4g=Wm7qCrK88g@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, James Craig <jcraig@apple.com>, Cynthia Shelly <cyns@microsoft.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "Ted O'Connor" <eoconnor@apple.com>
Hi Maciej,

On Tue, Sep 18, 2012 at 11:57 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Sep 18, 2012, at 9:28 AM, Laura Carlson <laura.lee.carlson@gmail.com> wrote:
>
>> Hi Janina,
>>
>> 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?

It could natively mean: this is element is hidden but discoverable. So
browsers would make it discoverable to users who wanted access to it.

Best Regards,
Laura

-- 
Laura L. Carlson
Received on Wednesday, 19 September 2012 11:01:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 11:01:19 GMT