Accessibility Under Pressure
What does accessibility require when people are stressed, interrupted, or trying to solve an urgent problem?
Hypothesis
"If accessibility is designed around real conditions of use—not only technical compliance—then residents should be able to report maintenance problems with greater accuracy, confidence, and independence across a wider range of abilities and circumstances."
The Problem Space
Accessibility is often evaluated as a checklist applied near the end of product development. Although technical conformance is essential, it does not guarantee that an experience will remain usable when someone is stressed, distracted, working from a phone, unfamiliar with the terminology, or relying on assistive technology. Maintenance reporting exposes this gap because residents must describe an unfamiliar problem, judge its urgency, provide useful evidence, understand what happens next, and sometimes act quickly to prevent additional damage.
Current Approach
I’m developing and testing a small pattern library for accessible service requests, beginning with a residential maintenance-reporting experience.
The experiment evaluates accessibility across five conditions:
• Perception — Can residents see, hear, or otherwise identify the information?
• Understanding — Can they interpret the language, choices, and consequences?
• Interaction — Can they complete the task using different input methods?
• Recovery — Can they recognize and correct mistakes without starting over?
• Pressure — Does the experience remain usable during stress, urgency, interruption, or limited attention?
The first prototype will include:
• Plain-language issue selection
• Keyboard and screen-reader navigation
• Large, clearly labeled interaction targets
• Alternatives to color-only status indicators
• Photo, voice, and text input options
• Save-and-resume functionality
• Emergency recognition and escalation
• Clear explanations of what happens next
• Accessible confirmation and status updates
The prototype will be evaluated through accessibility inspection, keyboard and screen-reader testing, high-zoom and reduced-vision scenarios, and task-based usability testing.
The goal is not to claim that one interface can satisfy every person or circumstance. The experiment asks whether designing for real conditions of use can produce patterns that are more resilient, understandable, and useful for everyone.Iteration Timeline
November 2025
Accessibility-First Components
The experiment began as a component library with accessibility requirements built into buttons, inputs, selects, modals, and other interface patterns instead of added during a final audit.
January 2026
Beyond Technical Compliance
Technical conformance does not automatically create an understandable or resilient experience. A component may support keyboard navigation and screen readers while still using confusing language, unclear choices, or difficult recovery paths.
August 2026
Designing for Conditions of Use
The experiment expanded beyond permanent disability classifications to examine the conditions in which accessibility can break down: stress, urgency, interruption, poor lighting, limited attention, unfamiliar terminology, temporary impairment, and mobile use.
August 2026
Maintenance Reporting Selected
Residential maintenance reporting was selected as the first test environment because residents must identify an unfamiliar problem, judge its urgency, provide useful information, and understand what happens next—sometimes while actively managing the issue.
In Progress
Accessible Request Flow
The current iteration is defining and prototyping six connected patterns: issue selection, problem description, evidence submission, emergency guidance, confirmation, and request status.
Planned
Testing Under Pressure
The prototype will be evaluated using keyboard navigation, screen-reader review, high-zoom and reduced-vision scenarios, interruption and save-and-resume testing, and task-based usability sessions.
Still evolving...
Current Insight
Accessibility is not only a characteristic of a person. It is also a relationship between a person, a task, an interface, and the conditions surrounding its use. Stress, urgency, interruption, unfamiliar language, poor lighting, injury, and limited attention can make an otherwise usable experience inaccessible. Resilient systems anticipate those conditions instead of assuming users will always arrive calm, focused, informed, and physically able.
Still Evolving
Open questions we're exploring:
- How should an interface communicate urgency without increasing fear or cognitive overload?
- Can emergency guidance be prominent without causing residents to classify routine issues as emergencies?
- Which input options provide genuine flexibility without creating more choices and complexity?
- How should voice, text, and photo submissions be translated into consistent information for maintenance teams?
- What should happen when a resident cannot identify or accurately describe the problem?
- How can the experience support multiple languages without relying on direct translations of technical terminology?
- Does simplifying the resident experience create additional interpretation work for the maintenance team?
- Which testing conditions can be simulated responsibly, and which require participation from people with lived experience?
Artifacts & Resources
Accessibility Under Pressure Model
A framework for evaluating service experiences across perception, understanding, interaction, recovery, and the pressures surrounding use.
Accessible Maintenance Request Ecosystem
A map showing how information moves among residents, property teams, maintenance coordinators, vendors, emergency services, and property records.
Resident Pressure-State Journey
A journey map documenting the resident’s questions, decisions, emotions, accessibility needs, and potential breakdowns from problem discovery through resolution.
Accessible Service Request Patterns
Six connected patterns covering issue selection, problem description, multimodal evidence, urgency guidance, confirmation, and request status.
Accessible Maintenance Reporting Flow
A mobile-first prototype designed for keyboard and screen-reader access, high zoom, plain-language comprehension, multimodal input, interruption recovery, and clear next steps.
Usability Under Pressure Test
A testing plan combining accessibility inspection with realistic task conditions such as interruption, limited input, reduced visibility, uncertainty, and time pressure.
Pattern Decisions and Accessibility Notes
Documentation explaining the purpose, expected behavior, accessibility considerations, limitations, and operational consequences of each pattern.
Related Experiments
Experiment Meta
Status
Active Experiment
Category
Tools
Last Updated
August 2026