Should AutomationProperties be renamed AccessibilityProperties?

[GalaxiaGuy]

There are bunch of properties that can be used for Accessibility in Xamarin Forms, usable via attached properties on AutomationProperties.

I assume that name was chose because of AutomationId being used originally for the one accessibility related property you could set.

[REscobar]

Automation implies a broader use case than accesibility

[GalaxiaGuy]

I would say automation implies a different use case than accessibility. Using accessibility features as a user is not automation. It feels like accessibility features have been coopted for automation use (but as a platform decision, not a Xamarin decision).

One of my reasons for suggesting it is the desire to add more accessibility functionality, especially platform specifics. Some of those features seem really out of place when considered automation properties, but having them in a different place to the existing ones would be awkward.

[REscobar]

Aren't screen readers and similar pieces of software implemented through automation?

In which cases would automation not be enough for accessibility?

I'm asking because I would like to know your input on this topic

[GalaxiaGuy]

It seems that automation is implemented using accessibility options.

On iOS all the relevant properties are named beginning with UIAccessibility. Android is a bit more ambiguous with contentDescription as the main thing you use, but then there is importantForAccessibility as the way you "show" or "hide" things, and accessibilityDelegate the thing you use for advanced scenarios.

Windows seems to be the odd one out with UWP putting things in System.Windows.Automation, which I assume why this naming scheme was chose for Xamarin Forms. (I have no experience beyond Googling, but it looks like Windows Forms used Accessibility as the basis to name things.)

Ultimately the name is less important to me than the functionality. I was planning on writing a suggestion for all the functionality I would like and immediately got stuck on naming.

For the curious, the accessibility features I would like off hand are (based mainly on what I've been recently using on iOS and Android):

Multi platform

Accessibility announcements (trigger an announcement - usually when something important on the screen changes)
Arbitrary accessibility tree/geometry (mostly for views that have custom drawing, but sometimes to provide a simpler hierarchy than the default visual tree supplies).

iOS specific

Accessibility traits.
Custom actions.
Custom rotor actions.

Android specific

Custom event names.
(Probably other stuff available on accessibilityDelegate)

[PureWeen]

We've had a few recent discussions around this @GalaxiaGuy and tend to agree with you. The current naming was chosen because we tend to default to UWP naming for things. We're planning on adding some additional features into .NET MAUI around accessibility and feel like it belongs inside of something with the word "Accessibility" in it

I'm really curious what you are thinking here

I was planning on writing a suggestion for all the functionality I would like and immediately got stuck on naming.

Can you elaborate on this?

Accessibility announcements (trigger an announcement - usually when something important on the screen changes)

Is this just a general announcement? Or are you setting the focus to something important that showed up on the screen like an error message?

We're in the process of putting together what we want Accessibility to look like in MAUI

A few ideas we're playing around with right now are

• [Spec, WIP] AutomationProperties AccessibilityLeafFlags xamarin/Xamarin.Forms#10986
• Remove TabIndex except for Desktop scenarios and replace it with something that lets you specify the ordering on the layouts
• We're starting to build up some API's here https://github.com/PureWeen/A11YTools that we're hopefully going to merge over to XCT and then they will finally end up in MAUI

[GalaxiaGuy]

I plan to add a more detailed response, but for things I can answer quickly:

Can you elaborate on this?

Accessibility announcements (trigger an announcement - usually when something important on the screen changes)

Is this just a general announcement? Or are you setting the focus to something important that showed up on the screen like an error message?

Just a cross-platform way to get to this:

https://developer.android.com/reference/android/view/View#announceForAccessibility(java.lang.CharSequence)
https://developer.apple.com/documentation/uikit/1615194-uiaccessibilitypostnotification

The exact circumstance I used it for was a "next" button that worked by just changing some content inline and the new content needed to be announced.

Remove TabIndex except for Desktop scenarios and replace it with something that lets you specify the ordering on the layouts

I'm not entirely sure I understand what you mean, but if it's like the following, it sounds like a good idea:

I've recently been working on improving accessibility in a non-Forms app. For iOS, we started by setting IsAccessibilityElement to true/false on things as appropriate, but found in most cases it was less confusing to have a single method at the root of a control just call IUIAccessibilityContainer.SetAccessibilityElements with the elements we wanted (and in the order we wanted).

[PureWeen]

Yea! Exactly that with IUIAccessibilityContainer.SetAccessibilityElements

but found in most cases it was less confusing to have a single method at the root of a control just call

Do you by chance have a sample of using this? I'm curious to see how you went about it. Even just some pseudo code?

Are you just adding IUIAccessibilityContainer to a UIView that contains a set of subviews and then returning those in a particular order?

[GalaxiaGuy]

Are you just adding IUIAccessibilityContainer to a UIView that contains a set of subviews and then returning those in a particular order?

Yes.

private void UpdateAccessibility(bool isEditing)
{
    var accessibilityElements = new List<UIView>

    if (isEditing)
    {
        accessibilityElements.Add(sizeButton);
        accessibilityElements.Add(quantityButton);
        accessibilityElements.Add(doneButton);
    }
    else
    {
        accessibilityElements.Add(editButton);
        accessibilityElements.Add(removeButton);
    }

    this.SetAccessibilityElements(NSArray.FromObjects(accessibilityElements.ToArray()));
}

There is some weird behavior with this occasionally. In some situations adding hidden controls is fine and they are correctly skipped over. Some times they aren't and voiceover still finds them.