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

Maciej:

Your response to John is profoundly troubling. It makes clear that, not
only have you and your chair colleagues failed to understand our a11y
harm concern here, you have also failed to understand the specific
explanation of that harm provided you in your WBS survey. As the one who
provided the comment you missed in its entirety, let me quote myself to
you here, from your WBS at:

https://www.w3.org/2002/09/wbs/40318/issue-204-objection-poll/results

"Janina Sajka Additional Comment to John Foliot's Test Page: The lost
focus behavior is particular relevant not to screen reader users, but to
sighted users who read the video display, but whose disabilities prevent
them from using a mouse (or other pointing device)--people who use
keyboard navigation, e.g. TAB/Shift+TAB to navigate."

Was my language somehow  obscure that you thought we were speaking of
screen readers like Voice Over?

Yet, you continue to misunderstand this even in the very message below
to which you respond so graciously, yet so ineptly below?

Janina


Maciej Stachowiak writes:
> 
> <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.
> 
> On Aug 13, 2012, at 7:28 PM, John Foliot <john@foliot.ca> wrote:
> 
> > Sam Ruby wrote:
> >> 
> >>   * Assertion of "harmful behaviors" is also not sufficiently
> >> supported
> >>     by evidence.  In particular, it makes a claim that has previously
> >>     been disputed, and without a single example of such markup.
> > 
> > It is impossible to demonstrate harmful behaviors in a technology that has
> > yet to surface - this is a ludicrous statement. 
> > 
> > Placing a <a href>Link</a> inside an @hidden container MUST still take tab
> > focus for a non-sighted user and their Assistive Technology to interact with
> > it, yet at the same time hides that focus from the sighted user: this is
> > simple logic.
> 
> 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. 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.
> 
> 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. 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.
> 
> 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. 
> 
> 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.
> 
> Regards,
> Maciej

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

The Linux Foundation
Chair, Open Accessibility:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Tuesday, 14 August 2012 11:03:01 UTC