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 Tuesday, 5 February 2013 15:28:08 UTC