There's a lot of content out there on how to make your website accessible. But I haven't seen much on the subject of accessibility to users of screen magnifiers. I'm one of them, and I frequently run into annoying issues on the web.
In this article, I'll give some tips on how you can make your website more accessible to users of screen magnifying software.
Disclaimers:
- This article is purely based on years of using the web with a screen magnifier. I have conducted no user research (I'd love to see the results of such studies though).
- I'm only going to discuss my experiences on the desktop, not mobile. While I do occasionally use the screen magnifier built into IOS, a mobile screen is so small that there's so little content on the screen when magnified to the desired level for me, that I usually prefer to use VoiceOver.
- Whereas making websites more accessible to screen readers is always a win since it doesn't alter the visual appearance of the site, making it accessible to users of magnifiers might be a balancing act. I'm not a designer, and so I might be arguing for things in this article that would improve the experience for the people using magnifiers, but would be worse for the 99% of your visitors who are fully-sighted. In such cases, please leave a comment, I'd love to know about these.
What's a screen magnifier
A screen magnifier is a piece of software that magnifies the screen (how unexpected!) It displays a portion of what would be on the screen, enlarged, either on the full screen, or on a region of the screen, leaving the rest unmagnified.
As an example, here's what it looks like for me to browse the articles on the home page of this site:
Moving the magnifier around the screen
Because the screen is being magnified, obviously not all of it will be visible on the display, so you move a sort of virtual rectangular magnifying glass around the screen as you move the mouse. On macOS, there are 3 options for how the movement of the magnifier relates to mouse movement, as illustrated in the following image.
I'm sorry about the small font size in this gif. The three rectangles represent the full-size unmagnified screen. The moving dot represents the mouse cursor. The screen on the left shows the setting to move the magnified image continuously with the cursor. The one in the middle shows the setting for keeping the cursor near the center, while the one on the right shows the setting for only moving the magnifier when the pointer hits the edge of the magnified area.
1. Leave tooltips and other mouse-triggered pop-ups visible while the mouse is on the displayed content.
This is the biggest annoyance for me, so I'm putting it first. If you only act on one of these, make it this one. Here's an example from the AWS API Gateway Console:
As you can see the tooltip might not be completely visible when the cursor is hovering over the information icon. I'd need to move the mouse to get it in full view, but that hides the tooltip. So I can never completely read the tooltip at the magnification level I want.
The AWS Lambda console shows how this can be done better:
This is much nicer. I can move my mouse over to the speech bubble in order to read it. Another option would be to toggle the tooltip on click, making it clear to the user that the icon is clickable by making it look more like a button, and changing the cursor into a hand when hovering over it.
2. Don't obscure content when the mouse is hovering over it.
The most annoying recent example I've seen of this is Kickstarter's pledge levels. 
I understand that they wanted to make the whole area into a huge "call to action" button when the mouse cursor is on it, but the overlay makes the underlying list of perks hard to read. A high-contrast border might have been equally visually distinctive, or changing the background of the text, keeping the text visible with good contrast.
Another frequent example of this, is controls covering carousel/slider images or videos on hover. Here's an example from TVL, a Belgian provincial television network. They clearly want to indicate that clicking the video will pause it. I think this is such a common interaction that such a big control isn't necessary, and even if it is, there are probably more usable ways of achieving it. 
You can summarize this and the previous point as "don't rely on mouse position for content."
3 Put the result of an action close to the place where the action was triggered.
An example here is Digital Ocean. (You get $10 in DigitalOcean credit if you sign up through that link, and I get credit if you spend $25)
In this example, I edit my profile details in a modal in the center of the screen, but a confirmation appears in a toast message on the top right.
In the case of the profile, you might also notice that the information displayed in the center has updated, but that's not quickly noticeable. The original place in their dashboard where I encountered this issue was when I first added funds to my account balance via paypal. A message had appeared in the top right, which I had missed, because I was looking in the center, part of the page, hwich contains the main content. My balance didn't immediately update, but I saw the transaction had gone through on Paypal, so for a couple of minutes, I thought there was a bug in DigitalOcean, where they took my money, but didn't give me credit.
I had a similar issue when using the search feature on CodePen after their redesign. If you only see the right side of the screen, it's not immediately clear where you should go after clicking the search button.
Visually, I actually love how the search page looks. It just confused me a bit, the first time I used it
That's it!
At least as far as I can see. But maybe my view is just too narrow 😊. Are you running into similar other issues in this genre? Do you have remarks on the points I've covered? Please let me know in the comments.
Top comments (12)
Brilliant read. I love insights like this. Been recently thinking about the 3rd point quite a bit. I've been messing around with toasts and other system-like notifications that result from user interaction and they've been feeling odd UX-wise.
I think your description perfectly sums up why it's not always good to do - it's better to keep the action/reaction localised (probably wise to approach this point on a case-by-case basis though...)
In terms of the screen readers - would that be something you'd be willing to give more examples / critiques of? I'm currently building out an Angular prototype and adding accessibility options, but rather than just check things off a list, I'd like to explore what the labels are actually doing when a screen reader picks them up, and how I can make it better :)
I'm always happy to check out a website, try it out and give feedback (as long as I don't have to pay to sign up :)).
This is awesome. It's always so exciting to come across expertise distilled down so smartly like this. I'm bookmarking your article and integrating these points into my accessibility testing workflow.
You rock.
Thanks for the insightful read --- I hadn't once thought about a screen reader and this will definitely change my perspective. Any idea if the new 'accessibility audit' in chrome devtools accounts for screen magnifiers?
I don't think so, but I'm not sure. I've never heard of any tool that checks magnifier-related issues. It might check for colo(u)r contrast, font size, and then the usual screen-reader best practices.
Gotcha. I'll do some poking around and report back if I find anything.
Btw, you inspired me to write this post today and I mentioned your post as a resource 😊
Wonderful article! People like yourself who rely on screen magnification, text resizing, high contrast, or other vision supports are so often overlooked in discussions of design. Thanks so much for sharing your recommendations!
I think your article is great. I am always interested in how people digest digital content. I think all of your comments are valid. The trick is compliance. Most of the time compliance is geared toward screen readers (obviously except color, etc.). So things like pop ups and other overlay issues go away when you are using JAWS or NVDA. Somewhere in the middle is a balance though. I think a toggle for screen magnifiers could blanket-change the format of a page and fix a lot of your issues while still remaining AT compliant. You are definitely in a pickle and I totally get your point. Great job on posting videos! There is nothing more effective than witnessing the issues that others have from their perspective. Thanks for sharing!
Nice!
Very interesting and useful thoughts, I'm working a project for persons with visual disability right now and this complements my insight.
Thanks!
Hi, and thanks for your comment.
Given that your product targets users with visual impairments, you'll probably get ample accessibility-related feedback, but if you want some more, I'll gladly give it a try.
Thanks for sharing!
Thanks for this. I personally hadn't thought through this scenario before.