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

Re: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Tue, 14 Aug 2012 20:51:31 +0100
Message-ID: <CAEhSh3eNLOuS5-3tQe7C-vbqobY4=NuEAq__0w8k0JwCr=Ekgg@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 August 2012 19:52:21 GMT