Consider not firing accessible children-changed and text-changed events during page load
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: jdiggs, Unassigned)
References
Details
Steps to reproduce:
- Launch Orca
- Load this page https://candidat.francetravail.fr/formations/recherche?alternance=true&quoi=formateur+adulte&range=220-229&tri=0
Expected results: Orca would present the content in a timely fashion.
Actual results: The page visually takes forever to load and even longer for Orca to present something.
Looking at Orca's debugging output, I'm seeing a huge number of object:children-changed:add:system events. I assume they are resulting from the page being populated progressively and with a lot of items. Orca's doing its best to immediately discard these events, but there are so, so many of them. :(
Is there anything reasonable that can be done on the Gecko end, such as not firing these events if page load has not completed?
|
||
Comment 1•1 year ago
•
|
||
Thanks for the report! It looks like your diagnosis is fair to me. I'm not sure that Gecko can avoid firing those events entirely, but maybe we could coalesce them if they are indeed useless/redundant. It's hard to know since we can't predict what the script will cause to be inserted later. I think doc load complete might be the wrong target since many things can happen before the official doc load complete that ATs ought to know about. cc-ing Jamie and Eitan.
|
||
Comment 2•1 year ago
|
||
This keeps cropping up; see the "see also" bugs. I'm still very curious to know whether this impacts Chromium for you, and if not, what does it do instead in terms of event firing?
We could suppress events before doc load for ATK, but I don't think this is a good idea. Doc load will only be fired once all images, etc. on the page load, but pages are often "usable" before that point. It would be unfortunate if a sighted user could interact with the page several seconds or minutes before a screen reader user reasonably could. Also, this could easily happen after doc load complete; e.g. if the page loads an initial DOM but then progressively loads the rest via JS. On the modern web, that's not at all inconceivable.
I'm also mindful that children-changed can be used to update the AT-SPI cache. So if we stop firing them in various situations, isn't that going to cause problems?
Description
•