Accessibility settings need one centralised hub, not scattered menus

What it is

When accessibility options scatter across menus (subtitles in audio, colour-blind mode in video, key mapping in controls, difficulty in gameplay), a player needing multiple accessibility features (colour-blind plus subtitle remapping) must shuttle between four menus to assemble their configuration, with no way to know what other support lies hidden elsewhere. A centralised hub gathers all accessibility options into one menu (top-level entry, unified layout, clear categories), making "browse what support exists" possible—for those in need, browsing the list of available support is itself a key service.

Why it happens

The hub's value mechanism lowers configuration's cognitive and navigation costs. Scattered placement assumes "players know what they need and where to find it," which generally fails for accessibility seekers: many don't know their difficulty has a solution at all (that motion sickness can be mitigated, that colour-blind modes exist), and their discovery path is browsing, not searching—browsing needs a complete list, and scattered placement means no list exists. Configuration cost multiplies with scattering too: multiple needs mean multiple menus, each re-learned, and configuration complexity compounds with the number of needs. The hub also signals: a prominent accessibility menu tells every player "this game takes accessibility seriously," shaping seekers' initial expectations (worth trying) and the community's evaluation dimension. Centralised organisation with categories (vision, hearing, motor, cognitive) makes browsing efficient, with effect descriptions beside every option (naming problems detailed next).

Where it stops holding

A hub does not mean related settings live only there—cross-references (a "more audio accessibility options →" link inside the audio menu jumping to the hub) keep contextual discovery while configuration stays central; bidirectional references beat a single location. The hub's organisational granularity also balances: classifying purely by impairment demands self-diagnosis (the label "cognitive impairment" isn't universally accepted or self-evident), while classifying by function (subtitle settings, feedback settings, time settings) is more neutral; the two can coexist (function-based primary, need-scenario tags as aid). The hub's placement depth is itself a discoverability question—accessibility entry should sit at the same level as other top-tier settings (video, audio, controls), with contextual shortcuts (colour-blind mode linked from video settings) preserved as quick paths. Hub maintenance cost is real: every new accessibility feature must update both the hub and contextual entries, so configuration-driven rendering (define once, render everywhere) keeps the cost down.

Applying it

• Build an accessibility settings centre: a top-level entry in the settings menu, organised by function (vision, hearing, motor, cognitive, time), each item with an effect description and current state.
• Place cross-links to the hub inside related menus (video, audio, controls), and point context-triggered recommendations (an HDR display detected → brightness options prompt) to the hub's corresponding items.
• Verification: have testers needing multiple accessibility features (or simulating those needs) complete configuration from scratch, counting menu jumps and total time. Configuration spread across multiple top-level menus means the centralisation needs redesign.

Related

• Same group: W8.08.2 First launch should surface accessibility options · W8.08.3 Setting names should describe effects, not jargon · W8.08.4 Buried options make players believe the game lacks support
• Nearby: G2.01 Information architecture and navigation · J1.01 Accessibility design principles · W8.08 Discoverability of accessibility settings
• Search terms: accessibility menu · settings hub · a11y settings · options design