👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @roseg43! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

An alternative to this solution if the intent is for the template content to act as a heading is to switch the template block over to core/heading. However, this represents an actual semantic change to the default block contents, which may result in theming inconsistencies with Media & Text blocks on older posts/pages.

Regarding the second suggestion: The paragraph was selected for this block because it was not possible to know which heading level would be the correct one.

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @roseg43! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Additionally, if a developer has removed custom font sizes from core/paragraph or the theme itself using theme.json, this class gets applied and then is not removable.

A similar issue has recently been fixed for the Cover block - #34993.

Personally, I'm okay with this change. But it would be nice to get more feedback. Cc @jameskoster, @jasmussen.

My take: yes, okay to remove. Many of these older blocks came with somewhat more opinionated defaults in order to display their variety. As design tools and theme.json properties mature, most of these should be absorbed there, and could potentially evolve to style variant presets if need be. (Such presets would not be class-based as they are today, but rather, shortcuts to predefined design tool settings, such as adding a value to the border radius control rather than attaching that radius to CSS)

Regarding the second suggestion: The paragraph was selected for this block because it was not possible to know which heading level would be the correct one.

That makes a lot of sense, thank you for the context behind the original decision! Given that context I think removing the font size declaration makes the most sense because ideally to meet the requirements of Success Criterion 1.3.1, paragraph text should look like paragraph text in its default state.

And I'll just add: While the larger size does show off the variety of the block, it's also inherently confusing to folks who aren't aware of the difference between semantic headings and text that looks like a heading. As an authoring tool, I would argue that Gutenberg should allow people to create less accessible content, but it should make it a deliberate choice when possible. To that effect, Media & Text is currently making it an unconscious decision.

Congratulations on your first merged pull request, @roseg43! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!

Thanks for the contribution, @roseg43! Congrats on your first merged PR in the Gutenberg project.

Thanks @Mamaduka for reviewing this so quickly! Happy to contribute, and looking forward to contributing more in the future.

I'm changing the label of this from Enhancement to Bug for two reasons:

1. It is an accessibility issue with the semantic structure of the content
2. If a developer has removed custom font sizes from core/paragraph or the theme itself using theme.json, the has-large-font-size class still gets applied and then is not removable via the UI.

Hey @adamziel @peterwilsoncc 👋

I would like to raise this patch for consideration of having it included in a minor WordPress release. I've outlined my rationale for marking this as a bug in the comment above and would love to get your thoughts on it.

Thanks in advance :)

@fabiankaegy Thanks! I've added the backport label to make this come up during the triage.

I just cherry-picked this PR to the wp/6.0 branch to get it included in the next release: c032340