- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 Sep 2012 16:05:50 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18744 --- 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> <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> 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 the QA contact for the bug.
Received on Monday, 10 September 2012 16:05:59 UTC