Process explorer difficult / impossible to use via screen reader

[RichCaloggero]

I believe the issue is that the list is constantly refreshing. This causes the screen reader to continually speak the current item. THis makes reading items impossible.

If you bring up context menu to explore options (was hoping for something to turn off or decrease refresh rate), you can't read the menu because screen reader keeps repeating current item.

• need setting to set refresh rate
• many columns to read so either HTML table or way to rearrange and eliminate columns

[isidorn]

@RichCaloggero thanks for letting us know, I have edited your comment to only include things related to the process explorer, since there are other issues which had captured your toolbar suggestions.

@RMacfarlane I think in short this issue is: "Process explorer is not accessible". And I agree with this and it would be great if we could improve this sometimes in the future. Does it make sense to use the table widget for the implementation of the process explorer, since that is the exact visual representation that you want. And if you used the table widget you would get accessibility for free?

fyi @joaomoreno as a table widget author

[RMacfarlane]

Currently the process explorer is using the tree widget - is there a difference in behavior between how these components handle changing data? I think there is probably more we can do to minimize rerendering parts of the explorer that haven't changed, but I'm not really sure what the best way to handle the refresh rate is. If the screen reader is reading a row that then gets removed, what should be read? Having the data potentially update every 2 seconds makes it very volatile. Maybe we should decrease the refresh rate when we are in "optimized for screen reader" mode

[isidorn]

@RMacfarlane oh lovely that you use the tree widget. Then I suggest to do the following:

• [ ] As soon as the process explorer is open focus the first element such that user can use up / down to move focus
• [ ] Even if the process explorer refreshes often if you keep you tree ids stable the focus and selection should remain stable. If this does not work then this sounds like a bug - but it works for me in all the debug trees for example
• [ ] Make sure you are using the TreeAccessibilityProvider, example
• [ ] If the row gets removed the focus should automatically move to the row below or above. Example: checkout what explorer does when you focus on an element and delete it
• [ ] Have a keybinding cmd + backspace or delete to kill process which has keyboard focus
• [ ] Make sure the focus does not jump unexpectedly like it does today (even though the element is not removed)

I think that would be a good start :)

[RichCaloggero]

The table widget is a better fit here I think because you can navigate columns. With current implementation, each list / tree item is read as one long string of stuff. This makes it very difficult to verbally parse.

With the table widget, I can read down a column to get a quick sense of how much CPU each process is using, or how much memory each process is using without having to listen and parse each entire item.

Maybe the only way to make sense of this is to try with NVDA. Open NVDA on windows and open task manager and navigate the tasklist. Each item is read as one long string of stuff, all columns lumped together in one long string of garbage.

The file explorer behaves better. Here you can left / right arrow among column,s then up / down among rows and hear only that columns data. HTML table widget behaves similarly out of the box!

Hope this explanation makes sense.

[isidorn]

@RichCaloggero It makes sense, however even our Table widget internally uses the list view. So we do not actually have a Table widget how you would like it - that you can navigate row / column.

As a first step we will improve how the Process Explorer behaves using a tree, and once you try it out we can further polish it.

[steverep]

I find the process explorer nearly impossible to use successfully with a screen reader. Looks like this issue has been idle for a year, so I thought I'd give it a bump and ask about the status.

As far as the tree vs table debate goes, I don't personally think it matters as long as accessibility guidelines are followed for whichever one is chosen. For the tree widget specifically though, I would strongly suggest the following to make it much easier to parse the speech:

• Adding units at the end of each value (e.g. % for CPU, MB for memory, etc.) since headers are not re-spoken
• Ensuring screen readers pause after each pseudo-column (e.g. by inserting hidden commas)

[isidorn]

@steverep thanks for your feedback, we really appreciate it.

Since all our UI should be accessible, we should think about putting this on the plan in the future. @Tyriar do you own the process explorer now?

[Tyriar]

@isidorn I do, generally it's not considered a priority when considering everything else on my/our plate though as it's intended primarily to be used by our team.

[isidorn]

@Tyriar maybe we should say it is a dev feature and not ship it in stable. If it is in Stable it has to be accessible would be my rule of thumb.

[Tyriar]

@isidorn I agree it should be accessible, we can't just remove a feature some people use.

[Tyriar]

I believe this is fixed now after @rebornix moved it to the tree view

[steverep]

Is this supposed to be fixed in latest insiders? If so, it's not fixed at all and this should be re-opened.

[Tyriar]

Thanks @steverep, you're right. I just tested and I see the following problems immediately:

• No focus when it's opened
• Tab does nothing
• Up/down doesn't move focus like other lists
• Up/down moved between the "column" divs

[steverep]

With NVDA on Firefox:

• I agree there is no obvious focus when opened, and ARIA needs to be set to indicate that it's loading initially
• Pressing tab after load will move you into the list, but nothing is read for each item except the position
• Up/down arrows navigate the list vertically as expected
• Left/right arrows either navigate vertically (not expected) or do nothing depending on the item. I suspect the latter is because it may be opening the tree, but there's no collapsed/expanded state announced and focus does not move.

[steverep]

@meganrogge can you help with this one? Every time I experience a slow down I'd like to investigate, but this isn't even kinda accessible.