Closed Bug 1689718 Opened 4 years ago Closed 2 years ago

[Bug] Talkback doesn't explicitly announce aria-disabled `li` element

Categories

(Core :: Disability Access APIs, defect)

Unspecified
Android
defect

Tracking

()

RESOLVED WORKSFORME
Accessibility Severity s3

People

(Reporter: ekager, Unassigned)

References

(Blocks 1 open bug)

Details

From github: https://github.com/mozilla-mobile/fenix/issues/17700.

Steps to reproduce

Precondition: Using Firefox for Android
Combo box example:

  1. Navigate to https://lby61.csb.app/
  2. With Talkback enabled, focus the input field's arrow button and double tap
  3. When the menu opens, focus the "Cat" option. Note that it only announces "Cat" despite it being aria-disabled

Simple example:

  1. Navigate to https://jzy9y.csb.app/
  2. With Talkback enabled, focus "Test". Note that it doesn't announce that the li is disabled despite it being aria-disabled
  3. Focus the input field beneath "Test". Note that it properly announces "Entry disabled".

Expected behavior

Would be nice if Talkback on Firefox for Android explicitly announced li (and other elements) as disabled if aria-disabled is applied to them. Would establish behavioral parity with Chrome and Samsung Internet on Android.

NB: enabled li options in the combo box will announce with "double tap to activate" so a Talkback user can technically distinguish between the an enabled and disabled option. Its a bit problematic still IMO since non-clickable section headers in the combobox can't be distinguished from disabled items since Talkback only announces the text for both.

Actual behavior

Talkback on Firefox for Android doesn't explicitly announce that a li element are disabled.

Device information

  • Device vendor / model and Android version: Android 10, Galaxy S9+
  • Firefox for Android version: 85.1.1

Change performed by the Move to Bugzilla add-on.

Severity: -- → S2
Whiteboard: [access-s3]
Blocks: 1788981

Eitan, there seems to be an inconsistency here, the bug is marked as S2 but has access-s3. Should it be S3 or should it be access-s2?

Flags: needinfo?(eitan)

My mistake. When a bug is in this component we usually don't use access-s\d flags. I would say S3 is accurate. With that said, I followed the STR, and this seems to work! I can spend time in mozregression figuring out what bug fixed it but our implementation has changed significantly enough that it doesn't matter.

Severity: S2 → S3
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(eitan)
Resolution: --- → WORKSFORME
Accessibility Severity: --- → s3
Whiteboard: [access-s3]
You need to log in before you can comment on or make changes to this bug.