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: Mon, 10 Sep 2012 16:05:49 +0000
Message-Id: <E1TB6Uf-0006US-MJ@jessica.w3.org>
To: public-html-a11y@w3.org

--- Comment #22 from John Foliot <john@foliot.ca> 2012-09-10 16:05:49 UTC ---
(In reply to comment #8)
> I don't know if I understand such fierce opposition John. The fact is no matter
> what 'term' is used much of the good practice that is used to support
> accessible content development for screen reader users will also be very good
> for other basic IO or serial input AT devices such as every single one that you
> mentioned; switches etc.

How? If you are sighted and using a foot switch and ZoomText, and the following
content is hidden, how will this work?

<div id="hidden" hidden>
  <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>

It's not just the vague reference to the term Asssitive Technology that irks
me, but that a significant user-interaction is being left undefined. If we have
learned anything with the @longdesc fiasco it is that if we do not specify how
this user-interaction is to manifest, then we do not get a common
user-experience, the technique is abused, misused and/or under-used, and a
decade later a whole slew of engineers, not around from the previous round of
discussions, seek to toss the whole mess out, citing alleged problems and a
desire to re-invent the wheel.

Despite repeated requests and urging, everyone appears to be ignoring this
particular elephant in the room.

> I think the basic premise of peoples input/suggestions for this bug such as
> from Steve or James, is good. Actually how this content would be revolved is
> largely down to User Agent support - we just need to ensure that the spec
> allows vendors to make provision for the creation of accessible content - using
> this or indeed any other method.

In an earlier series of emails, I attempted to press Maciej to better explain
how a sighted user, using a screen reading technology would be able to see this
hidden content that was being read aloud.  Ultimately, he punted, wanting to
have a telephone conversation with me (I accepted the offer, but my phone sits
silent) - the only other response I got was that with VoiceOver activated, then
the sighted user would also see the hidden content via what I understand to be
some form of modal overlay.

This is all well and good when a screen reader is integrated with the OS and
browser, but outside of the Mac/iOS platforms (and Google's attempt to
integrate a screen reader with ChromeOS/ChromVox), I am unaware of efforts with
any other OS or browser to actually provide for, say, the ZoomText user.

"FULL" Semantics includes supporting the <a> element, and WCAG 2 specifically
mandates that all links must preserve visible tab focus. 

Until this dichotomy is addressed, I will remain resolute with my Formal Object
against this decision. Until such time as this is clearly addressed and defined
to respect the needs of sighted, keyboard-only users who may also benefit from
these hidden hyperlinks, this proposal is fundamentally flawed.

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 Monday, 10 September 2012 16:05:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:30 UTC