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:
- 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 (
:focus-visibleandinert) or CSS feature support (:not()) to their browsers. - Apple makes a landing page touting its accessibility accomplishments, but the page itself has accessibility issues (not all are false positives, despite response).
- Google has a VPAT for Gmail that does not accurately describe its conformance, easily provable, and frustrating yet another claim of “but Google uses these colors”.
- Definitely do not follow YouTube as a good (or passable) example of how to build and use tabs.
- Google tweets a silent text-heavy video to promote its event for International Day of Persons with Disabilities, which is retweeted by the Google Accessibility account. I call them out, show how to do it accessibly, and Google deletes the tweet without acknowledgment while the Google Accessibility account never speaks of it.
- Google launches Designcember to promote its work on container queries and other technologies, but fails to support the developers and ensure the site is accessible. Which I call out. And for which my free labor is requested to QA fixes.
- Apple claims not once, not twice, but three times to have fixed CSS display property accessibility bugs, finally requiring a change in how Can I Use reports support.
- Google Chrome’s developer outreach site, Web.dev, shared how to build an
accessible
. Sadly, if you follow its advice you are guaranteed a SC 1.4.13 WCAG violation. Never mind translation issues, misunderstanding of how<tool-tip>custom element<abbr>is exposed, a conflation of accessible name and description, and an enforced inability to select text. - Apple demonstrates Safari in visionOS by using a WCAG-failing site to show Apple’s bespoke low-contrast focus styles. For good measure, Apple also promotes problematic HTML structures.
- Google Chrome’s Web.dev is moving off GitHub (again, also after ignoring issues for a year) in favor of to its own IssueTracker with accessibility issues.
- Apple recommends circular checkboxes, ignoring 40 years of UI precedent, in its visionUI design guidelines.
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.
Anyway
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.
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):
Designers: FAANG company uses this pattern so it’s okay!
Me sighing heavily while ushering them to a chair: if a FAANG company tells you to jump off a bridge are you gonna do it?
Don’t fall victim to peer pressure, be thoughtful about your patterns babes. 🌈⭐️
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:
- The profile contributions chart, February 2018, for which I just filed an issue (again) and as of September 2023 has still not rolled out even its moderately improved but still buggy effort at a revision.
- Overriding link text with
aria-label, February 2019, but fixed now. <details>/<summary>as a modal, April 2019, made less bad but still in use.- Tables broken for screen readers, June 2019, not fixed at GitHub but by browsers.
- Does not underline links in content, September 2020, and I just filed a request.
- Promoting inaccessible flowcharts for GitHub, March 2022.
11 Comments
Reply 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.
Reply 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.
Reply 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?!
Reply 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.
Reply 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.
In response to . 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 . 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.
Reply 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…
Reply […] to I Don’t Care What Google or Apple or Whoever Did by Adrian […]
Reply 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 . Reply Yeah, the inaccessible PDF from Google’s Disability Support still comes around as a painful example for me.
Leave a Comment or Response