IoT Interfaces, Location and Privacy · Study deck

Accessible IoT Interfaces: Adaptation and Device Sync

An interface can meet its WCAG and adaptation duties on one screen yet still fail when a person moves between a phone, display, voice device, and physical control.

UX Uma is your guide for this deck.

accessibilitymultidevice

After studying this chapter

Learning objectives

You will be able to:

Explain: Key Insight: In this hypothetical model, $35,000 of accessibility work could avert $448,000 in gross return costs and yield $413,000 net if the assumed 46-point return-rate reduction occurs.
Explain: Automated accessibility checks find some machine-detectable issues, such as missing alt text or contrast failures, but cannot establish complete conformance or usability for disabled users.
Explain: Automated result: No errors found in the tested rules; a knowledgeable human review and user testing are still required to assess WCAG AA conformance. (W3C).
Explain: Cost per unit: $50 refund + $18 support + $12 restocking = $80.

Major section

Multi-Device Experiences

Each surface should show the same final state even though its control and feedback differ.

A delayed subscriber must remain pending or stale rather than displaying an old value as current.
Version, time, and activity history give support staff the evidence to resolve that conflict.
The device publishes OFF.

Multi-Device State Synchronization and Consistent Terminology

Major section

Multi-Device Experiences (continued)

In this drawn example, the broker stores a retained message and forwards OFF to the app and dashboard.

A screen that has not processed the latest reported state should show pending or stale.
The tablet has room for side by side cards and a small chart, while the watch keeps only a compact glance and action.
These layouts change the amount of detail, not the meaning of the underlying state.

State Synchronization Sequence: a device publishes OFF through an MQTT broker to a mobile app and dashboard; the diagram shows UI updates and QoS 1 packet acknowledgments without a timing guarantee.

Major section

Deep dive: Accessible Medication Dispensers

WCAG 1.4.3: Contrast (Minimum): FAIL Text: Light gray (#CCCCCC) on white background.

Contrast ratio: 1.6:1 (needs 4.5:1 for WCAG AA).
Impact: 85% of elderly users can't read text.
Cost: 12-minute average support calls for "can't see instructions".

Major section

Deep dive: Accessible Medication Dispensers (continued)

Modeled result in the medication-dispenser design scenario: 70% of users with arthritis mis-tap wrong buttons; this is not observed user data.

WCAG 1.4.1: Use of Color: FAIL Medication slot colors: Red/green indicators (color-blind unfriendly).
Modeled result in the medication-dispenser design scenario: 8% of users cannot distinguish slots; this is not observed user data.
Modeled scenario: the alert is one 65 dB tone; 45% of users miss doses.

Major section

Deep dive: Accessible Medication Dispensers (continued)

Modeled result in the medication-dispenser design scenario: 45% of users miss medication reminders; this is not observed user data.

Hypothetical 10,000-unit business model: Treat all before/after return and retention rates, costs, and savings below as assumptions, not product-cohort outcomes.
Reason: "Too hard to use," "Can't see screen," "Buttons too small".
Cost per unit: $50 refund + $18 support + $12 restocking = $80.

Major section

Deep dive: Accessible Medication Dispensers (continued)

After (Accessible Design): Assumed customer return rate: 11%; do not describe this as normal for electronics.

Modeled net avoided return cost: $413K ($448K gross avoided returns − $35K redesign cost), conditional on the assumed return-rate change.
Key Insight: In this hypothetical model, $35,000 of accessibility work could avert $448,000 in gross return costs and yield $413,000 net if the assumed 46-point return-rate reduction occurs.
The return and retention inputs are not observed product outcomes.

Major section

Deep dive: Multi-Device UX Consistency

Key Insight: Consistency in terminology and data (state sync) enables users to switch devices seamlessly.

✗ Mistake 2: Making Voice Assistant Do Everything.
But interface design should leverage each platform's strengths—cramming a desktop interface onto a smartwatch creates terrible UX.
Design hierarchy: Smartphone = full-featured primary, Watch = glanceable quick actions, Web = detailed analytics, Voice = hands-free simple commands, Physical = works offline.

Responsive Design Patterns Across IoT Device Types

Major section

Deep dive: Beyond Automated Accessibility Tests

Issue: Buttons meet the 44×44 CSS px design target but are spaced only 2 device units apart.

The Mistake: Running automated WCAG checkers (WAVE, axe, Lighthouse) and assuming 100% pass rate means the product is accessible to disabled users.
Impact: User has no idea what icon represents (settings? Help? Close?).
Assumed: Product is accessible.

Major section

Deep dive: Beyond Automated Accessibility Tests (continued)

Issue: Video tutorials have auto-generated captions with errors in this fictional audit.

Automated accessibility checks find some machine-detectable issues, such as missing alt text or contrast failures, but cannot establish complete conformance or usability for disabled users.
Impact: User can't distinguish error text from normal text.
Who: Accessibility specialist (CPACC/WAS certified).

Major section

Deep dive: Beyond Automated Accessibility Tests (continued)

Limitations: Expert isn't actual disabled user, may miss real-world issues.

Automated Tool Results (WAVE): ✓ All images have alt text. ✓ Color contrast meets 4.5:1 ratio. ✓ Form inputs have labels. ✓ Heading hierarchy correct.
Best Coverage: Reveals real-world usability issues automated tools can't detect.
Task success rate (did they complete it?).

Major section

Deep dive: Beyond Automated Accessibility Tests (continued)

Automated result: No errors found in the tested rules; a knowledgeable human review and user testing are still required to assess WCAG AA conformance. (W3C).

In this fictional test, assume 18 issues that automated checks did not find; a real count requires a tracked audit.
In the hypothetical redesign, assume the return rate falls to 12%; do not call 12% a normal electronics rate.
Modeled avoided return cost: $276,000 (about $280,000 rounded), conditional on the assumed 58% to 12% return-rate change.

Deck summary

Key takeaways

Each surface should show the same final state even though its control and feedback differ.

In this drawn example, the broker stores a retained message and forwards OFF to the app and dashboard.
WCAG 1.4.3: Contrast (Minimum): FAIL Text: Light gray (#CCCCCC) on white background.
Modeled result in the medication-dispenser design scenario: 70% of users with arthritis mis-tap wrong buttons; this is not observed user data.
Modeled result in the medication-dispenser design scenario: 45% of users miss medication reminders; this is not observed user data.

Retrieval practice

Recall check 1 of 4

UX Uma says: answer from memory, then check your reasoning.

Q1Your industrial IoT system monitors 500 sensors across a factory. Engineers need to view real-time trends, configure complex automation rules, and analyze historical data. Should you prioritize mobile app or web dashboard development, and why?

APrioritize WEB DASHBOARD for dense trends, precision input, and analysis

BPrioritize MOBILE APP - smartphones are ubiquitous and engineers can monitor on the go

CBuild identical interfaces for both - consistency is most important

DSkip both and use only voice interface - hands-free is future of IoT

Show answer

Answer: A The stated engineering tasks favor a web dashboard with enough display area and precise input for trends, rule configuration, and history.

Retrieval practice

Recall check 2 of 4

UX Uma says: answer from memory, then check your reasoning.

Q2A user in a verified room says 'Turn off the lights' to that room's smart speaker in a home with lights in 12 rooms. The product's documented rule uses this room for unqualified light commands and announces the chosen room. How should the voice interface handle this request?

ATurn off ALL lights in the entire home - user said 'lights' (plural)

BDo nothing and respond 'Command too ambiguous, please specify room name'

CPresent a menu: 'Say 1 for bedroom, 2 for kitchen, 3 for all lights...' listing all 12 rooms

DUse CONTEXT to disambiguate - turn off lights in the room where user is located

Show answer

Answer: D The verified room and documented rule resolve this unqualified request to the local lights.

Retrieval practice

Recall check 3 of 4

UX Uma says: answer from memory, then check your reasoning.

Q3You're designing a smart home app for smartwatches and tablets. A tested indoor location signal identifies the user's current room, and the tablet can show all 15 rooms. How should the smartwatch use that reliable room context?

AShow only the CURRENT room (detected by location) with most-used actions, plus quick access to 'Favorites'

BShow all 15 rooms in a scrollable list - users expect feature parity across devices

CRemove room controls entirely and only show notifications - watches are for reading, not interaction

DUse the same tablet interface but with smaller fonts to fit the watch screen

Show answer

Answer: A The tested room signal lets the watch lead with that room's status and useful quick actions, while Favorites offers an explicit route elsewhere.

Retrieval practice

Recall check 4 of 4

UX Uma says: answer from memory, then check your reasoning.

Q4What equivalent interaction methods let people express the same intent across devices?

AAccessible Input Choices

BShared Cross-device State

CRedundant Output and Recovery

Show answer

Answer: A Learners need an equivalent way to express the same intent.

Q5Complete the IoT dashboard widget creator with DOM manipulation:

Aconst widget = document.createElement('div');

Bconst widget = document.newElement('div');

Cconst widget = document.querySelector('div');

Dconst widget = new Element('div');

Show answer

Answer: A document.createElement() creates DOM elements. innerHTML with template literals allows dynamic HTML content.

Print reference

Answers 1 of 2

Answer key.

A · The stated engineering tasks favor a web dashboard with enough display area and precise input for trends, rule configuration, and history.
D · The verified room and documented rule resolve this unqualified request to the local lights.
A · The tested room signal lets the watch lead with that room's status and useful quick actions, while Favorites offers an explicit route elsewhere.
A · Learners need an equivalent way to express the same intent.

Print reference

Answers 2 of 2

Answer key.

A · document.createElement() creates DOM elements. innerHTML with template literals allows dynamic HTML content.