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!

https://developer.chrome.com/docs/modern-web-guidance?hl=en

Modern Web Guidance  |  Chrome for Developers

Guidance on how to build for the modern web.

Chrome for Developers

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

@christianoliff Unfortunately I have neither the capacity nor the time (and frankly, not even the motivation) to make issues and PRs. I would probably have more motivation to do it if I had felt that Google had genuinely mad efforts to prioritize accessibility. But 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. It's not fair to us, to developers using the project, and to users.
@SaraSoueidan
I don’t think they need anyone’s free labor. ☺️
@SaraSoueidan @christianoliff The nuance here is that accessibility was prioritized directly into the guides we (as fairly-compensated contractors) wrote rather than as an aside or separate call-out because in our minds, that's how you build valid, modern code. We had many, lengthy discussions together ensuring we were aligned in appropriate best practices.

@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

Adrian Roselli, pH0 (@[email protected])

@[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.

Toot CafĂŠ

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

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

@leaverou @christianoliff @aardrian @castastrophe which brings me back to my first point: Are LLMs following the guides and generating accessible code using those best practices? (Examples I've seen says No) were people with disabilities involved in testing and ensuring the output of the LLMs was actually accessible/usable?
@SaraSoueidan @leaverou @christianoliff @aardrian Disabilities come in a lot of shapes and sizes. I'm autistic and was involved. Were individuals with low-vision involved? I don't know; many of the authors are trained and studied and test our code in screen readers to validate the approaches, yes.

@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 @leaverou @christianoliff @aardrian I saw that follow come through and had to 🥰 squee with my younger self for a minute. So much of your writing shaped my early love of the web.
@castastrophe @leaverou @christianoliff @aardrian I'm honored to hear this. Thank you 🩷
@SaraSoueidan You have contributed so much good to the web community, not just in sharing your knowledge but in raising awareness. (1/3)
For me, contributing to this project was an exciting opportunity to help non-coders produce better results when using AI. I hope professionals like us can tell what good code looks like, but for designers or small business owners trying to use AI to dream or imagine something new, I am hopeful projects like this can give them better results that can reach more users. (2/3)
Whatever the marketing or big corporate messaging is, I'm proud to be trying to make the web better in any way I can and I hope projects like this can add something good. It's certainly not making anything worse. 💜 (3/3)
@castastrophe I, too, am proud and happy that you contributed to the project. Google did something right by including you. I'm sure your work made it better than it would have been without it. 🩷

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

@leaverou @christianoliff @aardrian @castastrophe I posted a link in a previous post.

@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. 💯

@SaraSoueidan @christianoliff @aardrian @castastrophe Agreed, there seems to be a lot of confusion about this and it could be communicated better. I suppose it’s the curse of knowledge — it seems obvious to those of us immersed in this, but it clearly isn’t obvious to everyone!
@leaverou @christianoliff @aardrian @castastrophe Agreed, especially when the general messaging is "your AI can now create modern accessible interfaces!" but the actual way this works is not exactly that simple. It's like those component libraries marketed as being fully accessible without clearly stating that using the components in your projects does still require work & knowledge/skills on your end. This again reminds me of CSS carousels and what the messaging around those was. Similar.

@leaverou

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

#NecroMWP

@SaraSoueidan @christianoliff @castastrophe

Adrian Roselli, pH0 (@[email protected])

@[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.

Toot CafĂŠ

@leaverou

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

@SaraSoueidan @christianoliff @castastrophe

Adrian Roselli, pH0 (@[email protected])

@[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.

Toot CafĂŠ

@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]

@SaraSoueidan @christianoliff @castastrophe @aardrian
[3/3]
I understand that backing up claims requires effort and everyone’s time is limited, but that’s what makes the difference between productive discourse and sensationalist rhetoric. 🤷🏽‍♀️

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

@SaraSoueidan

“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) 🙏🏻

@SaraSoueidan @christianoliff @castastrophe @aardrian Also, I don’t know which guides @knowler was referring to but what I’ve seen from the folks leading the project was that a11y was definitely a priority for *them*.

@leaverou

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.

#NecroMWP

@SaraSoueidan @christianoliff @castastrophe

Adrian Roselli, pH0 (@[email protected])

@[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.

Toot CafĂŠ

@leaverou

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

@SaraSoueidan @christianoliff @castastrophe

#NecroMWP

@leaverou

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.

#NecroMWP

@SaraSoueidan @christianoliff @castastrophe