[6.x] Sidebar "Options for…" buttons are 16x32, below the 24x24 target size minimum

[bpmore]

Bug description

The sidebar's "Options for …" buttons render at 16×32 CSS pixels, below the 24×24 minimum in WCAG 2.2 SC 2.5.8 Target Size (Minimum), Level AA.

They also do not qualify for the spacing exception. A 24px-diameter circle centred on the button intersects the bounding box of the adjacent nav link, because the two controls sit flush against each other:

16x32  "Options for Collections"  blocked by: "Collections"
16x32  "Options for Articles"     blocked by: "Articles"
16x32  "Options for Assets"       blocked by: "Assets"
16x32  "Options for Blueprints"   blocked by: "Blueprints"

Because these live in the shared sidebar, they are present on every authenticated Control Panel page. They are the controls that open each section's actions menu, so they are not decorative.

Confirmed independently by axe-core's target-size rule:

Target has insufficient size (16px by 32px, should be at least 24px by 24px)

One other case, on the entry editor: the date picker's "Month" segment is 22×26 and sits against the "Open calendar" button.

Scope, measured rather than estimated

Screen	Undersized targets	Actually failing
/cp/dashboard	1	0
/cp/collections/{handle}	12	2
entry editor	13	3 (axe) / 5 (stricter)
/cp/assets/browse/{container}	10	1
blueprint builder	10	2

Most undersized targets in the CP do pass via the spacing exception — this is a narrow, specific problem with controls placed flush against a larger neighbour, not a systemic sizing issue. Worth saying explicitly, because a naive scan that counts every target under 24px reports a much larger and misleading number.

How to reproduce

1. composer create-project statamic/statamic, log in
2. On any CP page, hover a sidebar section to reveal its "Options for …" button
3. In the console:

const b = document.querySelector('button[aria-label^="Options for"]');
const r = b.getBoundingClientRect();
[r.width, r.height]   // [16, 32]

Suggested fix

Widen the hit area to at least 24px. The visual icon can stay 16px — padding or a negative margin on the button is enough, so the sidebar layout need not change.

Note on scope

This is a WCAG 2.2 criterion, so it is not a 2.1 conformance failure. Filing it because it is small, mechanical, and worth having in hand whenever you move the target to 2.2.

Related: #15390 (drag-only reordering) is the other 2.2 gap I found — it fails SC 2.5.7 Dragging Movements as well as 2.1's SC 2.1.1.

Environment

Environment
Laravel Version: 13.30.1
PHP Version: 8.4.23
Composer Version: 2.10.2
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: file
Database: sqlite
Logs: stack / single
Mail: log
Queue: sync
Session: file

Storage
public/storage: NOT LINKED

Statamic
Addons: 0
License Key: Not set
Sites: 1
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.31.0 PRO

Installation

Fresh statamic/statamic site via CLI

Additional details

Found during a WCAG 2.1 AA audit of a vanilla composer create-project statamic/statamic install with no addons and no custom code. Tested with axe-core 4.x on Chromium 153 at 1440x1000, plus manual keyboard traversal. Source references point at v6.31.0.

[bpmore]

Correction to my report, now that #15417 has landed: I described these as sidebar buttons. They are not — they're the breadcrumb dropdown triggers in the global header (global-header/Breadcrumbs.vue). My geometry and measurements were right, my description of where they live was not. Apologies for sending anyone to the wrong component.

@lazerg fixed the right one regardless: w-4! → w-6! takes the hit area from 16×32 to 24×32, and dropping mr-1 for -ml-4 keeps the spacing. That clears SC 2.5.8's 24×24 minimum.

Thanks for the quick turnaround on this one.

[jackmcdade]

It's all good, I knew what ya meant. I pulled the branch down, reviewed it with my eyeballs, read the code. It's a worthy change.