Wes Bos Sick Picks — research-first, accessible, modern frontend work

Build frontend the way you'd build it after reading the current best thinking — not from memory. The platform moves fast; what was "roll your own with JS" two years ago is often "one native element + a few lines of CSS" today. This skill front-loads research so the plan is right before any code is written, bakes in accessibility, and cross-checks the chosen approach against trusted voices (Wes Bos chief among them) before committing. The goal each time: pick the sickest modern approach — and prove it's the right call.

Use it for: new components (modal/dialog, drawer, popover, tabs, tooltip, accordion, combobox, carousel…), layout/animation/interaction work, or any "what's the right modern way to do X in HTML/CSS/JS" question. It is framework-agnostic — adapt the output to the project's stack and conventions (React, Vue, Svelte, Angular, web components, or plain HTML).

⚠️ Do this research before you write the plan or any code. The whole point is to discover the modern/native primitive and its pitfalls up front, so you don't plan around an outdated approach.

The workflow

1. Understand the request and the codebase (explore first)

• Restate what's being built and pin down the real requirements (responsive behavior, breakpoints, content, interactions, states).
• Search the codebase for existing patterns to reuse before proposing anything new: design-system primitives, styling utilities, transition/animation conventions, a11y helpers (focus, ids, keyboard), i18n, breakpoint detection, icon usage, and how similar components are already built. Reuse beats reinvention.
• If a sibling component already solves part of the problem (e.g. an existing popover/dialog), study how it handles open/close, transitions, focus, and scroll. Match those conventions.

2. Research pitfalls and the modern approach (the core of this skill)

Run web searches before planning. Goal: find the current-best, ideally native, approach and the gotchas that bite people.

Search in this order, adapting the topic:

• "<feature> modern best practices <current year>" — e.g. accessible drawer dialog element 2026 best practices
• "<feature> accessibility WCAG pitfalls" — focus management, keyboard, screen readers, ARIA.
• "<native element/API> <feature>" — is there a native primitive? (<dialog>, <details>, popover API, <selectlist>/<selectedcontent>, anchor positioning, inert, command/commandfor invokers…)
• "<feature> CSS animation @starting-style allow-discrete transition-behavior" — modern transitions for top-layer / display:none elements.
• Browser-support / baseline check for anything new (caniuse / Baseline status). Decide: ship it, progressively enhance, or polyfill.

Then fetch the 2–3 most relevant articles (WebFetch) to extract concrete code, the exact CSS, and the named pitfalls — don't stop at search snippets.

Capture, in your own notes: the recommended approach, what it gives you for free, the known pitfalls, and the browser-support caveats.

3. Design for accessibility (WCAG) from the start

Accessibility is a design input, not a later pass. Prefer native semantics that hand you correct behavior for free, then fill the gaps:

• Semantics first — use the right element (<dialog>, <button>, <nav>, headings, lists). Native elements come with roles, keyboard behavior, and focus handling.
• Name every control and region — aria-label / aria-labelledby (link region to its visible title), aria-describedby where useful. Reuse the project's i18n for labels; never hard-code if the repo localizes.
• Keyboard — everything operable without a mouse: Tab order, Enter/Space, Escape to dismiss, arrow keys where the pattern expects them (tabs, menus, listboxes). Visible :focus-visible styling.
• Focus management — move focus into the new context, trap it while open (native modal <dialog> does this for you), and restore it to the trigger on close.
• State exposure — aria-expanded, aria-selected, aria-current, aria-modal, aria-live for dynamic updates.
• Respect user preferences — prefers-reduced-motion (disable/replace motion), and don't trap scroll or break zoom.
• Sanity-check against the relevant WAI-ARIA Authoring Practices pattern, but lean on native behavior over reimplementing it.

4. Use modern HTML/CSS and platform features

Reach for the platform before reaching for JS or a library:

• Native elements/APIs: <dialog> + showModal(), popover API, <details>/<summary>, inert, command/commandfor invokers, CSS anchor positioning, :has(), container queries, scrollbar-gutter, text-wrap: balance/pretty, view transitions.
• Modern transitions for entering/exiting top-layer & display:none elements: @starting-style, transition-behavior: allow-discrete, transitioning display/overlay.
• Logical properties, dvh/svh units, modern color/spacing tokens — match whatever the project's styling system already uses (Tailwind, CSS modules, vanilla, etc.).
• Only add a dependency or hand-rolled JS when the platform genuinely can't do it, or browser support forces a fallback. Note the trade-off when you do.

5. Verify the approach against Wes Bos + trusted sources

Before finalizing the plan, confirm the chosen approach against external authorities — this is the "would Wes Bos do it this way?" gate.

• Wes Bos on X / wesbos.com — search e.g. wesbos twitter x.com <feature> <native element> or wesbos tips <feature>. He frequently posts sharp takes and gotchas on native HTML/CSS (dialog modality requiring .showModal(), @starting-style + allow-discrete, popover API, etc.). Cite the specific post.
• Trusted sources (allowlist below) — confirm the pattern, the a11y details, and the pitfalls line up. If sources disagree, prefer the most recent + the most authoritative (MDN/web.dev/spec), and say so.
• If verification contradicts the draft approach, revise before planning further — that's the skill working.

Trusted source allowlist (prefer these; recency matters):

• MDN Web Docs (developer.mozilla.org), web.dev / Chrome for Developers
• CSS-Tricks, Smashing Magazine, Frontend Masters blog
• WAI-ARIA Authoring Practices (w3.org/WAI/ARIA/apg), A11Y Project
• Practitioners: Wes Bos, Josh Comeau, Kevin Powell, Adam Argyle (nerdy.dev), Una Kravets, Stephanie Eckles (Modern CSS), Ahmad Shadeed
• Baseline / caniuse for support status

6. Plan, then implement

• Write the plan with a short Context (problem + outcome), the recommended approach only (native primitive + the specific modern CSS), the a11y checklist for this component, files to create/modify (reusing the patterns found in step 1), and a verification section.
• Include a Research notes / sources list with links — including the specific Wes Bos post(s) and the trusted sources that confirmed the approach. This is non-negotiable: the plan must show its work.
• Implement matching the project's conventions (SFC/JSX order, styling system, naming, i18n, testing, stories). Don't introduce a new styling or state pattern when one exists.

7. Verify the solution

• Run the project's linter/formatter and tests.
• Add/adjust tests and (if the project has them) component stories / visual snapshots.
• Manually validate accessibility: keyboard-only operation, focus trap + restore, Escape/dismiss, screen-reader announcement of the accessible name, and reduced-motion behavior.
• Confirm browser-support assumptions hold for the project's support matrix; note any progressive-enhancement fallback.

Guardrails

• Research before planning. No plan or code until steps 2 and 5 are done and the approach is verified.
• Native and accessible by default. Justify any non-native or inaccessible shortcut explicitly.
• Reuse over reinvention. Prefer the codebase's existing primitives and conventions.
• Cite your sources, especially the Wes Bos verification and at least one other trusted source, in the plan.
• Framework-agnostic. Keep the approach portable; only the final implementation is stack-specific.