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.
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
<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!