Accessible workstation case: what the two-week trial actually settled

What to take away

This accessible workstation case shows a fictional decision process, not a universal accommodation or legal conclusion. The general form of that process is the accessible technology guide. The right setup depends on the individual, the job, the technology, and the applicable organization and law.

The request

Maya, an experienced customer-support agent with low vision and fluctuating hand fatigue, was moving to a new ticketing platform. She already used enlarged text, keyboard shortcuts, and occasional speech output. The new system required more pointer use, displayed status through color, and opened dense customer records in side panels.

Maya asked for a workflow she could use throughout an eight-hour shift without repeated help. Her manager invited her, an accessibility specialist, IT, and the platform owner to define a trial. The group recorded which information was private and agreed that Maya would control any voice or remote-support features.

Task map

They broke the job into observable tasks:

They also tested a mistaken field entry, a dropped headset connection, and a full restart. Restart, sleep, and wake belong on the acceptance list for any new machine.

Communication and choice

The manager did not ask Maya to supply her own helper or accept whichever product IT already stocked. The team discussed the nature and complexity of each interaction and Maya's normal methods before selecting trial tools.

A benchmark existed for the technology itself. The U.S. Access Board's ICT accessibility standards require covered hardware, software, and support services to be accessible to and usable by people with disabilities, directly or through assistive technology.

They fold in WCAG requirements for digital content, and those standards bind federal agencies and telecommunications manufacturers rather than this employer. The team used them as a measuring stick for the platform, not as a workplace ruling.

The two-week trial

IT created a test account with representative, noncustomer data. Maya tried NVDA and JAWS as screen readers, Windows Magnifier and ZoomText for enlargement, built-in speech output for long records, keyboard-only navigation, and an accessible TOTP-based multi-factor authentication flow:

The specialist taught only the commands needed for the trial tasks, then expanded training after Maya chose the promising setup. Maya recorded fatigue, completion time, errors, and assistance after morning and afternoon sessions.

What failed

At 200 percent scaling, the ticket side panel covered the Save button. NVDA announced most fields but called the escalation selector only "button," and one wireless Bluetooth headset lost connection after sleep.

Separating an accessory fault from a machine fault follows the same isolation method used in common laptop problems and fixes. The platform's high-priority state relied on red text despite the active operating-system contrast theme.

The team did not label these Maya's training problems, but the platform owner fixed the selector label and added text to the priority state. IT chose the reliably reconnecting Bluetooth headset and created a documented wired USB fallback.

Maya used a mixed approach: Windows Magnifier at 200 percent for scanning lists and NVDA speech output for long histories. Combining a magnifier with speech is one of the pairings weighed in assistive tools compared.

Selecting and supporting the equipment

The team compared effectiveness, comfort, compatibility, privacy, training, repair, and replacement. NVDA paired with Windows Magnifier won on keyboard-only support and zero license cost; ZoomText offered smoother scaling but added a commercial license and a steeper learning curve. They avoided treating the first successful demonstration as final acceptance. Those categories, item by item, are the accessible technology checklist.

This is the shape of a reasonable accommodation under Title I of the Americans with Disabilities Act, enforced by the Equal Employment Opportunity Commission. For federal employers, Rehabilitation Act Section 501 applies; for federally funded programs, Section 504. It adjusts the job or work environment so a qualified employee can perform the position's essential functions, worked out for the individual rather than pulled from a stock list.

Defining the situation, researching options, trialing the technology, arranging training, and monitoring the result gave that adjustment its evidence.

IT stored the approved display profile and keyboard settings in the managed account. Maya kept an accessible command reference. The support ticket identified the workstation, software versions, headset model, access tools, and preferred contact method without adding unnecessary medical detail.

Final plan

The signed-off plan included NVDA at a custom speech rate, Windows Magnifier at 200 percent for scanning, the wired USB headset as primary audio with Bluetooth as secondary, accessible TOTP authentication, a documented error-recovery script, and quarterly review ownership:

Maya completed every acceptance task without prompting during the final test. The team retained the fault log because it showed which platform defects might affect other employees and customers. A safe order for working through such faults is in accessibility feature problems and fixes.

Lessons from the case

Common questions

Is Maya a real person?

No. The case is fictional and combines common planning and testing issues.

Why did the team test with noncustomer data first?

It allowed realistic workflow testing without exposing live customer information during setup and training.

Did the screen reader solve every barrier?

No. The team also fixed application labels, added non-color status text, changed hardware, and used magnification.

Is this a legal accommodation template?

No. Organizations should apply the law, policy, and qualified advice relevant to their location and situation.