[Spec, WIP] Accessibility.LeafFlags

[PureWeen]

Accessibility Grouping and Behavior

The API's discussed here are currently just a spike of behavior that we want.

AccessibilityLeafHint

With accessibility you need the ability to have more control over the grouping behavior of AccessibilityBranches

For example given the following layout

<StackLayout 
     Accessibility.HelpText="Read Me" 
     Accessibility.LeafHint="RemoveChildren" >
     <Label Text="internal text" />
     <Image x:Name="childImage" />
</StackLayout>

The app developer will want to provide a single help text to be read on the StackLayout and for the rest of the inner elements not to participate in the accessibility process

public enum AccessibilityLeafHint
{
     Default, // act normal
     Remove, // remove this node and all of the children
     RemoveChildren, //keep this node but remove children
     Keep, // if this is being removed by a parent hint then add this node (without children) back onto the tree
     KeepWithChildren // if this is being removed by a parent hint then add this node and all my children back in
}

API

public class Accessibility
{
       public AccessibilityLeafHint LeafHint //Attached Property
}

Accessibility Interaction

Provide the ability to indicate what will trigger an element

API

[Flags]
public enum AccessibilityInteraction
{
     Default,
     SingleTap,
     LongPress
}

public class Accessibility
{
       public AccessibilityInteraction Interaction  //Attached Property
}

Accessibility Checkability

This will cause an element to act like a switch or a checkbox with regards to accessibility.

public class Accessibility
{
       public bool IsChecked  //Attached Property
       public bool IsCheckable //Attached Property
}

Scenarios

// TODO

XAML Example

<StackLayout 
     Accessibility.HelpText="Read Me" 
     Accessibility.LeafHint="RemoveChildren" >
     <Label Text="internal text" />
     <Image x:Name="childImage" Accessibility.LeafHint="Keep"   />
</StackLayout>

Difficulty : high

[GalaxiaGuy]

What is the plan (specifically with regards to the new handler architecture) for platform specific properties? This might be a bigger question than just this issue, but I noticed this quote in the other accessibility spec:

our approach for accessibility within MAUI core is to stay away from "faking it" or trying to force equal behavior between the platforms.

Specifically, I've been using accessibilityValue on iOS (used for the logical value of a control like a slider https://developer.apple.com/documentation/uikit/uiaccessibilityelement/1619583-accessibilityvalue) and I don't know if there is an Android equivalent.

[llevera]

@PureWeen

While this approach is what we used in our Xamarin Forms project, I think for maui something sightly more "sound"/native is possible and preferred.

The difference is not huge, but mainly centers around the suitability of the concept of Keep on iOS. Ie the ability for a parent view present itself as part of the accessibility tree, but also one or more children to also be presented is fundamentally not the way iOS works. So, therefore achieving this requires a "fake" parent to take the place of the real parent, and for the parent and the child to be made into siblings. No such trickery is required on Android.

This works, but to have such a significantly worked around solution is probably not a great place to start.

My view is to instead respect the original design of iOS in particular and not allow parents and children to be accessible at the same time. Instead, I recommend instead to use Accessibility Actions on both iOS and Android. To explain how this helps, the situations where we typically needed Keep was when we had something like a Card view that had a few details on it with an Edit also inside the card. For semantic grouping purposes, we make the Card an accessibility element that combines the various bits of card details into one label. But then on iOS, this hides the Edit button, unless we play tricks with parents etc. If, instead, Accessibility Actions are used (which I believe is the intended solution by Apple), then the Card can have an Edit action attached, creating the same result without tricks.

Despite, this, I do think semantic grouping is a very necessary operation, and maui should present first class APIs to assist this. I will document these over at #469

[mattleibow]

We are probably going to do something else. We have already does a few different things with SemanticProperties and would like to continue to do something better than what we have in forms.