Skip to main content

Life's Uncertain

so eat dessert first!

Target.com Voice Control Accessibility Test Plan

Voice Control Accessibility Test - Target.com

Assistive Technology: macOS Voice Control (no Head Pointer, no mouse, no keyboard) Site Under Test: target.com Test Type: Naive user task-based evaluation WCAG Standard: 2.2 Level AA (Target's stated compliance target) Tester: Sean Kelley Date:

Test Environment

  • Device: 2024 iMac M4
  • Operating System: macOS Sequoia
  • Browser: Safari
  • Assistive Technology: macOS Voice Control
  • Input Method: Voice only
  • No mouse
  • No keyboard
  • No Head Pointer
  • Screen recording software: ScreenFlow

Purpose of This Test

This evaluation measures how effectively a person with a motor disability can independently navigate and complete common e-commerce tasks using only voice input.

The goal is not only to identify WCAG failures, but to evaluate real-world usability, task completion, and functional access.

Testing focuses on:

  • discoverability
  • operability
  • accessible naming
  • timing barriers
  • form interaction
  • dynamic content behavior
  • user feedback and status messaging

This evaluation reflects lived user experience rather than automated compliance scanning.

Testing Methodology

I'm using a 2024 iMac running macOS Sequoia 15.7.4.

Testing is being performed in a private Chrome browser window to reduce the impact of cached sessions, saved preferences, browser extensions, and previously authenticated states.

I am unable to move below my shoulders, so all interaction during testing is performed using macOS Voice Control without the use of a mouse, keyboard, or Head Pointer.

This evaluation reflects real-world use of assistive technology by a person with a motor disability performing common tasks independently.

During testing you may hear several Voice Control commands used to interact with the interface.

Common Commands Used

"Start Listening"

Activates Voice Control command recognition.

A blue microphone icon appearing in the upper-right corner of the screen indicates that Voice Control is actively listening for commands.

"Click [element name]"

Attempts to activate buttons, links, form controls, or other interactive elements using their accessible name or visible label.

Examples:

  • "Click Search"
  • "Click Add to Cart"
  • "Click Checkout"

This method is generally the fastest and most efficient interaction path when accessible naming has been implemented correctly.

"Show Numbers"

Displays numbered overlays next to clickable and interactive elements.

This method is often used when:

  • accessible names are unclear
  • labels do not match visible text
  • Voice Control cannot reliably target an element directly

The user then speaks the visible number associated with the desired element.

While effective, this method introduces additional steps and increases interaction time.

"Show Grid"

Displays a numbered grid overlay across the screen to allow precise targeting through multiple spoken commands.

This is typically used as a fallback method when direct targeting and numbered overlays are unsuccessful or unavailable.

"Show Grid" frequently requires:

  • multiple spoken commands
  • additional navigation steps
  • repeated zooming into screen regions
  • greater cognitive effort
  • increased task completion time

Although tasks may still technically be possible using grid navigation, the additional complexity may represent a meaningful accessibility barrier.

Accessibility Perspective

Accessibility testing focuses not only on whether a task can eventually be completed, but whether it can be completed:

  • independently
  • efficiently
  • predictably
  • without excessive effort
  • without relying on workaround behaviors

A task that requires repeated retries, fallback interaction methods, timing workarounds, or unusually high cognitive effort may still present a significant accessibility barrier even if completion is technically possible.

Different users interact with technology in different ways. Testing with assistive technology helps evaluate whether digital experiences support real-world usability rather than minimum technical compliance alone.

Before You Hit Record

  • Close all other apps. Only Safari (or your browser of choice) and ScreenFlow should be running.
  • Make sure Voice Control is on and the microphone icon is visible.
  • Open a blank browser tab - you'll navigate to Target.com as Task 1.
  • When narrating, say what you're trying to do, what Voice Control command you're using, and what actually happens. That gap between intent and outcome is where the accessibility findings live.

Narration Structure

For each task, narrate the following:

  1. Goal
  • What you are trying to accomplish
  1. Action
  • The Voice Control command used
  1. Result
  • What actually happened
  1. Barrier
  • Whether the interaction caused friction, confusion, delay, or failure
  1. WCAG Connection
  • Which success criterion may apply
  1. POUR Principle
  • Perceivable
  • Operable
  • Understandable
  • Robust
  1. Severity
  • Minor
  • Major
  • Blocker

The difference between expected behavior and actual behavior is often where the accessibility finding exists.

The 10 Tasks

Task 1 - Navigate to Target.com and Orient

What to do: Say "Open Safari" (if needed), then use Voice Control to get to target.com. Once loaded, try to identify the main navigation areas using "Show numbers" or "Show grid."

What to narrate:

  • Can you identify distinct page regions (header, nav, main content, footer)?
  • Are interactive elements labeled clearly enough for Voice Control to target them?
  • This maps to WCAG 1.3.1 (Info and Relationships) - is the page structure communicated programmatically?

BIT connection: This is a Perceivable barrier check. You're evaluating whether the interface makes its structure available to assistive technology - the first principle of POUR.

Task 2 - Use the Search Bar to Find a Product

What to do: Locate the search field and search for "wireless headphones." Try saying "Click search" or "Click search Target" - whatever label seems right.

What to narrate:

  • Could you find and activate the search input by name?
  • Did the label match what's visible on screen? (Voice Control relies on accessible names.)
  • After typing, did autocomplete suggestions appear? Could you interact with them?
  • This maps to WCAG 2.4.6 (Headings and Labels) and 4.1.2 (Name, Role, Value).

BIT connection: This tests Operable - can a user with a motor disability actually operate the search function without a mouse?

Task 3 - Browse a Product Category via Navigation Menu

What to do: Without using search, try to browse to a product category (e.g., Electronics > TVs) using the main navigation menu. Use Voice Control commands like "Click Categories" or "Show numbers" to interact with dropdown/flyout menus.

What to narrate:

  • Do dropdown menus open with voice commands?
  • Can you reach submenu items, or do menus close before you can act?
  • Are there timing issues - does the menu disappear while you're speaking a command?
  • This maps to WCAG 2.1.1 (Keyboard) and 2.5.3 (Label in Name).

BIT connection: Flyout menus are one of the most common Operable barriers for motor disabilities. If a menu requires hover or fast mouse movement, it's a barrier for Voice Control users. Note whether this is a situational, temporary, or permanent barrier - all three categories from BIT coursework apply here.

Task 4 - Apply a Filter on Search Results

What to do: From your search results for "wireless headphones," try to filter by a criterion - price range, brand, or rating. Use voice commands to interact with filter controls (checkboxes, sliders, dropdowns).

What to narrate:

  • Can Voice Control identify the filter controls?
  • If there are checkboxes, can you say "Check [label]" and have it work?
  • Do sliders (like price range) respond to voice input at all?
  • This maps to WCAG 2.5.1 (Pointer Gestures) - are complex gestures (like dragging a slider) available through simpler alternatives?

BIT connection: Sliders and drag-based UI are a textbook Operable failure for users with motor disabilities. Document whether an alternative input method exists.

Task 5 - Open a Product Detail Page and Read Key Info

What to do: Select a product from results to open its detail page. Try to locate: price, product title, star rating, and the "Add to Cart" button.

What to narrate:

  • Are product images labeled with alt text? (Say "Show numbers" to check if images are interactive or decorative.)
  • Can you distinguish the main product info from ads, recommendations, or sponsored content?
  • Is the page reading order logical if you were tabbing through it?
  • This maps to WCAG 1.1.1 (Non-text Content) and 1.3.2 (Meaningful Sequence).

BIT connection: This is a Perceivable check. You're evaluating whether a user relying on assistive technology gets equivalent information to a sighted mouse user - the core principle behind equal access, not just compliance.

Task 6 - Add an Item to Cart

What to do: Try to add the product to your cart using Voice Control. Say "Click Add to Cart" or whatever the button text appears to be.

What to narrate:

  • Did the button label match what you expected to say?
  • After clicking, was there confirmation the item was added? (Visual-only confirmation like a brief animation is a barrier.)
  • If a modal or popup appeared, could you interact with it via Voice Control?
  • This maps to WCAG 4.1.3 (Status Messages) and 3.2.2 (On Input).

BIT connection: Status messages that rely only on visual cues fail Perceivable for screen reader users, but also create a Understandable barrier for Voice Control users - if you don't know the state changed, you don't know what command to give next.

Task 7 - View and Modify the Cart

What to do: Navigate to your cart. Try to change the quantity of the item (increase to 2), then try to remove it.

What to narrate:

  • Can you find and activate the quantity controls?
  • Are the increase/decrease buttons labeled (or are they just "+" and "-" icons with no accessible name)?
  • Can you say "Click Remove" to delete the item?
  • This maps to WCAG 4.1.2 (Name, Role, Value) and 2.5.3 (Label in Name).

BIT connection: Icon-only buttons without accessible names are a barrier across multiple disability categories - motor (Voice Control can't target them), visual (screen readers can't announce them), and cognitive (unlabeled icons can confuse). This is the kind of finding that demonstrates intersectional barriers from your BIT coursework.

Task 8 - Attempt the Checkout Flow (Without Completing Purchase)

What to do: Click "Check Out" and see how far you get into the form flow without entering real payment info. You're testing the form, not buying anything.

What to narrate:

  • Can Voice Control fill in form fields? (Say "Click First Name" or "Click email.")
  • Do form fields have visible labels that match their accessible names?
  • Are error messages announced or only shown visually?
  • Are there any CAPTCHAs or verification steps that block Voice Control?
  • This maps to WCAG 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), and 1.3.5 (Identify Input Purpose).

BIT connection: Checkout is the most critical user journey in e-commerce. If a person with a motor disability can browse and add to cart but can't complete checkout, the entire experience fails. This is where functional access vs. technical compliance diverges - a distinction emphasized in BIT training.

Task 9 - Find the Store Locator and Search for a Nearby Store

What to do: Navigate to Target's store locator. Enter a zip code (use 92868) and try to find a nearby store's hours and address.

What to narrate:

  • Can Voice Control find the store locator link?
  • Can you enter a zip code into the input field?
  • Are results presented in a way you can navigate - or is it a map-only interface?
  • This maps to WCAG 2.1.1 (Keyboard) and 1.1.1 (Non-text Content) (if map is the only output).

BIT connection: Map-based interfaces that lack text alternatives are a barrier across the visual and motor disability categories. This task tests whether Target provides equivalent alternative access or forces users into an inaccessible interaction pattern.

Task 10 - Find and Review the Accessibility Statement

What to do: Locate Target's accessibility statement (usually in the footer). Read through it and note what assistive technologies they claim to support.

What to narrate:

  • Was the link easy to find?
  • Does the statement mention Voice Control or voice recognition software specifically?
  • Do they reference WCAG 2.2 Level AA?
  • Based on your experience in Tasks 1 - 9, does their statement match reality?
  • This maps to WCAG Conformance Requirement expectations for accessibility statements.

BIT connection: This brings it full circle. You've just tested the site as a real user with a motor disability using Voice Control. Now compare your lived experience against their published claims. The gap - if there is one - is the finding. This is what user-centered accessibility testing means, and it's the core value you bring as a tester with a disability.

Overall Evaluation Notes

Independent Task Completion

  • Which tasks could be completed without assistance?

Friction Points

  • Which interactions slowed task completion but were still possible?

Blocking Barriers

  • Which issues prevented task completion entirely?

Voice Command Predictability

  • Were labels intuitive and easy to target with speech input?

Timing Issues

  • Did menus, overlays, or dynamic elements disappear before interaction could occur?

Error Recovery

  • Could mistakes be corrected independently?

Cognitive Load

  • Did the experience require memorization, guessing, or excessive retries?

Accessibility Strengths

  • What worked well?

Accessibility Weaknesses

  • What consistently failed?

Final Assessment

  • Could a Voice Control user independently complete a purchase on this website?

After You Stop Recording

Things to note while it's fresh:

  1. Which tasks could you complete independently?
  2. Which tasks had barriers - and were they total blockers or just friction?
  3. Were Voice Control command names predictable, or did you have to guess?
  4. Did you hit any timing-based barriers (menus closing, sessions expiring)?
  5. What POUR principle was violated most often?

If you write this up later, structure findings as:

  • Barrier: What happened
  • Location: Where on the site
  • WCAG Criterion: Which success criterion applies
  • Severity: Blocker / Major / Minor
  • POUR Principle: Which principle it falls under
  • Recommendation: What would fix it