RE: Proposed rewording of ISSUE-204 text to address outstanding technical issues

Edward O'Connor wrote:
> 
> For convenience, here is the proposed text:
> 
> > Accessibility APIs are encouraged to allow a way to expose structured
> > content while marking it as hidden in the default view. Such content
> > should not be perceivable to users in the normal document flow in any
> > modality, whether using Assistive Technology or mainstream User
> > Agents.
> >
> > When such features are available, User Agents may thus expose the
> full
> > semantics of hidden="" elements to Assistive Technology when
> > appropriate, if such content is referenced indirectly by an ID
> > reference or hash-name reference. This allows Assistive Technologies
> > to access the content structure upon user request, while keeping the
> > content hidden in all presentations of the normal document flow. Some
> > examples of where it would be appropriate for the structure of
> > hidden="" elements to be exposed to users of AT with such an API
> > include:
> >
> >  * a <map> referenced from <img usemap>
> >  * table headers referenced with the headers="" attribute
> >
> > Cases where it would be inappropriate include
> >
> >  * <a href> containing a hash name reference to a hidden="" element
> in
> >    the same document
> >  * <label for> referencing a hidden="" form element
> >
> > Other specifications which define elements and attributes which may
> be
> > included in valid HTML documents (such as SVG, MathML, and WAI-ARIA)
> > may define how or whether this applies to their elements and
> > attributes.
> 
> There's ongoing discussion in Bugzilla (on bug 18744), and I think a
> bit
> more tweaking may be necessary to get as many people on board with the
> new text as we can. I'm confident that we'll be able to arrive at text
> that everyone can live with, and I hope that those who have FOed to the
> ISSUE-204 decision will work with us to address the remaining technical
> issues here.

Hi Ted,

I remain concerned that the very legitimate use-case scenario I have brought
forth has not been addressed.

Specifically, with an Assisitive Technology tool such as ZoomText, which is
both a screen magnifier as well as an ARIA aware screen reader, how will the
full semantics of the following piece of code be handled with regard to
conforming to WCAG 2.4.7? [1]

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

Some thoughts:

1) If the emergent spec is prepared to provide an itemized list of what
semantic constructs can be exposed (and thus are conformant, such as <span>
or <th>) versus those that are not (such as a hidden <a> element) - i.e,
something more definitive than "Cases where it would be inappropriate
include..." then I think that might be one path forward. 

2) The other is to specifically mandate User Agents that when an <a> element
is referenced, that is normally "hidden", that the UA subsequently present
that link visually for those users that so need. If I am to fully understand
Maciej's earlier description of how this works with Safari/VoiceOver [2],
then I think that would work. (I note as well that often with "overlays"
seen in the wild - many JS lightbox implementations for example - that the
tab focus is often "left behind" and not carried forward to the overlay, and
so specifically ensuring that is covered as well would be important).

As one of those who "FOed" this proposal, I have now tried to offer 2
potential solutions to address the concerns I have. 

I look forward to your thoughts.

JF

[1]
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visibl
e.html

[2] "... to be more specific, there is normally no change to the display of
the page itself; what VoiceOver speaks is displayed as a distinct overlay,
which shows both content and structural messages." 
(http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/0186.html)

Received on Tuesday, 11 September 2012 01:17:29 UTC