My Request to Google on Accessibility
Hey, Alphabet or Google or Chrome or whomever in that illegal monopoly continues to release things to the web platform that are full of accessibility barriers, I have what I think is a straightforward request.
My Request
Please, if your team cannot explain how the thing satisfies all WCAG Success Criteria at Level AA, then don’t release the thing.
If the thing is a new feature for the web platform (HTML, CSS, ARIA, SVG, etc.), then don’t even propose the thing until you have its WCAG conformance sorted.
Then understand WCAG is the bare minimum, is only table stakes, and does not in itself guarantee the thing is accessible. Which means be prepared for the thing to still contain barriers that must be addressed before it goes any further. Which means you’ll field some questions.
Blowback
I’ll run with two examples lead by Google in the web platform standards world, one older and one recent.
1. Toasts
In 2019 I got involved in a Google-lead effort to create a toast element (sorta). I gave ARIA feedback, helped make the GitHub content more accessible, and challenged some assumptions (primarily what they called research). I commented on only three other issues. Those links cover the totality of my involvement.
The toast effort died on the vine, I believe because it wasn’t well-scoped. And I got blamed for it (for being negative, disingenuous) and apparently I also never apologized. I wrote about this experience in more detail at Scraping Burned Toast.
2. Carousels
In late 2024, doing an end-run around the HTML spec and the concept of separation of concerns, Google drove carousels in the CSS Working Group. Then accessibility experts got wind of it and weighed in (more than just the once), only to get no traction.
Instead, Chrome did a dog-n-pony show (with the requisite accessibility lies). Prominent voices promoted it, some wrongly cooed over its accessibility, but only one person took the time to actually try it — and found it wanting. She got sideways criticism for a 6,000-word post and the implication that accessibility experts didn’t do enough. Who could have predicted?
Book-ends
Both of these book-end five years of a consistent experience for me (15 years based on posts linked below). Accessibility experts and disabled users (and the wonderful overlap of both groups) are not consulted at the start. Not in the scoping, not in the research, and not even in traditional shift-left-but-not-left-enough design phase.
Instead, we stumble across these things. We raise alarms or concerns or questions and are seen as buzzkills. Fun police. Hindrance to progress. We flag barriers and are ignored or dismissed or even harassed. And when the project inevitably catches fire, despite claims accessibility is baked in or the assertion it’s only a beta, we are told we didn’t weigh in early enough. We didn’t donate enough time. We didn’t participate in whatever opaque process in our copious free time.
Of course, ableism makes it easy to forget that accessibility experts and disabled users are already under a constant DDoS attack for our attention, never mind dealing with a US federal government that wants us to go away. I know I said I’m good at being a party-pooper, but I don’t want to be. It’s draining. And frankly, Google, it’s your fault (though not yours alone).
A Brief and Select History of WTF

- Google Material Design told us form fields were better without boxes, until they tested it (even though we all knew that was crap).
- Google sometimes deploys browser updates that can break the web for screen reader users, and then lets it sit for for two releases.
- Google shared lessons learned from its commendable Disability Support team in the form of an inaccessible PDF document it wrongly insisted it could not make accessible.
- YouTube removed the ability for community members to contribute subtitles or captions to videos.
- Google was content to let crowd-funding efforts drive the addition of CSS feature support (
:not()
) to its browser. - Google twaught a silent text-heavy video to promote its event for International Day of Persons with Disabilities, which the Google Accessibility account retwaught. When I pointed this out and showed how to do it accessibly, Google memory-holed its tweet.
- Google launched Designcember to promote its work on container queries and other technologies, but failed to support its own developers to ensure the site is accessible. Which I called out. And for which my free labor was requested to QA its fixes, but I did turn it into a teachable moment.
- Google Chrome’s developer outreach site, Web.dev, shared how to build an
accessible
. If you followed its advice you were 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. 2½ years on, other than moving my bug report to a new tracker, neither Google overall nor the author has made any effort to fix it. - Google Chrome’s Web.dev moved off GitHub (again) in favor of its own IssueTracker with accessibility issues, limiting participation.
- Google has updated Material Design to “Expressive” and, in a repeat of its tendency for confirmation bias with Material UI efforts, seems to again engage in lackluster research.
Wrap-up
Do you work for the company that formerly claimed it wouldn’t do evil? It sucks if you take this as a personal attack. It’s not. Your employer is simply doing a terrible job of supporting you in your efforts to support disabled users. If you want to be angry or frustrated, be angry or frustrated at the multi-billion dollar company that keeps throwing up barriers instead of spending a negligible amount of money to get experts and users involved.
It’s a paycheck that puts food on the table. I get that. Take its money and do what you can.
If you work for not-Google, like, say, Apple or Microsoft or Meta or Adobe or whatever, don’t be smug. If I had the energy I could take all of your employers to task for similar, egregious violations of user trust.
I did this rant in only one thousand and seven words!
Related

More of where I’ve tracked when Google has broken, dismissed, or forgotten accessibility and users.
- Google’s Web Book May Not Help Those Who Need It Most, November 2010
- New Main Element Approved, then Blocked, November 2012
- Google Maps: Misbehaving with UA Sniffing, January 2013
- I Don’t Care What Google Did, Just Keep Underlining Links, March 2014
- Use Only One <main> on a Page, September 2015
- Google’s AMP HTML, October 2015
- Tables, CSS Display Properties, and ARIA, February 2018, and not restricted to Google
- Scraping Burned Toast, June 2019
- I Don’t Care What Google or Apple or Whoever Did, March 2020, and not restricted to Google
- Don’t Rely on YouTube Transcripts, November 2020
- More Google and Afterthought Accessibility, January 2022
- It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties, July 2022, and not restricted to Google
- Comparing Manual and Free Automated WCAG Reviews, January 2023
- Baseline Does Not Really Cover Baseline Support, December 2023
- Don’t Use Web•dev for Accessibility Info, July 2024
One Comment
Thank you, Adrian. Will share some more thoughts with you directly.
Leave a Reply to Mark Lasser Cancel response