RE: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

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