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

Balloon does not seem to get focus when mouse dragging #113

Closed
jhung opened this issue Jan 14, 2016 · 5 comments
Closed

Balloon does not seem to get focus when mouse dragging #113

jhung opened this issue Jan 14, 2016 · 5 comments
Assignees

Comments

@jhung
Copy link

jhung commented Jan 14, 2016

When using the mouse to drag the balloon, it does not appear to gain focus. There is no focus box on the balloon when dragging. Also if using a combination of mouse and keyboard, dragging the balloon first with mouse then pressing tab puts focus on the balloon, when the focus should go onto the next focusable item (i.e. Remove wall button).

@jessegreenberg jessegreenberg self-assigned this Jan 14, 2016
@jessegreenberg
Copy link
Contributor

Good catch @jhung, thank you for creating the issue. Integrating accessible mouse interaction is a feature that PhET will be working on in the near future.

@terracoda
Copy link
Contributor

Yes, good catch @jhung. @jessegreenberg, I've noticed this, also, on all A11y sims (well FAMB and BASE). Mouse focus and keyboard focus are currently not synched. I made note of this when I tested FAMB. For FAMB there is an actual mouse focus in the original sim design, and these styles are actually visually different - yellow circles for mouse focus rope knots and pink squares for keyboard focus on rope knots.

@jessegreenberg
Copy link
Contributor

I believe this would mostly be implemented with phetsims/scenery#41. However, the focus event is separate from other mouse events. For most accessible forms, the focus highlight disappears if the mouse is pressed. If a button is pressed, the navigation order resets.

Implementing this would mean an addition to typical html behavior. That may be necessary for PhET's applications, but we should discuss how this would behave and investigate how the deviation could exist within scenery.

@terracoda
Copy link
Contributor

In traditional website design it is often the focus style that gets overlooked in the design process, making it difficult for many users (but especially visual keyboard users) to see where they are on the page. This is usually handled through the CSS psuedo-classes: Link, Visited, Hover, Focus, Active. It often makes sense (but not always) to have the hover style the same as the focus style.

In many PhET sims the visual change on hover (or mouse over) is subtle (e.g. Reset button) and in some cases it is not so subtle (yellow circles on knots in FAMB). Looking at the big picture, maybe some design efficiencies can be made? For example, could the focus and the hover on the Reset button be the same? And if so, the option that provides higher contrast, would be preferred from a visual accessibility perspective.

@jessegreenberg
Copy link
Contributor

As a general pattern we have since decided that focus will disappear after interaction with a mouse so this issue can be closed.

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