Polymorphic Task Decomposition

A way of describing multiple manipulations of the same data so a capability model can choose the most appropriate route for the user’s circumstances. The pre-requisite for intrinsic accessibility: without PTD-style task variation, the adaptation system has nothing to adapt between.

Polymorphic Task Decomposition: the Delete File exampleHierarchical task tree with root “Delete File” branching into two polymorphs. Direct Manipulation contains sub-tasks “Select File” before “Select Delete,” with leaf modality affordances for scanning and visual interaction. Modal Dialogue contains sub-tasks “Select Delete” before “Select File” before “Confirm Delete,” with leaf affordances for visual and non-visual listbox interaction.Delete FileDirect ManipulationSelect FileSelect DeletescanningvisualModal DialogueSelect DeleteSelect FileConfirm Deletevisualnon-visual listbox
The canonical PTD example. The same underlying intention — Delete File— realised as two polymorphs: Direct Manipulation and Modal Dialogue, each with its own task ordering and its own leaf-level modality affordances. The capability model selects between polymorphs at runtime based on user, device, and operating context.
Polymorphic Task Decomposition: the Delete File exampleHierarchical task tree with root “Delete File” branching into two polymorphs. Direct Manipulation contains sub-tasks “Select File” before “Select Delete,” with leaf modality affordances for scanning and visual interaction. Modal Dialogue contains sub-tasks “Select Delete” before “Select File” before “Confirm Delete,” with leaf affordances for visual and non-visual listbox interaction.Delete FileDirect ManipulationSelect FileSelect DeletescanningvisualModal DialogueSelect DeleteSelect FileConfirm Deletevisualnon-visual listbox

The canonical PTD example. The same underlying intention — Delete File— realised as two polymorphs: Direct Manipulation and Modal Dialogue, each with its own task ordering and its own leaf-level modality affordances. The capability model selects between polymorphs at runtime based on user, device, and operating context.

What it is

Conventional task analysis names the task and its decomposition into steps. PTD names a task as the equivalence class of multiple realisations of the same underlying intention: direct manipulation versus modal dialogue, voice versus gesture, full-screen versus assistive overlay, keyboard versus pointer. Each realisation is a polymorph of the same underlying task.

The capability model — see Intrinsic Accessibility for the formal structure — selects from these polymorphs at runtime based on the user’s capacity, the device’s capabilities, and the operating context. Without PTD, the model has nothing to select from; with PTD, the underlying task is the invariant and the realisation is the variable.

Why it matters

The bolt-on assistive technology approach assumes a single canonical realisation of every task and grafts alternative input or output onto it. PTD assumes the opposite: that multiple realisations exist by design, and the system chooses among them. That choice is what makes the whole framework intrinsically accessible rather than functionally accessible.

Practical consequence: Paradise’s analysers borrow PTD’s vocabulary for “there are several valid ways to express this; pick one and check the choice is consistent.” The cross-file event-handler validation is exactly this — a click handler and a keyboard handler are two polymorphs of the same activation task, and the analyser checks they co-exist when both are needed.

Reading on