- From: Greg Jellin <greg@gregjellin.com>
- Date: Mon, 12 Dec 2022 17:14:37 -0800
- To: Quentin Christensen <quentin@nvaccess.org>
- Cc: Adam Cooper <cooperad@bigpond.com>, Wai-Ig <w3c-wai-ig@w3.org>
- Message-ID: <3f2e24a2-c5a5-83d8-3946-f21a5a8c9372@gregjellin.com>
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 01:14:51 UTC