Check Web MIDI support before an accessibility audit

Before an accessibility audit, check that the browser can access Web MIDI and that the connected controller sends the input your app expects. A browser may support the feature while a permission setting, device connection, or app control still blocks the workflow.

Use Browser Info to check browser capabilities, then use MIDI Test to verify input from a real keyboard or controller. Treat these as setup checks, not as proof that the app is accessible.

Check Web MIDI availability

1. Open Browser Info in the same browser and on the same computer you plan to use for the audit.
2. In its supported features, look for Web MIDI support. Note the browser name, version, and engine along with whether the feature is reported as supported.
3. Connect the MIDI keyboard or controller you will use. If it was connected before the browser opened, reload the page after connecting it.
4. Open MIDI Test and allow access if the browser asks for permission.
5. Press several keys, including a soft and a firm press. Turn a knob or move a slider if the device has one, and press and release the sustain pedal if you will use it.
6. Check whether MIDI messages appear and whether key velocity, controller changes, and pedal activity are represented. Record which actions worked and which did not.

MIDI Test does not work in Safari. If you are auditing a Safari workflow, record that limitation and test the same task in the intended browser or with the app's documented fallback. Do not change browsers without noting it, because the audit should reflect the environment people actually use.

What the results mean

Web MIDI is supported and the controller sends messages

The browser can access Web MIDI, and the tested device is producing input the test can receive. This confirms the basic browser and device path. It does not show whether an app explains the controls, communicates state to assistive technology, or offers an alternative to using a physical controller.

Web MIDI is supported, but no messages appear

The browser reports support, but the test is not receiving the actions you tried. Check that the device is connected, selected if more than one device is available, and not being held by another app. Try a different key or control. A feature support report does not confirm that a particular device is working.

Web MIDI is not reported as supported

The current browser may not provide the feature, or its privacy settings may limit what the page can detect. Check the browser version and test again in a current browser that supports Web MIDI. Keep Safari's known limitation in mind: MIDI Test does not work there.

The test works, but the app does not

The browser and controller can communicate, so look at the app's connection flow, selected MIDI input, and controls. The app may not request access at the right time or may not explain what to do when access is denied. Test the app separately rather than treating the MIDI Test result as an accessibility pass.

Prepare the audit setup

1. Allow access for the correct site. If you denied a permission prompt, open the browser's site controls beside the address bar, change the MIDI permission if it is listed, then reload and test again. Permission names and controls vary by browser.
2. Close other MIDI software. Quit music software or device utilities that may be using the controller, then reconnect it and repeat the test. If you use a USB hub, try a direct port to rule out the hub or cable.
3. Check the device outside the browser. Confirm that the operating system or another known MIDI app can see the controller. If it is missing there too, check its cable, power, USB connection, and manufacturer setup instructions.
4. Test the task with a keyboard and screen reader. On Windows 11, review Settings › Accessibility › Narrator. On macOS, review System Settings › Accessibility › VoiceOver. Turn on the screen reader you use for the audit, then check whether the app's focus, instructions, and status changes are understandable without relying on MIDI input alone.
5. Check system accessibility settings. On Windows 11, open Settings › Accessibility. On macOS, open System Settings › Accessibility. Use the settings needed for the audit, such as keyboard access or larger text, and verify that the app remains usable with them enabled.
6. Document a fallback. If Web MIDI is unavailable or permission is declined, check whether the app offers another way to complete the task, such as an on-screen control or keyboard input. If there is no usable alternative, record the barrier rather than assuming the user can switch devices or browsers.

Separate feature support from accessibility

Web MIDI support answers a narrow question: can this browser expose MIDI input to a web page? An accessibility audit asks more. Can someone discover the controls, understand their purpose, operate the task with their preferred input method, and tell what happened afterward?

Test the app with the controller disconnected, with permission denied, and with a screen reader active. Check that instructions do not depend on color or sound alone, that controls have clear names, and that important changes are communicated in a way assistive technology can detect. A MIDI message arriving successfully does not answer any of those questions.

Record the browser and version, operating system, controller, permission choice, test actions, and any fallback used so another auditor can repeat the setup.