When I used to work in Boston I would take the Green Line into the city. There was a woman who would get on the train around Washington Street who was visually impaired. She wasn’t totally blind but still had very low vision. She would hold her iPhone one or two inches from her face so she could read the text as she killed time before her stop.
Since then I’ve conducted a handful of user tests at the Perkins School for the Blind and have observed the same behavior with low vision users who don’t have ready access to screen magnification software. Seeing how exactly people use a system can completely change how you design and build it — that’s not a new concept (it’s why we have usability tests). More often than not we put on blinders and only test how users interact with the product (where they click and how they look around), and ignore the intermediate step in looking at what they have to do to interact (how do they get to that click, and how they look around).
That’s the difference between the questions:, “Does this text make sense?” and “Can someone see this text? If so, does it make sense? What would make them not be able to see it?” The second question set is targeted at users, the first is on the product. By focusing on the second, we can create a system of universal design and a great end-to-end experience for all users.
Resizing text
WCAG 2.0 Level AA, Guideline 1.4.4 speaks to the importance of letting the user resize text:
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
This guideline states that all website text must be resizable (zoomable). This was more of a problem in older browsers from around 2005 where browsers wouldn’t resize text sizes as pixels or points, but that isn’t an issue anymore as all modern desktop browsers will trigger a full page zoom when the user presses cmd/ctrl+ (Pro Tip: If you set your media queries with EMs instead of PX zooming will also trigger the media query).
The more relevant portion of this guideline is for touch displays and pinch-zooming behaviors. In a nutshell: if you can pinch-zoom you’re good, if you can’t, you fail the guideline. Zooming is commonly disabled for a variety of design reasons, usually having to do with aesthetics and/or a pinned header (when you have a pinned header and you pinch-zoom, the header often takes over the whole display). When it’s disabled you’ll see this code in the <head>:
<meta name="viewport" content="width=device-width, initial-scale=1.0,
maximum-scale=1.0, user-scalable=no" />This tag sets the viewport to how wide the device is and sets the max-zoom to 100% while also turning off user scalability. This is one of the more common WCAG 2.0 Level AA failures. We can easily re-install zooming by changing that tag to:
<meta name="viewport" content="width=device-width, initial-scale=1.0">This is a small change that makes a huge impact to a large population of low vision users (like my friend on the Green Line), and I guarantee no one will complain that they can zoom in on text. While it does introduce some issues around pinning a header, the answer to that is fixing the header (unpin it on zoom), not removing accessibility and universal design features from users.
Small touches like this and looking at a problem a little differently can often be the difference between users returning and users not coming back. And of course we always want them coming back, so let that text zoom!
Jon Avila says:
Thanks for bringing awareness of the issue. Most mobile browsers now allow overwriting this setting — finally under iOS 10.x it is done automatically. On Android browsers like Firefox and Chrome it’s generally a setting that will allow the user to pinch zoom even when the scale is limited.
Regarding resizing of text to 200% no longer being an issue because of page zoom. It is an issue even with full page zoom. 1) Because as you mention things like headers can take up all of the page, scrollbars can be disabled with overflow hidden, content can actually get smaller when zoom in, content can be chopped off even in responsive sites — because many are not truly fluid. I use low resolution and run into issues everyday with page zoom on my PC. I often trigger responsive sites because I use low resolution.
Also a big issue with full page zoom is scrollbars — having to scroll to read text is very ineffective for people with low vision.
Google’s Accelerated Mobile Project pages are unusable with pinch zoom on my iPhone because they load pages in a iframe which seems to not work correctly when you try to scroll a magnified view.
And finally, if you see someone with low vision looking closely at something — it may be because we want to. I don’t like to use platform zoom or screen enlargement because I only see a small portion. Instead I would prefer to use larger text in the app or site and not have to pan to read. With smaller text I can actually fit more words on-screen. Bumping up zoom would allow me to sit back but see less words. I’ve heard that looking closely at things is not socially acceptable — but frankly I don’t care if it offends anyone — there is nothing wrong with looking closely at something — what works best for someone — is well — best for them. One size does not fit all. I agree there are people who are not aware of the tools and accessibility features out there and education is important.
Tim Wright says:
@Jon
Do you see this as a positive or a negative?