Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make sure $label_markup is always defined. #16189

Merged
merged 1 commit into from
Aug 1, 2019

Conversation

SergeyBiryukov
Copy link
Member

Fixes #16188.

Description

Since $label_markup in render_block_core_search() is defined conditionally, it causes a PHP notice if there's no label provided.

Making sure that the variable is always defined fixes the issue.

Screenshots

Screenshot of the PHP notice

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@gziolo gziolo added [Package] Block library /packages/block-library [Type] Code Quality Issues or PRs that relate to code quality labels Jun 16, 2019
Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing 👍

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 16, 2019
@afercia
Copy link
Contributor

afercia commented Jun 16, 2019

It's important to note that the search input field should always be labelled.

WordPress aims to produce semantic, web standards compliant, and accessible markup in the front end. This block should make sure there's a label. If developers want to visually hide the label (which is not recommended), then there should be an option or a fallback to a visually hidden label (with screen-reader-text).

Input fields can be labelled in a few ways:

  • recommended: with a visible <label> element associated with for/id attributes, according to the WordPress accessibility coding standards
  • with an aria-label attribute set on the input field
  • with an aria-labelledby attribute referencing some existing, visible, text in the page

Seems to me the simpler, and more standard, option is the first one. A simple fallback could be:

  • when the label is empty, fallback to a default label Search
  • add the screen-reader-text CSS class to the label element
  • document somewhere that a label is required and, if desired, developers can visually hide the label but that's not recommended 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Block library /packages/block-library [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Undefined variable notice in render_block_core_search()
4 participants