Radio Group Examples: Style both button and label on focus and hover

[jongund]

In the radio group examples, Keyboard focus no longer styles the label as well as the button.

Change it back to style both.

[mcking65]

@jongund, in radio.css, I see:

[role="radio"].focus:before,
[role="radio"]:focus::before {
  width: 16px;
  height: 16px;
  box-sizing: content-box;
  border-color: hsl(216, 94%, 73%);
  border-width: 3px;
  border-radius: 100%;
  box-shadow: inset 0 0 0 1px hsl(216, 80%, 50%);
}

Doesn't that provide the styling you are talking about?

Looking at the history for radio.css, it looks like the last change was by @MichielBijl in February. Did that change break something?

If so, any chance you can make a PR in the next couple of hours? Would that change be limited to radio.css? I ask because it looks like I should make a couple more editorial changes to the HTML.

[jongund]

No in the original examples the label was also styled, making it visually much easier to see than just styling the radio buttons. I can work on fixing this issue for the next release, since it requires adding focus and blur event handlers to change focus styling on the label. I also need to look at the APG section on focus styling in general to review the current recommendations. Jon From: Matt King <[email protected]> Reply-To: w3c/aria-practices <[email protected]> Date: Monday, December 11, 2017 at 1:42 PM To: w3c/aria-practices <[email protected]> Cc: Jon Gunderson <[email protected]>, Mention <[email protected]> Subject: Re: [w3c/aria-practices] Keyboard focus styling of radio button examples (#568) @jongund<https://github.com/jongund>, in radio.css, I see: [role="radio"].focus:before, [role="radio"]:focus::before { width: 16px; height: 16px; box-sizing: content-box; border-color: hsl(216, 94%, 73%); border-width: 3px; border-radius: 100%; box-shadow: inset 0 0 0 1px hsl(216, 80%, 50%); } Doesn't that provide the styling you are talking about? Looking at the history for radio.css<https://github.com/w3c/aria-practices/commits/master/examples/radio/css/radio.css>, it looks like the last change was by @MichielBijl<https://github.com/michielbijl> in February. Did that change break something? If so, any chance you can make a PR in the next couple of hours? Would that change be limited to radio.css? I ask because it looks like I should make a couple more editorial changes to the HTML. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#568 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABcE7Pjs-BgZ8c90G7bkuoNSzwxVnDHvks5s_YWmgaJpZM4Q90rM>.

[sh0ji]

I'm generally in agreement with @jongund that focus styling needs to be obvious and make it clear what element is being focused. Unless I'm missing something, just removing the outline: none; would be the easiest way to do this.

But I think a good argument could be made for leaving this the way it is: native input[type=radio] elements with a corresponding label only add a focus indicator to the radio input and not to the corresponding label. That's exactly what the current design does.

[ZoeBijl]

The current design is in line with native behaviour on both Windows and Mac. They’re also in line with the styling as used in the checkbox examples.

[mcking65]

@MichielBijl and @sh0ji,

@jongund has submitted PR #703 for this issue. The effect can be seen in his repo here:

https://rawgit.com/jongund/aria-practices/issue-568-focus-styling/examples/radio/radio-1/radio-1.html

I'd appreciate review from sighted CSS experts like you guys!

[mcking65]

@sh0ji, thank you for the review of pull #703.

You wrote:

Would it be useful to point out that most user agents do not style the hover state on native input[type="radio"] elements? It's a useful affordance, but should maybe be considered optional.

We have some styling notes under accessibility features. We do not need to point out that native radios do not have this feature, but could point it out as an accessibility feature of this example.

I don't understand what is happening visually on hover and how it is helpful to accessibility. So, if someone can propose some language to describe the effect and its advantage, that would be helpful.

@jnurthen, @MichielBijl, I'd like to merge 703 this week unless you have reasons not to do so ... please comment here or add review in the pr.

[mcking65]

Now that I've merged pull #703 from @jongund, per suggestion from @sh0ji, I'd like to improve the accessibility features documentation before closing this issue.

The current relevant bullet under accessibility features reads:

Uses CSS :hover and :focus pseudo-selectors for styling visual keyboard focus and hover.

This doesn't say that both the button and label are styled, doesn't say what the styling does, and does not give an accessibility advantage/reason. Could someone propose some new language for this?

[mcking65]

With commits 72ea89c and da21a48, this issue is resolved.