I Don’t Care What Google or Apple or Whoever Did
It is not uncommon that I raise an accessibility or usability issue with a client’s design or implementation and am met with either “But Google does this,” or “But Apple does this.” Mostly it is the default response to any issue I raise, but it is far worse when it is a reaction to a genuine technical failure or problem real users have identified.
That response does not address the problem I may have raised. It avoids. It offloads responsibility. It declines to even try.
A very very quick selection of decisions that Google and Apple made that were counter to what experienced usability and UX experts recommended:
- Google Material Design told us form fields were better without boxes, until they tested it.
- Apple told us removing button outlines in iOS was better, until users complained.
- Google relies on color alone for links in search results, which is a WCAG violation.
- Apple went with super-thin typefaces in iOS, until finally making them thicker in subsequent releases.
- Google Chrome uses a default blue focus indicator, which is invisible on their own blue-background navigation.
- Apple thought animating apps on launch was cool, until users with vestibular orders got sick.
Arguing that Apple or Google did something a particular way will not sway me on its own. I am not alone in this (see Heydon Pickering’s Listen To Me And Not Google).
Apple and Google get it wrong just as often as the rest of us. Their tendril-like presence in our everyday lives does not make them any better, and their people no worse. What ‘standards’ they have defined have been through brute force — Apple brought down Flash but wants phones with no physical affordances, Google built the most powerful search engine of the day but pushes half-baked features to its browser.
I don’t want more of Apple’s or Google’s cavalier “coolness” in interfaces. I don’t care that these untested or highly specific patterns are good enough for their teams to deploy. They can be immune to causing massive grief to their users, you cannot.
If you want to sway me with your defense of your terrible UI thing, try harder.
I may have ranted about this in a Twitter thread:
Getting hammered lately with “Google does this” or “Apple does this” justifications for terrible UIs.
Google Material Design told us form fields were better without boxes, until they tested it.
Apple told us removing button outlines in iOS was better, until users complained.
Update: March 26, 2020
A few days before I wrote this Nielsen Norman Group made a video arguing that there is a risk in copying the designs and patterns of famous sites, primarily because the context is different.
Additional support for this: At Apple, many of their web app teams have a single, simple directive, “parity with native.” It didn’t matter if you could improve accessibility on the web version, they would reject the idea out of hand if it didn’t exist in the native version. So, not only did they ignore the platform, they took native mistakes and replicated them often with great effort.
I can only imagine the teams at Apple or Google (in early days) were faced with “well Microsoft / Xerox / IBM do this…”
Their response, to diverge from the existing patterns and decide based on their own research / perspective, is exactly what gave them a competitive edge.
Stay hungry, stay foolish.
I’d go further and say “if Google or Apple (or Facebook) did it it’s a bad idea” if we’re talking UI/UX, every time I have to use their “simple and user-friendly” interfaces I just can’t contain my anger, how something so ugly and/or stupid could get shipped?!
People often forget that when they use the “Apple” or “Google” does this rationale — it’s often for Apple’s or Google’s OWN benefit. What works at company XYZ maynot be appropriate for your product/company/situation.
Good points! But:
“Google relies on color alone for links in search results, which is a WCAG violation.”
It’s not a WCAG violation as long as the contrast against the surrounding text is 3:1. The WCAG documentation on how to meet 1.4.1 illustrates this – see for instance the “Understanding techniques” link. WCAG doesn’t mean color in the traditional sense of the word, but as in hue. So relying on “color” is not a violation as long as the as the luminance contrast is sufficient (which makes it two different colors in this definition).
Red and Pink are the same color (hue) but they have different lightness (which is not color ). So red and pink would pass the requirement for “not distinguished by color (hue) alone” since they differ by lightness (which is not color) – as long as the difference in lightness (contrast) is 3:1 or greater.
Grei, I am aware of G183. Note the and clause in its name (emphasis added):G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them. I go into this in more detail in my post On Link Underlines.
In addition, there are cases of links in Google results that are not blue, that do not have sufficient contrast, along with links in the sidebar (which could arguably get a pass). This image shows part of Google search results with an arrow pointing to a low-contrast gray text link; more arrows pointing to black and gray links in the sidebar.
I was trying to show Ivy the new iPad on their website- and the site was probably 1/20th functional with medium-slow internet speeds. Should we copy that too? Just a bunch of broken stuff floating around in space / and weird mouse jumps and glitchy paint freak-outs? Apple does it…