- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Tue, 14 Aug 2012 20:51:31 +0100
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Maciej Stachowiak <mjs@apple.com>, John Foliot <john@foliot.ca>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Tue, Aug 14, 2012 at 8:32 PM, Janina Sajka <janina@rednote.net> wrote: > There's also a large set of users/use.cases where the a11y accomodation > is input side, not output side. A simple example is the mouth-stick user > who requires sticky keys, and not much else. They will > TAB/otherwise.navigate into a morase of content that is not displayed on > screen. No they won't - or at least, not as envisaged by the proposed spec text. The premise of complex hidden long descriptions is that there will exist complex long descriptions that are so useless to most users that there must be no default visual indicator that they even exist, but so useful to a minority of users that they must be capable of being opened. Mouth-stick users who need to open complex long descriptions will need clientside software (whether that's a browser or AT or some combination of the two) that renders them on screen at least while focus is inside the long description. Mouth-stick users who don't need to open complex long descriptions won't need such clientside software and therefore won't be opening complex long descriptions, and therefore will not fall into an invisible keyboard trap. Clientside software that moves focus into complex content hidden using the @hidden attribute without showing the content in some way would be buggy. I'd suggest the same would be true for content hidden using the aria-hidden attribute. -- Benjamin Hawkes-Lewis
Received on Tuesday, 14 August 2012 19:52:21 UTC