Guidepup Setup

Documentation

This package sets up your environment for screen reader automation.

It enables automation for VoiceOver on MacOS and NVDA on Windows.

Getting Started

Run this command:

npx @guidepup/setup

And get cracking with your screen reader automation code!

Usage

GitHub Actions

If you are using GitHub Actions, check out the dedicated guidepup/setup-action:

- name: Setup Environment
  uses: guidepup/setup-action

MacOS

If you are running this command locally you may need to take some manual steps to complete setup by following the manual VoiceOver setup documentation.

CI

If you are running this command in CI/CD, it is recommended to add the --ci flag to prevent interactive prompts:

npx @guidepup/setup --ci

Ignore TCC.db Updates

If updating the TCC.db is not possible (due to SIP) or required you can skip the database update step by using the --ignore-tcc-db flag:

npx @guidepup/setup --ignore-tcc-db

[!NOTE] If the necessary permissions have not been granted by other means, using this flag may result in your environment not being set up for reliable screen reader automation.

Recording

If you are encountering errors in CI for MacOS you can pass a --record flag to the command which will output a screen-recording of the setup to a ./recordings/ directory:

npx @guidepup/setup --ci --record

Windows

NVDA Installation

When running on windows a portable NVDA instance compatible with Guidepup will be installed to a temporary directory by default. The location of this installation directory is stored in the Windows registry under the key HKCU\Software\Guidepup\Nvda.

If you want to specify the directory that NVDA is installed to you can pass a --nvda-install-dir flag to the command:

npx @guidepup/setup --nvda-install-dir <NVDA_INSTALLATION_DIRECTORY>

Using HTTP / HTTPS Proxy for Installation

If you are using a proxy connection, you must define the proxy URL in an env variable. You can use any of the following variables:

• HTTPS_PROXY
• https_proxy
• HTTP_PROXY
• http_proxy

Foreground Timeout Lock

Modern versions of Windows have a setting which prevents new application instances launching in front of other applications in quick succession, requiring over 3 minutes between activations before it will actually show the window - in the interim it launches the window minimized.

Many test automation frameworks will completely close down a browser after a test has finished and then launch a new instance for the next test - on Windows this suffers from the timeout lock on foreground windows. This impacts on screen reader automation which need the window to activate and focus to be able to drive the screen reader on the application.

To mitigate this the setup script updates two keys in the Windows registry under HKCU\Control Panel\Desktop:

• ForegroundLockTimeout - Specifies the time in milliseconds, following user input, during which the system will not allow applications to force themselves into the foreground. Defaults to 200000.
• ForegroundFlashCount - Determines the number of times the taskbar button will flash to notify the user that a background window has been activated by the system. If the time elapsed since the last user input exceeds the value of ForegroundLockTimeout, the window will automatically be brought to the foreground. Defaults to 3.

Both of these are set to 0 by the setup script.

Powerful Tooling

Check out some of the other Guidepup modules:

• @guidepup/guidepup - Reliable automation for your screen reader a11y workflows through JavaScript supporting VoiceOver and NVDA.
• @guidepup/playwright - Seamless integration of Guidepup with Playwright.
• @guidepup/virtual-screen-reader - Reliable unit testing for your screen reader a11y workflows.
• @guidepup/jest - Jest matchers for reliable unit testing of your screen reader a11y workflows.

Resources

• Documentation
• Contributing
• Changelog
• MIT License