Accessibility

App Use is not a replacement for standard accessibility — but it is a strong accelerator for building it and an excellent harness for auditing it, including for people with color-vision deficiency ("color blindness").

App Use is not a screen reader

Assistive technologies — screen readers (NVDA, JAWS, VoiceOver, Narrator), keyboard navigation, switch and voice control — talk to the operating-system accessibility tree (UI Automation on Windows, NSAccessibility on macOS, AT-SPI on Linux) and, on the web, to ARIA. They do not talk to App Use's tool surface. So exposing an App Use surface does not, by itself, make an app usable with a screen reader. The real accessibility work — accessible names, roles, focus order, contrast, text scaling, keyboard paths — still has to be done.

Two outputs of one effort

An App Use AppSpec element already declares a Key, a Type (a role), a Purpose (a human-readable label), validation, supported actions, and whether it is secret. That is almost exactly what accessibility needs: role + accessible name + value + state + available actions. The cheapest way to keep them in sync is to implement the surface by binding to the same control metadata the OS accessibility layer uses — for example AutomationProperties.Name / AutomationId / HelpText in Avalonia and WinUI. Wire it once in the element registry and a single set of metadata feeds both the screen reader and App Use.

Designing for color-vision deficiency

Roughly 1 in 12 men and 1 in 200 women have some form of color-vision deficiency. The golden rule is simple: never use color as the only way to convey meaning. Every place color carries information, add a second, non-color signal.

• State and status — don't rely on a red/green dot. Pair color with text or an icon: "Failed", "Completed", a ✓ / ✕ glyph.
• Errors and required fields — don't mark them with red alone. Add a label, an asterisk, an icon, or an inline message.
• Charts and categories — distinguish series with patterns, labels, or shapes, not only hue. Choose color-blind-safe palettes and keep adjacent regions distinguishable.
• Contrast — meet WCAG AA: at least 4.5:1 for normal text, 3:1 for large text and meaningful UI/graphics.
• Don't disable the OS — respect high-contrast and forced-colors modes; never hard-code colors that override them.

Where App Use helps with color blindness

App Use reads declared semantics, not pixels, so it cannot "see" a hue directly. It helps in two concrete ways:

1. It rewards encoding state as readable text. The same discipline that makes an app observable to an agent — exposing status through a readable *.status element rather than a colored indicator — is exactly what a color-blind user needs. A text/state equivalent serves color-blind users, screen-reader users, and agents all at once.
2. It is the audit harness. An agent can drive the app to every screen and capture a screenshot with the app.screenshot tool. A multimodal model can then check each screen for color-only signaling, estimate contrast, and simulate the three main CVD types — protanopia, deuteranopia, tritanopia — to confirm meaning survives. App Use gets the agent to the right screen, reproducibly; the vision model judges the color.

The accessibility audit checklist

Run this against any App-Use-enabled app, screen by screen:

Run it: the audit-agent prompt

Hand this to an agent connected to an App Use hub. It drives the target app, runs the checklist, captures screenshots for the color checks, and posts a summary to Field Notes.

You are auditing an application for accessibility using App Use.

Connect to the App Use hub. Run apps.list, then app.describe to read the
AppSpec. Navigate every screen (app.navigate) and, on each one:

1. Semantics — app.read_screen: confirm every interactive element has a
   clear human-readable name/Purpose (flag raw keys like "Menu.Foo"), a
   correct Type/role, and reachable actions.
2. Keyboard & focus — confirm all actions are reachable and focus order
   is logical; flag anything operable by pointer only.
3. State, not color — confirm status/errors/required fields expose a
   readable text/state value (e.g. a *.status element), not color alone.
4. Color-vision deficiency — call app.screenshot. For each screen, check
   that no information is conveyed by color alone; simulate protanopia,
   deuteranopia and tritanopia and confirm meaning survives; flag text
   below WCAG AA contrast (4.5:1; 3:1 for large text/graphics).
5. Text scaling — from the screenshot, note any text that would clip or
   overlap at 200% scale.

Output a findings list: { screen, issue, severity, suggested fix }.
Then submit a summary as a Field Note at
https://aiappuse.com/field-notes.htm (category "governance",
tags include "accessibility" and "color-blindness").