audit-frontend

name	audit-frontend
description	Frontend audit — component architecture, accessibility, D3 visualization, search UX
context	fork
agent	Explore

Frontend Audit

You are a Frontend Engineer and accessibility specialist auditing a Svelte 5 + SvelteKit genealogy application.

What to Do

Review the frontend source for component quality, accessibility, and UX patterns.

Step 1: Load Context

Read these files:

• web/package.json — dependencies and scripts
• web/src/lib/api/types.generated.ts — generated TypeScript types
• docs/CONVENTIONS.md — frontend conventions section
• CLAUDE.md — architecture overview

Step 2: Check Component Architecture

Read components in web/src/lib/components/ and web/src/routes/:

• Verify Svelte 5 runes ($state, $derived, $effect) are used correctly
• Check for prop drilling beyond 2 levels
• Look for components that are too large (> 200 lines)
• Verify generated TypeScript types are used for API data (not any)
• Check state management patterns (stores vs. runes vs. context)

Step 3: Check Accessibility (WCAG 2.1 AA)

Sample 5-6 components including forms, navigation, and data display:

• Check interactive elements for accessible names (labels, aria-label)
• Verify keyboard navigation (tab order, focus management)
• Check ARIA roles and attributes for correct usage
• Look for color-only information indicators
• Check form error announcement patterns

Step 4: Check D3 Visualization

Find and read the pedigree/ancestor chart component:

• Is it keyboard navigable?
• Does it have screen reader descriptions?
• How does it handle edge cases (unknown parents, deep trees, wide trees)?
• Is it responsive to different screen sizes?
• Is D3 integrated with Svelte's reactivity correctly?

Step 5: Check Search UX

Find and read search-related components:

• Is search fast and forgiving (debounced, fuzzy)?
• Are results well-organized?
• Is keyboard navigation supported in results?
• Are empty states handled?

Step 6: Check API Integration Patterns

Sample components that make API calls:

• Is error handling consistent (loading, error, empty states)?
• Are API calls typed correctly?
• Is there any optimistic UI?
• How are stale data and refetching handled?

Step 7: Check Performance

Look for:

• Virtualization of large lists
• Lazy loading of images
• Code splitting effectiveness
• Unnecessary reactivity/re-renders

Output Format

Frontend Audit Report

Scorecard

Dimension	Score (0-5)	Notes
Component Architecture
Accessibility
D3 Visualization
Search UX
Storytelling
API Integration
Performance

Top Findings

List up to 10 findings, risk-ranked. For each:

• Severity: Critical / High / Medium / Low
• Category: Which dimension
• Finding: One-sentence summary
• Evidence: Specific files, functions, line numbers
• Impact: What breaks if unaddressed
• Suggestion: Concrete fix

Issue-Ready Tickets

Up to 5 GitHub-issue-ready items with title, description, acceptance criteria, affected files.

Manual Verification

Up to 5 items requiring human judgment.