W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

[Bug 18744] drop WAI-ARIA scope restriction in the text adopted in ISSUE-204

From: <bugzilla@jessica.w3.org>
Date: Fri, 07 Sep 2012 16:13:48 +0000
Message-Id: <E1TA1Bk-0007qF-Ph@jessica.w3.org>
To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744

--- Comment #7 from John Foliot <john@foliot.ca> 2012-09-07 16:13:48 UTC ---
I remain completely opposed to this proposal.  My reasons are:

> This allows Assistive Technologies to access the content structure...

A foot switch, a one-handed keyboard, a mouth stick and software such as
Dragon/Nuance's Naturally Speaking are all Assistive Technologies. How will the
hidden content be exposed to the users of these technologies? The vague and
undefined term "Assistive Technologies" as used here is inappropriate: if you
mean screen readers, then say screen readers, otherwise this proposed technique
must in fact "work" for all Assistive Technologies, such as those referenced
above.

> User Agents are encouraged to expose the full semantics of hidden="" elements

AS I have continued to point out (and logged a Formal Objection around), there
are certain "full semantics" that are extremely problematic with this current
text, mostly centered around the <a> element.

Scenario: Susan is a low-vision user who uses ZoomText (an Assistive Technology
that is both screen magnifier and ARIA-aware screen reader). She encounters a
web page that has the following code:

<div hidden>
 <ul>
  <li><a href="">Link 1</a></li>
  <li><a href="">Link 2</a></li>
  <li><a href="">Link 3</a></li>
  <li><a href="">Link 4</a></li>
 </ul>
</div>

To "expose the full semantics" is to present to Susan an unordered list of 4
hyper-links. Because ZoomText is ARIA-aware, the screen reading part of the
tool will announce those 4 links - however, what shall the "Zoom" part zoom to? 

As well, we have a WCAG requirement (2.4.7 Focus Visible
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible)
that specifically mandates "...that there is at least one mode of operation
where the keyboard focus indicator can be visually located." To meet this
requirement then, those links cannot "...remaining hidden in all presentations
of the normal
document flow" - they MUST be visually locatable or this technique is in direct
and Willful Violation of WCAG.

If this Working Group wishes to propose a sub-set of semantic structures and
markup that could be exposed to screen readers yet remain hidden in the
"...normal document flow" (what is normal anyway?), then that might be worth
investigating (for example, allowing <span lang="FR"> on hidden content might
be very useful), however as currently presented I will remain opposed to this
technique, and will leave my existing Formal Objection in place.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 7 September 2012 16:13:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 16:13:50 GMT