Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first alternative highlighted after retry #23

Open
otacke opened this issue Apr 20, 2017 · 10 comments
Open

first alternative highlighted after retry #23

otacke opened this issue Apr 20, 2017 · 10 comments

Comments

@otacke
Copy link
Contributor

otacke commented Apr 20, 2017

I noticed that after a retry the first alternative is highlighted via a CSS hover effect. At first, I thought I might have caused this behavior somehow in my latest pull request, but it can actually be found in multi-choice right now.

@falcon-git
Copy link
Member

I think this is by design to provide a good user experience for keyboard users. I agree that it looks a bit buggy if you're not using the keyboard. Not sure what to do about it.

@otacke
Copy link
Contributor Author

otacke commented Apr 25, 2017

Hmm, just for that purpose, it would be a little "overkill" to listen for keydown and mousedown (and touch) events in order determine whether the last interaction before the reset came from the keyboard or the mouse (or a touch device), wouldn't it?

@falcon-git
Copy link
Member

It would be a way of solving it. I didn't think of that. Good idea! I'll discuss it with those who implemented it tomorrow to see if they think it is "overkill".

@otacke
Copy link
Contributor Author

otacke commented Apr 25, 2017

Sounded just weird to me for such a tiny issue :-)

@falcon-git
Copy link
Member

Yes, but we have the same issue in a lot of content types. It is not only MultipleChoice, so if we could solve it in a nice way(code wise) for all it would be a step forward.

@otacke
Copy link
Contributor Author

otacke commented Apr 25, 2017

In that case, I am going to file in a patent first thing in the morning ;-)

@icc
Copy link
Member

icc commented Apr 25, 2017

Hehe...

I wonder if this could be made better by simply making the focus effect a bit softer. The purple background almost makes it seem like the option is selected instead of highlighted.

I can't recall where but I imagine that I've read something about that moving the focus to where the next "action" is needed is a good UX approach, especially when going "backwards". It may have been a WCAG thing.

@otacke
Copy link
Contributor Author

otacke commented Apr 25, 2017

I see. But wouldn't that have potential for confusing people with visual impairment?

For example, if you have a form with some instructions at the top and some input fields below, setting focus to the first input field would be great for people who're not impaired. They can still see the text and start typing right away. On the other hand, if you're blind and cannot see the text, you wouldn't get the context if the focus was on the input field right away, would you?

From this perspective, multiple choice seems to use the focus wisely: not setting focus on first start, but on retry.

@icc
Copy link
Member

icc commented Apr 26, 2017

Actually, I believe you do get the relevant context using a readspeaker if the HTML is set up correctly, and if not I guess that the user would normally 'zoom out' to the parent element until it makes sense.

@otacke
Copy link
Contributor Author

otacke commented Apr 26, 2017

I don't know. Will have to learn about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants