buildanything 1.8.0 → 2.0.0

package/skills/ios/swiftui-design-tokens/SKILL.md

@@ -0,0 +1,475 @@
+---
+name: swiftui-design-tokens
+description: Map brand design tokens (colors, typography, spacing, shapes) to SwiftUI Color/Font/Shape extensions with dark mode and Dynamic Type support. Use when implementing a design system, theming layer, or converting Figma/Style Dictionary tokens to Swift.
+license: MIT
+metadata:
+  author: oneshot
+  version: "1.0.0"
+---
+
+Generate SwiftUI design token infrastructure from brand specifications. Tokens follow a three-tier hierarchy and produce type-safe Swift extensions that respect dark mode and Dynamic Type.
+
+## Token Hierarchy
+
+Design tokens are organized in three tiers. Each tier references only the tier below it.
+
+```
+Component Tokens  ──>  Semantic/Alias Tokens  ──>  Global Tokens
+(buttonBackground)     (brandPrimary)              (blue600)
+```
+
+**Global tokens** are raw values with no semantic meaning: hex colors, point sizes, font names.
+
+**Semantic (alias) tokens** assign meaning to globals. A single semantic token resolves to different globals depending on context (light/dark, high contrast). Most UI code references this tier.
+
+**Component tokens** bind semantic tokens to specific controls. A `ButtonStyle` reads `button.background` rather than reaching down to `brandPrimary` directly.
+
+---
+
+## 1. Color Tokens
+
+### Global palette
+
+```swift
+// GlobalTokens+Color.swift
+extension Color {
+    enum Global {
+        static let blue50  = Color(hex: 0xE3F2FD)
+        static let blue600 = Color(hex: 0x1E88E5)
+        static let blue900 = Color(hex: 0x0D47A1)
+        static let grey50  = Color(hex: 0xFAFAFA)
+        static let grey900 = Color(hex: 0x212121)
+    }
+}
+```
+
+### Semantic tokens with dark mode
+
+**Option A -- Programmatic resolution (no asset catalog):**
+
+```swift
+// SemanticTokens+Color.swift
+extension Color {
+    // Resolves light/dark at read time via UIColor's trait system.
+    init(light: Color, dark: Color) {
+        self.init(uiColor: UIColor { traits in
+            traits.userInterfaceStyle == .dark
+                ? UIColor(dark)
+                : UIColor(light)
+        })
+    }
+}
+
+extension Color {
+    enum Brand {
+        static let primary    = Color(light: .Global.blue600, dark: .Global.blue50)
+        static let onPrimary  = Color(light: .Global.grey50,  dark: .Global.grey900)
+    }
+    enum Surface {
+        static let background = Color(light: .Global.grey50,  dark: .Global.grey900)
+        static let foreground = Color(light: .Global.grey900, dark: .Global.grey50)
+    }
+    enum Status {
+        static let error      = Color(light: Color(hex: 0xB71C1C), dark: Color(hex: 0xEF9A9A))
+        static let success    = Color(light: Color(hex: 0x1B5E20), dark: Color(hex: 0xA5D6A7))
+    }
+}
+```
+
+**Option B -- Asset catalog (preferred when designers hand off ColorSets):**
+
+1. Create `Colors.xcassets` with entries like `brand-primary`, setting Appearances to "Any, Dark."
+2. Reference them with a thin extension:
+
+```swift
+extension Color {
+    enum Brand {
+        static let primary   = Color("brand-primary")
+        static let onPrimary = Color("brand-onPrimary")
+    }
+}
+```
+
+Asset catalogs also support High Contrast variants (Appearances: "Any, Dark" + "High Contrast, High Contrast Dark") at no extra code cost.
+
+### Hex initializer (utility)
+
+```swift
+extension Color {
+    init(hex: UInt, alpha: Double = 1.0) {
+        self.init(
+            .sRGB,
+            red:   Double((hex >> 16) & 0xFF) / 255,
+            green: Double((hex >> 8)  & 0xFF) / 255,
+            blue:  Double( hex        & 0xFF) / 255,
+            opacity: alpha
+        )
+    }
+}
+```
+
+---
+
+## 2. Typography Tokens
+
+### Global type scale
+
+```swift
+// GlobalTokens+Typography.swift
+enum TypeScale {
+    case displayLarge   // 34pt
+    case displayMedium  // 28pt
+    case headlineLarge  // 24pt
+    case headlineMedium // 20pt
+    case bodyLarge      // 17pt -- iOS default body
+    case bodyMedium     // 15pt
+    case caption        // 12pt
+    case overline       // 11pt
+}
+```
+
+### Font extension with Dynamic Type
+
+Always use `Font.TextStyle` or `.relativeTo()` so the system scales with the user's preferred content size.
+
+```swift
+// SemanticTokens+Font.swift
+extension Font {
+    enum Brand {
+        static let displayLarge   = Font.system(.largeTitle, weight: .light)
+        static let displayMedium  = Font.system(.title, weight: .light)
+        static let headlineLarge  = Font.system(.title2, weight: .semibold)
+        static let headlineMedium = Font.system(.title3, weight: .semibold)
+        static let bodyLarge      = Font.system(.body)
+        static let bodyMedium     = Font.system(.subheadline)
+        static let caption        = Font.system(.caption)
+        static let overline       = Font.system(.caption2, weight: .medium)
+    }
+}
+```
+
+### Custom font families with Dynamic Type scaling
+
+When the brand requires a non-system typeface, use `.relativeTo()` to inherit the scaling curve of a built-in text style.
+
+```swift
+extension Font {
+    enum Brand {
+        static let headlineLarge = Font.custom("InterDisplay-SemiBold", size: 24, relativeTo: .title2)
+        static let bodyLarge     = Font.custom("Inter-Regular", size: 17, relativeTo: .body)
+        static let caption       = Font.custom("Inter-Regular", size: 12, relativeTo: .caption)
+    }
+}
+```
+
+This ensures a user who sets their Dynamic Type preference to "Extra Large" sees proportionally larger text, while respecting the brand typeface.
+
+### Testing Dynamic Type
+
+Use the environment override in previews to verify all sizes:
+
+```swift
+#Preview("Accessibility XXL") {
+    TokenShowcase()
+        .environment(\.sizeCategory, .accessibilityExtraExtraExtraLarge)
+}
+```
+
+---
+
+## 3. Spacing & Shape Tokens
+
+### Spacing
+
+Define spacing on a base-4 or base-8 grid. Expose as static properties so call sites read `Spacing.md` not magic numbers.
+
+```swift
+enum Spacing {
+    static let xxxs: CGFloat = 2
+    static let xxs: CGFloat  = 4
+    static let xs: CGFloat   = 8
+    static let sm: CGFloat   = 12
+    static let md: CGFloat   = 16
+    static let lg: CGFloat   = 24
+    static let xl: CGFloat   = 32
+    static let xxl: CGFloat  = 48
+}
+```
+
+### Corner radius
+
+```swift
+enum CornerRadius {
+    static let none: CGFloat   = 0
+    static let sm: CGFloat     = 4
+    static let md: CGFloat     = 8
+    static let lg: CGFloat     = 12
+    static let xl: CGFloat     = 16
+    static let full: CGFloat   = 9999  // pill shape
+}
+```
+
+### Elevation / shadow
+
+```swift
+struct Elevation {
+    let color: Color
+    let radius: CGFloat
+    let x: CGFloat
+    let y: CGFloat
+
+    static let none = Elevation(color: .clear, radius: 0, x: 0, y: 0)
+    static let sm   = Elevation(color: .black.opacity(0.08), radius: 4, x: 0, y: 2)
+    static let md   = Elevation(color: .black.opacity(0.12), radius: 8, x: 0, y: 4)
+    static let lg   = Elevation(color: .black.opacity(0.16), radius: 16, x: 0, y: 8)
+}
+
+extension View {
+    func elevation(_ e: Elevation) -> some View {
+        self.shadow(color: e.color, radius: e.radius, x: e.x, y: e.y)
+    }
+}
+```
+
+---
+
+## 4. Naming Conventions
+
+Follow a `Category.Role.Variant` pattern. Autocomplete guides developers to valid values.
+
+| Token path | Resolves to |
+|---|---|
+| `Color.Brand.primary` | Main brand color, adapts to dark mode |
+| `Color.Surface.background` | Screen/card background |
+| `Color.Status.error` | Destructive/error accent |
+| `Font.Brand.headlineLarge` | Primary heading, scales with Dynamic Type |
+| `Spacing.md` | Standard 16pt spacing unit |
+| `CornerRadius.lg` | Card corner radius (12pt) |
+| `Elevation.sm` | Subtle raised shadow |
+
+Nested enums (`Color.Brand`, `Color.Surface`, `Color.Status`) group tokens by purpose while keeping the namespace under the native SwiftUI type. This means call sites write `Color.Brand.primary`, not `DesignTokens.Color.brand.primary`.
+
+---
+
+## 5. Environment-Based Theming
+
+When an app supports multiple themes (e.g., per-brand white-labeling), inject the active theme through the SwiftUI environment.
+
+```swift
+// Theme.swift
+struct Theme {
+    let brandPrimary: Color
+    let brandOnPrimary: Color
+    let surfaceBackground: Color
+    let headlineFont: Font
+    let bodyFont: Font
+    let cornerRadius: CGFloat
+}
+
+extension Theme {
+    static let defaultTheme = Theme(
+        brandPrimary: .Global.blue600,
+        brandOnPrimary: .Global.grey50,
+        surfaceBackground: .Global.grey50,
+        headlineFont: .Brand.headlineLarge,
+        bodyFont: .Brand.bodyLarge,
+        cornerRadius: CornerRadius.md
+    )
+}
+
+// EnvironmentKey
+struct ThemeKey: EnvironmentKey {
+    static let defaultValue = Theme.defaultTheme
+}
+
+extension EnvironmentValues {
+    var theme: Theme {
+        get { self[ThemeKey.self] }
+        set { self[ThemeKey.self] = newValue }
+    }
+}
+```
+
+Usage in views:
+
+```swift
+struct BrandCard: View {
+    @Environment(\.theme) private var theme
+
+    var body: some View {
+        VStack {
+            Text("Welcome")
+                .font(theme.headlineFont)
+                .foregroundStyle(theme.brandOnPrimary)
+        }
+        .padding(Spacing.md)
+        .background(theme.brandPrimary)
+        .clipShape(RoundedRectangle(cornerRadius: theme.cornerRadius))
+    }
+}
+```
+
+Apply a theme to an entire subtree:
+
+```swift
+ContentView()
+    .environment(\.theme, .partnerBrand)
+```
+
+---
+
+## 6. Component Tokens
+
+Component tokens are the final tier -- they bind semantic tokens to a specific control's visual properties so the control never references globals directly.
+
+```swift
+struct ButtonTokens {
+    let background: Color
+    let foreground: Color
+    let font: Font
+    let cornerRadius: CGFloat
+    let paddingH: CGFloat
+    let paddingV: CGFloat
+
+    static let primary = ButtonTokens(
+        background: .Brand.primary,
+        foreground: .Brand.onPrimary,
+        font: .Brand.bodyLarge,
+        cornerRadius: CornerRadius.md,
+        paddingH: Spacing.md,
+        paddingV: Spacing.sm
+    )
+
+    static let secondary = ButtonTokens(
+        background: .clear,
+        foreground: .Brand.primary,
+        font: .Brand.bodyMedium,
+        cornerRadius: CornerRadius.md,
+        paddingH: Spacing.md,
+        paddingV: Spacing.xs
+    )
+}
+
+struct BrandButtonStyle: ButtonStyle {
+    let tokens: ButtonTokens
+
+    func makeBody(configuration: Configuration) -> some View {
+        configuration.label
+            .font(tokens.font)
+            .foregroundStyle(tokens.foreground)
+            .padding(.horizontal, tokens.paddingH)
+            .padding(.vertical, tokens.paddingV)
+            .background(tokens.background)
+            .clipShape(RoundedRectangle(cornerRadius: tokens.cornerRadius))
+            .opacity(configuration.isPressed ? 0.8 : 1.0)
+    }
+}
+```
+
+---
+
+## 7. Code Generation with Style Dictionary
+
+When tokens originate from Figma or a design tool, use [Style Dictionary](https://styledictionary.com/) to generate Swift from a JSON source of truth.
+
+### Token source file (`tokens/color.json`)
+
+```json
+{
+  "color": {
+    "brand": {
+      "primary": {
+        "value": "#1E88E5",
+        "darkValue": "#E3F2FD",
+        "type": "color"
+      },
+      "onPrimary": {
+        "value": "#FAFAFA",
+        "darkValue": "#212121",
+        "type": "color"
+      }
+    }
+  }
+}
+```
+
+### Style Dictionary config (`config.json`)
+
+```json
+{
+  "source": ["tokens/**/*.json"],
+  "platforms": {
+    "ios-swift": {
+      "transformGroup": "ios-swift",
+      "buildPath": "Generated/",
+      "files": [
+        {
+          "destination": "ColorTokens.swift",
+          "format": "ios-swift/enum.swift",
+          "filter": { "type": "color" }
+        }
+      ]
+    }
+  }
+}
+```
+
+### Custom Swift formatter (register in `build.js`)
+
+```javascript
+StyleDictionary.registerFormat({
+  name: 'swiftui/color-tokens',
+  formatter({ dictionary }) {
+    const lines = dictionary.allTokens.map(token => {
+      const name = token.name; // camelCase from transform
+      const hex = token.value.replace('#', '0x');
+      return `    static let ${name} = Color(hex: ${hex})`;
+    });
+    return `import SwiftUI\n\nextension Color {\n    enum Generated {\n${lines.join('\n')}\n    }\n}`;
+  }
+});
+```
+
+Run `npx style-dictionary build` to produce the Swift file. Commit the generated output so builds do not depend on Node at compile time.
+
+### Alternative: SwiftTokenGen
+
+[SwiftTokenGen](https://github.com/chrishoste/SwiftTokenGen) accepts Figma token exports or Style Dictionary JSON and generates Swift via Stencil templates, giving full control over the output format without writing JavaScript.
+
+---
+
+## 8. File Organization
+
+```
+DesignSystem/
+  Tokens/
+    GlobalTokens+Color.swift
+    GlobalTokens+Typography.swift
+    SemanticTokens+Color.swift
+    SemanticTokens+Font.swift
+    Spacing.swift
+    CornerRadius.swift
+    Elevation.swift
+  Theme/
+    Theme.swift
+    ThemeKey.swift
+  Components/
+    ButtonTokens.swift
+    BrandButtonStyle.swift
+  Utilities/
+    Color+Hex.swift
+  Generated/          # output from Style Dictionary (if used)
+    ColorTokens.swift
+```
+
+---
+
+## Decision Guide
+
+| Situation | Approach |
+|---|---|
+| Single brand, no runtime theming | Static extensions on `Color`/`Font` (Section 1-2) |
+| Single brand, dark mode needed | `Color(light:dark:)` initializer or asset catalog (Section 1) |
+| Multi-brand / white-label | Environment-based `Theme` struct (Section 5) |
+| Tokens from Figma / design tool | Style Dictionary code gen (Section 7) |
+| Many color variants + high contrast | Asset catalog with Appearances (Section 1, Option B) |

package/skills/ios/writing-for-interfaces/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: writing-for-interfaces
+description: Microcopy and tone review for iOS interfaces. Use when reviewing button labels, error messages, onboarding copy, empty states, alerts, permission prompts, and in-app text for clarity, brevity, and consistency with Apple's voice guidelines.
+version: 0.1.0
+status: ready
+---
+
+# Writing for Interfaces
+
+## Purpose
+Reviews and improves microcopy across iOS app screens — button labels, error messages, onboarding text, empty states, alerts, permission dialogs, and navigation titles. Ensures text is clear, concise, actionable, and consistent with Apple's tone guidelines.
+
+## When this fires
+- `/ux-review` iOS branch (Step 4e)
+- Any screen-level copy audit
+- Permission prompt or alert wording review
+
+## Inputs
+- Screen screenshots or SwiftUI view code containing user-facing strings
+- App category and tone keywords from `.build-state.md` (if available)
+
+## Outputs
+- Per-screen findings: issue, severity (P0/P1/P2), current copy, suggested rewrite
+- Tone consistency assessment across reviewed screens
+
+## Principles
+
+### Clarity over cleverness
+- Every label should be instantly understood on first read
+- Avoid jargon, abbreviations, and internal terminology
+- Use familiar words: "Delete" not "Remove from collection"
+
+### Brevity without ambiguity
+- Button labels: 1–3 words (verb or verb + noun)
+- Error messages: one sentence, state what happened and what to do
+- Empty states: one sentence of encouragement + one CTA
+
+### Actionable language
+- Buttons describe what happens: "Save Photo", "Send Message", "Try Again"
+- Avoid vague labels: "OK", "Submit", "Continue" (unless context is unambiguous)
+- Destructive actions name the consequence: "Delete Account", not "Confirm"
+
+### Consistent voice
+- Match the app's established tone (playful, professional, minimal, warm)
+- Keep capitalization consistent (Title Case for buttons, Sentence case for descriptions)
+- Use the same term for the same concept everywhere (don't alternate "photo" and "image")
+
+### Apple conventions
+- Permission prompts: explain the benefit, not the mechanism ("To send you reminders" not "This app needs notification access")
+- Alerts: title states the situation, message gives context, buttons name the actions
+- Navigation titles: short, noun-based ("Settings", "Profile", not "Your Settings Page")
+
+## Review checklist
+
+1. **Buttons** — Are labels verb-first and specific? Are destructive actions clearly named?
+2. **Error messages** — Do they say what went wrong AND what to do next?
+3. **Empty states** — Is there a friendly message + clear CTA to populate the screen?
+4. **Permission prompts** — Do usage descriptions explain the user benefit?
+5. **Alerts** — Does the title summarize the situation? Do button labels name the actions (not "OK"/"Cancel")?
+6. **Navigation titles** — Short, noun-based, consistent across the tab/flow?
+7. **Onboarding** — Is each screen one idea, scannable in 3 seconds?
+8. **Placeholders** — Do text field placeholders show format or example, not just the field name?
+9. **Tone consistency** — Does copy across screens feel like it was written by the same person?
+10. **Localization readiness** — Are strings free of concatenation, hardcoded plurals, and layout-breaking length assumptions?
+
+## Severity guide
+
+| Severity | Criteria | Example |
+|----------|----------|---------|
+| **P0** | Copy is misleading, causes data loss, or blocks the user | Destructive button labeled "OK" with no explanation |
+| **P1** | Copy is confusing, vague, or inconsistent — fix before ship | Error message says "Something went wrong" with no guidance |
+| **P2** | Copy works but could be tighter, friendlier, or more on-brand | Empty state says "No items" instead of something encouraging |
+
+---
+_In-house skill for buildanything iOS mode. See `protocols/ios-context.md` for Senior iOS Engineer persona._

package/skills/web/accessibility/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: accessibility
+description: Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA
+  standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
+origin: ECC
+---
+
+# Accessibility (WCAG 2.2)
+
+This skill ensures that digital interfaces are Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those using screen readers, switch controls, or keyboard navigation. It focuses on the technical implementation of WCAG 2.2 success criteria.
+
+## When to Use
+
+- Defining UI component specifications for Web, iOS, or Android.
+- Auditing existing code for accessibility barriers or compliance gaps.
+- Implementing new WCAG 2.2 standards like Target Size (Minimum) and Focus Appearance.
+- Mapping high-level design requirements to technical attributes (ARIA roles, traits, hints).
+
+## Core Concepts
+
+- **POUR Principles**: The foundation of WCAG (Perceivable, Operable, Understandable, Robust).
+- **Semantic Mapping**: Using native elements over generic containers to provide built-in accessibility.
+- **Accessibility Tree**: The representation of the UI that assistive technologies actually "read."
+- **Focus Management**: Controlling the order and visibility of the keyboard/screen reader cursor.
+- **Labeling & Hints**: Providing context through `aria-label`, `accessibilityLabel`, and `contentDescription`.
+
+## How It Works
+
+### Step 1: Identify the Component Role
+
+Determine the functional purpose (e.g., Is this a button, a link, or a tab?). Use the most semantic native element available before resorting to custom roles.
+
+### Step 2: Define Perceivable Attributes
+
+- Ensure text contrast meets **4.5:1** (normal) or **3:1** (large/UI).
+- Add text alternatives for non-text content (images, icons).
+- Implement responsive reflow (up to 400% zoom without loss of function).
+
+### Step 3: Implement Operable Controls
+
+- Ensure a minimum **24x24 CSS pixel** target size (WCAG 2.2 SC 2.5.8).
+- Verify all interactive elements are reachable via keyboard and have a visible focus indicator (SC 2.4.11).
+- Provide single-pointer alternatives for dragging movements.
+
+### Step 4: Ensure Understandable Logic
+
+- Use consistent navigation patterns.
+- Provide descriptive error messages and suggestions for correction (SC 3.3.3).
+- Implement "Redundant Entry" (SC 3.3.7) to prevent asking for the same data twice.
+
+### Step 5: Verify Robust Compatibility
+
+- Use correct `Name, Role, Value` patterns.
+- Implement `aria-live` or live regions for dynamic status updates.
+
+## Accessibility Architecture Diagram
+
+```mermaid
+flowchart TD
+  UI["UI Component"] --> Platform{Platform?}
+  Platform -->|Web| ARIA["WAI-ARIA + HTML5"]
+  Platform -->|iOS| SwiftUI["Accessibility Traits + Labels"]
+  Platform -->|Android| Compose["Semantics + ContentDesc"]
+
+  ARIA --> AT["Assistive Technology (Screen Readers, Switches)"]
+  SwiftUI --> AT
+  Compose --> AT
+```
+
+## Cross-Platform Mapping
+
+| Feature            | Web (HTML/ARIA)          | iOS (SwiftUI)                        | Android (Compose)                                           |
+| :----------------- | :----------------------- | :----------------------------------- | :---------------------------------------------------------- |
+| **Primary Label**  | `aria-label` / `<label>` | `.accessibilityLabel()`              | `contentDescription`                                        |
+| **Secondary Hint** | `aria-describedby`       | `.accessibilityHint()`               | `Modifier.semantics { stateDescription = ... }`             |
+| **Action Role**    | `role="button"`          | `.accessibilityAddTraits(.isButton)` | `Modifier.semantics { role = Role.Button }`                 |
+| **Live Updates**   | `aria-live="polite"`     | `.accessibilityLiveRegion(.polite)`  | `Modifier.semantics { liveRegion = LiveRegionMode.Polite }` |
+
+## Examples
+
+### Web: Accessible Search
+
+```html
+<form role="search">
+  <label for="search-input" class="sr-only">Search products</label>
+  <input type="search" id="search-input" placeholder="Search..." />
+  <button type="submit" aria-label="Submit Search">
+    <svg aria-hidden="true">...</svg>
+  </button>
+</form>
+```
+
+### iOS: Accessible Action Button
+
+```swift
+Button(action: deleteItem) {
+    Image(systemName: "trash")
+}
+.accessibilityLabel("Delete item")
+.accessibilityHint("Permanently removes this item from your list")
+.accessibilityAddTraits(.isButton)
+```
+
+### Android: Accessible Toggle
+
+```kotlin
+Switch(
+    checked = isEnabled,
+    onCheckedChange = { onToggle() },
+    modifier = Modifier.semantics {
+        contentDescription = "Enable notifications"
+    }
+)
+```
+
+## Anti-Patterns to Avoid
+
+- **Div-Buttons**: Using a `<div>` or `<span>` for a click event without adding a role and keyboard support.
+- **Color-Only Meaning**: Indicating an error or status _only_ with a color change (e.g., turning a border red).
+- **Uncontained Modal Focus**: Modals that don't trap focus, allowing keyboard users to navigate background content while the modal is open. Focus must be contained _and_ escapable via the `Escape` key or an explicit close button (WCAG SC 2.1.2).
+- **Redundant Alt Text**: Using "Image of..." or "Picture of..." in alt text (screen readers already announce the role "Image").
+
+## Best Practices Checklist
+
+- [ ] Interactive elements meet the **24x24px** (Web) or **44x44pt** (Native) target size.
+- [ ] Focus indicators are clearly visible and high-contrast.
+- [ ] Modals **contain focus** while open, and release it cleanly on close (`Escape` key or close button).
+- [ ] Dropdowns and menus restore focus to the trigger element on close.
+- [ ] Forms provide text-based error suggestions.
+- [ ] All icon-only buttons have a descriptive text label.
+- [ ] Content reflows properly when text is scaled.
+
+## References
+
+- [WCAG 2.2 Guidelines](https://www.w3.org/TR/WCAG22/)
+- [WAI-ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices/)
+- [iOS Accessibility Programming Guide](https://developer.apple.com/documentation/accessibility)
+- [iOS Human Interface Guidelines - Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility)
+- [Android Accessibility Developer Guide](https://developer.android.com/guide/topics/ui/accessibility)
+
+## Related Skills
+
+- `frontend-patterns`
+- `frontend-design`
+- `liquid-glass-design`
+- `swiftui-patterns`