-
Notifications
You must be signed in to change notification settings - Fork 97
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
Comments
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. |
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? |
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". |
Sounded just weird to me for such a tiny issue :-) |
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. |
In that case, I am going to file in a patent first thing in the morning ;-) |
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. |
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. |
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. |
I don't know. Will have to learn about that. |
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.
The text was updated successfully, but these errors were encountered: