RE: Moving forward with Issue-204

Edward O'Connor wrote:
> 
> >> The v3 proposal explicitly disallows authors from using structured
> >> content in hidden="" elements; the AllowAriaReferHidden imposes no
> >> such restriction.
> […]
> >> I think there could be compromise language on this issue, which
> >> simultaneously encourages (but does not require) UAs to expose the
> >> full semantics of hidden="" content to AT, and that requires authors
> >> to only use aria-describedby="" to refer to hidden="" content that,
> >> when flattened, does not lose essential meaning.
> 
> John took a stab at providing such compromise language:
> 
> > "Authors SHOULD avoid using hidden elements for longer content that
> > has structured text (e.g., headings, anchors, list markup, table
> > markup, etc.), as some user-agents/AT will flatten the referenced
> > elements to plain text, losing interactivity and semantic structure,
> > as noted above in the ARIA API mappings<linked>. If a (scripted)
> > mechanism is used to render the hidden content on-screen (on demand)
> > so that sighted and non-sighted users can effectively interact with
> > the structured content, then authors MAY provide structured content
> in
> > this scenario."
> 
> We're definitely making progress here, but I still think this wording
> overly restricts what authors are permitted to do. For instance,
> consider this markup:
> 
> <div id=foo hidden>
> <h1>Section 1</h1>
> <p>Lorem ipsum
> <h1>Section 2</h1>
> <p>Lorem ipsum
> </div>
> 
> I think authors should be able to reference this <div> from WAI-ARIA
> attributes like aria-describedby="". It does not lose essential meaning
> when flattened.

Hi Ted,

"Essential" - barely not (I mean, the text is preserved as string text), but important (almost critical) meaning, I disagree. 

One of the most common strategies non-sighted users deploy for quick inter-page navigation is to query the list of headings on a page, and then (by using their screen readers) "jump-to" the appropriate heading and then begin reading from that point forward.
http://webaim.org/projects/screenreadersurvey2/#finding 
http://webaim.org/projects/screenreadersurvey4/#levels 
http://webaim.org/projects/screenreadersurvey3/#headings

So, while the flat text is indeed preserved for the non-sighted user, any real usefulness is lost, resulting in a sub-optimal experience. Many feel that it is below the acceptable thresh-hold of acceptability (imagine if, under certain conditions, your web experience was artificially constrained based on poor authoring - how would/do you feel? Would you continue to encourage authors to perpetuate that bad experience?)

> 
> Here's my attempt at wording this restriction. What do you think?
> 
>   User Agents are encouraged to expose the full semantics of hidden
>   elements to Assistive Technology when such elements are referenced
>   from WAI-ARIA attributes. Because some User Agents flatten hidden
>   content when exposing it to Assistive Technology, authors SHOULD NOT
>   reference hidden content which would lose essential meaning when
>   flattened.
> 
> This is definitely not the best possible wording for this restriction,
> but I could live with it. Is this the only place in the spec where we
> talk about flattening? It's a term many web developers won't be
> familiar
> with; we should probably provide a definition or a reference to one.


The concern I/we have is with the Tab-Focus issue, and its direct contravention of WCAG (as outlined in my earlier email). Assuming a user-agent could preserve the semantic structure of @hidden content, then consider a list of links as active links in a @hidden state: what is the user-experience for sighted, keyboard-only users? 

<div id="hidden" hidden>
 <ul>
  <li><a href="this.html">This</a></li>
  <li><a href="that.html">That</a></li>
  <li><a href="other.html">The Other</a></li>
 </ul>
</div>

As my draft text states, the only way that this would be accessible to all users is if, via "a mechanism" (deliberately vague and undefined), these otherwise hidden links are *visually exposed* to the sighted users, so that they can see (and thus determine) which link they have tabbed unto. If the author/user-agent cannot achieve this, then I believe that, yes, authors SHOULD NOT be allowed to do this, and that the spec say so in the clearest of terms.

Bottom line (of course) is that even today authors can reference hidden structured content using aria-describedby, and users access that "flattened" (string-text) content today - complete with lousy user-experience for the same sighted, keyboard-only user*. I just think we should (as strongly as possible) avoid this possibility without appropriate checks and balances in place.

(* a close approximation we have of this today is the fairly common "Skip nav" link, that is often placed off-screen using CSS. While some sites expose the skip navigation link as part of the UI design - http://webaim.org/ - some expose it only when tabbed onto it - http://jimthatcher.com/skipnavold.htm - while others hide it from all sighted users all the time, which is what we are trying to avoid. Losing visible focus of one link {at the beginning of the page} is a poor experience, but loosing multiple tab-focus indications in the middle of a page is horrible)

Ted, I think at this point we've come to a crossroads: while I cannot speak for the entire Accessibility Task Force, it is my belief that the language I proposed in the version 4 draft is as far as we can comfortably go with regards to author requirements. I will point out that it *does* include a conditional MAY statement, leaving the door open to further experimentation (and perhaps a future removal of the restriction down the road) but at this time I can't back up any further: the user-base of keyboard only users only continues to grow and the requirement for visible focus is an entrenched WCAG Standard which cannot be ignored.

Every good-faith effort has been made here, and if at this time you and Jonas are still unprepared to endorse the V4 CP, then I will ask the Accessibility Task Force for their endorsement of the V4 CP and ask that the Chairs proceed with a WBS survey on Issue 204.

Hoping for a positive response, and thanks for working at this.

JF

Received on Friday, 29 June 2012 23:58:04 UTC