1785182 - ARIA progressbars expose child elements when they shouldn't

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):

1. Open this test case:
   data:text/html,<div role="progressbar" aria-valuetext="test"><p>&nbsp;</p></div>after
2. Press control+home to read the first line in the document.
   • Expected: NVDA should say: "progress bar test"
   • Actual: NVDA says: "after"

This occurs because the progressbar is exposing the paragraph child. According to the spec, the children of progressbars should be considered presentational, which means we shouldn't expose them in the tree.

We can fix this by treating progress bars the same as sliders here. It's currently not possible to test this in automated tests because MustPrune isn't exposed to our testing infrastructure via XPCOM, which means this will need to be tested manually with a platform inspection tool (or with NVDA).

Originally reported in: https://github.com/nvaccess/nvda/issues/913#issuecomment-1217422017

Triaging as s2 because this means some ARIA progressbars aren't exposed to NVDA users at all.

Comment 1

[Nathan LaPré]

Attachment: Bug 1785182 - prune children of progressbar elements from the acc tree, r?Jamie

Per the ARIA spec, children of progressbar elements are purely
presentational. So, we should prune their children from the
accessibility tree. This commit adds some logic to nsAccUtils::MustPrune
to forcibly prune these children, ultimately unbreaking the experience
for screen reader users who would otherwise not be told about some ARIA
progressbars.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3f84a300d979
prune children of progressbar elements from the acc tree, r=Jamie

Comment 3

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/3f84a300d979

Comment 4

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this issue on a 2022-08-16 Nightly build on Windows 10. Verified as fixed on Firefox 106.0b4(build ID: 20220925185751) and Nightly 107.0a1(build ID: 20220926213808) on Windows 10, Windows 11.