- From: Jesse Hausler <jhausler@salesforce.com>
- Date: Thu, 25 Jul 2019 09:41:32 -0600
- To: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAFAi0ChAY3kwd7wVnc2us-1H9UFjPyEmFO0mZ_amL-M1Z--Qrg@mail.gmail.com>
In a world of single page apps, if buttons can't move focus, we aren't leaving a lot of options out there for app developers. If a user presses a button with a proper accessible name, they should expect a result that was described. For instance, if I have an "edit" button, is it not fair to expect focus to move to the place where editing should occur? It shouldn't matter if that place is a modal, a non-modal, a slide in panel, or just a spot lower down on the page. I recently had a conversation with an expert in this group (they are welcome to identify themself if they'd like) about a product team that wanted a checkbox to open a modal in some situations. We both knew that this was wrong, but decided a "stateful" button would be ok, as long as the button didn't visually look like a checkbox. If that option is taken off the board, we're eliminating the ability to design and develop some pretty reasonable interaction patterns. Jesse On Thu, Jul 25, 2019 at 8:13 AM Detlev Fischer <detlev.fischer@testkreis.de> wrote: > IMO 2.4.3 Focus Order seems the perfect place to file these all too > frequent and serious issues > > Am 25.07.2019 um 15:20 schrieb Patrick H. Lauke: > > Depends though....if the button opens a modal dialog or dropdown menu > > or similar, I'd expect focus to move. It comes back down to user > > expectation/habit I guess... (I've sometimes been known to file very > > odd things where these don't behave the right way under Focus Order, > > but realise it's possibly stretching the intent of that SC a bit too) > > -- > Detlev Fischer > Testkreis > Werderstr. 34, 20144 Hamburg > > Mobil +49 (0)157 57 57 57 45 > > http://www.testkreis.de > Beratung, Tests und Schulungen für barrierefreie Websites > > >
Received on Thursday, 25 July 2019 15:42:32 UTC