RE: ATAG 2.0 Focus indicator during navigation

Hi Alex - In my scrolling example, I meant a situation in which scrolling with the mouse worked, but there was no automatic scrolling during tab navigation, but I digress... 

Here is my proposal for a new ATAG 2.0 SC. The wording is adjusted from that of WCAG [1] to be more similar to ATAG2's no keyboard trap wording [2]: 

A.3.1.2 Focus Visible: If that authoring tool provides, sequential keyboard access then a keyboard focus indicator can be visible. (Level A)

---

[1] 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

[2] A.3.1.2 No Keyboard Traps: If keyboard focus can be moved to a component 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, authors are advised of the method for moving focus away. (Level A)



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

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca


> -----Original Message-----
> From: Alex Li [mailto:alli@microsoft.com]
> Sent: February-05-13 12:45 PM
> To: Richards, Jan; w3c-wai-au@w3.org
> Subject: RE: ATAG 2.0 Focus indicator during navigation
> 
> Hi Jan,
> 
> I think visible focus is an entirely different requirement, which is why I
> objected to test in the first place.  [3] is about the order of the focus, not the
> visibility of focus.  Besides, [3] is related to A.3.1.3, not A.3.1.1 and A.3.1.4.
> 
> WCAG does not mention scrolling because if content needs scrolling to be
> read or used, then all users would need it.  If such content does not scroll
> then the content has a bug making it not functional to nearly everybody--
> thus not really an accessibility problem.
> 
> I do not object to adding a new SC.
> All best,
> Alex
> 
> -----Original Message-----
> From: Richards, Jan [mailto:jrichards@ocadu.ca]
> Sent: Tuesday, February 05, 2013 7:28 AM
> To: w3c-wai-au@w3.org
> Subject: ATAG 2.0 Focus indicator during navigation
> 
> Hi all,
> 
> Picking up yesterday's discussion...
> 
> Alex made the following comment about A.3.1.4, but it applies equally to
> A.3.1.1 (see [1] below), which also includes visible focus in the test:
> "If the SC only ask for keyboard to work, then the test should not test for
> visible focus. WCAG 2.0 has SC 2.4.7 for focus visibility (see [2] below). If we
> need to solve the same problem, then we need an SC for that. We cannot
> add extraneous test per 4.2 for A.3.1.4 above just to plug a hole in ATAG."
> 
> When we discussed this on yesterday's call, Tim, Greg, Jutta and I were all of
> the opinion that a visible focus indicator is intrinsic to sequential keyboard
> access, which already has a normative definition (see [3] below). It is similar
> to the need to scroll the viewport to have the focussed link in view (which
> WCAG 2.0 doesn't mention). Of course, browsers usually handle this (as they
> do visible focus indicators), but in both cases the behaviours can be blocked
> by content authors.
> 
> I think the people on the call yesterday would be ok to add an SC along the
> lines of 2.4.7 Focus Visible (but at Level A) as long as it wouldn't be perceived
> as a brand new requirement.
> 
> Alex, what do you think?
> 
> 
> ATAG 2.0 A.3.1.1
> ---
> [1] A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool
> is operable through a keyboard interface without requiring specific timings
> for individual keystrokes, except where the underlying function requires
> input that depends on the path of the user's movement and not just the
> endpoints. (Level A)
> - Note 1: Keyboard interfaces are programmatic services provided by many
> platforms that allow operation in a device independent manner. This success
> criterion does not imply the presence of a hardware keyboard.
> - Note 2: The path exception relates to the underlying function, not the input
> technique. For example, if using handwriting to enter text, the input
> technique (handwriting) requires path-dependent input, but the underlying
> function (text input) does not. The path exception encompasses other input
> variables that are continuously sampled from pointing devices, including
> pressure, speed, and angle.
> - Note 3: This success criterion does not forbid and should not discourage
> other input methods (e.g., mouse, touch) in addition to keyboard operation.
> 
> [2] WCAG 2.0 - 2.4.7
> ---
> 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of
> operation where the keyboard focus indicator is visible. (Level AA)
> 
> [3] ATAG2.0 Glossary: sequential keyboard access
> ---
> Using a keyboard interface to navigate the focus one-by-one through all of
> the items in an ordered set (e.g., menu items, form fields) until the desired
> item is reached and activated. This is in contrast to direct keyboard access
> methods such as keyboard shortcuts and the use of bypass links.
> 
> 
> Cheers,
> Jan
> 
> 
> 
> 
> 
> 
> 
> (MR) JAN RICHARDS
> PROJECT MANAGER
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
> OCAD UNIVERSITY
> 
> T 416 977 6000 x3957
> F 416 977 9844
> E jrichards@ocadu.ca
> 
> 
> 
>

Received on Wednesday, 6 February 2013 14:09:44 UTC