Accessibility, inclusive design and assistive technology
HCI2106 · 15 credits · Level 5
Designing for the full range of human ability, with the standards, the law and the methods that make it real.
Ten units
- 1Disability as a category: the medical model, the social model and their criticsThe social model won the design argument and over-reached: it explains built exclusion well, handles impairment badly, and the field now runs on a middle position it rarely states.
- 2Universal design and inclusive design: one solution for all?Universal design's promise of one solution for every user substitutes a designer's assumption for a user's evidence, and the inclusive-design tradition that followed it has fragmented the goal rather than settled it.
- 3Ability-based design and the adaptive interfaceMoving the burden of adaptation from the user to the system is the field's strongest technical idea, but its ability models are validated on prototypes and its benefit shrinks when the user is given control.
- 4WCAG and the conformance regime: what a standard can and cannot requireWCAG is a genuinely testable instrument whose reach was set by what could be agreed and measured, so conformance is a floor that under-represents cognitive, language and learning needs.
- 5Measuring accessibility: automated tools, audits and the conformance-experience gapAutomated testing finds only a minority of accessibility failures and expert judgement is itself a source of variance, so a clean audit is evidence about the tool, not about the user.
- 6Assistive technology: activity, context and the problem of abandonmentWhat determines whether assistive technology helps is fit, abandonment and provision rather than device capability, so a device that works in the laboratory can fail in a life.
- 7Screen readers, semantics and assistive-technology interoperabilityWhether a page works is settled in the accessibility tree and the interaction model that assistive technology reads, so visual correctness systematically misleads the people who build it.
- 8Cognitive accessibility, neurodiversity and ageingCognitive accessibility is the documented weak point of the standards and of the evidence base, and the neurodiversity critique shows that the deficit to be repaired may sit in the design rather than in the user.
- 9Inclusive and participatory research: who holds authorityParticipation transfers authority from the researcher to the disabled participant, and most of the field's participation is evaluative rather than authoritative, as its own reviews record.
- 10Law, policy and procurement: how access is actually enforcedThe law and the procurement contract are the strongest levers on accessibility in practice, and the gap between legal duty and access is a gap of implementation, timing and incentives rather than of statute.
10 of 10 units written. Rows marked in preparation have no body yet.
Specification
| Assessment | Weight | Type |
|---|---|---|
| Accessibility audit and remediation | 40% | coursework |
| Complex accessible widget with testing | 40% | coursework |
| Inclusive design case study | 20% | coursework |
What you will be able to do
- Apply WCAG 2.2 success criteria to a real page and prioritise the failures by user impact.
- Implement accessible semantics and focus behaviour for a complex widget.
- Test a product with assistive technology and report what a user actually experienced.
- Apply ability-based design to a brief and explain how it differs from accommodation.
- State the legal duties that apply to a product and where they are enforced.
The reading this module rests on
- W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2, with the Understanding documents. The normative text and the explanation are both required.
- Wobbrock, J., Kane, S., Gajos, K., Harada, S. and Froehlich, J. (2011). Ability-based design: concept, principles and examples. ACM Transactions on Accessible Computing 3(3). The reframing that this module teaches.
- Henry, S., Abou-Zahra, S. and Brewer, J. (2014). The role of accessibility in a universal web. W4A 2014. Short, and clear about why accessibility is a web architecture question.
- Newell, A. and Gregor, P. (2000). User sensitive inclusive design: in search of a new paradigm. CUU 2000. The origin of the inclusive design argument in HCI.
- Cook, A. and Polgar, J. Assistive Technologies: Principles and Practice. Elsevier. The clinical and technical reference for the assistive half.
Accessibility, inclusive design and assistive technology
Disability is treated too often as a personal attribute: something a body has, which a designer may or may not accommodate. That framing is the wrong place to start, because it turns exclusion into a natural fact rather than a decision. A short-sighted commuter, an older person with a hand tremor and a screen reader user meet the same booking form, and the form decides who gets through.
Hold two questions at once as you read. What does the law and the standard require, and what does the person in front of the system actually experience? The two answers are related, but they are not the same, and the gap between them is where most of the work lies.
Disability is a political category before it is a technical one
The medical model locates the problem in the impaired body and treats the task as cure or compensation. The social model locates the problem in an environment built for a narrow range of bodies, and treats the task as removing the barrier. The distinction is not academic. A shop with a step is a medical-model problem if the answer is a ramp for one person, and a social-model problem if the answer is a level entrance for everyone.
Newell and Gregor described the design work that follows (Newell and Gregor, 2000). They argued that universal usability is best served by extending user-centred design rather than replacing it, and they named the extension user sensitive inclusive design. Their caution is worth keeping: they wanted disabled people involved throughout a project, but not setting research questions or choosing methods, which need trained people.
The contested question in this area is how far the social model can be pushed. Critics argue that it can underplay the reality of impairment, and that a purely environmental account leaves the person invisible. Most working designers now take a middle position: the barrier is usually built, and the person's experience is still the evidence.
The people who benefit are not a small minority
Accessibility is often sold as a concession to a small group. The population reality is looser than that description. Henry, Abou-Zahra and Brewer argued that while accessibility is aimed at people with disabilities, the same work benefits users who face situational limitation, including device and environmental limits (Henry et al., 2014). A person holding a baby, reading in sunlight or using a phone one-handed is temporarily in the same territory.
Wobbrock and colleagues made the related point that ability is not static and that it changes with context (Wobbrock et al., 2011). Newell had earlier described a computer user as a point in a space of functional capability that shifts from minute to minute and across a lifetime (Newell and Gregor, 2000).
The design consequence is a rule you can apply at once. Do not ask whether a feature is for disabled users. Ask which abilities a task assumes, and what happens to someone who does not have them today. A drag-and-drop upload that assumes steady pointing fails for a person with a tremor, a person on a moving train and a person using speech input.
WCAG 2.2 is a testable instrument, and it is deliberately narrow
The Web Content Accessibility Guidelines organise success criteria under four principles: perceivable, operable, understandable and robust (W3C, 2023). The 13 guidelines sit under those principles, and the testable success criteria sit under the guidelines. Each criterion carries a level. Level A is the floor, AA is the level that policy usually demands, and AAA is the strictest.
WCAG 2.2 adds nine success criteria to WCAG 2.1 and removes one. The additions include focus not obscured (2.4.11, AA), dragging movements (2.5.7, AA), target size minimum (2.5.8, AA), consistent help (3.2.6, A) and accessible authentication (3.3.8, AA) (W3C, 2023). The removal is 4.1.1 Parsing, now obsolete.
The standard is honest about its own limits, and the limit belongs alongside the rule. It says the criteria address some accommodation for learning disabilities and cognitive limitations but not every need, and it records that reaching consensus on cognitive criteria was hard (W3C, 2023). It also says testing needs a combination of automated checks and human evaluation. That sentence is the answer to any claim that a scanner proves accessibility.
The criteria most often skipped, and the reasoning behind them
Compliance work tends to stop at the criteria a tool can count. The reasoning behind a criterion is what tells you when it applies. Four are commonly dropped.
Non-text contrast (1.4.11, AA) requires a contrast ratio of at least 3:1 for the visual information that identifies a control or a state (W3C, n.d.). A pale text field with no border can look modern and be invisible to a person with low vision.
Target size minimum (2.5.8, AA) requires a target of at least 24 by 24 CSS pixels unless one of five exceptions applies (W3C, n.d.). The spacing exception is the interesting one: a small control may pass if no other target is near it, which is why an inline link in a sentence is excused.
Focus not obscured (2.4.11, AA) asks that a keyboard-focused component is not entirely hidden by author content. Sticky headers, sticky footers and cookie banners are the usual culprits, and they break keyboard use even though the focus indicator still exists (W3C, n.d.).
Accessible authentication (3.3.8, AA) forbids a cognitive function test, such as recalling a password, unless an alternative or a helper mechanism is available. Blocking paste into a one-time code field removes the helper and fails the criterion (W3C, n.d.).
Access is an implementation property: the accessibility tree, semantics and focus
The accessibility tree is what assistive technology reads. The browser builds it from the document, and it holds a node for each element that matters, with a name, a role, a value and a state. A visual interface can look correct and produce a nearly empty tree.
Semantics come first. A button element carries the right role, is focusable and answers the keyboard. A styled div with a click handler carries none of that, so the screen reader announces little and the keyboard cannot reach it. Use the native element unless you have a reason not to, and then supply the role, state and keyboard behaviour yourself.
Focus management is the part that breaks complex widgets. A modal dialog must move focus into itself, hold it while open, and return it to the trigger on close. A custom combobox must answer the arrow keys and keep the screen reader informed about the active option. Criterion 4.1.2 Name, Role, Value is the test here.
Live regions carry updates that appear without a page change. A polite region waits for a pause; an assertive region interrupts. Use the quieter one unless the message is urgent, and keep the region in the tree before the update arrives, or the announcement is lost.
Assistive technology is a spectrum of practice, not a checkbox
Assistive technology is not one thing. Screen readers differ by platform in their commands, their browse mode and their handling of the same markup, so passing on one is not passing on all. Magnification, switch access, eye gaze, speech input, captions and audio description each place different demands on an interface.
Polgar and colleagues describe the field through the Human Activity Assistive Technology model, which places the technology inside an activity and a context rather than treating it as a device (Polgar et al., 2024). Their text is a clinical reference rather than a design manual, and it is written for practitioners who prescribe and configure technology rather than for interface teams.
The design lesson is that capability and use are different things. Wobbrock and colleagues report, citing earlier work, that no more than about 60 per cent of people who indicate a need for access technology actually use it (Wobbrock et al., 2011). A device that is configured correctly and left in a drawer has helped nobody.
Cognitive accessibility and ageing: where the standard reaches its limit
Cognitive accessibility is the weakest part of the standards, and the weakness is documented by the standards themselves. WCAG 2.2 records that defining criteria for cognitive, language and learning disabilities ran into difficulty over testability and consensus (W3C, 2023).
The supplemental guidance fills part of the gap. The cognitive accessibility guidance asks for familiar patterns, clear wording, short blocks of text and help that stays where the user expects it (W3C, 2021). It is a working group note rather than a normative standard, so it cannot be conformance-tested, and its recommendations are aims rather than criteria a tool can check.
Ageing brings several needs together at once: reduced vision, reduced hearing, slower processing and less tolerance for a task that punishes a mistake. Newell and Gregor argued that design which serves a disabling condition usually serves an older user as well, because both sit on the same capability curve (Newell and Gregor, 2000).
A concrete case makes the stake plain. A form that expires while the user is still reading fails Timing Adjustable (2.2.1, A), and no automated check will flag it because the behaviour depends on the person. Cognitive design has to be argued and tested with people.
Ability-based design: designing for what a person can do
Ability-based design changes the question from what disability a person has to what a person can do (Wobbrock et al., 2011). The authors argue that accessible computing has tended to centralise disability, and that this has limited what it built. Their alternative gives ability a central place in the design process.
The paper offers seven principles and a set of projects. In SUPPLE, the system measures a user's pointing performance and then rearranges and resizes the interface to fit it (Wobbrock et al., 2011). The system absorbs the mismatch, rather than asking the person to buy an add-on that makes them acceptable to the software.
The contrast with accommodation is the teaching point. Accommodation inserts a component between the person and an unchanged system. Ability-based design changes the system, or lets it adapt, so the burden of conforming moves from the human to the software.
The limits are real. Measuring and modelling ability is difficult, the systems described are research prototypes, and the approach depends on the software being malleable enough to sense and respond. Treat the seven principles as a design stance, not as a compliance route.
Inclusive research, procurement and the legal duties
Inclusive design research requires disabled people in the design team, not only at the evaluation stage. Newell and Gregor set the boundary: users belong in the project throughout, while trained researchers keep control of the research questions and the methods (Newell and Gregor, 2000).
Testing is where many projects meet assistive technology for the first time, and that is late. Testing with people who use a screen reader, a switch or speech input finds failures that no inspection catches, and it reports what the user experienced rather than what the markup contained.
The duties are not optional. The Equality Act 2010 requires a service provider to make reasonable adjustments, which the Act sets out as three requirements covering practices, physical features and auxiliary aids, and it treats the provision of information in an accessible format as one such step (Equality Act 2010). The European Accessibility Act sets accessibility requirements for a range of products and services, applied them from 28 June 2025, and required national law by 28 June 2022 (European Parliament and Council, 2019). The public sector accessibility regulations require public sector websites and applications to meet an accessibility requirement and to publish an accessibility statement (Public Sector Bodies Accessibility Regulations 2018).
Procurement is the quiet lever. A contract that names WCAG 2.2 AA and asks for testing with assistive technology users does more than a promise to improve later. The next area of study turns to the measurement of interaction techniques and the machinery of usability evaluation, which is how you would show that any of this worked.