W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2013

RE: ATAG 2.0 Focus indicator during navigation

From: Alex Li <alli@microsoft.com>
Date: Tue, 5 Feb 2013 23:08:34 +0000
To: "Richards, Jan" <jrichards@ocadu.ca>, "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <6ca1624e75c848f695075c4e39fd4a92@SN2PR03MB096.namprd03.prod.outlook.com>
From: Alex Li 
Sent: Tuesday, February 05, 2013 9:45 AM
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,

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



T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca
Received on Tuesday, 5 February 2013 23:21:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:04 UTC