Restore keyboard navigation on chosen.js preview customizations

silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS

https://www.silverstripe.org

BSD 3-Clause "New" or "Revised" License

721 stars 821 forks source link

Restore keyboard navigation on chosen.js preview customizations #2101

Closed chillu closed 6 years ago

chillu commented 11 years ago

We take pride in the fact that the majority of our CMS UI is keyboard navigatable, and I would like to keep it this way. It not only keeps the UI accessible to users without a mouse (motion impaired), but also to screen readers who only "see" focusable elements as interactive. The preview mode chosen.js UI controls violate this at the moment.

This was already mentioned in the original pull request, but gotten dropped due to the team running out of time.

Now that we're in the polish phase for 3.1, @adrexia @mateusz could one of you please look at this?

Visible keyboard focus and tabindex on "draft"/"live" switch
Enter key on "draft"/"live" switch switches mode
Up/down keys trigger overlay on mode dropdown
Up/down keys allow navigation through modes (should be built-in for chosen.js)
Enter key on mode switches mode (should be built-in for chosen.js)

adrexia commented 11 years ago

The draft/live switch uses radio buttons. Putting a tab index on them enables tabbing to the element, but because they are radio buttons (with the same name), the default way to switch between them is by using the arrow keys.

By using the arrow keys once you are on the switch, you can change the state on the preview without having to press enter. Normally with radio buttons its obvious that this is how you control them. However with our switch you would only know they are radio buttons by looking at the code, or using a screen reader. There are three solutions I can think of:

Live with the radio button functionality. Maybe add some sort of hint when the button is tabbed into.
Give the radio buttons unique names (this would be unsemantic, but would allow tabbing between the two elements)
Replace the radio buttons with something else...

@Ingo, which do you think is preferable?

chillu commented 11 years ago

Thanks for picking this up Naomi! To be honest I always thought the idea of radio buttons was overcomplicating things. Each of those essentially cause an iframe to reload, so map to a link. Hence they should be links in the first place. This would make focus behaviour more consistent, and also allow opening previews in new windows, bookmarking/sharing them, etc.

adrexia commented 11 years ago

The radio buttons allow the switch itself to be animated in pure css. In the end it probably didn't matter too much, as there was quite a lot of javascript written around the behaviour of the switch. However, now that it's implemented, changing away from radio buttons is not such a small thing.

The actual animation I might be able to retain by just adding an active class to the current view state, and using very similar markup to that used by the radio buttons (input:checked => a.active). I'll take a look at what would need to change in the js.

kinglozzer commented 6 years ago

Current state of play:

All are keyboard navigable
View mode toggle lacks any :focus styles, so it’s hard to tell when to hit the up arrow to open that menu (same issues for preview width)
Draft/Published buttons do have :focus styles now, so they seem to be fine to me

chillu commented 6 years ago

Thanks for the update, Loz! Wanna re-add those styles? I think in terms of product team attention, this might have to wait until we revisit those sections with React.

kinglozzer commented 6 years ago

https://github.com/silverstripe/silverstripe-admin/pull/516

kinglozzer commented 6 years ago

silverstripe/silverstripe-admin#516 has been merged, so I think this is fine for now