New issue
Advanced search Search tips

Issue 918270 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
dmazz...@chromium.org
chrome-perf-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Accessibility support enabled on Windows with HiDPI screens

Project Member Reported by cnardi@chromium.org, Dec 30 
Seems related to  bug 878072  and  bug 876605 . I'm using Windows 10 with a laptop that has a 4K display, and I noticed browsing Twitter was fairly slow. A look at tracing revealed loads of time spent in RenderAccessibilityImpl::SendPendingAccessibilityEvents. chrome://accessibility/ showed sure enough, native and web accessibility was enabled.

I suspect this has to do with my HiDPI screen. Everything is zoomed 250% as recommended (not via Magnifier, but I'm not sure if Windows makes a distinction in how that zoom is implemented). I bet the heuristic is turning on accessibility modes because of the zoom.

Comment 1 by brucedaw...@chromium.org, Jan 9 

dmazzoni - is there a way to find out what is turning on accessibility? DPI seems possible, but far from certain, and it would be good to know. HiDPI is becoming increasingly common (lots of small 4K laptop displays) so I'm sure that HiDPI by itself cannot be a reliable trigger.

Comment 2 by dmazz...@chromium.org, Jan 15 

We only enable accessibility if some other program tries to access Chrome via accessibility APIs, we don't use any other heuristics like HiDPI. I'm not aware of anything related to HiDPI, but I have seen us trigger based on certain touch screens.

I've been closely monitoring logs, I haven't seen any spikes in the percentage of users with accessibility enabled lately. We had a spike over the summer that seemed to be caused by something in the latest Windows update, so we mitigated it.

Comment 3 by cnardi@chromium.org, Jan 18 (4 days ago) 

I also have a touch screen on the laptop, so perhaps that is it.
►

Sign in to add a comment