#95 didn't do this because of the complications mentioned in #91 (comment) for multi-page sites/apps.

However there may still be a way to do this if only the zoom level scale (given by window.visualViewport.scale) is reported.

Still need to deal with it changing while on a page, but maybe that plus incorporating the current value could work somehow

Here's a list of various forms to consider

• Pinch zoom
• Page-level zoom ("Ctrl scroll")
• Browser-default font-size
• Browser-default zoom level
• External assistive technology

This seems possible for pinch-zoom using window.visualViewport.scale and for page-level zoom using window.devicePixelRatio. Both could be measured on page load and then polled for changes that would indicate use of the features.

Browser settings around default font size can be detected by measuring the font-size of elements (e.g. window.getComputedStyle(document.body).getPropertyValue("font-size") will be different depending on the browser default font size). Need to be careful about forcing a layout with this (if done before or after app styling comes in to play)

I have not yet found anything that could detect browser settings around default zoom.

Any use of external assistive technology (e.g. magnifier, ZoomText) will be undetectable

Probably something with Vitest (run in Deno) and happy-dom.

Failing that, using substantial custom mocks of the DOM environment and more unit-like tests.

For example, if a user uses multiple input modes, starting with the keyboard for navigation then switching to using a pointer input (e.g. a mouse).

This could be helpful for filtering out such users to focus in on "keyboard"-only users.

Recording new parameters for when pointer events happen (and combining them with the keyboard detection parameter) might make sense here