Mac Toolbar Labels and Accessibility
My Dad (90 yrs old) has developed cognitive issues, including the inability to reconcile symbols. He can’t use Apple Mail anymore as Mail compose window removed the ability to show text labels with buttons. Thanks @tim_cook Happy Global Accessibility Awareness Day on May 16
This continues a depressing trend—Safari hasn’t had text labels available on its buttons for many years now.
Apple may have done this to save vertical space, which is ironic, as using “text only”—when available—takes the least amount of space possible.
I prefer to see both the icons and the text. This is an option in NSToolbar, which the app can set and the user can configure. However, if the window uses NSWindowTitleHidden to hide the title (another accessibility problem) and put the toolbar in the title bar, the toolbar gets locked in icon-only mode.
At first, I thought this title-free design was intended for single-window apps, but Apple also uses it Safari and Xcode. And it’s been appearing in third-party apps like MarsEdit, OmniFocus, and ReadKit—a shame.
Update (2019-05-23): Daniel Jalkut:
Ideally Apple would fix this mode so that some kind of appropriate compromise could be made to support the streamlined title-bar-free mode, while also supporting the display of labels. I’m not holding my breath on that, though. Hopefully this workaround [for MarsEdit] will give those of you who either prefer, or outright depend upon the labels for accessibility reasons, something to tide you over.
I often find that VoiceOver is the only way to discover what a button with an inscrutable icon does.
Also, these windows with no distinct title bar leave little space for me to click and drag the window, so I’m zooming way in to find a tiny grab spot.
There’s a hugely important aspect to this: developers follow Apple’s lead when it comes to app design. I’m trying to find Apple apps that allow for buttons and titles, and all I’ve found so far is Mail and the iWork apps. (The iWork apps are document-based, which means their windows need titles.)
The most obvious example is Finder, which allows button labels and is not document-based. Automator, Preview, and Script Editor do, too, and are document-based. Then again, Xcode supports multiple windows, and is document-based, yet it doesn’t allow window titles or button labels. I think this style is basically the new brushed metal—used haphazardly by Apple and therefore by third-party developers as well.
OmniFocus is not document-based, but it supports multiple named windows. It puts the titles in giant text below the title bar, so it actually leaves less room for the content than in the previous version that did allow toolbar labels. However, the colored text can help show where you are, and it is visually consistent with the iOS app.
In fact, lots of Apple apps — and third-party apps — don’t even have configurable toolbars at all. This is a shame. At least with Safari — and the apps Michael mentions, and NetNewsWire — you can rearrange items to your liking, and choose the items you want to see.
Simmons’ NetNewsWire is an app that doesn’t use a window title, but it does have a hidden preference to change that, and then you can enable the toolbar labels.
I think it’s a real accessibility issue, and another instance of something that looks better but, for at least some people, works worse. I also think the problem is exacerbated by the current style where icons are just simple one-color hairline outlines objects, not colorful illustrations of actual objects.
Update (2019-05-24): macOS Human Interface Guidelines:
A title bar should be visible, but can be hidden in an immersive app like a game.
Provide a title unless there’s enough context that one is unnecessary.
[…]
Provide a short, descriptive label for every toolbar item. Users see these labels when they configure the toolbar to show icons and text, or text only.
That seems to be the extent of Apple’s guidance.
21 Comments RSS · Twitter
I always want “Icon and Text”, and I've been sad to see it disappear from so many Mac apps. Unfortunately, this is a change that's generally been caused by changes Apple made.
However, it can still be accessed in certain apps. I'm aware of these two at present:
In MarsEdit 4: defaults write com.red-sweater.marsedit4 ShowMainWindowTitleBar TRUE
In NewNewsWire 5: defaults write com.ranchero.NetNewsWire-Evergreen KafasisTitleMode TRUE
I hope it helps others.
Thanks, Paul!
[…] Tsai wrote today about the accessibility challenges presented by Mac toolbars that do not have text labels. These […]
FYI there is a secret preference in MarsEdit to restore the title bar and, correspondingly, the ability to show text labels for the toolbar icons: https://red-sweater.com/blog/3474/marsedits-secret-title-bar-preference
Changing the default is logical, I suppose, but vertical height doesn't explain why such an option would need to be removed. I used text for apps I seldom used, or to learn new things. I definitely like the option!
Finder, the formerly-iWork apps, Console, and Disk Utility all have Icons + Text mode which seems to work just fine. Safari and Notes have the "Customize Toolbar" panel which renders text correctly as well.
Funnily enough, Xcode has an 'Icons and Text' option in the context menu when no toolbar is visible, but it simply shows icons only.
Thank you for bringing this to my attention. I hadn't really thought about this aspect of hiding the title bar.
And the more I think about it, it is really important to allow the user to show the title bar, both from an accessibility viewpoint to see the labels but also for all users to be able to have a choice. So I decided in the latest release of Lingon X to add the option to the View menu to allow as many users as possible to easily choose what they prefer.
@Michael I think if you look at the way the close/minimize/zoom buttons align with the title-less buttons, it would be an aesthethic downgrade to add height to draw labels in the current design. I think they should fix this one way or another but I can see why they might have sort of thrown in the towel at some point on making that look good, and then never revisited the issue again.
The thing is.. even in Safari, if you use 'customize toolbar' the icons all have text labels. So A) the information is actually there anyway and B) frankly, the fact they label them in this section is a tacit admission they're not intuitive / differentiated enough to function with labels; if they actually did work sufficiently without labels, you wouldn't need the labels anywhere, would you?
(BTW, Don't get me started on the Xcode GUI.. just.. don't.)
Nothing about the current flat/bleached/neon color with gestures and zero discovery UI/UX paradigm is intuitive or good for accessibility, let alone for user who don't even require accessibility features.
By happenstance I worked on a Mac running Snow Leopard today along with an iPad running iOS 6, and what a difference. Everything is (was) obvious, colorful, intuitive. Sure it looks a little dated, but it's a joy to use either. Can we please leave this maximized for obfuscation flat design trend far behind yet, and put user experience first again?
It's often the simplest things (at which Apple used to excel) that make the biggest difference. Apple has chosen to to deny users the option to Customize Toolbar / choose "Icon and Text" in various Mail windows, as well as other apps that used to offer this hugely-useful interface feature. Users are now left with placing barely-discernible grey icons in the toolbar with no text descriptors underneath. And the only way to figure out what each icon represents is to waste time hovering the cursor over the icon.
@Daniel Jalkut Ah, you're right; very good point! I would probably be content with "Icons only" and"Icons, Text, and a Document Title", though that's a mouthful.
Most of these apps (like Notes or Safari) have their document titles elsewhere, either in a tab or some column of the interface. Notably, Finder duplicates the document title between the Title Bar (note the name of that element). Having a document title is also a component of accessibility as it means users should be able to find what they're looking at from a consistent location, specifically top-center of the current window. Admittedly, this is a more minor benefit, but I think a nice thing.
Funnily enough the HIG currently recommends giving both options: https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/toolbars/
Peter's comment about VO made me remember something else: You *can* get to the text description by hovering over the button and having a tiny tooltip appear. (Though Peter would readily point out, that such tooltips are very tiny and difficult for those of us with visual impairments!) But, nonetheless, a text description is still available for those who are patient enough to wait for one to appear.
I just wish that the "no titlebar" option would disappear. I miss having a place to grab a window -- if you try to fit two browser windows next to each other on a 15" laptop, you very quickly run out of places to click on the titlebar that doesn't also do something.
You can add Flexible Space to the toolbar, which provides a decent place to grab it. Unfortunately, it means seeing a lot less of the URL in Safari. You have to pick one or the other.
Shame on Apple. Elementary OS has the same unified title bar like Apple, but you can move the window with click and drag also on buttons.
This makes me sad. I read Steve Troughton-Smith's excellent article on the merging of Mac OS "Classic" and NeXTSTEP yesterday and was reminded of the furore within Apple where the incumbents felt like the HIG was being ignored (and it was) and that the subtleties that made the Mac such a wonderful tool were being glossed over. I lived through that, and miss some of the niceties like a window for a particular folder always remembering its position on the screen.
Given that we're now facing a future where the iOS approach will be migrating to the Mac - or merging with it - I remain unconvinced that the result will be an improvement. Issues like this one show that expediency is more important than inclusion. :(
Well, as a direct result of this discussion I've added Icon & Text options to the toolbar-esque buttons in Keyboard Maestro for the next version, so at least some good came from James Riordon’s comment, even if Tim Cook and Apple are unlikely to listen.
[…] icons is proven over and over again to be the most accessible and clearest UX (see Apple’s latest blunder). But if you need to (and I get it, sometimes you need to), Sara Soueidan and Scott O’Hara […]
[…] Interesting idea to apply OCR to screenshots. (Back in the classic Mac days there was a neat utility that could do this without actual OCR by intercepting the QuickDraw calls that were used to draw text to the screen.) Plus, toolbar labels! […]
[…] icons is proven over and over again to be the most accessible and clearest UX (see Apple’s latest blunder). But if you need to (and I get it, sometimes you need to), Sara Soueidan and Scott O’Hara […]
I'm not sure whether this is a new feature, however, there is a tool tip attached to each Safari Toolbar item. This would be enough for me except -- I have sight problems, and need to use a larger cursor/pointer. Unfortunately, the cursor covers the tooltip text. sigh
I'm reminded of Donald Norman's recent piece on the exclusionary impact of current design trends on the usability of tools by the elderly.
https://www.fastcompany.com/90338379/i-wrote-the-book-on-user-friendly-design-what-i-see-today-horrifies-me