Closed Bug 1610596 Opened 4 years ago Closed 4 years ago

An ARIA role on the top-level body element should not trump document role

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: jdiggs, Assigned: Jamie)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

Attached file body-with-role.html

Steps to reproduce:

  1. Launch the attached test case.
  2. Launch Accerciser.
  3. In Accerciser, locate the accessible object with role document-web.

Expected results: There'd be an object with role document-web.

Actual results: There is no object with role document-web; the author's use of role='main' on the body element trumps the role.

Impact: Orca gets events for descendants of the document and uses document logic when in a document. Because it cannot find an object with the document-web role, this logic doesn't kick in.

Notes:

  1. Technically this is a conformance error. See https://www.w3.org/TR/html-aria/#document-conformance-requirements-for-use-of-aria-attributes-in-html under "body." Maybe Gecko should ignore it? (Though see next item.)
  2. The way Chromium handles this is to expose the landmark role on a child of the object with document-web. Not sure if this is preferable to ignoring the conformance error, but Orca's fine with it, so I don't much care. ;)
Blocks: aria
Priority: -- → P2

(In reply to Joanmarie Diggs from comment #0)

  1. Technically this is a conformance error. See https://www.w3.org/TR/html-aria/#document-conformance-requirements-for-use-of-aria-attributes-in-html under "body." Maybe Gecko should ignore it? (Though see next item.)

I haven't actually seen this part of the spec before. According to this, the application and dialog roles aren't valid on body either. There are definitely real world apps which use role="application" on the body; e.g. Google Docs. NVDA at least wants the application to be at the top level in this case so it doesn't try to do browse mode for it (since the top level accessible gets focus).

We should probably try to get that clarified in the spec. In the meantime, I'm allowing these two roles so we don't break existing use cases.

This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.

Assignee: nobody → jteh
Status: NEW → ASSIGNED
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b545f9839545
Ignore ARIA roles other than application or dialog on body elements. r=MarcoZ
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
Regressions: 1642258
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: