pcsx2-qt: Add buddies and tabstops

[TheTechnician27]

Description of Changes

Adds buddies and tabstops to interactive elements in the Qt UI for accessibility, polish, and consistency.

Rationale behind Changes

Buddies

Buddies are a property in Qt which associate a label with an interactive element. For example, if I have a UI looking like label1: [spinbox1], Qt will associate spinbox1 with label1 when label1 is given spinbox1 as its buddy. This is transparent for most users, but for users with a screen reader, this means you can actually tell what an interactive element does. It's a win for accessibility with minimal maintenance overhead and arguably better self-documentation.

Currently, for example, focusing a spinbox will just say that you've focused a spinbox without saying what it's supposed to be for – rendering much of our UI totally unusable. With a buddy, it will read out the label on top of the element type. As an example, with buddies, the OSD scale option will read approximately as "OSD Scale: Spin Box 100", but without, it will only read "Spin Box 100". There is no way to focus the labels either, so it's unlikely they can be read out without buddies.

These are easy to follow in the raw XML, and the Qt Widgets Designer has an easy interface for them under Edit > Edit Buddies.

Tabstops

Tabstops are another property of Qt which allows an explicit ordering of elements when tabbing through a widget (i.e. focusing on one element then pressing Tab). Without them, the tab order is subject to the physical ordering of the elements in XML, which 1) does not inherently correspond to the row/column order displayed and 2) is highly chaotic and unrealistic to maintain, especially when a file is run through the Qt Widgets Designer.

Currently, tab orders in almost every menu are complete nonsense (see e.g. the global controller settings, various settings menus, etc.), which is a problem for both accessibility and polish.

These are trivial to understand in the raw XML, because they're represented as one singular list, and the Qt Widgets Designer has an easy interface for them under Edit > Edit Tab Order.

I chose the Graphics Display widget at random. Here is the current tab ordering without tabstops:

Suggested Testing Steps

• Make sure on each page with interactive elements that tabbing through is consistent and sensible.
• Make sure when using a screen reader that interactive elements with a label are read out.

Did you use AI to help find, test, or implement this issue or feature?

No.

[kamfretoz]

There seems to be a gap between Show FPS and Show FPS on the check boxes of the OSD Settings.

[TheTechnician27]

There seems to be a gap between Show FPS and Show FPS on the check boxes of the OSD Settings.

This is a screenshot of current master. I know what causes this and what fixes it, and a very easy fix was in a larger WiP PR that I decided to subdivide into this, #13367, and at least one or two more future PRs. I can fix it in this PR if people want that (it's just an issue of row number in the Qt XML), but it was left in this state intentionally to segregate buddies and tabstops from other UI changes that I intend to make in upcoming PRs.

[TheLastRar]

Default tab is now correct in Ethernet settings panel

[TheLastRar]

In the Graphics panel, the tab menu is the last thing you can tab to
This is unchanged from master, but I wonder if that can be resolved.

In the Audio panel, Standard Volume is tabbed to after FF volume, this should be the other way around (as is the case in Master).

In the HDD settings, I can't easily tab into the HDD section.
On Master, I can't tab into to the DHCP section easily (but can to the HDD section), so Idk what's going on, maybe Qt is having issues here.

Not everything was tested.
Aside from above, what I did test had improved tabbing order.

[TheTechnician27]

In the Graphics panel, the tab menu is the last thing you can tab to This is unchanged from master, but I wonder if that can be resolved.

I looked into this one, but I think that would have to be done dynamically in the code rather than statically in the .ui files. I could be wrong, but I think the XML files are totally blind to those tabs.

In the Audio panel, Standard Volume is tabbed to after FF volume, this should be the other way around (as is the case in Master).

I can actually reproduce this one, and I'm realizing the bug never showed up on my end because the GitHub artifact is treating these UI elements as "volume" and "resetVolume" rather than the new "standardVolume" and "resetStandardVolume" from #13316. I will push a fix shortly. I have now fixed this by rebasing and conforming the buddy and tabstops to the new IDs.

In the HDD settings, I can't easily tab into the HDD section. On Master, I can't tab into to the DHCP section easily (but can to the HDD section), so Idk what's going on, maybe Qt is having issues here.

Yeah, basically what's happening here is that in other panels like the Graphics settings, we have separate Qt .ui files for each tab (e.g. display, advanced). The DEV9 panel is the one case where we don't; the two tabs are in the same file. Qt has odd behavior where the tab ordering doesn't properly account for whether you have tabs (it's just a static, linear list), and so if your tabs "go into" the other tab, they more or less disappear into a black hole.

The options here were to 1) map the tabstops to header, then tab 1, then tab 2, then HDD footer knowing this is the "correct" mapping or 2) assume a most likely case of a user staying on the first tab and map an "incorrect" order of header, then tab 1, then HDD footer, then tab 2. (A nuclear option 3 is to turn them into separate .ui files like we do in Graphics and Debug.)

[TheLastRar]

In the Graphics panel, the tab menu is the last thing you can tab to This is unchanged from master, but I wonder if that can be resolved.

I looked into this one, but I think that would have to be done dynamically in the code rather than statically in the .ui files. I could be wrong, but I think the XML files are totally blind to those tabs.

Okay, that might be tricky, as is if fine for now.

I can actually reproduce this one, and I'm realizing the bug never showed up on my end because the GitHub artifact is treating these UI elements as "volume" and "resetVolume" rather than the new "standardVolume" and "resetStandardVolume" from #13316. I will push a fix shortly. I have now fixed this by rebasing and conforming the buddy and tabstops to the new IDs.

Can confirm, this is fixed.

The options here were to 1) map the tabstops to header, then tab 1, then tab 2, then HDD footer knowing this is the "correct" mapping or 2) assume a most likely case of a user staying on the first tab and map an "incorrect" order of header, then tab 1, then HDD footer, then tab 2. (A nuclear option 3 is to turn them into separate .ui files like we do in Graphics and Debug.)

Okay so it's a Qt issue then
I suspect option 2 might be more user friendly, but would be wrong if Qt ever fixes the issue.
The nuclear option is best but probably out of scope here.