RE: Promise broken on ISSUE 204?

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

Off screen tab stops fail WCAG 2.4.7 (focus visible) at level AA. http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html 

The sighted keyboard user who cannot use a mouse, will not know where their focus went and it is disorienting.

Cheers
David MacDonald

CanAdapt Solutions Inc.
  "Enabling the Web"
www.Can-Adapt.com

-----Original Message-----
From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis@googlemail.com] 
Sent: May-08-12 2:40 PM
To: Leif Halvard Silli
Cc: Maciej Stachowiak; Sam Ruby; Laura Carlson; Judy Brewer; Cynthia Shelly; Paul Cotton; David MacDonald; HTML Accessibility Task Force; HTML WG
Subject: 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 20:04:20 UTC