Icon-only buttons have no accessible name

[plind-junior]

Summary

Four interactive icon-only controls in the dashboard rely on MUI Tooltip (title prop) to convey meaning, but Tooltip does not expose an accessible name to assistive tech. Screen readers announce these controls as generic "button" / "link", and keyboard-only users get no name on focus.

Affected controls

Location	Control	Currently announced as
src/pages/DashboardPage.tsx:68	Docs link (MenuBook icon)	"link"
src/pages/DashboardPage.tsx:89	Theme toggle (Light/DarkMode icon)	"button"
src/components/dashboard/OrderbookDepth.tsx:246	Orderbook info (InfoOutlined icon)	"button"
src/components/dashboard/EventFeed.tsx:199	Scroll-to-top (KeyboardArrowUp icon)	"button"

Why Tooltip isn't enough

MUI's Tooltip renders its title into a portal that is shown on hover/focus but is not wired to the trigger via aria-label or aria-labelledby. For icon-only buttons the W3C practice is an explicit aria-label on the trigger itself (Tooltip can still provide the visual hint).

Expected behavior

Each icon-only control announces a short, descriptive name on focus. Theme toggle reflects the destination state ("Switch to dark mode" / "Switch to light mode") rather than the current state.

Acceptance criteria

• All four controls have a non-empty aria-label.
• Theme toggle label updates based on current mode.
• No visual regression (tooltips still show).
• tsc --noEmit passes; lint passes.

Scope (explicitly out)

• 100dvh viewport fix, ErrorBoundary, API retry / SSE reconnect, icon memoization — bundled together in upstream entrius#15 and flagged for scope creep. Each warrants its own issue + PR.

References

• Upstream PR Fix mobile viewport, add error boundary and accessibility #15 (closed unmerged) proposed the same fix bundled with several unrelated changes. This issue tracks the isolated a11y slice only.
• WAI-ARIA Authoring Practices — Button pattern (icon-only buttons must have an accessible name).