Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

Buttons require a visual focus state #142

Closed
marcysutton opened this issue Aug 19, 2014 · 15 comments
Closed

Buttons require a visual focus state #142

marcysutton opened this issue Aug 19, 2014 · 15 comments

Comments

@marcysutton
Copy link
Contributor

To make flat and raised buttons accessible from the keyboard, they should have visual contrast upon user interaction. In the Material Design spec, focus states are illustrated with a ripple effect:

Flat button states
Raised Button states

A similar ripple effect is needed to add focus states to all buttons.

@marcysutton
Copy link
Contributor Author

@ThomasBurleson are you the person in charge of ripple effects? There is still some work to be done for buttons and link buttons to be accessible, in addition to this focus style.

@ThomasBurleson
Copy link
Contributor

Yes, I am the primary author for effects.js and ink-stuff.
Shall we work together on Monday for button ARIA ?

Btw, inkFocus is an outstanding feature item to be worked on next week. (@see #175)

@ThomasBurleson
Copy link
Contributor

This will mostly like be resolved with approach similar to that used within the new css Ink Ripples solution.

@ajoslin
Copy link
Contributor

ajoslin commented Sep 11, 2014

Waiting on input from UX team.

@scarletsky
Copy link
Contributor

Hello, I found that on the demo site, a .focus class will add to material-button after clicking it. And the .focus class will remove when I click other place.

It probably cause by

.on('focus', function() {
element.addClass('focus');
})
.on('blur', function() {
element.removeClass('focus');
});

Don't you think it will be better to remove the .focus class after clicking it ?

@ThomasBurleson
Copy link
Contributor

@scarletsky Perhaps I do not understand. The .focus class is used to indicate when the button has focus. If you remove the focus indicator after clicking, then you are not showing that the click has also selected the focusable button element.

@scarletsky
Copy link
Contributor

@ThomasBurleson
This is just a UX question. I just feel confusing that why the .foucs class do not remove automatically.

@marcysutton
Copy link
Contributor Author

@ThomasBurleson the class being added to trigger ink effects in JS, yes? The implementation looks fine to me, as long as there's no race condition with the tabIndex being set after (I don't think there would be, just calling it out).

@scarletsky the focus state should stay on the element as long as it's focused, not based on a time interval.

@ThomasBurleson
Copy link
Contributor

@marcysutton
The .focus class only animates an offset for FABs; otherwise the focus class simple sets the background color... which is a ink effect (but not a ripple).

@ajoslin
Copy link
Contributor

ajoslin commented Sep 13, 2014

The focus class is used to add some visual styling to the outer element
while still passing focus to the inner element.
On Sep 13, 2014 9:18 AM, "Thomas Burleson" notifications@github.com wrote:

@marcysutton https://github.com/marcysutton
The .focus class only animates an offset for FABs; otherwise the focus
class simple sets the background color... which is a ink effect (but not a
ripple).


Reply to this email directly or view it on GitHub
#142 (comment).

@robertmesserle robertmesserle modified the milestones: 0.7.0, 0.7.1 Jan 7, 2015
@naomiblack naomiblack modified the milestones: 0.7.1, 0.8.0 Jan 26, 2015
@sambryant
Copy link

It seems like some of you are suggesting that the problem is that the element is remaining in a focus state. It's supposed to do that: http://jsfiddle.net/nv3rvru1/8/

I think the problem is the choice to apply visual effects based on focus state. However, I don't know enough to say how accessibility fits in here.

@albertboada
Copy link

👍

@skribbz14
Copy link

Don't you think there could be some sort of option applied to the that would choose whether we want the :focus to stay on or be removed after clicking? This seems to be a personal preference that not everyone agrees on, so allowing the developer to choose would make everyone happy.

@marcysutton
Copy link
Contributor Author

Buttons actually have a focus state now, so I'm closing this issue.

@skribbz14 to answer your question, consistency is more important in this case. Supporting both of those options would add complexity to maintain, and in my opinion would fragment the Material Design user experience. I have a question out to the UX team about how controls should handle visual focus in a way that works with the browser and looks intentional. Work on that can be tracked here: #1594

There is also a separate issue open for the button pressed state: #2089

@chanakaDe
Copy link

Yeah all the buttons are ok with now.

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

No branches or pull requests