CSS custom cursor does not scale according to Windows a11y Ease of Access pointer size
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
| Accessibility Severity | s3 |
People
(Reporter: mozbugzilla2021, Unassigned)
References
()
Details
(Keywords: access, testcase)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
- Go to Windows Settings -> Ease of Access -> Cursor & Pointer
- Increase pointer size
- Load test case at https://jsfiddle.net/snover/h8ub1f2n/show/
Actual results:
Custom CSS cursor drawn at original scale regardless of Ease of Access setting
Expected results:
Custom CSS cursor scaled to match system cursor scaling
By contrast, on macOS, changing the Accessibility -> Display -> Cursor size preference correctly scales custom CSS cursors.
The actual user agent tested was Firefox 72.0.1 on Windows 10 1909.
This same problem exists in Chrome, filed bug https://bugs.chromium.org/p/chromium/issues/detail?id=1042980 there.
Updated•6 years ago
|
I’m not a Windows developer so I don’t have any deep knowledge of platform APIs but I did some digging to try to help this along.
First, I looked through the Windows a11y API docs and didn’t find anything to get the EoA pointer size setting. Second, I looked at the Win32 cursor and system metrics APIs to see if there was anything there and, again, found nothing obviously related. So, I fell back to the registry.
On at least Win 10 1903, HKCU\SOFTWARE\Microsoft\Accessibility\CursorSize holds the setting in the UI (from 1 to 15), and HKCU\Control Panel\Cursors\CursorBaseSize seems to describe the system cursor size in pixels with the accessibility setting applied (so 1 = 32, 2 = 48, 3 = 64, … 15 = 256). I assume the formula used is just RawCursorSize + (AccessibilityCursorSize - 1) * RawCursorSize / 2.
As such, in order to scale to the EoA setting on Windows 10, it seems like CursorForImage could just query HKCU\SOFTWARE\Microsoft\Accessibility\CursorSize and, if the key exists, apply the scaling formula.
Earlier versions of Windows without the pointer size slider only have the ability to change the system cursor icon files, and the bigger ones are just larger drawings within the same 32x32 tile, so I don’t see any good way to handle these OS versions. That said, while checking the filename in e.g. HKCU\Control Panel\Cursors\Arrow would be a substantial hack, it also seems like it might not be unreasonable to do since it would probably cover >99% of cases where someone needs a larger cursor size on those older versions.
Unfortunately I don’t have a suitable compilation/testing environment to complete a working patch (I’ve been borrowing other computers to do testing) but I hope that getting this research out of the way makes it easy for someone with a compatible environment to implement something, if the approach described here doesn’t seem totally crazy, since this is a problem affecting real users today.
Comment 3•6 years ago
|
||
The priority flag is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 4•6 years ago
•
|
||
Posted to our internal Microsoft list asking for guidance. I wasn't able to find a desktop API that provides this, and I don't like the idea of digging around in the registry if we can avoid it.
Updated•6 years ago
|
I agree that querying the registry is a last ditch solution. Have you heard back on the internal Microsoft list about any intended way for software to generate cursors of the correct size? Any information you’ve received I will pass along to the corresponding Chromium ticket. I expect this will be at most a few lines of code to fix, once the path forward is clear. Thanks!
Checking in again to hear back about that internal Microsoft list response. If you could, please let me know what’s happening. Thanks!
Updated•5 years ago
|
I’ve tried corresponding with the MSFT Accessibility Twitter account directly since June and have hit a wall getting any more information. They told me that only CreateCursor (which is 1-bit only), LoadCursor, LoadCursorFromFile, and LoadImage support EoA, so the best I’ve got for a ‘blessed’ solution right now is to write the bitmap out to a .cur file on disk and then load it back in by LoadCursorFromFile, which is unpleasant. More recently, I incidentally discovered someone on HN who works directly on the Windows a11y team, and sent them an email today to see if they can help any more.
Updated•3 years ago
|
Comment 8•3 years ago
|
||
The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:spohl, could you consider increasing the severity?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•