-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
AccessibleName component #20524
Copy link
Copy link
Open
Labels
A-AccessibilityA problem that prevents users with disabilities from using BevyA problem that prevents users with disabilities from using BevyA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-StraightforwardSimple bug fixes and API improvements, docs, test and examplesSimple bug fixes and API improvements, docs, test and examplesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed uponThis work is generally agreed upon
Metadata
Metadata
Assignees
Labels
A-AccessibilityA problem that prevents users with disabilities from using BevyA problem that prevents users with disabilities from using BevyA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-StraightforwardSimple bug fixes and API improvements, docs, test and examplesSimple bug fixes and API improvements, docs, test and examplesS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-UncontroversialThis work is generally agreed uponThis work is generally agreed upon
What problem does this solve or what need does it fill?
Widgets involve a division of labor: the author of the widget code is usually a different person than the person writing the code that uses the widget. Even more than this, the widget is often located in a library, a separate source tree. This is true of the widget's accessibility properties as well: most of the widgets a11y attributes are determined by the widget code - things like role, checked, disabled and so on. However, a few accessibility properties are specified by the widget user - the most prominent of these is "label" or "name".
It's not helpful if the screen reader reads the widget's name as something generic like "button". In order to make the screen reader actually helpful, the user needs to be able to specify a descriptive name for the widget, which can only come from the widget user.
This is difficult in the current environment because all a11y properties are stored on a single mega-component,
AccessibilityNode. This requires the widget user to modify data structures created by the widget author. It would be much more ergonomic if the widget user could specify the name as a separate Component, and have this be inserted and merged in with the other a11y attributes.What solution would you like?
Using hooks and/or observers, we can update the
AccessibilityNodemega-component based on the presence of other components. We can introduce anAccessibleNamecomponent that contains just a string, and then copy that to the label attribute on the main node. IfAccessibleNameis immutable, we can also use insertion hooks to keep the two in sync.What alternative(s) have you considered?
It's not easy to break up
AccessibilityNodeinto multiple components. The problem is that inaccesskitthese are a singular, non-ECS data structure. It might be possible to redefine all of theaccesskitattributes as separate components, and then assemble them into anaccesskitNode structure in a just-in-time fashion; but I don't know enough aboutaccesskitto know whether this would work.