Add accessibleFocus utility.

[mtias]

This utility gives us the ability to target focus styles and make them more prominently visible without affecting input devices that don't navigate around the UI using the keyboard.

[ellatrix]

I'm not sure if this is the right way to do this, but maybe I'm wrong. Might a better focus design help?

[afercia]

I'm sorry but this seems based on a very wrong assumption, like if only keyboard users need a visible focus. It is also against the WCAG requirements.

I'd also note that I don't see an issue related to this PR, nor I've heard of any public discussion about the introduction of this utility.

[nylen]

It is also against the WCAG requirements.

Can you elaborate on this point?

I'd also note that I don't see an issue related to this PR, nor I've heard of any public discussion about the introduction of this utility.

This is pretty normal, development on the project is still moving quite quickly. It's fine to discuss the change here too.

[ellatrix]

Ideally we'd have one button for both arrows and one would use arrow keys to navigate. Not sure if such a thing is possible, but it would work a but like <input type="number> where you can increase or decrease the number with arrow keys, or like a dropdown/select where you navigate the options with arrow keys.

[ellatrix]

It actually is pretty much like an <input type="number> because you're increasing or decreasing the index to change the order.

[ellatrix]

(I'm assuming this is mainly to fix the prominence of the arrow button focus style.)

[afercia]

Can you elaborate on this point?

There's a lot of elaboration on the specification this project should follow:
https://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html

Also, there's already an issue open about focus visibility: #574

I don't see the point in trying to detect keyboard usage. Focus indication is a requirement to implement for all users. If this is meant for implementing focus visibility just when some keyboard usage gets detected, then it's a very wrong assumption.

Also, worth considering there are dozens of alternate pointing/input devices, some of them work in a sort of "keyboard emulation" that can't be detected.

[mtias]

@afercia thanks for your feedback!

I don't see the point in trying to detect keyboard usage. Focus indication is a requirement to implement for all users. If this is meant for implementing focus visibility just when some keyboard usage gets detected, then it's a very wrong assumption.

That wasn't really the assumption in the description. Reading the docs you linked to I also don't see where the implication that focus styles need to be the same for all contexts is established?

I grabbed a few quick examples from how Apple, Chrome, and GitHub are doing focus visibility in a more surgical manner:

Having the ability to set different focus styles when you are interacting with keyboard navigation from other interactions that don't rely on keyboard seem useful in crafting a more tailored UI. Small example of a distracting consequence of keyboard oriented focus styles applied during click behaviour which doesn't seem to be helping: https://cloudup.com/cz3K6JxKAOl

[afercia]

@matias what I see in the browser toolbar is the platform specific (macOS) focus style applied on the browser frame. The focus style on the "Watch" GitHub button happens also on mouse click, it's just a different style on :active. The fact GH is doing that way doesn't mean it's WCAG compliant though 🙂

Quoting from the second link I posted:

People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

That clarifies that a clear indication of focus is not only for keyboard users. Sure, it can be different but it must always be very clear so I'm wondering if it's really worth it making it different. The point of making the focus style "lighter" when not using a keyboard just doesn't meet the spec.

[nylen]

Thinking more about this, it should be called keyboardFocus, keyboard-focus, has-keyboard-focus rather than accessibleFocus.

[ellatrix]

Trying to find a way to make everyone happy.

@afercia It looks like the video @matias shared shows an issue where the focus is temporarily moved to the "x" icon and then disappears, which is a bit strange and maybe it's also a accessibility issue? Not sure. Is there any way we can make this better?

@matias Are there any other specific issues that you have in mind?

[afercia]

@iseulde thanks for pointing me at the video. What I see there is a control that gets clicked: when clicked, is at the same time in an :active and :focus state. So if there's a CSS style for :focus that gets applied. If there's the need to have a different style while it's clicked then :focus:active should work in all browsers and core is already using that for the nav tabs.

Sidebar:
I cant even tab into it. However, assuming I can, when I press the X and the whole sidebar together with the focused control disappear, what happens is a classical example of focus loss.
I think I've already highlighted this point countless times: a focused element should never, ever be removed, disabled, hidden, while it has focus. When doing so, focus is lost. If there's really, really, the need to do that, then focus should be managed programmatically and be moved back to a logical place.

Quickly testing the sidebar on Chrome, when I press the X, focus is completely lost and the browser puts it back to the document root. This is the worst scenario where users would be forced to start content navigation again from the scratch.

Navigation from the "Post Settings" button to the Sidebar is also a big concern. I thought the sidebar was supposed to be open by default, as I've been told in #467

[jasmussen]

Navigation from the "Post Settings" button to the Sidebar is also a big concern. I thought the sidebar was supposed to be open by default, as I've been told in #467

Just a quick note to say it will be open by default, but if you dismiss it then it's cookied as dismissed until you toggle it back on again. But this is in part blocked also by #450, and representative only of the very in-flux state of development it's in right now.

[ellatrix]

Thanks for the feedback @afercia! That :active trick sounds like a good solution to fix the visual issue! Other than that, we clearly need some help with all the accessibility issues, while we do our best to improve it where we can and have the knowledge. In case of the sidebar, it sounds like moving it back to the sidebar toggle button would be logical.

[ellatrix]

Just to make it clear: I primarily added the focus styles to visualise where the the focus is. I knew there would be issues we'll have to improve, both in terms of design and accessibility, but at least now we see what needs to be improved. :)

[afercia]

Yep worth noting the :focus:active trick may not work well for controls that stay visible, because after you click them and then release the mouse button, they will still be in a :focus state.

About the interaction with the sidebar, I'd propose to discuss that separately, there are a few basic a11y concepts to focus on.

[ellatrix]

Yep, we should open separate PRs and tickets for separate issues. Feel free to make tickets for any issue you see, I'll have an eye on focus issues and make sure they get fixed.

[aduth]

Should we close this pull request?

[nylen]

+1 for close, I don't think this is the right solution. If this is going to stick around, it needs a rename to keyboardFocus.

[gziolo]

I think we can close it after reading all comments. @mtias feel free to reopen if you disagree with that.