iced-rs/iced

Implement accessibility support

Open

#552 opened on Oct 5, 2020

View on GitHub
 (26 comments) (53 reactions) (0 assignees)Rust (30,491 stars) (1,572 forks)batch import
accessibilityfeaturehelp wanted

Description

Background

Platforms typically mediate an interface between applications with a user interface, and accessibility tools (such as a screen reader), enabling assistive technologies:

Iced should provide the building blocks for making accessible applications, and integrate them automatically where possible.

Requirements

  • Integrate with native platform APIs for accessibility, and provide reasonable accessibility integration for widgets built-into iced.
    • Ability to communicate the widget hierarchy
    • Ability to communicate the type, state, and 'properties' of widgets in the hierarchy
    • Ability to query for a widget at a specific location.
    • Ability to provide updates of changes to widgets, or their location in the hierarchy
  • User-code should not need to use platform-specific crates.
  • User widgets should be able to provide additional information to accessibility APIs.
    • Additional or better markup/attributes
    • 'Navigations' or actions
    • Indicate relationships to logically-related widgets

Ideas

  • Automatic integration
    • Track widgets in a nested hierarchy
    • For each widget in the hierarchy, automatically determining basic information that can be communicated to accessibility APIs (ie: whether its a button/label/input etc, button/label text, focus state).
    • Communicate a representation of the hierarchy, basic widget information, and mutations to the platform-specific accessibility interface. This implementation could be shared with layout debugging and unit-testing facilities.
    • Implement hit-testing.
  • Widget-specific extensions
    • Allow widgets to provide additional markup or attributes to an accessibility API
    • Allow widgets to indicate actions/navigation options to an accessibility API (this could be implemented at a higher level as messages?)
    • Allow widgets to indicate relationships to logically-related widgets

Imho, this means we first need to implement:

  • A widget hierarchy that lives longer than layout/draw iterations
  • A stable identity for a widget in the hierarchy.

Related issues

https://github.com/hecrj/iced/issues/282

Contributor guide

Tech stack
rust
Domain
accessibilitydesktop
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Familiarity with Iced's widget systemUnderstanding of platform accessibility APIs (ATK, UIA, NSAccessibility)
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
15
Research direction
Start by reviewing the current widget tree implementation in iced native and iced winit. The issue suggests implementing a persistent widget hierarchy (see related issue #282). Investigate how platform accessibility APIs like ATK and NSAccessibility expose widget trees. Consider using a trait based approach to allow widgets to provide accessibility metadata without requiring platform specific crates in user code.