surshar / claude-code
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.
Built by Anthropic · github.com/anthropics
- Update skill description to emphasize accessibility as a core principle - Add accessibility to the Design Thinking checklist - Add full 'Accessibility Excellence' section covering: - Semantic Structure (HTML elements, heading hierarchy, landmarks) - Keyboard Navigation (tab order, focus indicators, skip links) - Visual Accessibility (contrast, color independence, reduced motion) - ARIA & Screen Readers (labels, live regions, state attributes) - Interactive Components (buttons vs links, form labels, modals) - Testing Checklist for verification - Emphasize that accessibility and bold design are not in conflict - Update closing statement to reference serving all users
| @@ -1,27 +1,28 @@ | ||
| 1 | 1 | --- |
| 2 | 2 | name: frontend-design |
| 3 | -description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics. | |
| 3 | +description: Create distinctive, production-grade frontend interfaces with high design quality and full accessibility. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished, accessible code that avoids generic AI aesthetics. | |
| 4 | 4 | license: Complete terms in LICENSE.txt |
| 5 | 5 | --- |
| 6 | 6 | |
| 7 | -This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices. | |
| 7 | +This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics while ensuring full accessibility for all users. Implement real working code with exceptional attention to aesthetic details, creative choices, and inclusive design. | |
| 8 | 8 | |
| 9 | 9 | The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints. |
| 10 | 10 | |
| 11 | 11 | ## Design Thinking |
| 12 | 12 | |
| 13 | 13 | Before coding, understand the context and commit to a BOLD aesthetic direction: |
| 14 | -- **Purpose**: What problem does this interface solve? Who uses it? | |
| 14 | +- **Purpose**: What problem does this interface solve? Who uses it? Consider the full spectrum of users including those with disabilities. | |
| 15 | 15 | - **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction. |
| 16 | -- **Constraints**: Technical requirements (framework, performance, accessibility). | |
| 16 | +- **Accessibility**: Accessibility is not a constraint—it's a design opportunity. The best interfaces are both beautiful AND universally usable. | |
| 17 | 17 | - **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember? |
| 18 | 18 | |
| 19 | -**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity. | |
| 19 | +**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity. Great design serves everyone. | |
| 20 | 20 | |
| 21 | 21 | Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is: |
| 22 | 22 | - Production-grade and functional |
| 23 | 23 | - Visually striking and memorable |
| 24 | 24 | - Cohesive with a clear aesthetic point-of-view |
| 25 | +- Fully accessible to all users | |
| 25 | 26 | - Meticulously refined in every detail |
| 26 | 27 | |
| 27 | 28 | ## Frontend Aesthetics Guidelines |
| @@ -39,4 +40,53 @@ | ||
| 39 | 40 | |
| 40 | 41 | **IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well. |
| 41 | 42 | |
| 42 | -Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision. | |
| 43 | +## Accessibility Excellence | |
| 44 | + | |
| 45 | +Accessibility is not an afterthought—it's fundamental to great design. Beautiful interfaces must work for everyone. Follow these principles: | |
| 46 | + | |
| 47 | +### Semantic Structure | |
| 48 | +- **Use semantic HTML elements**: `<header>`, `<nav>`, `<main>`, `<article>`, `<section>`, `<aside>`, `<footer>`. These provide meaning to assistive technologies. | |
| 49 | +- **Heading hierarchy**: Use `<h1>` through `<h6>` in logical order. Never skip levels. Screen reader users navigate by headings. | |
| 50 | +- **Lists and tables**: Use proper `<ul>`, `<ol>`, `<dl>` for lists and `<table>` with `<thead>`, `<tbody>`, `<th scope>` for tabular data. | |
| 51 | +- **Landmarks**: Ensure main content is in `<main>`, navigation in `<nav>`. Use `role` attributes only when semantic HTML isn't available. | |
| 52 | + | |
| 53 | +### Keyboard Navigation | |
| 54 | +- **All interactive elements must be keyboard accessible**: Users must be able to Tab to and activate every button, link, and control. | |
| 55 | +- **Logical tab order**: Follow visual reading order. Use `tabindex="0"` to make custom elements focusable; avoid positive tabindex values. | |
| 56 | +- **Visible focus indicators**: Never remove focus outlines without providing a clear alternative. Style `:focus-visible` with distinctive, on-brand styling. | |
| 57 | +- **Skip links**: Provide "Skip to main content" links for keyboard users to bypass repetitive navigation. | |
| 58 | +- **Keyboard shortcuts**: For complex interactions, support standard patterns (Escape to close modals, Arrow keys for menus). | |
| 59 | + | |
| 60 | +### Visual Accessibility | |
| 61 | +- **Color contrast**: Maintain WCAG AA minimum ratios—4.5:1 for normal text, 3:1 for large text and UI components. Bold color choices CAN meet contrast requirements. | |
| 62 | +- **Don't rely on color alone**: Use icons, patterns, text labels, or underlines alongside color to convey meaning (errors, status, links). | |
| 63 | +- **Text sizing**: Use relative units (rem, em) so text scales with user preferences. Never disable zoom. | |
| 64 | +- **Reduced motion**: Wrap decorative animations in `@media (prefers-reduced-motion: no-preference)`. Essential animations should be subtle. | |
| 65 | +- **High contrast mode**: Test with `forced-colors` media query. Ensure UI remains usable. | |
| 66 | + | |
| 67 | +### ARIA & Screen Readers | |
| 68 | +- **ARIA labels**: Use `aria-label` or `aria-labelledby` for elements without visible text labels. Icon buttons MUST have accessible names. | |
| 69 | +- **Live regions**: Use `aria-live="polite"` for dynamic content updates (notifications, loading states). Use `aria-live="assertive"` sparingly. | |
| 70 | +- **State attributes**: Communicate state with `aria-expanded`, `aria-selected`, `aria-checked`, `aria-pressed`, `aria-current`. | |
| 71 | +- **Hidden content**: Use `aria-hidden="true"` for decorative elements. Use `.visually-hidden` class (not `display: none`) for screen-reader-only text. | |
| 72 | +- **First rule of ARIA**: Don't use ARIA if native HTML provides the semantics. A `<button>` is better than `<div role="button">`. | |
| 73 | + | |
| 74 | +### Interactive Components | |
| 75 | +- **Buttons vs links**: `<button>` for actions, `<a href>` for navigation. Never use `<div>` or `<span>` for interactive elements. | |
| 76 | +- **Form labels**: Every input needs an associated `<label>` with `for` attribute, or use `aria-label`. Placeholder text is NOT a label. | |
| 77 | +- **Error handling**: Associate error messages with inputs using `aria-describedby`. Announce errors to screen readers. Don't rely on color alone. | |
| 78 | +- **Modals and dialogs**: Trap focus inside modals. Return focus to trigger element on close. Use `<dialog>` element or proper ARIA roles. | |
| 79 | +- **Loading states**: Announce loading with `aria-busy="true"` and `aria-live`. Provide text alternatives to spinners. | |
| 80 | + | |
| 81 | +### Testing Checklist | |
| 82 | +Before considering any interface complete, verify: | |
| 83 | +- [ ] Navigate entire interface using only keyboard (Tab, Enter, Space, Escape, Arrow keys) | |
| 84 | +- [ ] Test with screen reader (VoiceOver, NVDA, or browser extensions) | |
| 85 | +- [ ] Check color contrast with browser DevTools or axe | |
| 86 | +- [ ] Resize text to 200% and ensure layout doesn't break | |
| 87 | +- [ ] Enable reduced motion and verify animations respect preference | |
| 88 | +- [ ] Run automated accessibility audit (axe, Lighthouse) | |
| 89 | + | |
| 90 | +**CRITICAL**: Accessibility and bold design are not in conflict. High contrast ratios work with dramatic color palettes. Semantic structure enhances, not limits, creative layouts. Motion can be both delightful and respectful of preferences. The goal is inclusive excellence. | |
| 91 | + | |
| 92 | +Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision that serves all users. |