- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 19 Sep 2012 06:00:49 -0500
- 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 UTC