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 L. Carlson
Received on Wednesday, 19 September 2012 11:01:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:30 UTC