emilk/egui

egui access_kit API docs

Open

#4,396 opened on Apr 23, 2024

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Rust (29,051 stars) (2,037 forks)batch import
accessibilitydocs and examplesgood first issue

Description

Is your feature request related to a problem? Please describe. Is there documentation on how to use access_kit as a ui developer using egui? I looked through both egui and access kit docs and don't see documentation for developers on how to develop accessible apps. I've read a bit of the source code I thought might be relevant but haven't had much luck yet.

From what I can tell enabling access_kit mostly just "works" (about as good as an iOS app using VoiceOver which is pretty impressive), but it wasn't apparent that would be the case until I set everything up and ran VoiceOver with my app.

Describe the solution you'd like I'd like to see documentation explaining to ui-developers using egui:

  • how to create accessible experiences using access kit (high level summary)
  • documentation explaining what gets accessibility labels for free (label text, for example)
  • documentation explaining how to provide accessibility labels to widgets that don't have any. For example, I have a component with a visual, non-textual representation that has an informational component that should be shared with screen reader users. How can I add accessibility labeling to that widget?

In addition to ui-developer docs, I'm also interested to know if the accessibility tree can be accessed at runtime in order to read things like "label_a has text 'wowow'". I'm interested in the possibility of using access kit as a way to drive out ui tests for egui.

Describe alternatives you've considered Reading source code until I understand the capabilities, which I have greater risk misunderstanding without docs

Additional context Thanks for the great library! :)

Contributor guide

Tech stack
rust
Domain
accessibilitydocumentation
Issue type
documentation
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Rust programmingegui framework basicsaccessibility concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
80
Research direction
Investigate how egui currently integrates access kit by looking at the source code, particularly files like `egui/src/access.rs`. Review existing access kit documentation and egui's documentation structure. Propose a new documentation section in the egui book that explains how to create accessible apps, including automatic labeling and manual overrides, and how to access the accessibility tree for testing. Engage with maintainers via the issue comments to align on scope.