If there’s one thing that designers hate, it’s inconsistency. Surely the minds behind the world’s leading creative software wouldn’t make such an error? Well it looks like they have: right now the mixture of rounded and square-edged app icons on Adobe’s popular tools is driving designers crazy.
The apparent error has been a bone of contention for some time, but the recent release of Photoshop 2020 has reignited the rage of designers everywhere. The matter is detracting somewhat from all the exciting updates from Adobe MAX 2019, including the news that Photoshop on the iPad is finally here, and Illustrator on the iPad is in the works too.
Wondering why the XD and Photoshop icons in your dock or have rounded corners, while Illustrator and InDesign remain stubbornly square? Stephen Nielson, who leads the Photoshop product management team at Adobe has taken to Twitter to explain that it’s actually intentional. He tweeted that “Adobe apps get rounded corners when they become multi-device and cloud-aware”. So now you know.
While it makes a little more sense now you know the thinking behind the inconsistency, Design Twitter is having none of it. Neil A. Evans summed up the crux of the problem, tweeting: “An icon that has to be explained is rubbish. I don’t care if it’s multi platform, if I install it on my other platforms I’ll already know. Make the icons consistent.”
An icon should be the purest version of what it represents, with no prior knowledge required (see our roundup of the best iOS app icons for more tips). While the difference between multi-device, cloud-aware apps and standalone apps is a big deal for those working at Adobe, it doesn’t make a big difference to the general user – and certainly not the extent of wanting a different type of icon to remind them.
Another hot take: I really don’t care whether or not my Adobe apps are cloud-aware (whatever that even means), and I doubt I’ll ever get the urge to be reminded by looking at an app icon’s corners. https://t.co/eFZ8kGRPK7November 6, 2019
If you’re really struggling with the non-uniform icons, there is a solution. Go into Finder, and in the app’s info panel you can override its icon. Copy in the 2019 icon, and you’ll have a beautifully consistent dock once again. Phew.
We can test for focus visually. If the button gets focused, there should be the default visual glow around the button.
We can also test for focus programmatically. In JavaScript, you can get the focused element with document.activeElement. When we click a button, we can log the focused element.
Note: If you’re using Chrome, you can use the Live Expression tool (so there’s no need to log document.activeElement).
Testing for keypress
Here, we can add a keydown event listener to the document. Here, we want to log what element triggered the event. We can tell the element with event.target.
After clicking on a button, does Tab go to the next focusable element? If it goes to the next focusable element, that element should receive a focus outline.
Likewise, does ShiftTab goes to the previous focusable element? If it goes to the previous focusable element, that element should receive a focus outline too.
I did not log document.activeElement because the focus glow is enough.
Results
Safari (Mac)
When you click on a button in Safari (12.1.1), the button does not get focus. The document gets focus instead. We know this because:
There’s no focus glow on the button.
document.activeElement points to .
Since gets focus, any further keypress originates from the .
Tabbing into the next element works as expected. The next element gets focus.
ShiftTab doesn’t work as I expected. I expect the previous element to get focus, but gets focus instead.
Firefox (Mac)
When you click on a button in Firefox (Nightly 70.0a1), the button does not get focus. The document gets focus instead.
Any further keypress originates from the .
Tab does not work as expected. When you press Tab, Firefox focuses on the first element in the document.
ShiftTab is funny. If is the first thing you clicked on, Firefox focuses on the last focusable element in the document. If you focused on an element before clicking the button, Firefox focuses that element.
The problem with Firefox and buttons date back to Firefox 63 (at least). MDN has a section on this:
Firefox (Windows)
When you click on a button in Firefox (Quantum 68.0.1, Windows version), the button gets focus, but the focus glow does not show up.
Further keypress originates from the .
Tab works as expected. The next item gets focus.
ShiftTab works as expected. The previous item gets focus.
Chrome (Mac)
When you click on a button in Chrome (Canary 78.0), the button gets focus. This implementation is different from Safari and Firefox.
The next keypress originates from . This is expected since is the focused element.
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Chrome (Windows)
When you click on a button in Chrome (Chrome 75.0), the button gets focus.
The next keypress originates from .
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Edge (Windows)
When you click on a button in Edge (Edge 17), the button gets focus, but the focus ring did not appear.
The next keypress originates from .
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Summary of the results
We tested for four things across the common browsers:
Does clicking focus the button?
After clicking, does keypresses originate from the button?
After clicking, can we tab to the next element?
After clicking, can we shift-tab to the previous element?
Here are the results in a table form.
Test
Safari
Firefox ()
Firefox (⊞)
Chrome ()
Chrome (⊞)
Edge (⊞)
Focused element
(but no focus glow)
(but no focus glow)
Next Keypress from:
Tab goes to:
Next element
First element in document
Next element
Next element
Next element
Next element
Shift Tab goes to:
Previously focused element (if any)
Previous Element
Previous Element
Previous Element
Previous Element
You can see the inconsistencies here. It’s clear as day. The major inconsistencies are:
Firefox on Mac is simply weird. Everything seems wrong.
Some browsers don’t focus on the button when they’re clicked.
Some browsers don’t include a focus glow on the button when they’re clicked.
The HTML Spec doesn’t state what browsers should do after a user clicks on a button. So no browsers are at fault for the inconsistent behavior.
Here’s a potential fix
I think Chrome’s implementation (both Mac and Windows) makes the most sense.
When you click on a button, focus should be on the button.
Button should have a focus glow.
When you press Tab after clicking a button, the next element should get focus.
When you press ShiftTab after clicking a button, the previous element should get focus.
Note: If you’re the kind of person that hates the default focus style, you can restyle the focus ring (or you can wait for :focus-visible to be widely supported).
There’s a quick fix if you want to make the other browsers behave consistently with Chrome’s implementation. All you have to do is add this code at the top of your JavaScript.
document.addEventListener('click', event => {
if (event.target.matches('button') {
event.target.focus()
}
})
This code focuses on the button when you click on it. This also makes sure:
The focus glow appears.
Tab goes to the next element.
Shift-Tab goes to the previous element
Important note: You want to put this code AT THE TOP of your JavaScript files. It works because event listeners are called in the order they’re declared. Focus will always go to the button first. You can then redirect focus to other elements if you desire.
Important note #2: I have not tested this code thoroughly with all devices yet. (Only Mac versions Safari, Firefox, and Chrome). I appreciate it if you can help to conduct some tests. Let me know if I’m wrong in any way. Thanks.
In case you were wondering why I did these tests: I realized the inconsistent behavior when I was writing the Keyboard section for Learn JavaScript. I did these tests because I wanted to teach my students the right way to handle buttons and focus (which is a big part of accessibility!).
Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!
We can test for focus visually. If the button gets focused, there should be the default visual glow around the button.
We can also test for focus programmatically. In JavaScript, you can get the focused element with document.activeElement. When we click a button, we can log the focused element.
Note: If you’re using Chrome, you can use the Live Expression tool (so there’s no need to log document.activeElement).
Testing for keypress
Here, we can add a keydown event listener to the document. Here, we want to log what element triggered the event. We can tell the element with event.target.
After clicking on a button, does Tab go to the next focusable element? If it goes to the next focusable element, that element should receive a focus outline.
Likewise, does ShiftTab goes to the previous focusable element? If it goes to the previous focusable element, that element should receive a focus outline too.
I did not log document.activeElement because the focus glow is enough.
Results
Safari (Mac)
When you click on a button in Safari (12.1.1), the button does not get focus. The document gets focus instead. We know this because:
There’s no focus glow on the button.
document.activeElement points to .
Since gets focus, any further keypress originates from the .
Tabbing into the next element works as expected. The next element gets focus.
ShiftTab doesn’t work as I expected. I expect the previous element to get focus, but gets focus instead.
Firefox (Mac)
When you click on a button in Firefox (Nightly 70.0a1), the button does not get focus. The document gets focus instead.
Any further keypress originates from the .
Tab does not work as expected. When you press Tab, Firefox focuses on the first element in the document.
ShiftTab is funny. If is the first thing you clicked on, Firefox focuses on the last focusable element in the document. If you focused on an element before clicking the button, Firefox focuses that element.
The problem with Firefox and buttons date back to Firefox 63 (at least). MDN has a section on this:
Firefox (Windows)
When you click on a button in Firefox (Quantum 68.0.1, Windows version), the button gets focus, but the focus glow does not show up.
Further keypress originates from the .
Tab works as expected. The next item gets focus.
ShiftTab works as expected. The previous item gets focus.
Chrome (Mac)
When you click on a button in Chrome (Canary 78.0), the button gets focus. This implementation is different from Safari and Firefox.
The next keypress originates from . This is expected since is the focused element.
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Chrome (Windows)
When you click on a button in Chrome (Chrome 75.0), the button gets focus.
The next keypress originates from .
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Edge (Windows)
When you click on a button in Edge (Edge 17), the button gets focus, but the focus ring did not appear.
The next keypress originates from .
Tab works as expected. The next element gets focus.
ShiftTab works as expected. The previous element gets focus.
Summary of the results
We tested for four things across the common browsers:
Does clicking focus the button?
After clicking, does keypresses originate from the button?
After clicking, can we tab to the next element?
After clicking, can we shift-tab to the previous element?
Here are the results in a table form.
Test
Safari
Firefox ()
Firefox (⊞)
Chrome ()
Chrome (⊞)
Edge (⊞)
Focused element
(but no focus glow)
(but no focus glow)
Next Keypress from:
Tab goes to:
Next element
First element in document
Next element
Next element
Next element
Next element
Shift Tab goes to:
Previously focused element (if any)
Previous Element
Previous Element
Previous Element
Previous Element
You can see the inconsistencies here. It’s clear as day. The major inconsistencies are:
Firefox on Mac is simply weird. Everything seems wrong.
Some browsers don’t focus on the button when they’re clicked.
Some browsers don’t include a focus glow on the button when they’re clicked.
The HTML Spec doesn’t state what browsers should do after a user clicks on a button. So no browsers are at fault for the inconsistent behavior.
Here’s a potential fix
I think Chrome’s implementation (both Mac and Windows) makes the most sense.
When you click on a button, focus should be on the button.
Button should have a focus glow.
When you press Tab after clicking a button, the next element should get focus.
When you press ShiftTab after clicking a button, the previous element should get focus.
Note: If you’re the kind of person that hates the default focus style, you can restyle the focus ring (or you can wait for :focus-visible to be widely supported).
There’s a quick fix if you want to make the other browsers behave consistently with Chrome’s implementation. All you have to do is add this code at the top of your JavaScript.
document.addEventListener('click', event => {
if (event.target.matches('button') {
event.target.focus()
}
})
This code focuses on the button when you click on it. This also makes sure:
The focus glow appears.
Tab goes to the next element.
Shift-Tab goes to the previous element
Important note: You want to put this code AT THE TOP of your JavaScript files. It works because event listeners are called in the order they’re declared. Focus will always go to the button first. You can then redirect focus to other elements if you desire.
Important note #2: I have not tested this code thoroughly with all devices yet. (Only Mac versions Safari, Firefox, and Chrome). I appreciate it if you can help to conduct some tests. Let me know if I’m wrong in any way. Thanks.
In case you were wondering why I did these tests: I realized the inconsistent behavior when I was writing the Keyboard section for Learn JavaScript. I did these tests because I wanted to teach my students the right way to handle buttons and focus (which is a big part of accessibility!).
Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!
