Closed chillu closed 6 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:
@Ingo, which do you think is preferable?
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.
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.
Current state of play:
:focus
styles, so it’s hard to tell when to hit the up arrow to open that menu (same issues for preview width):focus
styles now, so they seem to be fine to meThanks 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.
silverstripe/silverstripe-admin#516 has been merged, so I think this is fine for now
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?