Digital Works

Appearance

Spec: Accessibility ​

Overview ​

Make DigitalWorks fully accessible to users with disabilities, including screen reader support, keyboard-only navigation, high contrast modes, and reduced motion preferences. Target WCAG 2.1 AA compliance for all interactive elements.

Motivation ​

  • Educational institutions must provide accessible tools (legal requirement in many regions).
  • Students with visual impairments, motor disabilities, or cognitive differences deserve equal access.
  • Accessibility improvements (keyboard navigation, clear focus indicators) benefit all users.
  • Microsoft Store and enterprise deployment often require accessibility compliance.

Requirements ​

Functional Requirements ​

Screen Reader Support ​

  1. UI Automation: All interactive elements expose UIA (UI Automation) properties.
  2. Component Announcements: Screen reader announces component type, name, pin states.
  3. Canvas Navigation: Navigate between components using arrow keys with screen reader feedback.
  4. Wire Announcements: Describe wire connections (e.g., "Wire from AND1 output to OR2 input A").
  5. Simulation State: Announce signal state changes on focused elements.
  6. Live Regions: Simulation status and errors announced automatically.

Keyboard Navigation ​

  1. Full Keyboard Access: Every operation achievable without mouse.
  2. Tab Order: Logical tab order through toolbox, canvas, panels, menus.
  3. Canvas Keyboard Navigation: Arrow keys move between components; Enter to select/interact.
  4. Wire Drawing via Keyboard: Mode to draw wires by selecting source pin → destination pin.
  5. Component Placement: Keyboard-based placement with grid navigation.
  6. Focus Indicators: Visible focus ring on all interactive elements (high contrast).
  7. Shortcut Keys: Comprehensive keyboard shortcuts for all common operations.

Visual Accessibility ​

  1. High Contrast Mode: Full support for Windows high contrast themes.
  2. Color Independence: No information conveyed by color alone (add shapes/patterns/labels).
  3. Configurable Colors: User-customizable wire, component, and signal colors.
  4. Text Sizing: UI respects system text size settings (large text mode).
  5. Minimum Contrast: All text and UI elements meet 4.5:1 contrast ratio (AA).
  6. Wire State Indicators: Signal state shown by pattern/shape, not just color (e.g., dashed = low, solid = high).

Motor Accessibility ​

  1. Large Click Targets: Minimum 44×44px touch/click targets for all interactive elements.
  2. Sticky Keys Support: Single-key shortcuts work with system sticky keys.
  3. Dwell Click: Compatible with eye-tracking and dwell-click assistive tech.
  4. Reduced Precision: Generous snap-to-pin tolerances for users with limited fine motor control.

Cognitive Accessibility ​

  1. Reduced Motion: Respect prefers-reduced-motion; disable animations.
  2. Clear Labeling: All buttons and controls have descriptive labels (no icon-only without tooltip).
  3. Consistent Layout: Predictable, consistent UI layout across all views.
  4. Error Guidance: Clear, actionable error messages (not just codes).

Non-Functional Requirements ​

  • Pass Microsoft Accessibility Insights automated audit.
  • Screen reader testing with NVDA and Narrator.
  • Keyboard testing: complete a full circuit design workflow without mouse.
  • WCAG 2.1 AA compliance for all non-canvas UI elements.
  • Canvas accessibility is best-effort (graphical by nature) with keyboard navigation alternative.

Design ​

UIA Tree for Canvas ​

The canvas presents a flat graphical view, but for accessibility, expose a logical tree:

Canvas (role: diagram)
├── Component: AND1 (role: group)
│   ├── Pin: Input A - High (role: status)
│   ├── Pin: Input B - Low (role: status)
│   └── Pin: Output - Low (role: status)
├── Component: OR1 (role: group)
│   ├── Pin: Input A - Low (role: status)
│   └── Pin: Output - Low (role: status)
├── Wire: AND1.Out → OR1.InA (role: connector)
└── Annotation: "Half Adder" (role: text)

Keyboard Navigation Model ​

Tab → enters canvas
Arrow keys → move focus between components (spatial navigation)
Enter → select component (or toggle interactive input)
Space → start wire from focused pin
Escape → cancel current operation
F2 → rename/edit properties
Delete → delete focused element
Ctrl+Arrow → move selected component

High Contrast Integration ​

csharp
// Detect high contrast mode
var settings = new UISettings();
bool isHighContrast = AccessibilitySettings.HighContrast;

// Use system high contrast colors
var foreground = isHighContrast ? SystemColors.WindowText : normalForeground;
var background = isHighContrast ? SystemColors.Window : normalBackground;

// Wire states in high contrast: use patterns instead of colors
WireStyle highSignal = isHighContrast ? WireStyle.SolidThick : WireStyle.Green;
WireStyle lowSignal = isHighContrast ? WireStyle.Dashed : WireStyle.Gray;

Screen Reader Announcements ​

csharp
// When focus moves to a component
AutomationProperties.SetName(element, "AND Gate, 2 inputs, Output: High");
AutomationProperties.SetHelpText(element, "Press Enter to select, F2 to edit properties");

// Live region for simulation updates
AutomationProperties.SetLiveSetting(statusBar, AutomationLiveSetting.Polite);

Implementation Tasks ​

  1. Audit all UI controls for UIA properties (Name, Role, State).
  2. Implement canvas keyboard navigation (spatial arrow-key movement).
  3. Implement keyboard-based wire drawing (pin-to-pin selection mode).
  4. Add UIA automation peers for canvas elements (components, wires).
  5. Implement high contrast mode rendering (patterns, system colors).
  6. Ensure all color-conveyed information has non-color alternative.
  7. Add visible focus indicators to all interactive elements.
  8. Implement live region announcements for simulation state.
  9. Add prefers-reduced-motion support (disable animations).
  10. Verify minimum contrast ratios across all themes.
  11. Test with Narrator and NVDA screen readers.
  12. Test complete workflows with keyboard-only input.
  13. Run Microsoft Accessibility Insights automated checks.

Risks & Open Questions ​

  • How detailed should screen reader descriptions of complex circuits be (too verbose vs. too sparse)?
  • Should there be an audio mode that plays tones for signal states?
  • Canvas is inherently visual — how much can be made accessible vs. providing alternative views (text-based circuit description)?
  • Performance impact of maintaining UIA tree for large circuits (1000+ elements)?

Priority ​

Low-Medium — Required for educational institution compliance; improves quality for all users.