Same function, same name and place, lowers learning cost

What it is

Search is called Search and sits top-right on this page; on the next it is Find, inside a menu. For someone with a cognitive disability that is not a new synonym—it is the path just built on the last page, cut. Consistent identification lowers learning cost: the same function keeps the same accessible name and the same relative place across pages, so people can proceed by recognition instead of re-pairing “what is this control” on every screen.

A predictable flow skeleton is a cognitive-accessibility tactic; this leaf is narrower. It pins one function across pages—its name and its slot. It is not a brief for how the whole page anatomy should be designed.

Why it happens

Name and place bind into one compound cue. People with cognitive disabilities build that cue slowly and then depend on it. A rename forces semantic re-interpretation; a move forces a spatial re-search; both pull barely-sufficient executive resource off the current task. Experts can patch with a scan. Impaired memory and executive function often cannot, and the behaviour is repeated wrong entries or abandonment.

Relative order matters more than absolute pixels: within a viewport class, Help, Search, and Account only have to keep the same sequence for a reorder not to have happened. Moving Search from the top bar into a hamburger without renaming it is already a new place for visual users, and a new index for linearised users. Both paths have to stay consistent.

Studying it

Conformance checks whether repeated navigational mechanisms keep the same relative order, and whether components with the same function share an accessible name. A harder pass crawls templates into a table: function → accessible name, role, slot in that viewport. A drifted name or a swapped slot on any page fails.

Independent variables: name consistency across templates, whether relative order is fixed. Dependent variables: time to find the target function, first-click errors, times a control that used to be in the chrome can only be found inside a menu.

Do not treat “can returning users still find it six months after a redesign” as the main evidence here—that is cross-version maintenance. Test page-to-page inside the current version.

Where it stops holding

A page that simply has no Search is absence, not a rename. Logged-in and logged-out may have two maps, but each map must still be internally same-name, same-place. A responsive collapse of the top bar into a menu is a viewport-class change; keep order inside that class, and keep the accessible name. Different products and brands need not match each other. Calling Submit “Submit” on the form page and “OK” in the dialog is the same function renamed.

Applying it

• Give reused functions one visible name and one accessible name. Search is Search, not Find on the next page.
• Park them in fixed slots within a viewport class. Do not reorder primary actions around “what this page emphasises.”
• Verify: stack five pages at the same viewport; Help, Search, and Account should align. Then walk the same controls with a screen reader and hear whether the names match word for word. Any rename or order swap fails.

Related

• Same group: J4.11.2 Predictable navigation lets users form a stable mental map · J4.11.3 Unexpected context changes break the user's plan · J4.11.4 Consistency has to survive version changes; churn costs cognitive-disability users more
• Nearby: J4.07 Cognitive accessibility · G1.08 Terminological consistency · G2.10 Stability costs of personalised navigation
• Search terms: consistent identification · consistent navigation · cognitive accessibility