Lack of visible focus for interactive components

[Wagner3UB]

To fix the issue #5125

Centralize the management of focus states to ensure visual consistency, simplify future maintenance, and resolve accessibility (A11y) issues within Semantic UI components.

Main Changes

Architecture: Created the focus.less file and the .universal-focus-style() mixin. This eliminates CSS rule duplication and establishes a "single source of truth" for focus indicators.

UX Improvement: Global implementation of the :focus-visible pseudo-class. This ensures that focus indicators appear only during keyboard navigation, keeping the interface clean for mouse users.

Component Fixes:

Semantic UI Checkboxes: Since the framework hides the original input, focus logic was applied to the label::before pseudo-element, ensuring visibility during keyboard navigation.

Inputs and Skiplinks: Border and contrast adjustments to meet accessibility standards.

Color (@innerFocusShadow & @outerFocusOutline)

The choice of White (#fff) and Black (#000) follows the "Dual-Ring Strategy" for maximum accessibility:

Universal Visibility: Using a white inner shadow combined with a black outer outline ensures the focus indicator remains visible on any background (light, dark, or multicolored).

WCAG Compliance: This high-contrast pairing (black/white) guarantees we meet the minimum 3:1 contrast ratio required for UI components.

Brand Neutrality: Neutral colors avoid visual conflicts with the site's primary palette while providing a clear, standard functional cue for keyboard navigation.

Note
Please be aware that since these are global rules, specific component styles or legacy CSS may still override these definitions in certain contexts. Future refactoring might be needed if specific edge cases arise.

Example:
https://github.com/user-attachments/assets/20021d84-4b5c-4e58-8a39-a32db1c012a0

[Wagner3UB]

@wesleybl Hey Wesley, how it's going in Brasil?

I need to ask you about the focus when we’re inside the editor title field.

As I’m trying to modify the universal focus style to overcome some Semantic UI limitations, your Cypress test fails when it tries to assert that there is no outline. This happens because the :focus-visible selector has higher priority than :focus, so the outline ends up being visible again.

volto/packages/volto/cypress/tests/core/blocks/blocks-title.js

Line 20 in 49a483c

it('No border in input', () => {

My question is a bit more specific, we need a visual indicator for all interactive elements, we can’t simply hide the outline. I know it looks ugly to have a border inside an input, and I’m aware of that. Maybe our goal here should be to work on this and make it more acceptable for those who see it. But unfortunately, we can’t make it disappear.

[Wagner3UB]

@wesleybl Hey Wesley, how it's going in Brasil?

I need to ask you about the focus when we’re inside the editor title field.

As I’m trying to modify the universal focus style to overcome some Semantic UI limitations, your Cypress test fails when it tries to assert that there is no outline. This happens because the :focus-visible selector has higher priority than :focus, so the outline ends up being visible again.

volto/packages/volto/cypress/tests/core/blocks/blocks-title.js

Line 20 in 49a483c

it('No border in input', () => {

My question is a bit more specific, we need a visual indicator for all interactive elements, we can’t simply hide the outline. I know it looks ugly to have a border inside an input, and I’m aware of that. Maybe our goal here should be to work on this and make it more acceptable for those who see it. But unfortunately, we can’t make it disappear.

Same thing for the files blocks-table.js and blocks-slate.js

[wesleybl]

@wesleybl Hey Wesley, how it's going in Brasil?

I need to ask you about the focus when we’re inside the editor title field.

As I’m trying to modify the universal focus style to overcome some Semantic UI limitations, your Cypress test fails when it tries to assert that there is no outline. This happens because the :focus-visible selector has higher priority than :focus, so the outline ends up being visible again.

volto/packages/volto/cypress/tests/core/blocks/blocks-title.js

Line 20 in 49a483c

it('No border in input', () => {

My question is a bit more specific, we need a visual indicator for all interactive elements, we can’t simply hide the outline. I know it looks ugly to have a border inside an input, and I’m aware of that. Maybe our goal here should be to work on this and make it more acceptable for those who see it. But unfortunately, we can’t make it disappear.

Hi @Wagner3UB!

Actually, it wasn't me who removed the border. It was @tiberiuichim in: #5186

I only added the test.

I personally find the black border on inputs distracting, since the editor already adds a blue border to the focused block.

But if this is better for UX, okay. I just think that if the border is applied, it should be applied to all blocks, not just the core blocks. But it's already like that, right?

[Wagner3UB]

@tiberiuichim Hey Tiberium! I’ll need your help with this one. We kind of have a “conflict of interest” here. It’s not pretty, but in my opinion, from an a11y perspective, it’s necessary, or at least important. Here is your fix: #5186

[wesleybl]

@Wagner3UB I really find it strange to have a black border when we already have a blue border when the Slate input is selected:

Doesn't the blue border serve its purpose? Is there another option?

[Wagner3UB]

@stevepiercy Can you run your review also here buddy? Ty!

[stevepiercy]

Looks fine, with a tweak to the news fragment to describe what this PR actually does, as I understand it. Please correct it, if I'm wrong. Thank you!