Widget corner close button is invisible on touch: opacity 0 until hover
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- css
- Domain
- accessibility, frontend
Research direction
Start in assets/css/desktop.css at .os-widgets__card-close and compare the nearby touch treatment for .os-widgets__add. Make the corner close visible on devices matching hover: none, deciding whether it should remain fully opaque or use the chrome close’s dimmed treatment. Done means the corner button is visible on touch while the existing hover and focus-visible behavior remains intact.
Written by the indexing model from the issue text.
Description
Summary
.os-widgets__card-close in its corner form (non-movable widgets) sits at opacity: 0 until the card is hovered or the button takes :focus-visible. Touch devices have no hover, so on a phone the button is invisible even though it stays clickable.
#791 raises that target to the WCAG 2.2 SC 2.5.8 floor of 24x24, which is the right fix for the size limb. But a target nobody can see on the device where the pointer is a fingertip is only half the win, and the phone layer is exactly where #790 said it mattered most.
Where
assets/css/desktop.css:
.os-widgets__card-close {
opacity: 0;
}
.os-widgets__card:hover .os-widgets__card-close,
.os-widgets__card-close:focus-visible {
opacity: 1;
}
Precedent, a few rules below
.os-widgets__add already carries this treatment, with the reasoning in its comment ("Touch has no hover to approach the column with"):
@media ( hover: none ) {
.os-widgets__add {
opacity: 1;
pointer-events: auto;
}
}
Suggested shape
@media ( hover: none ) {
.os-widgets__card-close {
opacity: 1;
}
}
Two things to decide along with it:
- The chrome variant is already
opacity: 0.7, so it is visible on touch and needs nothing. Only the corner form is affected. - Whether an always-visible corner close is acceptable visual weight on a touch layout, or whether it wants the dimmed treatment the chrome close gets.
Related
- #790 is the size-conformance report.
- #791 raises the three declared sizes to 24x24.
- Dominant language
- TypeScript
- Stars
- 269
- Forks
- 42
- Avg merge
- 11h 50m
- Merged PRs (30d)
- 149
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WordPress/openstation
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
WordPress/openstation#854 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
WordPress/openstation#820 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WordPress/openstation#800 ·
-
Agents: the runner drops per-turn usage and model, so openstation_agent_completed reports no spend Open
Difficulty 3/5 1-2 days Newbie friendliness 78/100
WordPress/openstation#861 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 76/100
WordPress/openstation#862 ·
All issues in WordPress/openstation
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100