Missing view type in spoken output

The Missing view type in spoken output rules ensures that all interactive elements, such as buttons, switches, and links, expose the correct role or type to assistive technologies. This allows screen readers like TalkBack (Android) or VoiceOver (iOS) to announce the role or type of the element to users, helping them understand how to interact with the element.

Success criteria

• The rule checks whether all interactive elements correctly expose their role or type to screen readers.

How to fix

To fix violations related to missing view type in spoken output:

Example

The following example scan report shows a missing view type in spoken output violation. The issue is identified for a custom view that does not expose its control type to the screen reader.

Violation

• Custom View: The element with className: "android.view.View" and elementType: "android.view.View" is missing a proper control type. The spoken description is set as "my view description, Double–tap to activate.", but the screen reader cannot announce what type of element this is (e.g., button, switch, etc.).

Fix

Ensure the custom view exposes a meaningful control role to the screen reader instead of using a generic android.view.View:

• If the element behaves like a standard control, use the appropriate native view class. For example, Button.
• If you must use a custom view, explicitly set the accessibility role using AccessibilityNodeInfo. For example, set the role to ROLE_BUTTON if it behaves like a button.

References

• 4.1.2 Name, Role, Value (Level A) - WCAG 2.1 · WCAG 2.2