5. The Shlaer-Mellor lens

The structural claim

Pages 2 through 4 give the formal account of what functional, intrinsic, and equivalent-experience accessibility are. They give definitions and a measurement vocabulary. They do not give a method for building interfaces that satisfy those definitions. The gap between definition and construction is the gap this page is for.

The structural claim is that accessibility is a recursive-design problem. That is: it has the same shape as the problem Shlaer-Mellor Object-Oriented Analysis and Design was built to solve — bridged semantic information domains rendered concrete by a model compiler for given platform constraints. The accessibility vocabulary is different; the structure is the same. The methodological apparatus that has been used in real-time embedded systems, telecoms switching, and defence comms since the late 1980s is therefore available to be used for the construction of accessible interfaces too.

The claim is not analogical. It is structural: the two problems have isomorphic shape, and the same modelling constructs solve them. What follows lays out the isomorphism.

The Shlaer-Mellor frame, briefly

Shlaer-Mellor analyses a system as a collection of independent-but-related problem domains, each with its own subject matter (its own vocabulary, its own information model, its own assumptions), joined by formal bridges that map counterparts between the bridged domains. The abstract analysis is then translated— not elaborated — into a concrete realisation for a specific platform (defined by populated counterpart tables) via a model compiler. The same domain analysis produces different concrete realisations for different targets. That last property is what recursive design names: design abstractions that are reused across multiple targets, not re-elaborated for each.

The Shlaer-Mellor frame distinguishes itself from other object-oriented methods by being information-modelling-focusedrather than program-structure-focused. The information model describes the entities of the domain and their relationships; the state model describes how the entities behave over time; the action specification describes what happens at each state transition. The compiler maps these three together onto the target platform’s execution model. The method has specific machinery for resource competition, for role-changing entities, and for cross-domain dependencies that does not exist in the more common UML-centric methodologies.

The accessibility mapping

Accessibility, treated as a recursive-design problem, consists of the following domains: content-semantics, navigation, modality (visual / sonic / haptic / gestural), user capability, device capacity, environment, and custom-and-practice. Each is a well-defined subject matter with its own information model. The bridges between them are the same shape as Shlaer-Mellor bridges — typed relationships that the model compiler operates on.

The “platform” the system is targeting is the user-plus-environment. A screen-reader user on a phone in a quiet room is one platform; a sighted user on a laptop in a noisy office is another; a switch-access user on a tablet using a shared screen-magnifier in a clinical context is a third. The same domain analysis — the same content, the same semantics, the same navigation structure — is rendered concrete differently for each platform by the adaptation system. The adaptation system is the model compiler.

The functional-and-intrinsic distinction from pages 2 and 3 maps directly onto the recursive-design frame. Functional accessibility is the property that at least one traversal of the bridges yields a usable concrete realisation for the user-and-environment platform. Intrinsic accessibility is the property of the underlying domain analysis that it admits many such traversals across many user-platforms. The compiler does the actual work; the analysis is what the compiler operates on.

The specific construct mappings

Each of the Shlaer-Mellor modelling constructs has a direct accessibility-domain counterpart. The construction is not contrived; the constructs were chosen because the accessibility problem actually needs them.

Domain charts → the CISNA five-layer model

The five layers — Adaptation, Navigation, Semantics, Inventory, External Content — are a domain chart for the accessible-hypermedia problem. They differ from canonical Shlaer-Mellor domain charts in that the relationships between layers are peer rather than client-server: each layer admits queries from any other layer above it, rather than being consulted only through a fixed hierarchy. That deviation is itself a methodological contribution; the peer relationship is what lets the adaptation system reason laterally across layers when rendering for a specific user-platform.

Bridges between domains

Inventory↔Semantics and Semantics↔Navigation are the named bridges in the CISNA analysis. The bridges express how meaning composes upward from raw content (the leaf inventory items) to adapted presentation (what the user actually receives). They are formal: typed relationships that the compiler operates on, not metadata annotations on the side.

Assigner state models for resource competition

Mobile devices have audio channels that are competed for at runtime — an incoming call earcon, a new message earcon, a voice-note recording session, an accessibility prompt all want the channel and cannot all have it simultaneously. Shlaer-Mellor handles competition for a finite resource via the assigner state model: a state machine that owns the resource and arbitrates between contenders. No other OO method reviewed during the original development handled this so cleanly. The audio-channel competition for accessibility prompts is exactly an assigner problem; it is a category of problem the method has machinery for and most others do not.

Subtyping with role migration (disjoint-complete)

An accessibility notification migrates through a lifecycle: Announcing → Dwelling → Expiring → (gone). It remains the samenotification through the transitions; what changes is the role it plays in the rendering. Shlaer-Mellor supports this via disjoint-complete subtyping with role migration — an instance of a supertype is in exactly one subtype at a time and migrates between subtypes as its role changes. The modality-aware rendering of each phase (audible-and-visible during Announcing, reduced-presence during Dwelling, suppressed during Expiring) is the model compiler picking the right concrete realisation for each phase for each user-platform.

State Transition Tableswith “Can’t Happen” and “Ignore” cells

Shlaer-Mellor expresses state behaviour as exhaustive tables in which every combination of state and incoming event has an entry — even if the entry is “cannot happen here” or “ignore this event in this state.” The accessibility analogue is user-capability-specific exception handling: an event sequence that makes sense for a sighted pointer user can be a Can’t-Happen for a screen-reader keyboard user; an event sequence that requires acknowledgement from a hearing user can be Ignore for a deaf user, with a different equivalent prompt issued separately. The exhaustive-table form forces the analysis to be explicit per user-platform rather than implicit.

Action Specification Language → Action Language

Shlaer-Mellor specifies state actions in an Action Specification Language, abstract enough to be platform-independent and concrete enough to be executable. The accessibility realisation is the Action Language XML notation, with a Forth-style threaded-interpreter execution model. The execution model itself dates back to the threaded-interpreted Forth runtimes of the mid-1980s; the Action Language carries that shape forward into accessibility-relevant execution. Same execution model, four problem domains, four decades.

The lineage that makes the claim non-rhetorical

Recursive design as accessibility is not a retrospective rationalisation. The lens has been the central engineering vocabulary across four decades and four problem domains. The continuity matters because it is what makes the structural claim non-rhetorical — the same constructs really do work in each domain, and the working is documented.

• Forth at Metal Box (1984–89). The threaded-interpreter execution model that, twenty-five years later, became the runtime for the Action Language.
• Shlaer-Mellor from 1989 onward. OOA/D as practised industrially — domain charts, bridges, assigner state models, subtyping with role migration, action specification languages, model compilation. Twenty-five years of professional practice across telecoms switching, embedded systems, defence comms.
• Ascom AG (1994–96). Shlaer-Mellor in production with Tcl simulation, including the bridge-composition extension that describes inter-domain dependencies as sequences of interactions traversing domain boundaries. The extension was carried into the accessibility methodology a decade later.
• Nokia Mobile (1997–2001). Adaptive UIs as recursive design: self-adapting interfaces moving across devices of varying capability, with a single underlying analysis.
• The CISNA work (2004–13). Shlaer-Mellor applied explicitly to accessibility, with the bridge-composition extension and the Forth-style threaded-interpreter Action Language execution engine.
• Paradise (current). The ActionLanguage intermediate representation (IR) for source-level accessibility analysis. The same shape again, this time applied to JavaScript runtime behaviour rather than to interface adaptation.

One continuous engineering project, applied to four problem domains, across four decades.

Reading on

• The standalone summary of the Shlaer-Mellor lens, shorter and less formal, lives at /research/shlaer-mellor-lens.
• The running code — the original PhD-era Action Language XML notation, with four worked examples that execute in the browser via a TypeScript port of the Java reference engine — lives at /playgrounds/action-language.
• The CISNA five-layer model, which is the accessibility domain chart this page assumes, has its own page at /research/cisna-model.

Continue

← Previous: 4. Equivalent Experience · Next: 6. Communities of Practice →