W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > April 2017

Errata for 2.4.7 Focus Visible: Any keyboard operable user interface component

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Thu, 20 Apr 2017 18:38:10 -0500
To: public-comments-wcag20@w3.org
Cc: "Michael Cooper" <cooper@w3.org>
Message-Id: <OFC41B8396.CAD21199-ON86258108.007B2E66-86258108.0081D738@notes.na.collabserv.com>
Errata 1. Insert a term to a SC 2.4.7:
We've had several issues when trying to clarify the intent of 2.4.7 Focus 
Visible which can often be traced back to the Success Criteria wording 
itself.  It's missing the term "component", as in " user interface 
component"

The term is defined in the normative glossary.  The shorter term "user 
interface" is not defined in the glossary, by the way. 
The term "element" is also used 5 times and the term "component' was used 
4 times on the Focus Visible Understanding SC 2.4.7 page, so the intent 
was/is clearly there that the component or element of the user interface 
should have a visible indicator, 
        and NOT the whole UI or whole page, 
        not any part of the UI or page, 
        not the "active page" indicator, etc. 
        but the specific component/element that is keyboard operable. 

I believe this clarification is an editorial errata, and not a substantive 
errata.

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

recommended edit/errata:
2.4.7 Focus Visible: Any keyboard operable user interface component has a 
mode of operation where the keyboard focus indicator is visible. (Level 
AA) 


Errata 2. Add a definition for "keyboard operable" into the glossary. 

Rationale for this Errata: 
Web authors are incorrectly adding keyboard focus to non-operable 
elements/components on pages.  An example of a element that should NOT 
receive focus because it is not keyboard operable is a heading (e.g. h1, 
h2, etc.). 

Why would a sighted user ever want the focus indicator to be visible on a 
non-operable element (e.g. heading) when navigating with the Tab key? 
#1 - The visible focus indicator causes users, and especially user with 
cognitive disabilities, aging user, etc. to think that there is some 
interaction that can be preformed, when there isn't.
#2 - Causes the keyboard tab ring to stop on headings and other 
non-operable elements slows leyboard navigation down, increases the no. of 
stops, for things that are un-necessary.

Arguments I've heard from uninformed web authors and designers for the 
keyboard to stop on things like headings for screen reader, magnifier, 
voice command and control, and even keyboard only users is really 
missinformed, thinking they are inproving the UX for the users with 
disabilities, but in reality are forcing a one-size-fits-all behavior into 
their web page and failing to allow user agents to control and configure 
the behavior per the end users's preferences ands settings. Web Authors 
would never beable to provide all the necesssary assistive features would 
some, but not all, end user require. 

Reading order and Tab order are two very different things that get 
confused often because web authors think they are suppose to provide 
keyboard access, and therefore, visible focus inticator, on everything so 
they can i, test the meaningful sequence, ii test the headings, iii test 
the correct movement of the magnifier, etc. - when not realizing the 
confusion and inaccessibility that is created for other users. 
 
as-is:
[keyboard operable] not defined.

Recommended Errata: [add a new glossary term]
Keyboard Operable:  user interface components that users can interact 
with.  Interactions would include user actions such as 
        open, close, expand, collapse, check, un-check, select, un-select, 
sort, preform the function of a control (e.g preform the function of a 
button), etc.
Componets on a page that are NOT keyboard operable elements include such 
elements as headings, text, images, and lists that have no interaction or 
controls behavior associated with them.  In other words they are no user 
interactions designed into them. Web authors should avoid styling and user 
expereince behaviors that would confuse a user into thinking that 
something is operable when it is not, such as adding the componet into the 
keyboard tab order or adding a visual focus indicator to no-operable 
components. 

This might also be a candidate for a new SC in 2.1
___________
Regards,
Phill Jenkins
pjenkins@us.ibm.com
Senior Engineer & Accessibility Executive
IBM Research Accessibility
linkedin.com/in/philljenkins/
ibm.com/able
facebook.com/IBMAccessibility
twitter.com/IBMAccess
ageandability.com
Received on Thursday, 20 April 2017 23:38:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 April 2017 23:38:50 UTC