Repeater controls are impossible to access with keyboard navigation

[teppokoivula]

Short description of the issue

Repeater controls are impossible to reach with a keyboard, which is a pretty big issue in terms of accessibility. I would also argue that the default setting for the "loudControls" setting is somewhat problematic from a more general usability point of view, since the user has to know that these controls exists to be able to fully utilize the editor GUI.

Expected behavior

I would expect to be able to manage Repeater items with a keyboard as well as a mouse or touch interface. Currently that is not possible, since these options are not tabbable, and can't be modified with keyboard controls.

As for "loudControls ", while the old behaviour can be restored by flipping a setting, and I get the idea behind this option (and generally support making things less cluttered), but from my point of view this update is actually a small step backwards.

Actual behavior

See short description of the issue.

Setup/Environment

• ProcessWire version: 3.0.189 dev

[teppokoivula]

After taking a closer look I stand corrected: the loudControls setting didn't actually affect the "tabbability" (not sure if that's a word, but you get the point I hope) of the Repeater controls: even with said option set to "always", those controls are still impossible to reach. And, testing on an earlier setup, they have been so either always, or since quite a while back.

The point about them being hidden by default (which, in my opinion, is a a potential problem in itself, as described above) stands, but the bigger accessibility issue with keyboard navigation predated today's commit :)

[Toutouwai]

I guess the controls should be changed to <button> elements (probably applies to a lot of elements in the admin that have JS behaviours attached) and given a tabindex.

Regarding the visibility, maybe the controls could be shown when any item within the repeater has focus?

[ryancramerdesign]

I'm open to it, but also not sure 100% keyboard-based management of repeaters is practical even if we made it technically possible. Same goes for some other repeatable types (like images). I think in an administrative environment, requiring a pointing device for some actions (whether mouse, trackpad, touchscreen) is reasonable. Many things are drag-and-drop sortable as it is, and that's not something you can do with a keyboard as far as I know. I see the add-on actions for repeaters like that, power tools in an admin environment. None of them are technically required to manage content (except maybe the Delete action) but they are helpful extras like insert in-place, clone/copy/paste, etc. Folks got along fine before we had them, but for power users with a compatible device, they can be time saving tools.

If doing things like converting those actions to a button and/or having tabindexes on them would solve a current need someone has and it will actually get used, I'm definitely open investing the time in it. But also don't want to maintain an expectation that the admin is a full-on keyboard environment, as a lot of things are aimed for pointing devices.

As for the visibility of the repeater header actions, my thought was that these are things you don't need 98% of the time, but they are adding visual clutter 100% of the time. I thought it would be better to hide them until you hover the header, suggesting you need something there. So they are there when you want them, and not when you don't. This is also consistent with how the actions in the page-list work. I thought this was a good default behavior, but made it configurable in case anyone preferred them always visible. I'm flexible on what the default is though (always visible vs. contextually visible) and don't feel that strongly about it either way. I'm happy to change the default but would like to gather more feedback first, as I think it's always beneficial for PW's appearance to minimize visual clutter when possible. So would want to first see if there's more consensus about this particular case.

[teppokoivula]

First of all, I should probably mention that I'm aware that we're currently not working towards fully accessible admin section. I say currently, because I do hope that one day we might. Keeping that in mind, I'm mostly interested in things not going "to the wrong direction" in this area, and on the other hand potentially finding "easy wins" where relatively small change could make a relatively big difference in terms of a11y :)

I think in an administrative environment, requiring a pointing device for some actions (whether mouse, trackpad, touchscreen) is reasonable. Many things are drag-and-drop sortable as it is, and that's not something you can do with a keyboard as far as I know.

It's true that drag and drop is problematic: it pretty much needs to be accompanied by a "move up/down" type of option. Since this needs a separate implementation, it of course complicates things somewhat. That being said, I'm actually curious to see if that could be baked into our repeatable elements (I'd be happy to give it a try).

Regarding the power user aspect of it all, I do — to an extent — agree. And yes, I also think that delete is an exception here. That being said, when we're talking about accessibility, one important guideline is that if something can be done with, say, a mouse, it must also be doable with other methods. In order to provide everyone equal opportunity to use the system.

I think it's best not to go too deep into that particular rabbits hole here and now. Just something to consider :)

If doing things like converting those actions to a button and/or having tabindexes on them would solve a current need someone has and it will actually get used, I'm definitely open investing the time in it. But also don't want to maintain an expectation that the admin is a full-on keyboard environment, as a lot of things are aimed for pointing devices.

Making them buttons would be a good solution 👍

If that turns out to be difficult, adding tabindex="0" would make it possible to focus on them as well, but in that case they should also get role="button" to signal browsers and devices that they are really buttons. Generally I'd say that this is a bit of an antipattern, so I'd go with buttons if at all possible.

Note that these buttons should also get accessible text content. Title property is announced by some screen readers, but to my best knowledge this is a bit flaky. aria-label works better, but actual text (in this case likely with a suitable sr-only class) would be the most reliable solution.

But also don't want to maintain an expectation that the admin is a full-on keyboard environment, as a lot of things are aimed for pointing devices.

No pressure — every step towards that is a win in my books. And, again, I'd be happy to put some of my time towards this as well if it helps :)

I'm happy to change the default but would like to gather more feedback first, as I think it's always beneficial for PW's appearance to minimize visual clutter when possible. So would want to first see if there's more consensus about this particular case.

I hear you, that makes sense!

I'm personally slightly conflicted about this behaviour: as I said I really like uncluttered things, but at the same time I've found that users (particularly those with less experience with the system, or who use it rarely) get very easily confused by such things.

For an example, back in the days we had so many reports from end-users who simply couldn't spot collapsed fields, or couldn't recognize them as something they could interact with, that eventually we had to make an internal rule that collapsed fields / fieldsets are not to be used, ever. Since then I've been careful not to hide anything I expect users to ever access by default... :)