Closed Bug 1579750 Opened 6 years ago Closed 6 years ago

HTML5 aside element exposes wrong IAccessible2 xml-roles object attribute when ARIA role attribute is set

Categories

(Core :: Disability Access APIs, defect, P2)

69 Branch
All
Unspecified
defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox71 --- verified

People

(Reporter: mozbugzilla2021, Assigned: morgan)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

  1. Load test case at https://jsfiddle.net/jhkfsqon/6/show
  2. Inspect generated IAccessible2 xml-roles object attribute for <aside role="note"> and <aside role="group">

Actual results:

xml-roles object attribute on <aside> elements is always complementary

Expected results:

The xml-roles object attribute should match the ARIA role attribute and be set to note and group, respectively, per CORE-AAM Role Mapping General Rules.

Chrome works as expected and sets the xml-roles object attribute for <aside> elements to match the ARIA role attribute.

Firefox works as expected with other HTML5 elements like <header> and <footer>, which is interesting. (I didn’t test every HTML5 element, so I don’t know which other ones might be broken.)

This bug currently causes <aside> elements with non-default role attributes to be read incorrectly in at least NVDA 2019.2.

The actual versions of Firefox I used for testing were Firefox 69 (release build 20190827005903) and Firefox 71a1 (nightly build 20190908094652) on Windows 7.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

It seems that this is simply due to HyperTextAccessible::LandmarkRole returning values for <aside>, <nav>, and <main>, and then Accessible::Attributes using the return value of that function preferentially to the ARIA role attribute. It seems like the logic in Accessible::Attributes simply needs to be changed so that it looks for the role attribute first, and then falls back to the return value of LandmarkRole if it doesn’t.

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jteh)
Blocks: aria
Flags: needinfo?(jteh)
Priority: -- → P2
Assignee: nobody → mreschenberg
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by mreschenberg@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d44a3247d4fa Consider aria role before landmark role for xlm-roles attribute. r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Confirmed the issue with 71.0a1 (2019-09-08).
Fix verified with 72.0a1 (2019-11-19) on Windows 10 and 71.0b11 on Windows 10, macOS 10.13, Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Hardware: Unspecified → All
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: