RE: Keyboard trap clarification for ATAG2

All WCAG 2.0 2.1.2 says is the users ought to be advised.  I think it is best to let the tool maker figure out how to do that.  Adding “known” or “documented” does not change any behavior in the tool maker’s part.  It just adds more confusion as to why it is different from WCAG 2.0.  Let’s keep it simple.

As to the additional wording of “including editing views that render content that may have keyboard traps". I advise to not add it because the SC is meant to cover everything, not just editing views that render content that may have keyboard traps.  Adding the additional words adds length to an already lengthy sentence and may mislead audience to think that it is a condition clause.  Furthermore, nobody don’t knows what counts as “may have keyboard traps”.  If the group feel that it is an important point to make, I advise to place it in the implementation note.  Again, let’s keep it simple.

From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf Of Sueann Nichols
Sent: Tuesday, October 04, 2011 12:24 PM
To: Richards, Jan
Cc: w3c-wai-au@w3.org; w3c-wai-au-request@w3.org
Subject: RE: Keyboard trap clarification for ATAG2


Jan,

Are you suggesting the keyboard key that is used is documented or that the keyboard focus be moved to a specific or known place?    If it's the latter, there are two separate requirements.  The first is to have key definition  that will always respond , the second the have a documented 'known' place the focus will move to.

In WCAG 2.0 the definition seems to cover the first requirement, but ATAG seems to be imposing a second behavior that goes beyond WCAG 2.0, for no apparent reason.   Regardless of being in an authoring tool or any other Web application, if there is a universal need to ensure the keyboard doesn't get trapped.  But there does not seem to be a requirement, especially a single A level to also add the requirement there be a documented 'place' the keyboard focus will go to.

Can you clarify?

Sueann Nichols

Phone: (720) 396-6739 (t/l) 938-6739
ssnichol@us.ibm.com<mailto:ssnichol@us.ibm.com>
IBM Human Ability & Accessibility Center
http://www.ibm.com/able


[Inactive hide details for "Richards, Jan" ---10/04/2011 02:51:59 PM---Hi Sueann, The WCAG 2.0 text always begged the question:]"Richards, Jan" ---10/04/2011 02:51:59 PM---Hi Sueann, The WCAG 2.0 text always begged the question: “how is the user, who may think they are in

From:


"Richards, Jan" <jrichards@ocad.ca<mailto:jrichards@ocad.ca>>


To:


"w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>" <w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>>


Date:


10/04/2011 02:51 PM


Subject:


RE: Keyboard trap clarification for ATAG2


Sent by:


w3c-wai-au-request@w3.org<mailto:w3c-wai-au-request@w3.org>

________________________________



Hi Sueann,

The WCAG 2.0 text always begged the question: “how is the user, who may think they are in a keyboard trap after trying the standard exit keys,  advised that a non-standard exit method must be employed?” I assume the answer is that because the content author knows what their content is doing, so they could include a tooltip explaining the situation.

In the case of an authoring tool, that works fine for the authoring tool UI...

but it’s harder to see how the authoring tool can inject exit method advice into content it is rendering when it can’t determine whether a keyboard trap will be present. All it can reasonably be expected to do is provide a universal exit method that will always work, no matter what the rendered content being edited tries to do.

That’s why I’ve proposed in the past wording such as a “known” or “documented” place.

Cheers,
Jan

(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocad.ca<mailto:jrichards@ocad.ca>

Twitter @OCAD<http://twitter.com/ocad>
Facebook www.facebook.com/OCADUniversity<http://www.facebook.com/ocaduniversity>

OCAD UNIVERSITY
100 McCaul Street, Toronto, Canada  M5T 1W1
www.ocadu.ca<http://www.ocad.ca/>

From: Sueann Nichols [mailto:ssnichol@us.ibm.com]
Sent: October 4, 2011 1:42 PM
To: Treviranus, Jutta (Academic); Alex Li; Richards, Jan
Cc: w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>; w3c-wai-au-request@w3.org<mailto:w3c-wai-au-request@w3.org>
Subject: Re: Keyboard trap clarification for ATAG2


Seems cleaner to use the WCAG wording as Alex suggested.   I would not add the additional text Jutta is suggesting as I believe it is  redundant to the point of the topic.   But, I do think Jan's  suggestion is also a bit more clear.   The problem is, it does address the documentation requirement, but that should be covered through the requirement to document all accessibility features and keyboard definitions.

Sueann Nichols

Phone: (720) 396-6739 (t/l) 938-6739
ssnichol@us.ibm.com<mailto:ssnichol@us.ibm.com>
IBM Human Ability & Accessibility Center
http://www.ibm.com/able


[Inactive hide details for "Treviranus, Jutta (Academic)" ---10/04/2011 12:43:52 PM---Perhaps we can remove "of the page" and in]"Treviranus, Jutta (Academic)" ---10/04/2011 12:43:52 PM---Perhaps we can remove "of the page" and insert the words after components, "including editing views
From:


"Treviranus, Jutta (Academic)" <jtreviranus@faculty.ocad.ca<mailto:jtreviranus@faculty.ocad.ca>>

To:


Alex Li <alli@microsoft.com<mailto:alli@microsoft.com>>

Cc:


"Richards, Jan" <jrichards@ocad.ca<mailto:jrichards@ocad.ca>>, "w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>" <w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>>

Date:


10/04/2011 12:43 PM

Subject:


Re: Keyboard trap clarification for ATAG2

Sent by:


w3c-wai-au-request@w3.org<mailto:w3c-wai-au-request@w3.org>

________________________________




Perhaps we can remove "of the page" and insert the words after components, "including editing views that render content that may have keyboard traps" and then use this text.

Jutta

On 2011-10-04, at 12:26 PM, Alex Li wrote:

> I don’t get why we are trying to reinvent the wheel here.  What is it about WCAG 2.0 2.1.2 that does not cover what we need here?
> 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
>
> All we need to do is to remove the term “of the page”.
>
> From: w3c-wai-au-request@w3.org<mailto:w3c-wai-au-request@w3.org> [mailto:w3c-wai-au-request@w3.org] On Behalf Of Richards, Jan
> Sent: Tuesday, October 04, 2011 9:00 AM
> To: w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>
> Subject: Keyboard trap clarification for ATAG2
>
> On yesterday’s call I said that I would take a shot at simplifying the keyboard trap requirement. It still says “documented”, but it is more clear that it only applies narrowly to editing views that render content to the point where keyboard traps become possible:
>
> A.3.1.2 No Keyboard Traps: *Keyboard traps* are prevented as follows: (Level A)
>     (a) In the Authoring Tool User Interface: No keyboard traps are present; and
>     (b) In Editing-Views that Render Content: If an editing-view renders the content being edited such that a keyboard trap might exist in the content, then the authoring tool provides a documented keyboard method for moving the focus away from such content.
>
> keyboard trap (UNCHANGED)
> A user interface situation in which a keyboard interface may be used to move focus to, but not from, a user interface component or group of components.
>
> Cheers,
> Jan
>
>
> (MR) JAN RICHARDS
> PROJECT MANAGER
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
>
> T 416 977 6000 x3957
> F 416 977 9844
> E jrichards@ocad.ca<mailto:jrichards@ocad.ca>
>
> Twitter @OCAD
> Facebook www.facebook.com/OCADUniversity<http://www.facebook.com/OCADUniversity>
>
> OCAD UNIVERSITY
> 100 McCaul Street, Toronto, Canada  M5T 1W1
> www.ocadu.ca<http://www.ocadu.ca>