Focusable element's role correct

Some elements in your app may have an identity crisis.

A share icon looks like a button on screen. It is tappable and triggers a share action. But VoiceOver announces "Share, Image".

Today, we are introducing a new automated rule in Abra Desktop and Abra SDK: Focusable element role correct.

Available for Android and iOS apps built with SwiftUI, Jetpack Compose, Flutter, React Native and .NET MAUI.

The programmatically determined role

A screen reader does not infer the role of an element from its appearance. It uses the role exposed through the accessibility layer of the operating system.

Developers define this role through properties such as className on Android or accessibilityTraits on iOS.

The role defines how an element should be understood: as a button, tab, switch, heading, image or another type of element. Screen readers typically announce the role together with the accessible name.

Some roles are also expected to expose specific accessibility properties.

• A tab is expected to expose whether it is selected.

• A switch is expected to expose whether it is on or off.

• A dropdown is expected to expose the current selection as its value.

A button is not expected to expose these kinds of states or values.

That is why elements that need to convey state or value should use a role designed for it, such as Switch, Tab, or Adjustable.

Present vs. correct

Our earlier rule, Focusable element role present, checks whether a role is exposed at all.

For example, in an Android app, a custom delete button uses a generic View component with the default className. TalkBack announces only the name, with no role attached.

But what about elements where the role is present, but incorrect?

• In an Android app, a toggle switch is implemented using a Button without setting the accessible class name to android.widget.Switch. TalkBack announces "Wi-Fi, Button", failing to indicate that it is a switch.

• In an iOS app, an image is displayed as a button with the accessibilityLabel set to "Share". The accessibilityTraits remain image. VoiceOver announces "Share, Image", failing to communicate that the element is actionable.

In all these examples, the role is present. It is just not correct. The new Focusable element role correct rule detects many more patterns where the role does not match the element's function.

The rule applies to all focusable elements — including buttons, tabs, headings and images.

Why this matters

People who rely on assistive technologies depend on a correct role to understand how an element behaves.

If the role does not match the element's function, screen readers communicate incomplete or misleading information.

Users may not realise an element is interactive, may not know its current state, or may misunderstand how it behaves.

Why manual testing misses this

A manual tester navigates the app with a screen reader and reports what they hear. If the announcement sounds reasonable, the element often passes.

But the announcement alone does not always reveal whether the underlying accessibility properties are correct.

Take this example: a developer creates a custom button but does not expose the Button role through the accessibility API. Instead, the role is included directly in the accessible name. VoiceOver announces "Submit Button" — sounds fine. A manual tester could easily pass it. But the role property is actually missing. The name is doing the job of two accessibility properties.

Abra removes this guesswork. Instead of relying only on screen reader announcements, Abra extracts accessibility information directly from the Android and iOS accessibility layer. It validates name, role, state and value independently. If the role is missing or incorrect, Abra flags it.

Compliance: WCAG and EN 301 549

The Focusable element role correct rule maps to:

• WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value for interactive elements

• WCAG 2.2 Success Criterion 1.3.1 Info and Relationships for structural elements such as headings

Both criteria are included in EN 301 549, the European accessibility standard commonly used to assess compliance with the European Accessibility Act (EAA).

Catch common accessibility issues automatically

In many of our mobile accessibility audits, we find issues that Abra's automated rules detect. With a few clicks, you can test a screen against all of them:

• Focusable element name present

• Focusable element role present

• Focusable element state present

• Focusable element value present

• Language of the app present

• Portrait orientation

• Landscape orientation

• Target size (minimum)

• Target size (enhanced)

• Focusable element name correct

• Focusable element role correct — new

For everything that automation cannot cover, Abra includes almost 100 manual rules. Together, they let you report the remaining issues and produce a complete audit report demonstrating compliance with WCAG and EAA.

Get started with Abra

Want to test your own app?

Contact us to start a free trial or schedule a demo. During the demo, we will show which accessibility issues Abra detects in your app.