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.