Add basic automation/accessibility properties to all controls

[mrlacey]

Created apps need to be able to support automation for the purposes of testing and accessibility tools.

I believe the absolute minimum needed are:

• Id (so it can be refrenced - although possible overlap with 'x:Name')
• Label (e.g. to determine what a screen reader should say)
• Visibility (to control where this shows up. - equivalent to AccessibilityView in UWP or InAccessibleTree in Xamarin.Forms)

The above should be supported by ALL controls in the standard.

Additional related features/properties could be added in later versions.

Automation properties are needed for many testing scenarios having them from the start will be invaluable to those wanting to test their apps that use XAML Standard.

Accessibility is often considered as a "nice to have" or something that can be added later. It would be great to demonstrate Microsoft's commitment to building software that empowers every person to achieve more by including the ability to build software for every person right from the start of this project.

[insinfo]

@mrlacey Yes good recommendation, ideally this new XAML Standard 1.0 specification, define the primitive object with these properties, for example in the abstract class FrameworkElement or UIElement

[crutkas edited to remove unnecessary cross linking]

[birbilis]

Just don't do it like in html. Too much stuff to add

[mrlacey]

@birbilis What specifically don't you like about adding accessibility features to HTML? Roles, aria-* attributes, or something else? Do you see/know a way of supporting automation and accessibility without adding extra properties?

I'm pushing for equivalents of Automation​Properties from UWP and AccessibilityEffect from Xamarin.Forms.

[birbilis]

especially the ARIA stuff are too verbose

imagine that one has to also localize strings like accessible descriptions that end up most of the times being duplicates with tooltips

why is it so hard for the system to reuse a tooltip as accessible description if the accessible description is missing? Could even have the UI system not do it and have a more clever screen reader, but I get the notion of not having screen readers understand and inspect each UI system's graph, but use a UI automation API instead. I just don't want as dev to have to write and localize redundant strings

[birbilis]

also I want less verbose XAML to read, so accessible properties that are not specific to a control instance should be settable once if possible for each class of UI items via some style / control template.

long field names are also bad for readability btw

[birbilis]

as for matching Label controls to their matching UI controls, it could be done via binding by element name (as long as shorthand syntax for binding by name is also supported like done in Avalonia - see https://github.com/Microsoft/xaml-standard/issues/60).

question is if Label should have a field for the control it matches, or if control should have a field for the label that matches to it. Adding to the Label the field means existing controls don't need modification but then you need a Label Manager API so that having a control you can ask for its label without traversing the UI graph yourself. Also may need to have namespace contexts there based on visual hierarchy / graph, think WPF has such a thing so that you don't have confusion with same named controls. But might remember wrong. Also dot syntax could be used to refer to a deeper context (can combine this with dot syntax for propery setting and binding maybe - https://github.com/Microsoft/xaml-standard/issues/94)

[birbilis]

I understand that some sectors have legal responsibility to implement specific accessibility protocols (say ARIA in webpages), but don't think there is a platform agnostic one for native UIs

So, would help to have some basic accessibility properties that map to platform specific ones underneath, but would also like to see functionality for those who want to avoid using those properties when they become redundant (like the tooltip case I mentioned above)

[mrlacey]

@birbilis wow. lots of text there and I'm not sure I understand all your points, but:

• Yes, unnecessarily long names are bad but I'm not advocating for a long name. 'Id', 'Label' and 'Visibility' aren't too long, are they? Even if they were attached properties from a class called Automation, would Automation.Visibility be too long?
• The argument that this shouldn't be done because it's more things for developers to optionally set is not a good one. If you choose not to support accessibility because it's more work than you want to do, that's not a reason to exclude the ability to do so from the standard.
• There's nothing to stop you reusing translated text in multiple places. (e.g. tooltip & label.) I do. That providing a good accessible label might require the creation and translation of more pieces of text is not a reason to make it harder for the standard to support people who need accessibility tools to use software.
• If you're writing and localizing redundant strings then you're doing something wrong. There's nothing about supporting accessibility in the standard that would force you to do something that's redundant.
• If you find that you are using the same strings (or any value) in multiple properties on the same control it would be easy to create a wrapper control that sets the duplicate properties all at once and so keep your XAML files simpler.
• If you think there are standard subsitute rules that could be used for missing labels, what are they? And are they necessarilty better than what a tool might do automatically? (I'd want an accessibility expert to answer that second question, but for the first, are there more than 'Text' or 'ToolTip'? I.E. So if a control has a Text property and hasn't set the Automation.Label it should automatically set the Label to the text value? Then what about text that's updated? Would this have to support INotifyPropertyChanged, etc. too?)
• I get that adding automation and accessibility can be hard and many developers don't like or want to do it. But, that's not a good reason to exclude the ability to do it in a standard way.

[insinfo]

@mrlacey I fully agree with you, and besides the same that is in the XAML Standard 1.0, and is already implemented in the APIs, the developer is the one who has the final word on what he will implement in the Software he is developing.

[birbilis]

Seems your wish was granted :-) https://blog.xamarin.com/accessbility-xamarin-forms

Note: With the release of Xamarin.Forms 2.3.5-pre3, we have renamed the Accessibility class’s name to AutomationProperties.

iOS, Android, and Windows all expose APIs for developers to build accessible mobile apps for everyone. We’re excited to announce that we’ve added new APIs for accessibility in Xamarin.Forms to make it even easier for developers to build accessible, cross-platform mobile applications. In this post, we’ll take a look at new APIs added to Xamarin.Forms that make it easy to build accessible mobile applications. AutomationProperties APIs in Xamarin.Forms

Xamarin.Forms 2.3.5 provides a base set of hint-related accessibility APIs. They consist of the following:

AutomationProperties.Hint
AutomationProperties.IsInAccessibleTree
AutomationProperties.LabeledBy
AutomationProperties.Name

By defining these properties, we can utilize the underlying accessibility functionality in iOS and Android, such as VoiceOver.

[birbilis]

Here's sample code from that article:

<toolkit:EntryLine
        Text="{Binding Email}" 
        Keyboard="Email"
        HorizontalOptions="FillAndExpand"
        Placeholder="email address"
        x:Name="EntryEmail"
        StyleId="EmailTextField"
        IsEnabled="{Binding IsNotBusy}"
        BorderColor="#ECECEC" 
        AutomationProperties.Hint="Enter your email here" 
        AutomationProperties.IsInAccessibleTree="true" 
        AutomationProperties.Name="Email entry field">

        <toolkit:EntryLine.HorizontalTextAlignment>
            <OnPlatform x:TypeArguments="TextAlignment" iOS="Center"/>
        </toolkit:EntryLine.HorizontalTextAlignment>
</toolkit:EntryLine>

[Mike-E-angelo]

(Deleted... moving to #14)

[birbilis]

Actually there are several issues logged already (https://github.com/Microsoft/xaml-standard/issues/14, https://github.com/Microsoft/xaml-standard/issues/35, https://github.com/Microsoft/xaml-standard/issues/70) on both platform specific markup and platform specific properties. Despite one's personal taste there are scenarios where those are needed, especially to cover cases till something is added/standardized at a newer evolution cycle in the XAML standard

[birbilis]

Also checkout these regarding "Implicit ARIA semantics" http://html5doctor.com/on-html-belts-and-aria-braces/
http://rawgit.com/w3c/aria/master/aria/aria.html#implicit_semantics and probably this is interesting too https://www.w3.org/TR/wai-aria-1.1/#co-evolution

[birbilis]

so, grounded on "implicit semantics" concept, when there's a Tooltip property, I believe the AutomationProperties.Hint should be redundant (should be autofilled upon read with ToString() from the tooltip content [assuming a XAML tooltip, not just a string]) and only if explicitly provided should be used instead of the tooltip text with screen readers etc. accessing the automation API