Design Protocol for Kiara Inc. products

Kiara Inc. Web Design Checklist (Vibe Coding Ready)

Color Tokens

  • [ ] White: #FFFFFF — primary background
  • [ ] Gray-100: #F5F5F5 — subtle backgrounds
  • [ ] Gray-300: #D1D5DB — borders, dividers
  • [ ] Gray-500: #6B7280 — placeholder text
  • [ ] Gray-700: #374151 — secondary text
  • [ ] Gray-900: #111827 — primary text
  • [ ] Red: #DC2626 — primary CTA, errors, destructive
  • [ ] Orange: #F97316 — secondary CTA, highlights, badges
  • [ ] Green: #16A34A — success states
  • [ ] Blue: #2563EB — links, info states

Color Hierarchy

  • [ ] White/Gray → structure (80–90%)
  • [ ] Red → action/danger (sparingly)
  • [ ] Orange → support/promotion
  • [ ] Green → success/confirmation
  • [ ] Blue → links/info

Component States

  • [ ] Default → base color
  • [ ] Hover → 10% darker or opacity shift
  • [ ] Active/Pressed → 20% darker
  • [ ] Disabled → Gray-300 bg, Gray-500 text, no pointer
  • [ ] Focus → 2px ring, Blue or current color offset

Button Rules

  • [ ] Primary CTA → Red bg, white text
  • [ ] Secondary CTA → Orange bg, white text
  • [ ] Tertiary → Gray border, transparent bg
  • [ ] Destructive → Red outline or red bg (context-dependent)
  • [ ] No red + orange buttons in same group

Typography

  • [ ] Font family: system or specify (e.g., Inter, Noto Sans)
  • [ ] H1: 2rem / bold
  • [ ] H2: 1.5rem / semibold
  • [ ] H3: 1.25rem / medium
  • [ ] Body: 1rem / regular / Gray-900
  • [ ] Secondary text: 0.875rem / Gray-700
  • [ ] Caption: 0.75rem / Gray-500

Spacing Scale

  • [ ] 4px base unit
  • [ ] xs: 4px | sm: 8px | md: 16px | lg: 24px | xl: 32px | 2xl: 48px

Borders & Radius

  • [ ] Border color: Gray-300
  • [ ] Border width: 1px default
  • [ ] Radius: sm: 4px | md: 8px | lg: 12px | full: 9999px

Shadows/Elevation

  • [ ] sm: 0 1px 2px rgba(0,0,0,0.05)
  • [ ] md: 0 4px 6px rgba(0,0,0,0.1)
  • [ ] lg: 0 10px 15px rgba(0,0,0,0.1)

Form Inputs

  • [ ] Default → Gray-300 border, white bg
  • [ ] Focus → Blue ring, Gray-900 text
  • [ ] Error → Red border, Red text below
  • [ ] Success → Green border (optional)
  • [ ] Placeholder → Gray-500

Links

  • [ ] Default → Blue, underline optional
  • [ ] Hover → Blue darker, underline
  • [ ] Visited → optional Purple or same

Icons

  • [ ] Default → Gray-700
  • [ ] Interactive → inherit button/link color
  • [ ] Decorative → Gray-500

Accessibility

  • [ ] Contrast: 4.5:1 (normal text), 3:1 (large text/UI)
  • [ ] Never color alone for meaning — add text/icon
  • [ ] Focus visible on all interactive elements
  • [ ] Test colorblind modes (protanopia, deuteranopia)
  • [ ] Touch targets: min 44×44px

Dark Mode (if applicable)

  • [ ] Swap White ↔ Gray-900
  • [ ] Reduce Red/Orange intensity (use lighter variants)
  • [ ] Shadows → subtle or remove
  • [ ] Test contrast again

Hard Rules

  • [ ] No colored large backgrounds
  • [ ] No red + orange in same action group
  • [ ] If everything pops, nothing matters

(to make it accessible)

Here’s a practical, standards-aligned accessibility checklist you can use for websites and mobile apps. It’s organized by category so it works both as a design review tool and a handoff checklist for developers and QA.

1. Foundations (Standards & Planning)

  • ☐ Follow Web Content Accessibility Guidelines (WCAG) 2.1 or 2.2, target Level AA

  • ☐ Consider accessibility from the start of design, not as a fix later

  • ☐ Design for permanent, temporary, and situational disabilities

  • ☐ Include accessibility acceptance criteria in user stories

  • ☐ Test with real users and assistive technologies

2. Visual Design & Layout

  • ☐ Color contrast:

    • Text contrast ≥ 4.5:1 (normal text)

    • Large text ≥ 3:1

  • ☐ Do not rely on color alone to convey meaning

  • ☐ Text is resizable up to 200% without loss of content or function

  • ☐ Clear visual hierarchy (headings, spacing, alignment)

  • ☐ Avoid flashing content (>3 flashes/second)

  • ☐ Support dark mode with sufficient contrast

3. Typography & Readability

  • ☐ Minimum body text size ~ 16px (or platform equivalent)

  • ☐ Use readable fonts (avoid overly decorative styles)

  • ☐ Line height ≥ 1.5× font size

  • ☐ Adequate letter and word spacing

  • ☐ Text is not embedded in images unless essential

4. Navigation & Structure

  • ☐ Logical heading order (H1 → H2 → H3)

  • ☐ Consistent navigation across screens

  • ☐ Skip navigation links (web)

  • ☐ Clear, descriptive page and screen titles

  • ☐ Breadcrumbs or clear location indicators (when applicable)

5. Keyboard & Input Accessibility

  • ☐ All functionality usable with keyboard only

  • ☐ Visible focus indicators at all times

  • ☐ Logical tab order

  • ☐ No keyboard traps

  • ☐ Touch targets ≥ 44×44 px (mobile)

6. Forms & Data Entry

  • ☐ Every input has an associated label

  • ☐ Clear instructions and examples

  • ☐ Error messages are:

    • Descriptive

    • Easy to find

    • Programmatically associated with inputs

  • ☐ Required fields are clearly identified (not by color alone)

  • ☐ Success and error states are announced to screen readers

7. Buttons, Links & Controls

  • ☐ Buttons and links have descriptive text

  • ☐ No “click here” or ambiguous labels

  • ☐ Controls have clear states (hover, focus, active, disabled)

  • ☐ Icons have accessible names or labels

  • ☐ Links are visually distinguishable from text

8. Images, Media & Icons

  • ☐ Informative images have meaningful alt text

  • ☐ Decorative images are ignored by assistive tech

  • ☐ Icons have text alternatives

  • ☐ Video includes:

    • Captions

    • Audio descriptions (if needed)

  • ☐ Animations can be paused or disabled

9. Screen Reader & Assistive Tech Support

  • ☐ Content is announced in a logical order

  • ☐ Dynamic updates are announced (ARIA/live regions)

  • ☐ Role, state, and value are conveyed for custom components

  • ☐ No redundant or repetitive announcements

  • ☐ Landmarks are used appropriately (web)

10. Mobile-Specific Accessibility

  • ☐ Supports screen rotation

  • ☐ Respects system font size and contrast settings

  • ☐ Gestures have alternatives (no gesture-only actions)

  • ☐ VoiceOver / TalkBack tested

  • ☐ Haptic feedback is not the only signal

11. Testing & Validation

  • ☐ Automated checks (Lighthouse, axe, etc.)

  • ☐ Manual keyboard testing

  • ☐ Screen reader testing (NVDA, VoiceOver, TalkBack)

  • ☐ Color-blindness simulation

  • ☐ Accessibility issues documented and tracked

12. Legal & Compliance Awareness

  • ☐ Meets regional requirements (e.g. Americans with Disabilities Act, European Accessibility Act)

  • ☐ Accessibility statement provided (web)

  • ☐ Ongoing monitoring and audits planned