Bug 494469

Can confirm

Technically this is correct as is, because clicking on thje "Accessibility" list item takes you to a single page, not a group of pages.

However on a practical level, I can appreciate that the result sure *looks* like a group of pages, because it has a sidebar that you use to select pages. However technically speaking the sidebar selector that gives you this impression is implemented entirely within the base Accessibility page, and does not use the System Settings' app's own grouping mechanism. This is because we explicitly don't want to use it; we want this page to be exposed to the user as one page, with the view switcher being an internal implementation detail. We don't want it to be exposed as like 7 pages.

I see three options here:

1. Say it's intentional and close the bug on these technical grounds
2. Say it's intentional but admit that the lack of an arrow is a bit odd, and work on a way to let this and similar pages manually opt into showing an arrow
3. Re-think grouping on the page, and split this KCM into like 8, and use the standard grouping mechanism.

---

Disadvantage of #1 is that it's unsatisfying and will feel rude to the bug reporter and anyone else who brings this up.

Disadvantage of #2 is that it will require more technical work to re-implement something we already have for pages using the standard system.

Disadvantage of #3 is that we'll lose the ability to show a single base "Accessibility" page we can easily direct people to.

It may be worth noting, that the only reason why I discovered this in the first place, is that I tried to reduce the settings' window width. If you normally do that in these nested-groups, the contents readjusts, where it only shows [middle sub list | detailed setting], where as with accessibility it shows [left main list | middle sub list | detailed setting]

*** Bug 494400 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #2)
> I see three options here: [...]
> 3. Re-think grouping on the page, and split this KCM into like 8, and use
> the standard grouping mechanism. [...]
> Disadvantage of #3 is that we'll lose the ability to show a single base
> "Accessibility" page we can easily direct people to.

I have a different related proposal:

- Merge some of the groups where the separation is somewhat arbitary in the first place. Modifier Keys, Keyboard Filters, and Activation Shortcuts (which gives a way to enable/disable the features of the first two) could be one entry, "Keyboard Accessibility" (or similar). Mouse Navigation and Shake Cursor could be something like "Mouse Accessibility". Color Blindness Correction and the Zoom page once it lands could be part of a "Display Accessibility" page.
- Make this much smaller number of pages individual kcms in the Accessibility group with the regular grouping mechanism, rather than one kcm. That solves this issue and makes the pages more accessible through search.
- Create a proper Accessibility landing page as the entry point for all accessibility-related things. This would work similar to kcm_landingpage, with a very restricted number of toggles (Enable Screen Reader could go here maybe), and a list of curated links to other kcms, including the others in the Accessibility group but not restricted to them. A fair number of open feature requests are about things that are relevant to accessibility, but configured elsewhere (Screen scaling and font size, pointer speed, keyboard repeat rate...). We can mostly centralize this on the landing page (with maybe an occasional cross-kcm link on the individual accessibility kcms).

Hmm, it sounds like a pretty radical set of changes to me.

CCing Oliver regarding the above, since he's doing some work here already.