- From: Greg Jellin <greg@gregjellin.com>
- Date: Mon, 12 Dec 2022 18:49:15 -0800
- To: Adam Cooper <cooperad@bigpond.com>, 'Quentin Christensen' <quentin@nvaccess.org>
- Cc: 'Wai-Ig' <w3c-wai-ig@w3.org>
- Message-ID: <392f7a4a-0cbb-832c-9c5c-fb509baa6297@gregjellin.com>
They actually are indeed links, each within a listitem. On 12/12/2022 6:46 PM, Adam Cooper wrote: > > 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 <greg@gregjellin.com> <mailto:greg@gregjellin.com> > *Sent:* Tuesday, December 13, 2022 12:15 PM > *To:* Quentin Christensen <quentin@nvaccess.org> > <mailto:quentin@nvaccess.org> > *Cc:* Adam Cooper <cooperad@bigpond.com> > <mailto:cooperad@bigpond.com>; Wai-Ig <w3c-wai-ig@w3.org> > <mailto: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:49:30 UTC