- From: John Foliot <john@foliot.ca>
- Date: Tue, 14 Aug 2012 12:10:54 -0700
- To: "'Maciej Stachowiak'" <mjs@apple.com>
- Cc: "'Sam Ruby'" <rubys@intertwingly.net>, <public-html@w3.org>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Maciej Stachowiak wrote: > > > <chair hat off, browser accessibility implementor hat on> > > Hi John, > > I am wary of getting into a potential debate, but I have some comments > on this, in case you decide to switch to a reopen request or withdraw > the Formal Objection. Or if you stand by your FO, I would like this > information to be on the record. I am speaking here, not as a co-chair, > but strictly based on my experience contributing to WebKit's > accessibility code. Hi Maciej, Thank you for your thoughts. I have no appetite to get into yet another long, protracted debate either. Your comments below are valuable to my current Formal Objection, as they serve to illustrate exactly why the Chairs appear to have missed critical information in their decision. Should the following response and further discussion convince the Chairs to re-open Issue 204 I would not be opposed to that decision, however until such a decision is taken I will retain the Formal Objection. This is not a "harm" issue for users who are Blind, or for tools that avail themselves to the Accessibility APIs. No, it is manifestly harmful for sighted users who do not employ a mouse, and MUST rely on other forms of interaction with their computers - which has been traditionally using a keyboard or other key-press mechanism (http://www.aboutgbs.com/mouthstick%20in%20use-med%20equip.jpg): this is not about Mr. Stevie Wonder, it is about Mr. Hector Picard (http://www.flickr.com/photos/bevarmstrong/3736091551/). This has very little (if anything) to do with the Accessibility APIs, and everything to do with how users interact with rich content. > > I believe there is a counter-example to your assertion that this is > required by "simple logic". For the combination of Safari and > VoiceOver, there is no relationship between tab focus and exposure of > full semantics via VoiceOver. This is not about "semantics", it is about inter-action models. > Here are a few factors to note: > > (1) Decisions on tab focus and exposure via the accessibility API are > made by completely separate pieces of code; there is no technical > relationship. > (2) Navigation in content exposed to the screen reader is usually done > via custom keybindings that are specific to the screen reader rather > than tab, so there is no functional relationship. > (3) Safari out of the box does not navigate links at all when pressing > tab. So out of the box at least, the screen reader already has the > behavior of not tabbing to links, even for content that is not hidden. As I am not an iOS / MacOS user, I cannot comment extensively on the above. However, based upon what you have provided, I am curious to know how the above also satisfies the following User Agent Accessibility Guidelines: 1.1.3 Identify Presence of Un-rendered Alternative Content: The user can specify that content be rendered with an adjacent indicator when un-rendered alternative content is present (e.g. an icon to indicate an image has a short text alternative). (Level A) http://www.w3.org/TR/UAAG20/#gl-access-alternative-content ...as well as this: Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links. Summary: The user can visually distinguish selected, focused, and enabled items, and recently visited links (1.3.1), with a choice of highlighting options that at least include foreground and background colors, and border color and thickness (1.3.2). http://www.w3.org/TR/UAAG20/#gl-access-alternative-content I am also curious how your explanation relates to the following statement from Apple's own web site: "VoiceOver provides visual references to enable blind and sighted users to work together on the same computer at the same time." http://www.apple.com/accessibility/voiceover/ With the current Change Proposal being accepted, how will this visual reference manifest in VoiceOver? (I know, "Apple doesn't comment...") "Tabbing" is not the issue, focus of (inter)active elements is the issue, and specifically visual indication that an element is active. In your scenario, VoiceOver announces a link, but how does the sighted user know where it is, so that they can "work together" with the non-sighted user? Since (AFAIK), Apple products that include VoiceOver still do not provide voice-input interaction (out of the box), how does the sighted amputee or quadriplegic interact with that hidden link? Or is VoiceOver *ONLY* for blind users? (http://nolegsarms.files.wordpress.com/2009/04/8efc.jpg) > > I hope you can see that *if* it is not actually inevitable that a link > inside a hidden container MUST take tab focus, then the rest of your > argument doesn't follow. All links must take some form of focus (key-binding) so that they can be acted upon, or not, as decided by the end-user. If that focused key-binding cannot be seen by the sighted user, how can they interact with it? > On the other hand, if what you describe above > is actually an inevitable outcome, then I at least see how it could be > bad and I believe the accessibility criteria cited point in that > direction. Clarifying the issue: Whether though tabbing or via another method of accessing the key-binding, the act of binding a link to an interaction trigger IS inevitable, and announcing that binding but not rendering it on screen is a critical concern, and one that both UAAG and WCAG have noted. Both of those WAI Recommendations specifically state that this binding MUST be exposed to all users somehow. > > If you had an example of an implementation where there *is* a direct > relationship (as reported by an implementor with direct knowledge, or > based on some form of testing or technical analysis), then that would > be very relevant information. Dragon NaturallySpeaking (http://www.nuance.com/dragon/index.htm): This leading speech-to-text software allows sighted, mobility impaired users to interact with HTML-rich content via speech input. Nuance/Dragon recommend that all links be visible ("obvious to the user"), and that link text be unique, so that the user need only say the link text to activate the link, however, should that prove to be problematic, the user can also have each link enumerated by the software, at which point they speak the "number" of the link, and the interaction is then triggered. >From Nuance's documentation: . To be accessible by speech, an element must have some text clearly associated with it. For text links, this text is intrinsic. For non-text links, supply it in the element's ALT attribute. The user can then activate the element by saying the text or any word or consecutive words within the text. . The association of the text with the element should be obvious to a user. If the text is not displayed as part of the element, provide some additional indication to make the text and its relationship to the element clear to the user. . Whenever possible, the text associated with a link should be unique within the page or frame set.2 Although Dragon can deal with ambiguities by displaying numbers next to ambiguous items and letting the user choose a number, this requires an extra step on the part of the user. http://www.nuance.com/ucmprod/groups/healthcare/documents/webasset/nd_004979 .pdf (PDF) Question: if the link is "hidden" what should Dragon do? Enumerate it or not? How does the current Change Proposal support the need for "obvious to the user"? There is a flaw in the current Change Proposal that does not appear to address this question (and frankly, I am unsure what should happen either, however until we know this, there remains a possibility of an unsolvable problem). Mouse-less Browsing (https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/): This Firefox plug-in also binds links to numbers, and provides a visual indication of this fact to users who have activated the plug-in. I recently took a screen capture of the test page I posted (which Janina referenced in her Objection - http://john.foliot.ca/html5/w3c/hidden.html) with Mouse-less Browsing activated: http://john.foliot.ca/html5/w3c/mouseless.jpg You will note that the first visible link is actually #22, the previous 21 links are hidden to the sighted user. What if, instead of at the beginning of the document the hidden links were numbers 7, 13, 26 and 30? Do you find it acceptable that those enumerated links simply "disappear" for the sighted user? (personally, I don't) And what, exactly, should happen if the sighted user "guesses" and attempts to visit link 13? Since it would currently *ONLY* be exposed as a link to the Accessibility API, should it (would it) work? If yes, why, and if no, why not? Again, it is unclear to me (and likely others) what should happen here - once again we introduce the risk of an unsolvable problem. ZoomText (http://www.aisquared.com/zoomtext/): This combination of Screen Magnifier and Screen Reader now supports ARIA - which means that the hidden link *WILL* be exposed to the software as a link. However, as a screen magnifier, whenever there is an "active key-binding" announced, the magnifier will move its visual focus to that link. Where should ZoomText move its focus when an active link is also hidden? Again, it is unclear to me what should happen, and the current Change Proposal has no guidance here. Examples of the imminent harm we have. > > I'm writing this in hopes that you will reconsider your Formal > Objection. If this turns into a longer discussion, then we may want to > take it offlist. At this time I am not inclined to withdraw my Formal Objection. In fact, should the decision of Issue 204 be used to "steer" the decision for Issue 30 and obsolete @longdesc, it will be the grounds for my Formal Objection on that decision too - a bad decision predicated upon a flawed understanding and decision for Issue 204. That said, should the Chairs reconsider their decision and choose to re-open Issue 204 (based upon what I have provided here, or what others have provided - http://lists.w3.org/Archives/Public/public-html/2012Aug/0162.html) then I will continue the dialog. It goes without stating that a re-opening of Issue 204 will also have a material impact upon Issue 30 however. JF
Received on Tuesday, 14 August 2012 19:11:37 UTC