-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Description
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 AccessibilityNode
mega-component based on the presence of other components. We can introduce an AccessibleName
component that contains just a string, and then copy that to the label attribute on the main node. If AccessibleName
is 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 AccessibilityNode
into multiple components. The problem is that in accesskit
these are a singular, non-ECS data structure. It might be possible to redefine all of the accesskit
attributes as separate components, and then assemble them into an accesskit
Node structure in a just-in-time fashion; but I don't know enough about accesskit
to know whether this would work.