Re: Promise broken on ISSUE 204?

On Tue, May 8, 2012 at 1:21 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>> On May 7, 2012, at 3:03 PM, Benjamin Hawkes-Lewis wrote:
>
>>> As far as I know, nobody has put forward a single example where they
>>> are happy to declare that placing accessibility-related content in
>>> @hidden would be better for users and authors than alternative
>>> techniques.

> Benjamin, one of the alternative techniques authors are going to use,
> is <element style=display:none >Hide me.</element>,
> which, as you said, would be problematic if viewed without CSS enabled.
> The same goes for placing content off screen. Thus, for authors, it
> would often better to place it inside
>   <element hidden >Hide me.</element>

I think I've failed to make myself clear.

Accessibility-related content is relevant to the current application
state, not irrelevant. It should be usually be available when author
styles are not applied and images are not loaded.

Content irrelevant to the current application state should *not* be
available when author styles are not applied, because its irrelevance
is not a purely stylistic issue. I think it makes sense, given its
original design, to place irrelevant content in @hidden.

What I'm asking about is why we should support putting content
relevant to the current application state (such as labels and
descriptions applicable to visible content, or in Maciej's argument
whole navigable subtrees!) in an attribute originally intended to
designate content irrelevant to the current application state.

> My question: Why can't this method be used in *combination* with
> @hidden? It seems at least John F's updated version of the change
> proposal, nothing would prevent you from doing that.

Off-screen controls are included in the tab order, exposed the
accessibility tree, listed in enumerations of controls (e.g. JAWS link
list), available to skip commands, and are available to users who do
not apply author styles.

Under the new proposal, @hidden controls wouldn't have any of these
advantages AFAICT.

If we're talking purely about UA conformance requirements *and* we
think authors are more likely to err by including content that should
be rendered in @hidden than expecting @hidden content to be rendered,
why don't we mandate that *if* content focus or interactive focus is
moved into a @hidden subtree, the hidden property should be removed
from the subtree until focus leaves again? I don't understand what
future leap of technology we're waiting around for here by leaving
behavior undefined.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 8 May 2012 18:40:48 UTC