RE: Is the escape key sufficient as a method for WCAG 2.1.2 No Keyboard Trap

Are the elements in the dropdown natively (tab) focusable? That is, is the dropdown a list of links or similar? If so, then also presuming that appropriate role semantics for items in this dropdown have not been applied … in which case, it may also fail 4.1.2. otherwise, sequential tab focus can only be achieved using JS.

 

 

 

 

From: Greg Jellin <greg@gregjellin.com> 
Sent: Tuesday, December 13, 2022 1:31 PM
To: Adam Cooper <cooperad@bigpond.com>; 'Quentin Christensen' <quentin@nvaccess.org>
Cc: 'Wai-Ig' <w3c-wai-ig@w3.org>
Subject: Re: Is the escape key sufficient as a method for WCAG 2.1.2 No Keyboard Trap

 

Adam, you may be happy to know that the pattern in question does also allow navigating the list via arrow keys, in addition to tab, and that enter/space and click all select the focused option. IMO, the pattern is quite usable for keyboard-only and SR users, but I agree that eliminating tabbing from the listbox would allow users to more easily move onto the next element.

Greg

On 12/12/2022 6:03 PM, Adam Cooper wrote:

Greg,

 

The term ‘functionality’ in success criterion 2.1.1 is the key term. 

 

In WCAG 2.x, it is defined as “processes and outcomes achievable through user action”.

 

It is arguable that ‘processes and outcomes’ are user tasks  such as ‘select an option from a listbox’ rather than interaction behaviours.

 

WCAG is mute as to whether the dropdown remains visible after focus is moved on or whether a user has to press TAB umpteen thousand times or even that whether the ESC is an appropriate key as long as a desired option can be selected from the dropdown using a keyboard … 

 

You may want to look at SC2.4.3 in which the understanding section implies that preserving operability may actually be about navigational efficiency … cue the howls of protest.

 

It’s a shame that WCAG is overshadowed by this kind of technocratic exegesis as it obscures its generalised intent of making the web more accessible for people like me … and, for me, that’s about making using it not only effective but also, efficient and satisfying.

 

Why should it take me more time and effort to perform a simple task like selecting an option from a dropdown just because I have a vision impairment?

 

 

 

 

From: Greg Jellin  <mailto:greg@gregjellin.com> <greg@gregjellin.com> 
Sent: Tuesday, December 13, 2022 12:15 PM
To: Quentin Christensen  <mailto:quentin@nvaccess.org> <quentin@nvaccess.org>
Cc: Adam Cooper  <mailto:cooperad@bigpond.com> <cooperad@bigpond.com>; Wai-Ig  <mailto:w3c-wai-ig@w3.org> <w3c-wai-ig@w3.org>
Subject: Re: Is the escape key sufficient as a method for WCAG 2.1.2 No Keyboard Trap

 

Quentin, perhaps you missed the part where I said I agreed and will advocate for the solution Adam proposed. I agree with pretty much everything you said, but there is also the reality of people's positions and reach within an organization. In this case I'm external to the org and have limited reach. That won't stop me from making suggestions with those I have access to.

On 12/12/2022 5:06 PM, Quentin Christensen wrote:

There is also an unfortunate trend of shaping the argument around undesirable but "trendy" behaviour in order check off a criteria on a list rather than actually meeting the user need. 

 

Aiming to meet WCAG compliance is good, but surely you should be aiming to make the interface USEABLE for the people for whom WCAG was designed to help.

 

You've got a direct response from a screen reader user arguing that whether or not your interface technically meets WCAG, it is not useable for screen reader users, and your response could be taken as "my job is to check off a list, not make it work".  And I appreciate that you personally likely didn't write the interface and that your job is to check off WCAG compliance on the project, and I'm not intending to attack you personally.  BUT, part of that job is also ensuring that the company isn't flooded with user complaints saying their product is not accessible - they'll come back to you and say "But you said it was accessible and met WCAG!".

 

In fact, representing a screen reader manufacturer myself, I completely agree with Adam, and would further argue this isn't even an issue exclusive to screen reader users, but to ALL users who might try to navigate your list with the keyboard.

 

Perhaps the question to ask here, is not whether this "solution" meets WCAG, but going one step further back, and asking why this interface is needed instead of the standard way of navigating lists which works across the board, needs no special instruction, and wouldn't require you to question whether it meets WCAG or not?

 

Rant over :)

 

On Tue, Dec 13, 2022 at 10:59 AM greg jellin <greg@gregjellin.com <mailto:greg@gregjellin.com> > wrote:

Great point Adam. Totally agree. Unfortunately, my role on this task is assessing wcag compliance, however I will advocate for that solution.

On Mon, Dec 12, 2022, 3:47 PM Adam Cooper <cooperad@bigpond.com <mailto:cooperad@bigpond.com> > wrote:

Greg,

Who cares whether it passes xyz? As a screen reader user, tabbing through items in either a menu or list is the wrong pattern especially if it's something I am doing over and over again like at work. 

If I can highlight an option using arrow keys, and then tab out of the listbox and onto the next field or button, then I have saved a heap of repetitive strain injury ... 

There is an unfortunate trend in web design and development that believes tabbing is the appropriate means of navigating long lists. For example, a WordPress global navigation menu. What happens if I need to get to the very last item in the very last menu over and over? That's right - tab, tab, tab, tab, tab tab ... arrow key navigation is much more efficient and saves my brain and my joints.

The model for menus is common operating systems - there's no reason why the web has to be different (except for poor design, development, and rubbish accessibility support!).




-----Original Message-----
From: Greg Jellin <greg@gregjellin.com <mailto:greg@gregjellin.com> > 
Sent: Tuesday, December 13, 2022 9:52 AM
To: Wai-Ig <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> >
Subject: Is the escape key sufficient as a method for WCAG 2.1.2 No Keyboard Trap

I'm dealing with a combobox that presents a list of options
(role=listbox) after the user types a few characters.

Once the listbox is present, if the user tabs, focus moves through each item. Once reaching the end of the visible list, focus cycles through the list from the beginning. The user can not escape the listbox via tab or arrows.

The user can escape the component via the escape key (collapses the listbox and the user can continue tabbing through the page) or by deleting the text entered into the input.

Is this sufficient to pass 2.1.2 No keyboard trap? I would argue that the escape key meets the "other standard exit method" part of the SC.

Thanks in advance!

Greg







 

-- 

Quentin Christensen
Training and Support Manager

 

Web:  <http://www.nvaccess.org/> www.nvaccess.org 

Training: https://www.nvaccess.org/shop/

Certification: https://certification.nvaccess.org/

User group: https://nvda.groups.io/g/nvda

Facebook: http://www.facebook.com/NVAccess 
Twitter: @NVAccess <https://twitter.com/NVAccess>