fix: Adds ariaLabel attribute to navigation block

[singhakanshu00]

What?

fixes #68719

Why?

• The navigation block doesn't preserve the default aria-label attributes passed from a theme pattern when making any change to the template part the pattern is used into.

How?

• In footer.php we are adding ariaLabel as an attribute, but we haven't added this attribute to block.json of the Navigation block.

Testing Instructions

• Activate Twenty Twenty-Four.
• Make sure the Footer hasn't been customized. Reset any change if necessary.
• Go to any page on the front end.
• Inspect the 3 elements in the footer.
• Observe they all have an appropriate aria-label: About, Privacy, Social Media.
• Note: these are the values that come from the theme pattern footer.php.
• Edit the footer and make any unrelated change, e.g.: change the Site title to open in a new tab and save.
• Go to any page on the front end.
• Inspect the 3 elements in the footer.
• Observe the aria-label, it is preserved.

Screenshots or screencast

hey.mp4

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @singhakanshu00! In case you missed it, we'd love to have you join us in our Slack community.

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

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: singhakanshu00 <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: carolinan <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: im3dabasia <[email protected]>
Co-authored-by: afercia <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

Thanks for contributing, @singhakanshu00!

Please use reserved keywords when to link PRs to the issues. See: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests

[carolinan]

Why is the aria label needed as a block attribute when the aria label block support is already enabled?
I think the reason why the block support is not working needs to be researched first.

[singhakanshu00]

Why is the aria label needed as a block attribute when the aria label block support is already enabled? I think the reason why the block support is not working needs to be researched first.

Hi @carolinan
I did research and here was my conclusion to why I decided to add ariaLabel as an attribute:

• https://github.com/WordPress/WordPress/blob/cf9594c4aee929a658242434b8890aa5bbbf5ca1/wp-content/themes/twentytwentyfour/patterns/footer.php#L70 if you see here in the footer.php file from twenty twenty four theme we are adding ariaLabel as an attribute.

• gutenberg/packages/block-library/src/navigation/index.php

  Line 345 in aec60be

  $navigation_name = $attributes['ariaLabel'] ?? '';

  in this line from index.php file of the block we are fetching the ariaLabel from the attribute array, so the first time when it is rendering, ariaLabel is set from the pattern and it is showing in the UI. But once we edit something in the editor, since attribute is not registered, $attributes['ariaLabel'] is returning null and displays an empty string.

Hence I added an ariaLabel attribute. Let me know if I missed something.

Thanks

[Mamaduka]

@carolinan is correct. @singhakanshu00, based on the details you've shared, the root cause of the issue seems to be with ariaLabel support. We should try to fix it there instead of patching the bug for a single block, as it might affect other blocks.

[fabiankaegy]

Adding the supports.ariaLabel flag should automatically register that attribute for any blocks that opt into the flag. There should be no need to manually register the attribute.

If this is currently broken we need to resolve it at the root and not "fix" the cause here :)

[t-hamano]

I think this is a bit of a tricky problem.

The underlying problem is that block support for dynamic blocks is not complete. There are two main reasons for this:

Block support schema issues

ariaLabel support, like other block support, injects attributes via blocks.registerBlockType. The ariaLabel schema references a saved HTML element. This works for static blocks, but not for dynamic blocks like the Navigation block, because the HTML is not saved.

Why is the aria label needed as a block attribute when the aria label block support is already enabled?

This is exactly why we need to add block attributes explicitly, i.e. store them as comments.

We have tried in the past to add anchor support to dynamic blocks as well as static blocks, but encountered similar issues that are still not resolved. See #51402 for details.

Server-side processing

For block support to work in dynamic blocks, registration is required on the PHP side, not just the JS side. However, there is no PHP-side processing for ariaLabel support.

---

To fundamentally solve this problem, I think we need to extend the ariaLabel support and make it work for both static and dynamic blocks somehow.