As discussed with Gijs and Florian, accessibility of about:processes is currently... non-existent:

• we re-render the entire table every few seconds, which breaks with screen readers;
• keyboard navigation is impossible.

How could we make about:processes better at that?

1. Keep the same table rows for processes that persist between 2 renderings, and only update the cell contents for memory/cpu and other per-process things. Can probably just find back rows using the pid of each process.
2. add new rows for new processes
3. remove rows when processes go away
4. use <button> or <input type=image> for controls (with alt/tooltip/aria-label to make their actions accessible)

Thanks, it's definitely a good start. Right now, the default sort is somewhat arbitrary (increasing pid), so for the default view, we can do that.

Things get more complicated when users sort by e.g. decreasing memory count or decreasing CPU usage as we need to reorder rows. I'm not sure how to handle that.

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #2)

Things get more complicated when users sort by e.g. decreasing memory count or decreasing CPU usage as we need to reorder rows. I'm not sure how to handle that.

Ah, hm, that's messy... You could try using CSS (ie the order property in flexbox/grid), though I don't know how maintainable that will be, and if that preserves focus, as I imagine the layout frames will still get destroyed - that'd need testing.

Alternatively, for keyboard focus, you could track focus and make sure focus stays with the same element. I don't know what to do for AT. Marco, what's the canonical way to make a live-updating table (where rows get reordered) properly accessible to ATs? (e.g. what does Windows' Task Manager do?)

I guess in terms of controls, task manager doesn't really have controls in the tree, the controls are fixed outside of the tree and operate on the selected row, and selection persists through updates. Presumably we could do the same...

A few things:

1. CSS ordering does not influence the order of screen reader rendering. Screen readers read by DOM content order alone. So what would need to be changed is the table markup itself, not the CSS ordering, since then, the screen reader view would remain the same and be out of date.
2. Are there actionable items on each table row? Like can you right-click the mouse, get a menu, and do things with the process that you selected? I am asking because for keyboard users, selection only makes sense if that is actually the case. For read-only, non-interactive tables, keyboard focus would not even be needed on each row. But I assume that these actually do have actions that you can perform for each process, so yes, if things get reordered, keyboard focus should stay with the element it was at before, and updates should be minimal.

And aside: Windows Task manager does exactly what Gijs said: The table is only for navigation, the actions to end a task, etc., are performed by tabbing to the buttons outside the table. If ending a task or process, focus then usually returns to the top of the refreshed list, since the last selected item went away. We could do either that, or use the previous or next element instead, to keep the position roughly where the user was before. Similar to when you delete a message in Thunderbird, and focus goes to the next or previous message or conversation.

The severity field is not set for this bug.
:neha, could you have a look please?

For more information, please visit auto_nag documentation.

Doesn't need to block Fission Nightly. Tracking for our Fission Beta experiment (M7).

Florian and Jamie, can you discuss together the work needed here and an assignee for it, please? There's no one from the DOM Fission team who can work on this.

Neha, do you know if about:processes will be discoverable by users (e.g. through some menu option) or will it only be accessible via the URL? Obviously, I'd prefer everything were accessible (and really, this should have been accessible from the start when it was first implemented), but prioritisation is more important than ever now. If this will only be accessible via the URL (suggesting we essentially see it as a developer debugging tool), that significantly impacts how we prioritise it. Thanks.

The goal is that eventually, Firefox task manager from the hamburger menu will point to about:processes instead of about:performance, as it does now. But that depends on some more work to be done on about:processes which is not resourced at the moment. So, for now, you can assume that this will only be available via the URL.

(In reply to Neha Kochar [:neha] from comment #10)

The goal is that eventually, Firefox task manager from the hamburger menu will point to about:processes instead of about:performance, as it does now. But that depends on some more work to be done on about:processes which is not resourced at the moment.

Is this being tracked somewhere? it'd be good to ensure that accessibility is taken into account when this work is resourced.

The main meta for about:processes is Bug 1628531 and the Task Manager work is tracked in Bug 1656383.

Removing Fission milestone tracking for all about:processes work.