Vendor Blind Spot
Status: ready
Symptom
"That's a vendor screen, we don't control it." The user still meets that screen in the middle of the task and gets stuck there.
Flow: pay for city parking
Broken part: payment vendor web view
Team: not our app
User: can't pay
Where it shows up
Payment SDKs, identity verification, appointment calendars, insurance portals, maps, support chat, CAPTCHA, embedded web views, white-label modules.
Why it blocks the task
For the user there's no line between our code and the vendor's. The task works or it doesn't. The vendor screen is often exactly the critical step: payment, identity, booking.
Legally, outsourcing doesn't remove the obligation either. The ADA Title II rule covers content a public entity provides through contractors and vendors, and uses a parking payment app as an example. Commercial apps have a different legal structure, but the product lesson is the same: the vendor isn't outside the task evidence.
Regulatory brief
ADA Title II:
a public entity may use a vendor app,
the service still has to be accessible
Web Accessibility Directive:
an embedded vendor flow that's part of a public service is in scope
European Accessibility Act:
a covered service can't exclude its payment, identity or ticketing vendor
Legal decides liability. Product still has to prove the task works.
Root cause
- Procurement asked for a checkbox or a generic report, not task evidence.
- The vendor's report was never replayed on our flows.
- The SDK or web view was left out of the QA plan.
- Support has no route for vendor accessibility bugs.
- The release decision treats the vendor screen as out of scope.
Before
Task: book an appointment
Vendor screen: calendar
Evidence: vendor says it's accessible
Our test: skipped
Decision: ship
Fix
Verdict: vendor screens are in the walkthrough of every task they're part of, with the same profiles as our own screens. A failure is our blocker, with a vendor fix or an alternative path.
Why: the user's task is what's tested. Who wrote the screen decides who fixes it, not whether it's tested.
Task: book an appointment
Screen owner: vendor calendar
Profile: VoiceOver
Result: fail
Actual: time slots read as "button, button, button"
Decision: blocker
Next: vendor fix, or an accessible booking path we own
Vendor acceptance criteria for the contract:
1. Our critical tasks pass with VoiceOver and Larger Text AX5.
2. The SDK exposes labels, values, traits and errors.
3. An embedded web view works with VoiceOver and a keyboard.
4. Accessibility bugs have an owner and a fix time.
5. An alternative path exists for blockers.
If the vendor provides only a web report and we embed a native SDK, we ask for native evidence too.
Check
Profile: release review
Task: every critical flow that includes a vendor screen
Expected: the vendor screen is in the walkthrough
evidence attached per profile
the owner and the fallback path are named
WCAG mapping
Vendor reports usually use WCAG. Keep the mapping, and replay the task on iOS.
App Store and product risk
If the app claims VoiceOver or Larger Text support, tasks that go through vendor screens need the same evidence. Otherwise the label drifts even when every first-party screen is clean.
Related patterns
- Regulatory Evidence Map
- Compliance Ready PR
- Testing Evidence Record
- Evidence Based Release
- Platform Interaction Contract