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

fix(radio): radio buttons not being a tab stop and missing focus indication #1731

Closed
wants to merge 1 commit into from

Conversation

crisbeto
Copy link
Member

@crisbeto crisbeto commented Nov 4, 2016

  • Fixes the radio buttons not being tabable.
  • Adds focus indication to the radio buttons.

Referencing #421.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Nov 4, 2016
Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CC @tinayuangao for any additional comments

@@ -239,6 +239,9 @@ export class MdRadioButton implements OnInit {
@HostBinding('class.md-radio-focused')
_isFocused: boolean;

/** Tabindex for the input element. */
@Input() tabindex: number = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The property should be tabIndex

I'm confused why this wasn't working, though- focus should have gone to the native radio without having to explicitly set a tabindex. Where were you seeing the problem?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't remember right now, but I was testing against the local demo app. I'm retrying now and it works fine without the tabindex, so I assume it was because I wasn't seeing the ripple. I've removed the tabindex changes from the PR.


it('should make the native input element a tab stop', () => {
expect(fruitRadioNativeInputs[0].tabIndex).toBe(0);
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being a tab stop is something better covered by an e2e test where we can actually press the tab key, but it is good to have a unit test that asserts we're forwarding the tabIndex property.

@@ -1,6 +1,6 @@
<!-- TODO(jelbourn): render the radio on either side of the content -->
<!-- TODO(mtlin): Evaluate trade-offs of using native radio vs. cost of additional bindings. -->
<label [attr.for]="inputId" class="md-radio-label">
<label [attr.for]="inputId" class="md-radio-label" [class.md-ripple-focused]="_isFocused">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a TODO to only show this focus indicator when the focus came from a keyboard event?

@crisbeto
Copy link
Member Author

crisbeto commented Nov 8, 2016

Updated the PR to address the comments.

@@ -1,6 +1,7 @@
<!-- TODO(jelbourn): render the radio on either side of the content -->
<!-- TODO(mtlin): Evaluate trade-offs of using native radio vs. cost of additional bindings. -->
<label [attr.for]="inputId" class="md-radio-label">
<!-- TODO(crisbeto): only show focus indication if focus came from a keyboard event -->
<label [attr.for]="inputId" class="md-radio-label" [class.md-ripple-focused]="_isFocused">
Copy link
Member

@jelbourn jelbourn Nov 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pulled down the PR and tested it out; I found that changing the selected radio within a group somewhat quickly (such as when using the keyboard) leaves a trailing grey circle on the radio.
(doesn't occur on master)

…cation

* Fixes the radio buttons not being tabable.
* Adds focus indication to the radio buttons.

Referencing angular#421.
@jelbourn
Copy link
Member

jelbourn commented Dec 2, 2016

@crisbeto what's the status on this one?

@crisbeto
Copy link
Member Author

crisbeto commented Dec 3, 2016

Sorry, @jelbourn I missed this one in between all of the notifications. The issue is that the ripple still animates for a little after you move focus away from the radio button. It can be fixed by changing this line to *ngIf="!_isRippleDisabled() && _isFocused", however now there won't be ripples when you click multiple times on a radio button.

I tried setting up the the blur event so that it checks if the focus is still within the radio button, but the event.relatedTarget comes up null occasionally (not sure why) and using document.activeElement requires that we use a timeout. Perhaps we should try to find some more generic solution within the ripple?

Alternatively this could become easier to fix once we have the ability to know where the last focus event came from (whether it was a click or a keyboard event).

@andrewseguin
Copy link
Contributor

Please rebase

@crisbeto
Copy link
Member Author

Looks like much of the setup for this and #1730 has changed @andrewseguin. I'll probably end up closing them and redoing.

@andrewseguin
Copy link
Contributor

Sounds good, apologies for the delay in getting this merged when you sent it out

@crisbeto
Copy link
Member Author

Closing and will re-do based on the current APIs.

@crisbeto crisbeto closed this Feb 18, 2017
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes PR author has agreed to Google's Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants