[Accessibility] Fix SfTextInputLayout HelperText and ErrorText not visible to screen readers

[Copilot]

Screen readers like VoiceOver (macOS) and Narrator (Windows) were unable to access HelperText and ErrorText in SfTextInputLayout because they were drawn directly on canvas without semantic information.

Root Cause

The GetSemanticsNodesCore() method only created semantic nodes for numeric controls but ignored the assistive text elements that are rendered via canvas.DrawText().

Solution

Added semantic nodes for HelperText and ErrorText with proper positioning and accessibility labels:

// Before: Only numeric controls had semantic nodes protected override List<SemanticsNode> GetSemanticsNodesCore(double width, double height) { PopulateNumericSemanticsNodes(Content); _textInputLayoutSemanticsNodes.AddRange(_numericSemanticsNodes); return _textInputLayoutSemanticsNodes; // HelperText/ErrorText missing! } // After: Includes assistive text semantic nodes protected override List<SemanticsNode> GetSemanticsNodesCore(double width, double height) { _textInputLayoutSemanticsNodes.Clear(); PopulateNumericSemanticsNodes(Content); _textInputLayoutSemanticsNodes.AddRange(_numericSemanticsNodes); PopulateAssistiveTextSemanticsNodes(); // NEW: Adds helper/error text nodes return _textInputLayoutSemanticsNodes; }

Key Features

• Non-breaking: Visual appearance and behavior remain unchanged
• Proper priority: Error text overrides helper text (matches visual behavior)
• Positioned correctly: Uses existing _helperTextRect and _errorTextRect fields
• Clear labeling: Screen readers announce "Helper text: [content]" or "Error text: [content]"
• Automatic updates: Integrates with existing property change handlers

Testing

Added comprehensive unit tests covering:

• Helper text semantic node creation
• Error text semantic node creation
• Error text overriding helper text
• Edge cases with empty or missing text

Example

<!-- This XAML is now fully accessible to screen readers --> <textInputLayout:SfTextInputLayout Hint="Name" HelperText="Enter your full name" ErrorText="This field is required" HasError="True"> <Entry /> </textInputLayout:SfTextInputLayout>

Before this fix, screen readers could only access the Entry field. Now they can navigate to and read both helper text and error text, providing complete accessibility for users with visual impairments.

Fixes #181.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[PaulAndersonS]

@copilot
I implemented your accessibility fix for the helper and error text, but encountered a focus order issue. Currently, the helper or error text receives focus first — even though it appears visually below the main control — which disrupts expected navigation.

The source code draws the helper and error text natively instead of using semantic-friendly elements like Label, which causes screen readers to interpret the content incorrectly.

To ensure proper semantic flow and focus order (entry field first, followed by helper or error text), I recommend modify the drawing of helper and error text in to MAUI Label controls and add the text respectively. The Entry will focus first and then the helper or error label will focus from accessibility. So generate the codes and share me

[Copilot]

@copilot
I implemented your accessibility fix for the helper and error text, but encountered a focus order issue. Currently, the helper or error text receives focus first — even though it appears ...

I've implemented the accessibility fix using MAUI Label controls as you requested. The changes replace canvas drawing with proper semantic elements, ensuring correct focus order.

Key changes in commit af4bc46:

• Replaced canvas-drawn helper and error text with MAUI Label controls
• Removed semantic nodes (since Label controls handle accessibility automatically)
• Labels are positioned properly at the bottom of the layout
• Entry field now receives focus first, followed by helper/error labels
• Error text still properly overrides helper text when both are present
• Visual appearance and behavior remain unchanged

The Label controls provide native accessibility support and proper semantic structure, fixing the focus order issue where assistive text was receiving focus before the main input control.

[PaulAndersonS]

@copilot You're working on a .NET MAUI application using the TextInputLayout control, where accessibility behavior differs across platforms. A recent fix added Helper and Error text as Labels to improve screen reader focus. On Windows, this works as expected—Helper/Error labels get focus properly with screen readers like Narrator. However, on Android, the entire TextInputLayout control fails to receive focus when TalkBack is active.
Upon investigation, it seems that embedding the Entry, Clear button, and now Helper/Error labels inside an SfView might be interfering with accessibility focus. Specifically, adding Labels as children appears to disrupt the container's ability to register focus correctly.
Please inspect the following:
🔍 The implementation of the SfView class, its behavior in Android, and how it handles child accessibility events
🧩 The associated handler class and any native view mappings or accessibility delegates
⚙️ Whether IsImportantForAccessibility, Focusable, or similar Android accessibility flags are correctly applied to the container and children
🧪 Modify the behavior so that TextInputLayout and its children participate correctly in TalkBack's focus order
✅ Propose or apply an Android-specific fix ensuring that the control’s primary content (Entry) and Helper/Error text are individually and collectively discoverable by TalkBack, restoring parity with Windows behavior
Keep in mind that we expect the Entry to be focusable by default and the Helper/Error to be announced contextually—not block focus for the entire layout.

[Copilot]

@copilot You're working on a .NET MAUI application using the TextInputLayout control, where accessibility behavior differs across platforms. A recent fix added Helper and Error text as Labels to impro...

I've implemented an Android-specific fix for the TalkBack accessibility issue in commit 5fa0d5a. The problem was that adding Label controls as children to the SfView was interfering with Android's accessibility focus order.

Key changes:

• Proper ImportantForAccessibility management: Labels are marked as not important for accessibility when invisible/empty, preventing focus interference with the main Entry control
• Dynamic accessibility updates: Accessibility properties are updated when labels become visible/hidden through UpdateLabelAccessibilityImportance()
• Handler-aware initialization: Accessibility configuration is applied when platform handlers are ready via OnAssistiveLabelHandlerChanged()
• Proper focus order restoration: Entry field now receives focus first, followed by helper/error labels when present

The fix ensures that on Android with TalkBack:

1. The TextInputLayout container remains focusable and doesn't lose accessibility completely
2. The Entry control gets focus priority as expected
3. Helper/Error labels are discoverable by TalkBack only when they have content
4. Focus order matches the visual layout and user expectations

This maintains full backward compatibility while restoring proper Android TalkBack functionality alongside the existing Windows accessibility improvements.