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.
- Google deploys an update to its browser that can break the web for screen reader users, and lets it sit for for two releases.
- Apple for years has hidden the semantics of lists when they are styled, forcing developers to use hacks to reinsert them.
- Google shares lessons learned from its commendable Disability Support team in the form of an inaccessible PDF document that insists it cannot make accessible.
- Apple continues to fail to build VoiceOver support for an HTML element that has existed since the dawn of HTML and 2½ times longer than VoiceOver on iPhone.
- YouTube announces it is removing the ability for community members to contribute subtitles or captions to videos.
- Apple still does not send a focus event when a native button is clicked, an issue first reported in 2009, again in 2012, again in 2013, and yet again in 2013.
- Both Apple and Google are content to let crowd-funding efforts drive the addition of accessibility features (
inert) or CSS feature support (
:not()) to their browsers.
As I Was Saying
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.
Technique G183 is very controversial. There’s a growing chorus of accessibility specialists who are calling for it to include stronger warnings, or just remove the technique entirely. Much of the controversy surrounds the fact that the “colour == hue” loophole is being introduced by a non-normative technique document. See Technique G183 (and note 1 in F73) provide loophole resulting in inaccessible content (was: Technique G183 not applicable to touch/inputs that lack hover/focus).
I was one of the moderates in that discussion; nowadays I never recommend technique G183. It comes up so often that I’m developing a kind of Spider-sense tingle just before a designer mentions it.
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…