- From: Greg Jellin <greg@gregjellin.com>
- Date: Mon, 12 Dec 2022 18:30:53 -0800
- To: Adam Cooper <cooperad@bigpond.com>, 'Quentin Christensen' <quentin@nvaccess.org>
- Cc: 'Wai-Ig' <w3c-wai-ig@w3.org>
- Message-ID: <0af3180e-0266-a1cd-acf2-c4f9fad6f120@gregjellin.com>
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 <greg@gregjellin.com> > *Sent:* Tuesday, December 13, 2022 12:15 PM > *To:* Quentin Christensen <quentin@nvaccess.org> > *Cc:* Adam Cooper <cooperad@bigpond.com>; 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 > > 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 <http://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> >
Received on Tuesday, 13 December 2022 02:31:07 UTC