The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.
- 🇬🇧United Kingdom rachel_norfolk UK
Marking as the patch needs a re-roll if an eager first time contributor at DrupalCon would like to oblige...
- First commit to issue fork.
- 🇮🇳India abhaisasidharan
I've reviewed this and also updated the code to add visually-hidden class in the template_preprocess_fieldset().
I've also tested this and attaching a screenshot that shows the class visually-hidden being added.
@till79 has added tests for the description being shown and hidden. - 🇦🇹Austria vierlex
I have reviewed the MR and can see that an additional a css class 'visually-hidden' will be set for when #description_display is invisible.
The tests are covering the description and the invisibility feature successfully.I also noticed the data attribute 'data-drupal-field-elements' is being added, which doesn't seem to do anything?
Searching through the gitlab repository on the 11.x branch, there is only one more occurrence https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/them...
Maybe this data attribute can be safely removed? Or does this improve accessibility somehow? The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.
- 🇬🇧United Kingdom rachel_norfolk UK
Just to keep this nice issue rolling along…
When adding tests, it is always worth just looking at the format of all the others as a check you’ve done everything “just right”. Also, of course, you can run tools like PHPStan (like the bot does) before committing as a way to see what will happen.
The ultimate irony is that I’m also quite guilty of occasionally forgetting to add this very return type to my own tests!
Great work by the whole bunch of contributors at DrupalCon Barcelona to get it to this stage!