Files

T

klevze 603af17e56 Remove legacy WPF app, flatten WinUI project to repo root, rename namespace

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>

2026-08-13 14:07:10 +02:00

3.4 KiB

Raw Blame History

description, applyTo

description	applyTo
Accessibility requirements for interactive controls, keyboard navigation, screen readers, and contrast	*/.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	Any UI change — verify accessibility approach
2	AutomationProperties	Adding or modifying interactive controls
3	Accessibility Insights	Testing tool — run before finalizing UI changes
4	Keyboard Accessibility	Adding navigation, focus management, or shortcut keys
5	High Contrast Themes	Adding custom styles, colours, or theme resources

3.4 KiB Raw Blame History

Accessibility

Rules

Anti-patterns

Validation

Verification Checklist

Must Read & Research

3.4 KiB

Raw Blame History