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

Hi Janina,

First, let's try to keep a professional tone. I have a thick skin, but calling people "inept" sets the wrong vibe for the mailing list.

On Aug 14, 2012, at 4:02 AM, Janina Sajka <janina@rednote.net> wrote:

> 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?

I believe my remark below is equally applicable to your comment. To my understanding as an implementor, hidden content can be exposed to assistive technologies (including screen readers such as VoiceOver) without exposing it to the TAB cycle for keyboard users. Thus, non-screen-reader users making use of the keyboard will not experience a problem, as they will not tab into invisible content. My understanding of the specific concern raised by John, both in his survey comment and in his formal objection below, is that exposing content with full semantics to assistive technologies will inevitably put it in the tab cycle, thus leading to the harm both of you are worried about, namely sighted keyboard users tabbing into invisible content. The point of information I wanted to provide is that it does not necessarily have this effect, for either screen reader users, or users viewing the screen and navigating with the keyboard.

I hope this clarifies the point I raised about WebKit's accessibility implementation details.

Regards,
Maciej


> 
> 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 16:57:29 UTC