GNOME.org
 

Re: [orca-list] Strange tree behavior on master

Hey Nolan.
So the problem I was seeing was due to a couple of things which have been in Orca for at least two years designed to minimize some chattiness. Thus I don't *think* this is due to the recent changes in master. But regardless, I removed one and modified the other. As a result, I now see the following:
1. When the tree on the left does not have sufficient space to show text for the tree items, Orca presents the name of the thing at tree level 1. That fixes the bug you reported (I think/hope).
2. When the tree on the right does have sufficient space to show the displayed text, you now get that name twice. I would argue this is not a bug in Orca. Here's why:
The Riot developers have an object with the ARIA "group" role (translates to the panel role for us) and an aria-label with the displayed text "Favorites", "Rooms", "Direct Messages". This group has a descendant ARIA role "treeitem". The treeitem doesn't have an aria-label. However, when the tree has enough room, this treeitem has a child span with the same contents as the aria-label value for the group.
Treeitems are supposed to have accessible names. Thus when the author hasn't provided one via aria-label, the user agent is expected to calculate it. When the treeitem is showing text, it gets its name from the span and we have a treeitem called, say, "Direct Messages" inside a group called "Direct Messages". 

With this background in mind....
I changed Orca to stop treating the ARIA "group" role as "layout only" when the author has provided an explicit name (e.g. via aria-label). When Orca thinks something is "layout only", it will not include it as part of the new ancestors. I think this change makes sense. After all, if the author slaps a label on an element for accessibility purposes, screen readers should not ignore that label. Bug in Orca fixed.
But when the treeitem gains focus, and it has an accessible name, that treeitem's name should not be ignored. So I think Orca is doing the right thing by presenting it.
The fact that the treeitem and its parent have the same accessible name is not Orca's fault, and trying to be clever about this sort of thing led to the bug you were experiencing.
So.... If we want to fix this chattiness problem, perhaps the Riot developers could consider not putting the aria-label on the group when there is sufficient room to display its text in the treeitem. 

Thoughts? And also did I manage to fix the original bug for you? :)

--joanie

On 4/22/20 10:21, Nolan Darilek wrote:
Hmm, I wonder if the splitter positioning is also causing my odd focus jumps? As a reminder, arrowing up from the message text entry causes focus to land on toolbars then jump out of the message list. I thought maybe mouse connectivity had something to do with it, but after spending more time with that it doesn't seem to.
I'm not sure if the Members/Notifications/Files tabs are the splitters to which you refer. They used to have collapsable ARIA roles associated with them but don't seem to anymore, so I'm not immediately sure how to test this myself. I'll try, though. 


Thanks for figuring this out.

On 4/22/20 9:11 AM, Joanmarie Diggs wrote:
Aha! I can reproduce the problem if the tree doesn't have enough room due to window size, or dragging what serves as the splitter between the room list and the room conversation to the left. But when that's not the case, then I cannot reproduce the problem even using Firefox 75 and riot.im/develop.
So.... I shall see about fixing the problem I can reproduce and hopefully that will solve what you're seeing too. :) 

Thanks!
--joanie

On 4/22/20 09:55, Nolan Darilek wrote:

I was using Orca master, Firefox 75, and https://riot.im/develop.


1. Load an environment with the previously-mentioned versions.

2. Access https://riot.im/develop with a logged-in Matrix account.
3. Press ctrl-home, or otherwise navigate to the top of the screen. Interestingly, Ctrl-home doesn't seem too reliable here for me. 

4. Tab until you reach the tree of rooms.
Interestingly, I can't reproduce the "blank" behavior now, but I'm not getting level 1 tree labels read. Before, when I got the "blank" issue, I heard lots of "panel, leaving panel..." spam. Starting to wonder if the "blank" behavior may be related to the odd focus jumps I previously reported in Riot.
Thanks for looking into this. If you still can't duplicate, I'll do the USB dance and log into Send so I can send a debug log. 

On 4/22/20 8:47 AM, Joanmarie Diggs wrote:
I just tried Orca master, Firefox Nightly, and my company's instance of Riot (riot-web version: 1.5.15, olm version: 3.1.3) and Orca is presenting all the group titles ("Favorites", "Direct Messages", "Rooms", "Low Priority").
So I need more concrete steps to reproduce the tree level 1 items not being presented. 

How do I make the "blank" issue happen?

--joanie

On 4/22/20 09:32, Nolan Darilek wrote:
ORCA_3_36_1 doesn't exhibit the "blank" behavior, but it doesn't read out the level 1 tree labels.
Interestingly, it does seem to read "Favorites", a level 1 label, at least once. But only when I arrow up to a level 2 tree item from below, and only with that particular section. 

On 4/22/20 8:26 AM, Joanmarie Diggs wrote:

Hey Nolan.
I'll take a look. In the meantime, are you able to compare with Orca 3.36? 

--joanie

On 4/22/20 09:10, Nolan Darilek wrote:

Hey folks,
I know there's been lots of churn on master, and am not sure if this is a regression. On riot.im/develop, there's a nice keyboard-navigable tree of Matrix rooms with collapsable levels and titles. This used to work fairly well, but now has a few failure cases:
  * Sometimes titles don't read (I.e. "Favorites", "Rooms", etc.) Room names and counts seem to read fine.
  * I hear "blank" a lot more than I used to, particularly when arrowing around the tree. The blanks aren't associated with tree items, so it seems like I'm either missing rooms, or I have to arrow several times to reach them.
This still seems to work under NVDA and Windows 10, so I'm wondering if a recent change in master may have messed this up?
If you can't duplicate, please let me know and I'll capture a debug.out. I don't do that automatically because I've been using Firefox Send to upload these, Send has the annoying habit of logging me out, and my quarantine computer setup makes password management a pain. I'm away from home without my USB hub, and the only way to get to my passwords is to unplug my USB headset, plug in an external speaker, plug my PGP smartcard into the USB port vacated by the headset, log in, then remove the card so I can plug the headset back in. If anyone knows of a free place to upload files of debug.out size, please let me know. Maybe I'll clean out my Dropbox one of these days, but it isn't high on the priority list. 

_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html 


_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]