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

Greg,

Thanks for the reply.  While I probably need to eat lunch so I'm not
hangry, I would reiterate that I didn't intend to come across as attacking
you personally.  I appreciate you are analysing the project externally, and
I'm glad that you are advocating for useability and accessibility. :)

All the best

Quentin.

On Tue, Dec 13, 2022 at 12:14 PM Greg Jellin <greg@gregjellin.com> wrote:

> 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> 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> 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>
>>> Sent: Tuesday, December 13, 2022 9:52 AM
>>> To: Wai-Ig <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: 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>
>
>

-- 
Quentin Christensen
Training and Support Manager

Web: 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>