Accessibility
Accessibility: a worked guide from route registry through to a production build.
Example
Start with semantic elements and themed components, supply application labels and descriptions, then verify the complete task with keyboard and screen reader.
import { Button, Dialog, DialogContent, DialogDescription, DialogTitle, DialogTrigger } from '@askrjs/themes/components';
<Dialog>
<DialogTrigger asChild><Button>Delete project</Button></DialogTrigger>
<DialogContent>
<DialogTitle>Delete project?</DialogTitle>
<DialogDescription>This action cannot be undone.</DialogDescription>
<DeleteProjectActions />
</DialogContent>
</Dialog>Goal and architecture
Public UI components own their documented interaction and accessibility behavior. The 0.5 contract exposes components and props; static accessibility metadata and its type aliases remain private. Test observable roles, relationships, keyboard handling and focus rather than importing internal descriptions.
Implementation
Compose the public components and let each owning root manage its state and focus. Use asChild when a different host element is needed, and test its disabled, keyboard and ref behavior. Custom controls must explicitly provide appropriate roles, labels, interaction and teardown.
Failure states
Check accessible names, roles, ARIA relationships, keyboard activation and focus order in the rendered application. Disabled controls must suppress activation and follow the documented tab-order behavior. Test overlay focus restoration after close and teardown, including nested compositions.
Verification
Assert the rendered accessible role and name, ARIA relationships, disabled behavior and callbacks. Drive keyboard and pointer events and verify focus before and after dismissal or unmount. Include keyboard-only and screen-reader checks for custom overlay compositions.