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.

Be Best

A very very quick selection of decisions that Google and Apple made that were counter to what experienced usability and UX experts recommended:

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.

The overall argument is based on the appeal to accomplishment fallacy, a variation on the argument from authority when the authority is not agreed upon as a recognized authority, which is a form of red herring fallacy. In other words, if that is your only evidence then you have no evidence.


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:

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.

Update: April 2, 2022

Anna reminds us that what I outline above extends to all the companies in the Facebook, Apple, Amazon, Netflix, and Google (FAANG) world (and whichever ones replace them):

Simply copying patterns that other organizations built for their very specific use cases without a critical evaluation is just lazy.

Update: May 21, 2022

For some reason GitHub’s 2019 use of <details> / <summary> has come up this week, namely people raving about it. I was tagged in a few Twitter threads, some lengthy, and decided I should probably collect some examples of historic GitHub accessibility issues:



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.

Paul Grenier; . Permalink

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?!

zakius; . Permalink

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).

See Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision:

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.

In response to Grei. Reply

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.

In response to Grei. Reply

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.

Andrew Macpherson; . Permalink

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…

sheriffderek; . Permalink

[…] to I Don’t Care What Google or Apple or Whoever Did by Adrian […]


I’ve run into this with document accessibility too, hearing “[ insert name of big corporation here ] did it and it’s accessible, so we can do it too.” The accessibility and usability of the document they referenced was a nightmare for AT and keyboard users.

In response to Colleen Gratzer. Reply

Yeah, the inaccessible PDF from Google’s Disability Support still comes around as a painful example for me.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>