Don’t Re-Create Browser Features
There has been some discussion lately around, of all things, text resizing widgets on web sites. It was kicked off by a post from Jeffrey Zeldman suggesting that perhaps it is time to bring them back.
Even mighty responsive design benefits from offering a choice of font sizes—because there are just too many complications between too many screen sizes and device features and too many pairs of eyes to ensure that even the best designer can provide a readable experience for everyone without adding a simple text size widget.
I built text sizing widgets for years, every damn site. I was so proud of them too. It was a way of showing I care about users. It was all ego. As soon as I could start tracking clicks on those widgets I found they were not used. Even on sites I built for low vision communities.
Instead, a good design with non-hardcoded typefaces that is responsive and does not disable zoom was all I needed. In short, good development techniques and best practices. That handled most of my edge cases just fine. For the remainder, a little documentation in the form of simple, contextual help text.
Notice I am not referencing assistive technology. For the most part, those users don’t need your widgets, they have already obtained tools to work around a non-inclusive web.
How Is This a Thing Again?
The real problem users have today is that browsers hide the text sizing controls in an effort to make their interfaces look cleaner, simpler. This anti-pattern means many folks do not know how to adjust a page, and as a result we are discussing training users all over again on brand new custom controls that will work inconsistently across the web.
Maybe channel your desire for a more inclusive web into filing bugs with browser makers to make these controls front and center again.
But You Are Going to Make One Anyway
If you end up putting a text size widget on your site, make sure to put some tracking on it.
If you find nobody uses it, consider removing it. If you find people use the option to scale text up, consider just making the base size of type on your site larger.
Then continue tracking and when you find nobody scales the text (for as many iterations as it takes), consider removing the widget.
Why Stop at Text Size?
Allowing users to choose from one of three (or more?) sizes of text is a nice offering, but it is also doing too little. If you want to make your site easier for all users to read, consider an option to adjust the contrast. And the leading. And the typeface. And the word spacing. And the justification. And the color. And those damn all-caps headlines. And so on.
I am not saying not to do a text widget just because you do not allow configuration of all the other text-related styles, but understand that you are setting an expectation with your user that you will not truly fulfill. Particularly if you only offer three text sizes. Especially if one of those text sizes is smaller than the base size.
How You Could Do It
Instead of custom widget, maybe help educate users on how to use their own web browser. Perhaps link to, or offer as pop-up help, quick instructions on how to scale text in the user’s current browser.
Now you will have educated a user. You will have armed a user to have a better experience across the whole of the web. You will have stopped selfishly building a widget for just your users and contributed to empowering all users.
What could be more inclusive than that?
How Not to Do It
The New York Times has been cited repeatedly as an example of a text sizing widget. Except it is a terrible example that I hope nobody follows. I hate to beat up NYT since it was probably done with the best of intentions, but using it as your base experience will do more harm.
- It only resizes text in an article, nowhere else (so not navigation, headlines, bylines, etc).
- The widget is hidden behind a gear icon.
- The gear icon is only visible when you are at the top of the page, well above the content the widget affects.
- Scrolling down to see the content causes the opened widget to disappear.
- The buttons in the widget fail to have a clear indicator of which option is selected (consider what users it will benefit and how invisible that style is to them).
- It does not retain the size you have chosen as you navigate the site.
- It does not retain the size you have chosen when you return to the site.
- It does not affect the print styles for the site.
A video demonstration:
You may want to try it yourself.
If you aren’t making your own widget perceivable, operable, understandable, and robust, then you may be doing it wrong. You will end up doing more harm than good. You may turn off your users instead of delighting them.
We already have enough web developers who try to recreate native controls that ultimately do not work. Let’s not add more to the pile.
Related
12 Comments
Reply “Maybe channel your desire for a more inclusive web into filing bugs with browser makers to make these controls front and center again.”
Zoom controls are available directly in the main menu in Firefox, Chrome and Edge. The user can also access them directly via keyboard shortcuts. This seems sufficient.
In response to . Reply For users like you and I that is easy to find. For the average computer user that is not necessarily so easy (I cannot find a recent article talking about how few people are truly knowledgeable about using the software on their computers).
The issue is that hiding (or removing completely) the option behind a hamburger menu (because that’s what they are in all three browsers) is an extra bit of friction. This leaves it open for developers / designers to feel that it is a feature they must offer. Moving text sizing back to the toolbar as the default on install may help mitigate that urge.
But I agree, the browser controls are far better than whatever the average developer will produce for a site.
In response to . Reply Found it: The Distribution of Users’ Computer Skills: Worse Than You Think
In response to . Reply Most browsers got rid of the menu bar to save screen space on mobile devices. This made the zoom function even harder to find then it already was for most users. And hiding it in a menu was already a step back compared to having it on a toolbar, as in Internet Explorer 3, or next to the URL bar, as in Opera 3.x – 7.x. (You can find screenshots of these browsers on Wikipedia.)
Reply I referenced this pattern in a post about how skip links are an accessibility hack, and like font size widgets, creating custom web page controls for what should be native browser features.
We need to stop reinventing the wheel and let the manufacturer of the car the user is using take responsibility for how the wheels are implemented on the car.
In response to . Reply George, I agree wholeheartedly with your closing statement (in addition to your notes on text sizing widgets):
Save us, browser vendors! Give keyboard-only users a shortcut to navigate directly to the main content on the page!
Reply Sime, people don’t even know crtl+. They don’t. My uncle doesn’t. My friend’s mom with diabetic retinopathy doesn’t. A surprising number of our students don’t.
You know what else a lot of browsers offer? The ability to set the general default font size. I do this in chromium because I dev with that browser the most. Guess what? So many websites still set their text in px that it almost doesn’t matter: I *still* have to ctrl++ on every damn page because px overrides my needs.
Which would teach me, as a non-developer user, that the settings are bullshit anyway so why use them.
Adrian: re the NYT widget only resizing the article, I can actually see a use for it (if they didn’t hide the setting and it affected every article). The Correspondent does that, when you create an account: they bring you to a page and ask: do you prefer, after you’ve logged in, a serif or sans-serif font? Large, medium, or small? Dark theme or light (contrast)? You get shown these exist, they (so far as I can see) only affect the articles (the reason you’re there) but they stay with you every article until you change them again. For a site whose main purpose is reading long articles, I can see this being ok as widgets on a website. Not necessarily for anything else.
Instead, agreed that these settings need to be easier for users to find in browsers. And for that matter, contrast-reducers: I’ve met in the last several months a few low-vision people who actually have trouble even at the lowest WCAG contrast settings– they want it even lower. Would be nice if browsers offered that. Browser, or OS, should allow users to set all their settings, or at least most.
WCAG is going to, at some point, add in a lot of missing cog stuff. The question is, will all those options become the job of the developer, or the job of the browser vendor?
In response to . Reply Mallory, I agree that some personalization settings, when done site-wide and consistently, can be valuable to users. I think NYT fails to do it effectively, let alone consistently.
As for WCAG updates, much of that will fall to developers. Browsers have UAAG, and I think they have mostly limited what they will implement, leaving much of that work to developers.
Reply Almost takes me back to the days of personalizing the user agents themselves (VISP disc anyone?). But that’s another story for another time.
I’m in the school of thinking it’s better to create text-size widgets (plus other features) AND provide simple plain clear instructions for browser (noticed I didn’t say English there?). Simply because you don’t know if the user has access to the browser controls or menu. Examples of which include kiosks at airports, train stations, health gyms and department stores to name a few. Plus some corporate networks and universities still lock down web browsers (not just the proxy server). So not just because the browser may have hidden their controls.
Also providing a text-size widget helps with digital inclusion. Not all users who do get online will have the digital skills (or confidence) to play with the browser (desktop or mobile) features.
Yes, the NYT example isn’t perfect and there is some room for improvement but credit given for at least identifying and catering for user customization. Out of interest what was their response when you reported your findings? Be good to see them taking the constructive feedback on board and see what they come up as a solution in response. A lot of the time users don’t report issues so something not working for them doesn’t get addressed. We might ask to see what their stats are on those widgets see if we can get an insight into numbers.
Reply On desktop browsers, the hamburger menu in Firefox, Chrome and Edge does a great job of exposing these controls to the user in a highly visible spot, as opposed to the old “View > Text size” menu.
The “problem” seems to be more acute with mobile browsers, where it’s def hidden under Settings > Accessibility > Text size.
In my experience, a lot of people get this configured by their phone company’s salesperson, who just bumps the OS text size as soon as he unboxes the phone and installs the chip for the customer.
The proper solution for mobile, I believe, is what Opera for Android does: pinch zoom + text reflow.
Reply I recently gave a talk where I showed Sanquin (Dutch blood bank) doing exactly this (edumacating users): https://www.sanquin.nl/ click on the A+ (I swear it’s not a blood type) in the menu at the top. It goes to a page telling users how to set font settings in 2 major OSes in multiple popular browsers, and people who were looking for a text-enlarge widget are likely the ones to click that. Win-win!
In response to . Reply I happen to like this solution. Great way to satisfy the client who never clicks it but insists on it regardless.
Leave a Comment or Response