-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Spec] Implement IsInSemanticTree property for accessibility #927
Comments
Love this concept! Accessibility by default. |
Couple of thoughts on this:
|
As mentioned above, I am not 100% convinced such a enum is the right mechanism to enable more control. Group semantics might be more natural to express the parent-child relationships, although I do concede iOS and Android do expose this in similar ways to what is proposed for
This is sensible - on iOS is very difficult for a parent to be removed but with any children included. Doing so requires high levels of workarounds.
The problem with linking these properties is that this is that it will go far further than the native platforms. Eg, if For eg, on iOS this code
Results in
By sticking to
Doing so will mean keyboard navigation is not effected. This might be best left for native calls. |
My overall thought on But generally I think it should be kept as a fairly utilitarian pass through to |
Implement IsInSemanticTree property for accessibility
Create a property that determines whether a specific element (and its children) are in the semantic tree for accessibility. This influences whether or not screen readers can access and read aloud in-app elements.
This property is reminiscent of the Xamarin.Forms AutomationProperties.IsInAccessibleTree property. However, IsInSemanticTree goes beyond the boolean and with a greater scope, will enable developers to have more control over the accessibility of each element in their apps.
API
SemanticProperties.IsInSemanticTree
Properties
IsInSemanticTree.Default
Every .NET MAUI control will have a
Default
value of being in the semantic tree (IncludeNode) or being outside of the semantic tree (RemoveSubtree). Developers will be able to use this property in complex/nuanced scenarios where straying from the defaults will enable them to make their apps more accessible (see example below).IsInSemanticTree.IncludeNode
IncludeNode
ensures the specified element is in the semantic tree and will be accessible to screen readers. It is the opposite of RemoveNode.IsInSemanticTree.RemoveNode
RemoveNode
ensures the specified element is NOT in the semantic tree and will NOT be accessible to screen readers. It is the opposite of IncludeNode.IsInSemanticTree.RemoveSubtree
RemoveSubtree
ensures the specified element AND any children it may have are NOT in the semantic tree and will NOT be accessible to screen readers. This is the equivalent of setting RemoveNode to the specified element, and every single one of the specified element's child elements.Implementation Details
IncludeNode
isAccessibilityElement=true
importantForAccessibility=yes
RemoveNode
isAccessibilityElement=false
importantForAccessibility=no
RemoveSubtree
accessibilityElementsHidden=true
importantForAccessibility=noHideDescendants
Scenarios
XAML Example
The above sample renders two labels - one as a heart icon, and one as the text "Heart". By default, all labels are in the semantic tree and therefore screen reader accessible. Therefore, without the setting of
SemanticProperties.IsInSemanticTree="RemoveNode"
, screen readers would focus on both the icon and the text. In this case, where the text already describes the icon, it is unnecessary to focus on the icon at all (by default, the screen reader would focus on it and confusingly read back nothing; if a semantic description is set to it, it would read back information that is already captured by the text, thereby making it redundant). In this scenario, manipulating whether or not a control IsInSemanticTree allows for a more accessible experience.Further considerations and areas of investigation
Difficulty: [medium]
Related: #469
The text was updated successfully, but these errors were encountered: