Settings should have an Accessibility section of its own, not two toggles filed under Appearance #281

New issue

Closed

opened 2026-09-19 09:43:08 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-19 09:43:08 +00:00

Owner

Settings → Appearance has become the place accessibility preferences go because there is nowhere else to put them. Two of its five cards are accessibility choices and say so in their own comments — "An accessibility choice, beside the others here (#203)", "Beside the other accessibility choices (#227)" — and a third, Gone quiet, is not an appearance preference at all. Somebody who needs these settings has to know they are filed under the page about light and dark.

Give them a section of their own: Settings → Accessibility, in the sidebar beside the rest, holding the toggles that decide how the interface behaves for somebody who needs it to behave differently.

README calls this one of the project's stated commitments — "Accessible to everyone. Keyboard-operable, screen-reader-announced, usable with scripts off, and checked against WCAG 2.2 AA" — and #273–#278 have just finished making the pages conform. Conformance is the floor; what a person can then change is a separate thing, and it currently has no address.

What exists today, and where

src/postulo/templates/settings/appearance.html is five cards:

Card	What it is	Belongs
Theme	light / dark / system	Appearance
Show in the navigation	which items appear	Appearance, arguably
Gone quiet	`quiet_after_days` — when an application counts as stale	Neither; it is a dashboard rule
Your career	`show_career_order` — the number, for somebody who cannot use the arrows (#203)	Accessibility
Keyboard shortcuts	`keyboard_shortcuts` — the way out of single-key shortcuts, WCAG 2.1.4 level A (#227)	Accessibility

The fields are accounts/models.py:298 and :309; the form is AppearanceForm (accounts/forms.py:421-436); the sidebar entry is SettingsSection(slug="appearance", …) in core/settings_sections.py:37.

The wiki already points at one of them by its full path — Accessibility.md:52, "switched off in one place, Settings → Appearance → Keyboard shortcuts" — so that sentence changes with the page.

What the new page should hold

Moved, definitely: show_career_order and keyboard_shortcuts. Both exist to make something usable for somebody it is otherwise not usable for, which is the whole test for belonging here.

Candidates, each needing a decision rather than an assumption. The stylesheet honours three environment preferences and offers no way to ask for them from inside Postulo:

prefers-reduced-motion: reduce — static/css/app.css:3701, kills animation and transition durations.
prefers-contrast: more — app.css:2459.
forced-colors: active — nine blocks, app.css:592 onwards, the Windows High Contrast work from #277.

Reading these from the operating system is the right default and should stay the default: it is the setting the person already made, once, for everything. The question is whether an in-app override earns its place, and the honest case for one is narrow — a managed or shared machine where somebody cannot change the OS setting, or a person who wants Postulo calmer than the rest of their desktop. If it goes in, it is a three-way choice (follow my system / always / never), not a checkbox, because a checkbox cannot express "follow my system" and defaulting one to off would quietly override the OS.

Probably also here, if it is wanted at all: the underline-links-everywhere preference, a larger base text size, and anything that comes out of the Known gaps section of the wiki later. None of these exist yet; this issue does not add them, it gives them somewhere to land.

Points to settle

Whether moving the two is a breaking change for anybody. The fields stay on Profile and keep their values, so nothing is lost — but a bookmark to /settings/appearance/ no longer shows them. A redirect is not possible at that granularity; the wiki line is the thing that must be updated, and the release note should say the settings moved.
Whether quiet_after_days moves too. It is on the wrong page today, but its right home is a dashboard or applications section that does not exist. Probably leave it and note it, rather than widen this.
Whether the page states the conformance target. A short line — what Postulo is checked against, and a link to the wiki's Accessibility page and its Telling us section — would make this the place somebody lands when something does not work for them. That is worth more than any single toggle on it.
Whether an empty-ish page is acceptable at first. Two toggles is a thin page. It is still a better answer than two toggles filed under Appearance, and the section is the thing that makes the next one easy to add.

Notes for whoever takes it

Adding the section is SettingsSection(slug="accessibility", label=_("Accessibility"), url_name="settings:accessibility", icon="…", order=15) in core/settings_sections.py — between Appearance (10) and Language and time (20) — plus a path in accounts/settings_urls.py and a view on SettingsSectionMixin (accounts/settings_views.py:31). The registry is already the supported way in, and sections() sorts by (order, slug).
There is no accessibility icon in the set. static/icons/ has 45 and none of them fits; Lucide has accessibility and person-standing. Add the name to assets/icons.txt and run npm run sync:icons — tests/test_icons.py checks the two agree.
AppearanceForm splits into two forms over the same model. Watch navigation, which is not a model field and is rebuilt in __init__/save (accounts/forms.py:457-481) — it stays with Appearance.
tests/test_page_coverage.py requires every named pattern to be visited by the browser suite or excused, and tests/security/test_isolation_sweep.py wants every pattern accounted for: a new settings view fails both until it is listed. (Per #232.)
The wiki commit goes with it — Accessibility.md:52 names the old path, and What you can expect is where the new page should be described. Refs postulo/postulo#N.
Three catalogues to fill while working (fr-fr, pt-pt, pt-br), flagged draft; the other 36 wait for the release sweep.

*Settings → Appearance* has become the place accessibility preferences go because there is nowhere else to put them. Two of its five cards are accessibility choices and say so in their own comments — "An accessibility choice, beside the others here (#203)", "Beside the other accessibility choices (#227)" — and a third, *Gone quiet*, is not an appearance preference at all. Somebody who needs these settings has to know they are filed under the page about light and dark. Give them a section of their own: **Settings → Accessibility**, in the sidebar beside the rest, holding the toggles that decide how the interface behaves for somebody who needs it to behave differently. README calls this one of the project's stated commitments — *"Accessible to everyone. Keyboard-operable, screen-reader-announced, usable with scripts off, and checked against WCAG 2.2 AA"* — and #273–#278 have just finished making the pages conform. Conformance is the floor; what a person can then *change* is a separate thing, and it currently has no address. ## What exists today, and where `src/postulo/templates/settings/appearance.html` is five cards: | Card | What it is | Belongs | |---|---|---| | Theme | light / dark / system | Appearance | | Show in the navigation | which items appear | Appearance, arguably | | **Gone quiet** | `quiet_after_days` — when an application counts as stale | Neither; it is a dashboard rule | | **Your career** | `show_career_order` — the number, for somebody who cannot use the arrows (#203) | **Accessibility** | | **Keyboard shortcuts** | `keyboard_shortcuts` — the way out of single-key shortcuts, WCAG 2.1.4 level A (#227) | **Accessibility** | The fields are `accounts/models.py:298` and `:309`; the form is `AppearanceForm` (`accounts/forms.py:421-436`); the sidebar entry is `SettingsSection(slug="appearance", …)` in `core/settings_sections.py:37`. The wiki already points at one of them by its full path — `Accessibility.md:52`, *"switched off in one place, **Settings → Appearance → Keyboard shortcuts**"* — so that sentence changes with the page. ## What the new page should hold **Moved, definitely:** `show_career_order` and `keyboard_shortcuts`. Both exist to make something usable for somebody it is otherwise not usable for, which is the whole test for belonging here. **Candidates, each needing a decision rather than an assumption.** The stylesheet honours three environment preferences and offers no way to ask for them from inside Postulo: - `prefers-reduced-motion: reduce` — `static/css/app.css:3701`, kills animation and transition durations. - `prefers-contrast: more` — `app.css:2459`. - `forced-colors: active` — nine blocks, `app.css:592` onwards, the Windows High Contrast work from #277. Reading these from the operating system is the right default and should stay the default: it is the setting the person already made, once, for everything. The question is whether an in-app **override** earns its place, and the honest case for one is narrow — a managed or shared machine where somebody cannot change the OS setting, or a person who wants Postulo calmer than the rest of their desktop. If it goes in, it is a three-way choice (*follow my system* / *always* / *never*), not a checkbox, because a checkbox cannot express "follow my system" and defaulting one to off would quietly override the OS. **Probably also here, if it is wanted at all:** the underline-links-everywhere preference, a larger base text size, and anything that comes out of the *Known gaps* section of the wiki later. None of these exist yet; this issue does not add them, it gives them somewhere to land. ## Points to settle - **Whether moving the two is a breaking change for anybody.** The fields stay on `Profile` and keep their values, so nothing is lost — but a bookmark to `/settings/appearance/` no longer shows them. A redirect is not possible at that granularity; the wiki line is the thing that must be updated, and the release note should say the settings moved. - **Whether `quiet_after_days` moves too.** It is on the wrong page today, but its right home is a dashboard or applications section that does not exist. Probably leave it and note it, rather than widen this. - **Whether the page states the conformance target.** A short line — what Postulo is checked against, and a link to the wiki's *Accessibility* page and its *Telling us* section — would make this the place somebody lands when something does not work for them. That is worth more than any single toggle on it. - **Whether an empty-ish page is acceptable at first.** Two toggles is a thin page. It is still a better answer than two toggles filed under *Appearance*, and the section is the thing that makes the next one easy to add. ## Notes for whoever takes it - Adding the section is `SettingsSection(slug="accessibility", label=_("Accessibility"), url_name="settings:accessibility", icon="…", order=15)` in `core/settings_sections.py` — between Appearance (10) and Language and time (20) — plus a path in `accounts/settings_urls.py` and a view on `SettingsSectionMixin` (`accounts/settings_views.py:31`). The registry is already the supported way in, and `sections()` sorts by `(order, slug)`. - **There is no accessibility icon in the set.** `static/icons/` has 45 and none of them fits; Lucide has `accessibility` and `person-standing`. Add the name to `assets/icons.txt` and run `npm run sync:icons` — `tests/test_icons.py` checks the two agree. - `AppearanceForm` splits into two forms over the same model. Watch `navigation`, which is not a model field and is rebuilt in `__init__`/`save` (`accounts/forms.py:457-481`) — it stays with Appearance. - `tests/test_page_coverage.py` requires every named pattern to be visited by the browser suite or excused, and `tests/security/test_isolation_sweep.py` wants every pattern accounted for: a new settings view fails both until it is listed. (Per #232.) - The wiki commit goes with it — `Accessibility.md:52` names the old path, and *What you can expect* is where the new page should be described. `Refs postulo/postulo#N`. - Three catalogues to fill while working (`fr-fr`, `pt-pt`, `pt-br`), flagged `draft`; the other 36 wait for the release sweep.

tiagoagueda added this to the 0.4.0 milestone

2026-09-19 09:43:08 +00:00

tiagoagueda added the

enhancement

accessibility

interface

labels

2026-09-19 09:43:08 +00:00

tiagoagueda referenced this issue

2026-09-19 09:53:17 +00:00

Rebuild the masthead on the component layer: an avatar-only account button, a + menu, and a main navigation made for a phone #282

tiagoagueda referenced this issue from a commit