0

Wanted some opinions on using HTML selects for keyboard input. We're developing an app in React using Material UI, and their version of a select dropdown element is pinging a few questions in testing.

The Material UI SelectField operates as such with keyboard:

https://www.youtube.com/watch?v=swz82ul6Hao

A browsers default action is as such:

https://youtu.be/MCaDh9JlIr4

I note that when you tab to the input and activate it (enter or down-arrow) in the default browser version, the currently selected item, or the first default item is focussed - whereas with the Material UI version, you have to press up or down once its activated to get any item focussed...

Any thoughts on this?

closed as primarily opinion-based by locationunknown, Joel Tebbett, Andrew Martin, Ken Mohnkern, Mayo Sep 19 '17 at 21:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

0

Generally:

  • If you are developing an app using Material UI for android:

Let the default behaviour of the Material UI as is.

  • If you are developing an app using Material UI for a web app:

Let the default behaviour of the browser take over without forcing mechanics of your selected UI to the user.

Especially for users with disabilities who might use a specific browser and they are more familiar with the mechanics. Taking over that behaviour does usually more bad than good.

  • If you are developing a desktop app using Material UI:

Use the behaviour you want (Material UI's in that case). You are putting the user in a controlled (by you) ecosystem so the mechanics are largely guided by you.


As always, if you are unsure test with users and ask for feedback.

I am happy though that you and your team pay attention even to (at first glance) "small" things like that.

0

I think you should always let the user know the current state of the system, in this case telling them where the focus is.

If you can easily replicate browser behavior maintaining material concept of design, I would go for it, it can only be a benefit.

Instead, if the browser default behavior is going to take a lot of work and/or ruin the general experience like a dirty spot, maybe in this case it's a small thing and you can skip it. I would think like a possible end user and ask me (or ask them directly, if you have the possibilities) what would be the best trade off for him.

Talking about accessibility there is a guideline in WCAG (https://www.w3.org/WAI/intro/wcag) that state: "For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies."

If you read the "understanding" page https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html you find a paragraph where it is said that "the focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology".

Reading this one can say that it's important that the focus has always to be visible, but, as it is for everything, I still think it really depends on the context.

I hope this could help!

Not the answer you're looking for? Browse other questions tagged or ask your own question.