Semantics and some structure changes by PureWeen · Pull Request #635 · dotnet/maui (original) (raw)

Description of Change

This PR adds the Semantics structure to Maui.Core which lets you alter how views are semantically processed by things like screen readers. Because the semantics processing is required at the View level this PR grew into an involved restructuring of the the AbstractViewHandler classes. Currently we are stuffing everything into AbstractViewHandler which causes us to have three different properties for accessing a "NativeView". This PR sets up a generic inheritance structure and via method hiding just consolidates all of that to a single property for the Virtual View and a single property for the Native View. This also let me setup disconnect/connect hooks at the ViewHandler level.

This PR has a large set of changes to some fundamental structures so we will plan on filling out the testing more once we have more UI based tests. None of these changes can reliably be tested in an automated fashion we can really only test that some properties are set

Additions made

• Adds
  • ViewHandlerOFT: Rename of AbstractViewHandler
  • Renamed TypedNativeView to NativeView and just collapsed all "NativeView" getters (View, TypedNativeView, NativeView) into NativeView
  • Added VirtualView to IViewHandler
  • Changed the NativeView return type on IViewHandler from object? to NativeView?. Everywhere we are currently accessing this property we are casting it to the NativeView or throwing an exception if it's the wrong type. Not sure if there's a use case here for that being of type object?
  • Semantics: Container class for describing the semantic properties of a View
  • Controls.SemanticProperties: Attached Property for setting semantic properties from the controls project
• Removes
  • NativeView/TypedNativeView

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might effect accessibility?

• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arragement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR then the PR will need to provide testing to demonstrate that accessibility still works.