Open Bug 1745688 Opened 3 years ago Updated 2 years ago

Remove descendants of <select> Accessibles in content document

Categories

(Core :: Disability Access APIs, task, P3)

task

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

Details

After bug 1744009, we won't have layout frames for descendants of <select> elements. Instead, we always use the e10s ContentSelectDropdown implementation, which uses a separate menulist only when the <select> is expanded. If possible, we should remove the descendants from the a11y tree as well, which would allow us to simplify a11y code in the same way it did for layout. (Bug 1744009 creates these descendants without a layout frame.)

This should hopefully be fine for a11y clients, as these descendants never got focus in content documents anyway; the ContentSelectDropdown items got focus. Certainly, it will be fine for NVDA. We need to verify that it is okay for JAWS; it's possible JAWS uses the descendants for some purpose other than focus (e.g. checking the value).

Aside from cleanup, here are reasons I think we should do this:

  1. Chromium does not expose descendants of a collapsed select, nor do native Win32 combo boxes nor most ARIA combo boxes.
    • Eitan, on Slack, you said that Chrome does expose options in a collapsed select. This doesn't match what I'm seeing. How did you test this? I wonder if the exposure is different on Windows and Mac?
  2. Even though we expose those options, they never get focus. The user interacts with the parent process dropdown.
  3. Bug 1549202 proposes fudging the tree so that the parent process dropdown appears as a child of the select, which is better for a11y clients. If we do that, we only want clients to ever see a single dropdown: the one from the parent process.

NI for question in comment 1.

Flags: needinfo?(eitan)

(In reply to James Teh [:Jamie] from comment #1)

Aside from cleanup, here are reasons I think we should do this:

  1. Chromium does not expose descendants of a collapsed select, nor do native Win32 combo boxes nor most ARIA combo boxes.
    • Eitan, on Slack, you said that Chrome does expose options in a collapsed select. This doesn't match what I'm seeing. How did you test this? I wonder if the exposure is different on Windows and Mac?
      I looked at the tree via edge://accessiblity in Edge on linux. Assumed it is the same on chrome.

Risk and disruption aside, I am all in favor of doing this.

Flags: needinfo?(eitan)

Ah. It's possible Chrome is pruning those nodes out of the platform tree, but keeps them in the core tree. It does this for aria-hidden as well.

You need to log in before you can comment on or make changes to this bug.