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

Focus is invisible in WHC #215

Closed
StommePoes opened this issue Sep 24, 2020 · 4 comments
Closed

Focus is invisible in WHC #215

StommePoes opened this issue Sep 24, 2020 · 4 comments
Assignees
Labels
a11y Anything relating to accessibility.

Comments

@StommePoes
Copy link

StommePoes commented Sep 24, 2020

Keyboard-only users of Windows High Contrast mode (WHC) cannot determine their current focus position in most of the components. Radio controls (where focus and selection are usually a shared state) are entirely indistinguishable.

This is because WHC forces a small set of available colours, in order to make it easier to force a high contrast (even though users can create their own themes with any level of contrast if they wish). Changes in colour used to denote state are not visible: border-color, background-color etc used as the sole visual method of denoting a state (such as focus or selection) do not appear. Box-shadow also does not appear. Opacity changes do.

I threw together a page of my own that just has some random components, because that was easiest to test: https://stommepoes.nl/work/shoelace/shoelace_demo.html

  1. Choose a Windows browser which supports Windows High Contrast: Edge, Firefox. Do not use Chrome even with the flag turned on.
  2. Turn on WHC: use the keyboard shortcut (left Alt+Shift+PrtScn) OR go through the Windows Display settings under High Contrast. It doesn't really matter which theme is used.
  3. Using the keyboard, Tab through components.
  4. Notice you often have no idea where you are, nor which radio, menuitem or tab control has been selected.

Impact statement: all interactive elements must have a visible and obvious focus indicator, so that sighted keyboard users have a clear indication of which element has focus.

Screenshot of a section of the test page in WHC Black theme, where focus is somewhere in the Menu. Also visible are the radio controls, all of which appear selected.

  • OS: Windows. Can be tested on any Windows version. WHC is old.
  • Browser: Use Edge or Firefox. IE supports as well but...

Note that it is more important that users' own OS-level settings work than that any particular web page happens to have a high-contrast theme. These are not available on most other websites, and do not affect application chrome (such as browser URL bars).

Solution
For most components, adding a single line to places where box-shadow and border-color is being changed will make focus visible:
outline: 2px dotted transparent;
This will not be visible to other users and works well in conjunction with components relying on box-shadow and colour changes.

For the SVGs in the radio controls, set the <circle> elements' opacity to 0 unless the radio is focussed/selected.

@StommePoes StommePoes added the bug Things that aren't working right in the library. label Sep 24, 2020
@claviska claviska added the a11y Anything relating to accessibility. label Sep 24, 2020
@claviska claviska added this to the v2.0.0 (stable) milestone Mar 21, 2021
@claviska claviska removed the bug Things that aren't working right in the library. label Mar 21, 2021
@claviska
Copy link
Member

claviska commented Apr 9, 2021

Radios have been fixed in 75bd54d.

Now that :focus-visible has landed in Safari TP, I'd like to start moving away from using box-shadow for focus and use a more prominent outline for keyboard users.

Many libraries (including Shoelace) use box-shadow as a "prettier" alternative to proper focus rings because we didn't have :focus-visible. Rather than patch the rest of the issues you've outlined (pun intended) with a solution that's likely to be neglected in future components and during refactors, I'd prefer to solve it with a proper focus outline.

I'll report back on this once I get that updated.

@StommePoes
Copy link
Author

Sure, that's cool.
I've also seen people sneak actual thin solid outlines into box-shadows where it basically gives you a prettier outline with a fade.

Re future testing: Chrome browser is now acceptable for testing WHC on Windows. It should, for the most part, function exactly as Edge browser :)

@claviska
Copy link
Member

claviska commented Nov 14, 2022

Apologies for the delay. It looks like many of the WHC issues have been resolved by switching from border-radius to outline in beta.74. Here's the remaining list of things I've found that need to be addressed:

  • <sl-color-picker> is impossible to use
  • <sl-dialog> has no border when open
  • <sl-drawer> has no border when open
  • <sl-menu-item> focus state is invisible
  • <sl-progress-bar> is invisible
  • The checked state of <sl-radio-button> is invisible
  • The thumb focus and track in <sl-range> are invisible
  • Colors are indistinguishable in <sl-rating>
  • <sl-skeleton> is invisible
  • <sl-split-panel> border/handle is invisible
  • <sl-tab> no obvious active state
  • <sl-tree-item> selected state is invisible

I'll be working through many of these today, so if anyone notices something that isn't on this list, please comment below!

@claviska
Copy link
Member

All known WHC / forced colors mode issues have been resolved in the following commits:

d79d7da
b296ac0
36e677d
6167993

I'm still learning about this, so suggestions on how styling can be improved even more are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y Anything relating to accessibility.
Projects
None yet
Development

No branches or pull requests

2 participants