klevze
603af17e56
The repo carried two parallel UIs (WPF + WinUI) sharing Models/Services via
cross-directory Link includes. Now that WinUI is the only frontend, collapse
the structure so the WinUI project IS the repo root instead of a nested
sibling folder:
- Delete the WPF project entirely (App.xaml, MainWindow.xaml, csproj) and its
bin/obj output
- Move AmiReel.WinUI/* up to the repo root (App, MainWindow, MainPage,
DialogHelper, Assets, Package.appxmanifest, app.manifest, Properties,
.github/instructions, AGENTS.md) via git mv, preserving history
- Rename AmiReel.WinUI.csproj -> AmiReel.csproj; regenerate the solution as
AmiReel.slnx (the newer XML solution format) with a single project
- Rename namespace AmigaDB.VideoRenderer.{Models,Services} -> AmiReel.{...}
and AmiReel_WinUI -> AmiReel across all files, including the embedded
ffmpeg/ffprobe resource logical names in the csproj and ToolExtractor
- Models/ and Services/ no longer need the Link-based cross-directory
<Compile Include>; they're picked up by the SDK's default globbing now
that they live under the project directory
- Rename assets/ -> branding/ (source icon art) to avoid a case-insensitive
collision with Assets/ (packaged tile art) once both sit at repo root
- Merge the two .gitignore files into one; track the PublishProfiles pubxml
files instead of ignoring them (no secrets, and they keep publish
reproducible across machines) as branding, gitignore, etc.
- Simplify publish-win-x64.ps1 (drop the -Target Wpf/WinUI switch, there's
only one target now) and rewrite README.md to describe the single-project
layout, build/run/publish commands, and file structure
Verified: dotnet build succeeds for both AmiReel.csproj and AmiReel.slnx, and
the built exe launches and renders identically to before the move.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
63 lines
3.4 KiB
Markdown
63 lines
3.4 KiB
Markdown
---
|
|
description: 'Accessibility requirements for interactive controls, keyboard navigation, screen readers, and contrast'
|
|
applyTo: '**/*.cs, **/*.xaml'
|
|
---
|
|
|
|
# Accessibility
|
|
|
|
These rules apply to **every UI change**. They are not optional add-ons.
|
|
|
|
---
|
|
|
|
## Rules
|
|
|
|
- **Every interactive control** must have an `AutomationProperties.Name` or `AutomationProperties.LabeledBy`.
|
|
- Add a stable, unique `AutomationProperties.AutomationId` for controls targeted by UI automation tests (and for key interactive elements).
|
|
- Use semantic XAML controls — prefer `Button`, `HyperlinkButton`, `ListView` over styled `Border`/`Grid` with click handlers.
|
|
- Ensure **keyboard navigation** works for all features:
|
|
- Logical tab order via `TabIndex`.
|
|
- `AccessKey` bindings for frequently used actions.
|
|
- `KeyboardAccelerator` for shortcut keys.
|
|
- Maintain **minimum contrast ratios** (4.5:1 for normal text, 3:1 for large text) — test in High Contrast mode.
|
|
- Support **screen readers** (Narrator / NVDA): test that all content is announced correctly.
|
|
- Images must have `AutomationProperties.Name` describing the image purpose (or `AutomationProperties.AccessibilityView="Raw"` for decorative images).
|
|
- Do not rely on colour alone to convey meaning — add icons, text, or patterns.
|
|
|
|
## Anti-patterns
|
|
|
|
- Clickable `TextBlock` or `Image` without `AutomationProperties`.
|
|
- Custom controls that are not keyboard-focusable.
|
|
- Using `Visibility.Collapsed` to "hide" content from screen readers (use `AccessibilityView` instead).
|
|
|
|
## Validation
|
|
|
|
- Build & register the MSIX package — see **Build, Run & Deploy** in `.github/agents/Agents.md`.
|
|
- Test keyboard navigation: tab through every new/changed UI area.
|
|
- Test High Contrast: switch to Windows High Contrast theme and verify readability.
|
|
- Run Accessibility Insights for Windows on the app.
|
|
|
|
### Verification Checklist
|
|
|
|
- [ ] All interactive controls have `AutomationProperties.Name`
|
|
- [ ] Keyboard navigation works for the changed area
|
|
- [ ] Tested with High Contrast theme enabled
|
|
- [ ] Tab through the entire UI with keyboard only.
|
|
- [ ] Verify key interactive controls have stable, unique `AutomationProperties.AutomationId` values (especially controls used by UI automation tests).
|
|
- [ ] Switch to Windows High Contrast theme and verify readability.
|
|
- [ ] Run Narrator and verify all controls are announced correctly.
|
|
- [ ] Run **Accessibility Insights for Windows** on the app.
|
|
|
|
## Must Read & Research
|
|
|
|
> **Agent Rule:** Before any accessibility-related change, you **must** fetch and review these references using `fetch_webpage`. Apply what you learn.
|
|
|
|
| # | Reference | When to consult |
|
|
|---|---|---|
|
|
| 1 | [Accessibility in WinUI](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessibility) | Any UI change — verify accessibility approach |
|
|
| 2 | [AutomationProperties](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/basic-accessibility-information) | Adding or modifying interactive controls |
|
|
| 3 | [Accessibility Insights](https://accessibilityinsights.io/docs/windows/overview/) | Testing tool — run before finalizing UI changes |
|
|
| 4 | [Keyboard Accessibility](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/keyboard-accessibility) | Adding navigation, focus management, or shortcut keys |
|
|
| 5 | [High Contrast Themes](https://learn.microsoft.com/en-us/windows/apps/design/accessibility/high-contrast-themes) | Adding custom styles, colours, or theme resources |
|
|
|
|
|