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

<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

Received on Tuesday, 14 August 2012 05:29:04 UTC