Thrilled Modern Web Guidance is now out, keeping quiet has been SO HARD! š¤
Iāve had the opportunity to collaborate with Google on this project as a domain expert consultant over the past few months, and have seen firsthand the level of thoughtfulness and genuine care for developers and the web platform that has gone into it. ā¤ļø
Itās still very early days, but Iām proud to have played a small part, and excited for what's next. Looking forward to seeing what folks build!
@philipwalton to discuss it in more detail in 30 mins!
@leaverou Hey Lea!
I was looking for the accessibility section and the only thing I could find was about syncing :user-invalid with aria-invalid, and this is described as the way to make error announcements accessible?
I also couldn't find any accessibility guidance for keyboard management so now I'm assuming it refers to the built-in management that comes with <dialog> and popover?
Is this all? or am I missing something important somewhere?
@SaraSoueidan Hi Sara!
AFAIK most a11y guidance lives with the relevant use case guides ā I believe the (in development) accessibility section you saw is intended for big picture a11y guidance + use cases *specifically* about a11y.
The idea being that a11y is an essential part of implementing a use case, not something the agent should search for separately.
That said, there are definitely gaps ā it's a very early preview! If you can, please file issues, even if terse šš¼
@leaverou Thank you Lea! That's helpful.
Another question: Are the gaps documented so we can know about them?
@SaraSoueidan @christianoliff I can assure you that everyone who worked on MWG, within and outside Google, sees a11y as a big priority. And as @castastrophe said, all were fairly compensated. I suggested opening issues because itās early and there are oversights, not because anyone expects to develop the bulk of the content this way.
PS: Google is among the few browser vendors that DO compensate web platform folks fairly instead of expecting free labor, so thatās quite unfair.
@leaverou @christianoliff @castastrophe My statement is also based on past experiences with features made by Google, and that we (community) discussed within the last year.
Documentation/Best practices are good but how do they translate into implementation? has user testing been done by people with disabilities for a project at this scale and impact? I haven't dug in yet (again, no time capacity especially in the midst of everything happening in Lebanon), but others are: https://toot.cafe/@aardrian/116608683977339586
@[email protected] Ok, more things I see immediately... ā¢ `<div>`s with `aria-label`, breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Don%27t%20put%20aria%2Dlabel%2Faria%2Dlabelledby%20on%20elements%20that%20shouldn%27t%20be%20named%20%E2%80%94%20e%2Eg%2E%20plain%20%3Cdiv%3E%2C%20%3Cspan%3E%2C%20or%20custom%20elements%20without%20a%20role%2E ā¢ Low-contrast text. LOTS. Breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Minimum%20contrast%20standards%3A%20Maintain%204%2E5%3A1%20for%20normal%20text%20and%203%3A1%20for%20large%20text%20or%20icons ā¢ Named regions _in_ `<details>`? ā¢ `aria-controls` on `<summary>`? ā¢ SVG chart values not exposed, navigable. Errors aside, this is over-engineered (for the prompt even), encodes unnecessary dependencies on fonts, is meant for Chrome viewers. Sure, it gets some basics right, but Iād send a team back if they brought this.
@leaverou @christianoliff @castastrophe @aardrian To elaborate more on: "My statement is also based on past experiences with features made by Google, and that we (community) discussed within the last year."
Google has become infamous for releasing features without enough consideration for a11y. Move fast & break thingsāfor people with disabilities. And when a11y SME criticize, the response usually is "open issues and help us fix this" when they could have hired a11y ppl from the start [cont'd]
@leaverou @christianoliff @castastrophe @aardrian ...and by "a11y people" I don't just mean a11y advocates/practitioners. I also mean people with disabilities who can test features and provide real feedback based on their experiences as disabled AT usersāexperiences that many of us specialists/advocates don't have.
So when I say Google wants free labor from SME, it's partly because of this too.
@leaverou @christianoliff @castastrophe @aardrian
Some past context and examples articulated way better by Adrian than I can possibly do in short posts on Masto:
https://adrianroselli.com/2022/11/accessibility-gaps-in-mvps.html
https://adrianroselli.com/2025/05/my-request-to-google-on-accessibility.html
@SaraSoueidan @christianoliff @aardrian
These posts make the point that itās ok for an MVP to have accessibility bugs, but not to ignore a11y altogether, and I agree.
After browsing even this early preview your impression is that a11y was not considered? Iām not an a11y expert but Iād find that baffling ā are we looking at different repos?
As both @castastrophe and I explained, a11y was considered separately for every individual use case guide, and baked in it. [1/n]
@leaverou @christianoliff @aardrian @castastrophe "These posts make the point that itās ok for an MVP to have accessibility bugs, but not to ignore a11y altogether, and I agree."
These posts make the point that companies claim one thing but the product falls short on those claims. So far, MWG does the same.
The guides are there, but the implementation tells a different story it seems. Remember that devs will use AI to generate the code; they won't use the guides to write the code themselves.
@castastrophe @leaverou @christianoliff @aardrian
"Disabilities come in a lot of shapes and sizes."
I didn't say otherwise.
"I'm autistic and was involved."
Yes, I know. I checked your profile and saw you have lived experience (and hit the follow button :))
"many of the authors are trained and studied and test our code in screen readers to validate the approaches, yes."
I do too, but I'm still not a daily SR user so I can't speak on behalf of disabled daily SR users.
@SaraSoueidan @christianoliff @aardrian @castastrophe Which examples have you seen? Because one that made the rounds earlier today was someone using stock Gemini thinking MWG was baked in it (itās not, it must be installed separately).
And yes, there are evals to verify that the guidance is followed which run prompts repeatedly in multiple different LLMs and measure what expectations were met, and many of these expectations test the a11y guidance. Itās all in the repo.
@SaraSoueidan @christianoliff @aardrian @castastrophe Also, there is a huge blind spot there: a fair comparison would have run the prompt without MWG and compared the results. LLMs are not deterministic. There is no guarantee any skill will be used for any given prompt.
It doesnāt mean that once you install MWG itās suddenly responsible for any and all bad output your agent produces. The goal is to improve the output *overall*.
@SaraSoueidan @christianoliff @aardrian @castastrophe If you write a skill/guide well, it will be picked often when itās relevant and rarely when it isnāt, but there are no guarantees.
Thatās why evals run things multiple times and measure overall stats.
One prompt run once in one condition tells you absolutely nothing.
@leaverou @christianoliff @aardrian @castastrophe
Excellent! This is the kind of clarification/disclaimers that the general messaging and marketing around MWG needs more of. šÆ
You can compare what I identified with the output Ana got (which, as you know, did not use MWP).
Yes, the MWP output is dramatically better. But it wonāt pass WCAG, despite accessibility claims on the MWP site. Never mind the over-engineering.
My results again:
https://toot.cafe/@aardrian/116608683977339586
@[email protected] Ok, more things I see immediately... ā¢ `<div>`s with `aria-label`, breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Don%27t%20put%20aria%2Dlabel%2Faria%2Dlabelledby%20on%20elements%20that%20shouldn%27t%20be%20named%20%E2%80%94%20e%2Eg%2E%20plain%20%3Cdiv%3E%2C%20%3Cspan%3E%2C%20or%20custom%20elements%20without%20a%20role%2E ā¢ Low-contrast text. LOTS. Breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Minimum%20contrast%20standards%3A%20Maintain%204%2E5%3A1%20for%20normal%20text%20and%203%3A1%20for%20large%20text%20or%20icons ā¢ Named regions _in_ `<details>`? ā¢ `aria-controls` on `<summary>`? ā¢ SVG chart values not exposed, navigable. Errors aside, this is over-engineered (for the prompt even), encodes unnecessary dependencies on fonts, is meant for Chrome viewers. Sure, it gets some basics right, but Iād send a team back if they brought this.
Another warranting a response.
You do not address any of the issues I identified here, which Sara linked:
https://toot.cafe/@aardrian/116608683977339586
I have more responses coming to individual posts. Iām using #NecroMWP so itās easier to find my out-of-timeline individual responses (and mute them, if you prefer).
@[email protected] Ok, more things I see immediately... ā¢ `<div>`s with `aria-label`, breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Don%27t%20put%20aria%2Dlabel%2Faria%2Dlabelledby%20on%20elements%20that%20shouldn%27t%20be%20named%20%E2%80%94%20e%2Eg%2E%20plain%20%3Cdiv%3E%2C%20%3Cspan%3E%2C%20or%20custom%20elements%20without%20a%20role%2E ā¢ Low-contrast text. LOTS. Breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Minimum%20contrast%20standards%3A%20Maintain%204%2E5%3A1%20for%20normal%20text%20and%203%3A1%20for%20large%20text%20or%20icons ā¢ Named regions _in_ `<details>`? ā¢ `aria-controls` on `<summary>`? ā¢ SVG chart values not exposed, navigable. Errors aside, this is over-engineered (for the prompt even), encodes unnecessary dependencies on fonts, is meant for Chrome viewers. Sure, it gets some basics right, but Iād send a team back if they brought this.
@SaraSoueidan @christianoliff @castastrophe
2. Re-reading this thread, you make bold claims (no a11y people hired, a11y not considered, free labor expected) with zero concrete evidence to back them up.
Not a single concrete error or omission was mentioned (of which I donāt doubt there are many!), only vague generic allusions.
Instead, the only justification for these claims was your and @aardrianās prior dissatisfaction with the company in unrelated projects!
[2/3]
@leaverou @christianoliff @castastrophe @aardrian I literally just asked an LLM what "sensationalist rhetoric" means and the response is kind of hilarious considering we're meant to be having a productive discourse:
"language designed to provoke strong emotional reactions ā such as shock, outrage, fear, or excitement ā often by exaggerating, dramatizing, or oversimplifying a situation"
@leaverou @christianoliff @castastrophe @aardrian Please re-read it then.
1. I never said no a11y people were hired. (Seriously. Re-read the thread.)
2. I never said a11y wasn't considered. I said it wasn't prioritized. You mentioned gaps https://front-end.social/@leaverou/116604968036839087 and Nathan mentioned omissions due to time constraints https://sunny.garden/@knowler/116605015311224934
3. Yes I would conclude that free labor is expected when the answer to Qs is "open issues and PRs" (which is expected to be without compensation, right).
@SaraSoueidan @christianoliff @castastrophe @aardrian
1. Iāve re-read it 3x now and still see this strongly implied, yes. š¤·š½āāļø
2. There are gaps and omissions about EVERYTHING, not just a11y! Itās not that a11y was deprioritized over other things, itās that this is a very early preview.
3. In every project, āOpen issuesā is the standard response when someone alludes theyāve found issues, without providing details. It doesnāt mean the project is relying on these.
@leaverou @christianoliff @castastrophe @aardrian
"I'm once again demotivated by the expectation of a11y specialists needing to do free labor to make up for Google's lack of prioritization."
This does *not* imply that Google didn't hire a11y specialists. Productive discourse is no longer productive when one party insists that the other implied something they never did. You're putting words in my mouth now that I didn't say. You're misunderstanding and insisting on it.
āwhen they could have hired a11y ppl from the start.ā
Who says they didnāt?
āā
Anyhow, it doesnāt matter whether youāre truly unaware of how it came across or are now backpedaling ā I accept you are not currently making that claim!
@leaverou Thank you. I'm not backpedaling though. But reading it the way you quoted it I understand why it can come across wrong seeing that it ends with a period. I should have indicated that that specific statement was continued/expanded in the next post. https://front-end.social/@SaraSoueidan/116610138440233627 (I'll edit the post to indicate that it's continued)
And it is why I asked (in another post) about usability testing with disabled users (e.g. screen reader users)
@SaraSoueidan Sadly, I donāt have details on the scope and scale of usability testing that happened, I wasnāt involved in that part. All I know is that it was nonzero, which I know is not very useful. š¤·š½āāļø
PS: I love the framing of āusability testing with disabled usersā. Iāve made this point myself in the past, that accessibility is effectively usability for certain user segments, but wasnāt sure how a11y folks felt about it.
@leaverou "Nothing about us without us" is what it all comes back to.
Re a11y vs usability: in my course, the 1st chapter is about a11y vs inclusivity vs usability because I know how important the distinction and *relationship* between them is. There is no usability without accessibility. They're strongly tied. That's also why a11y folks always emphasize that technically accessible != usable. You can only confidently say that it's accessible if it is actually usable (by ppl with disabilities) šš»
Sara linked to my post with multiple concrete errors, which I am linking again:
https://toot.cafe/@aardrian/116608683977339586
So thatās one justification.
My prior ādissatisfactionā is a post that shows a pattern of behavior from Google ā with evidence. Since the best predictor of future behavior is prior behavior, as MWP demonstrates, those posts are appropriate.
End of individual replies. Thank you for your time.
@[email protected] Ok, more things I see immediately... ā¢ `<div>`s with `aria-label`, breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Don%27t%20put%20aria%2Dlabel%2Faria%2Dlabelledby%20on%20elements%20that%20shouldn%27t%20be%20named%20%E2%80%94%20e%2Eg%2E%20plain%20%3Cdiv%3E%2C%20%3Cspan%3E%2C%20or%20custom%20elements%20without%20a%20role%2E ā¢ Low-contrast text. LOTS. Breaking https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md#:~:text=Minimum%20contrast%20standards%3A%20Maintain%204%2E5%3A1%20for%20normal%20text%20and%203%3A1%20for%20large%20text%20or%20icons ā¢ Named regions _in_ `<details>`? ā¢ `aria-controls` on `<summary>`? ā¢ SVG chart values not exposed, navigable. Errors aside, this is over-engineered (for the prompt even), encodes unnecessary dependencies on fonts, is meant for Chrome viewers. Sure, it gets some basics right, but Iād send a team back if they brought this.
While I am loathe to revive this thread, I have to address this:
āThese posts make the point thatā¦ā
Thatās not at all what they say.
1. The first is about MVPs/etc. and accessibility messaging, and does not say bugs are ok.
2. The second is directed *at Google* and asks āPlease, if your team cannot explain how the thing satisfies all WCAG Success Criteria at Level AA, then donāt release the thing.ā
For the PS part, my experience says otherwise. I have been asked to donate time to Google repeatedly. No other browser vendor has done that to me. I am aware of other accessibility practitioners who would say the same. Sure, itās anecdata, but so is yours.
@SaraSoueidan @leaverou The primary accessibility guide is here: https://github.com/GoogleChrome/modern-web-guidance-src/blob/2d86433cc9f33e00c3d5aa8539326020851b17d7/guides/accessibility/accessibility/guide.md
Some use cases have accessibility guidance baked in. In a few, it was intentionally omitted (largely due to time constraints or complexity ā which would be handled in the future).
@knowler Thank you!
Another question please (sorry I'm still getting oriented here): is there a readable list of all use cases and their guides somewhere?
@christianoliff I see you already found the other repo!
For anyone else reading, the difference is explained here: https://github.com/GoogleChrome/modern-web-guidance-src/blob/main/CONTRIBUTING.md#repository-architecture-and-release-flow
I believe the reason is that there is nothing like npmignore for skills ā they just clone the repo ā so you don't want all the dev stuff in there.
Peter Rushforth šØš¦šŗš¦
Lea Verou, PhD
mikesutherland
Sara Soueidan
christianoliff :-)
Matthias Ott
castastrophe
Adrian Roselli, pH0
Nathan Knowler
