Re: Promise broken on ISSUE 204?

Benjamin Hawkes-Lewis, Tue, 8 May 2012 19:39:56 +0100:
> On Tue, May 8, 2012 at 1:21 AM, Leif Halvard Silli 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.

OK. You mean that it should then fallback to be visible. Is that the 
whole idea?

For whom would that be good or relevant? 
* Not for users of ARIA supporting UAs, anyway: The ARIA support 
doesn't disappear just because CSS is disabled.
* And if, instead of @hidden, authors used aria-hidden="true" in 
combination with CSS, then, if CSS was disabled, the element would 
still be hidden, from assistive technology's point of view. (As you 
know, ARIA says that you MUST - unless you use a native feature, like 
@hidden - use aria-hidden='true' for hidden content.)
* It could be relevant for text browsers. But currently, I think none 
of them support @hidden. When they implement @hidden, then it could 
make sense.

> 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.

I agree that it makes sense to not use @hidden if the purpose is that 
it falls back to become visible when CSS is disable. 

If so, perhaps it would be better to describe the ideal instead of 
forbidding anything ... Also, if you want to forbid authors from doing 
it, then there is many more things that should be forbidden. 

Such as: <foo aria-labelledby=script></foo>
         <script id=script>Description here</script>
    And: <head><script id=script>Description here</script>
         </head><body><foo aria-labelledby=script></foo>
    And: <foo aria-labelledby=empty></foo>
         <span id=empty aria-label="Description here"></span>

> 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.

Strictly speaking, "current state" means "any state". E.g. let's say an 
application has two states: You are not required to remove @hidden from 
any of the states.

>> 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.

You said "when JS is available":

>>> when JS is available, hide extra content off-screen but move it
>>> on-screen if it receives focus?

And JS can remove @hidden. But OK. I don't know exactly what you meant. 
Perhaps you meant CSS? 

> 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.

It is a pure author requirement that 
   <div id=i hidden tabinde=0>foo</div> 
shouldn't be made linked to via hyperlink. Since it can be linked to, 
it can also be made visible - and thus focusable - via CSS: 
*:target{display:block}. So we might see that authors makes a @hidden 
section visible and focusable.

Leif H Silli

Received on Tuesday, 8 May 2012 21:23:06 UTC