SearchBox role is hardcoded and can not be changed.

[ilyatum]

Environment Information

• Package version(s): 7.128.1

Describe the issue:

In some cases search box is a part of a larger region with a role 'search'. In this case role of the wrapper for a SearchBox need to be change to 'presentation'. However, setting role attribute on a SearchBox control has no effect, it remains "search" for a wrapper and "searchbox" for input.

Reason is that these roles are hard coded and can not be changed. This is the code from SearchBox.base.tsx

  <div **role="search**" ref={this._rootElement} className={classNames.root} onFocusCapture={this._onFocusCapture}>
    <div className={classNames.iconContainer} onClick={this._onClickFocus} aria-hidden={true}>
      <Icon iconName="Search" {...iconProps} className={classNames.icon} />
    </div>
    <input
      {...nativeProps}
      id={id}
      className={classNames.field}
      placeholder={placeholderValue}
      onChange={this._onInputChange}
      onInput={this._onInputChange}
      onBlur={this._onBlur}
      onKeyDown={this._onKeyDown}
      value={value}
      disabled={disabled}
      **role="searchbox"**
      aria-label={ariaLabel}
      ref={this._inputElement}
    />

At least it should be possible to change the role of the outer element.

Actual behavior:

Generated HTML for a SearchBox wrapper has a hard coded role of 'searchbox'.

Expected behavior:

Generated HTML for a SearchBox wrapper has a role attribute set as specified, e.g. "presentation".

Priorities and help requested (not applicable if asking question):

Are you willing to submit a PR to fix? (Yes, No)

Yes.

Requested priority: (Blocking, High, Normal, Low)

Normal.

Products/sites affected: (if applicable)

Word WAC.

[paulgildea]

@ilyatum Thanks for reaching out. Let's follow up to better understand the experience that you are trying achieve.

@ecraig12345 - Is this by design?

[ecraig12345]

SearchBox is a bit weird because the native props are applied to the inner <input>, not the root element. This is actually the reverse of the pattern I think we're trying to move towards, which is that native props are applied to the root (and there's inputProps or an input slot for passing native props to the input), but fixing that would be pretty disruptive. And we probably shouldn't pull out just role and apply it to the root since that could be confusing.

One possible solution is adding a new prop rootProps?: React.HTMLAttributes<HTMLDivElement>. As @ilyatum pointed out elsewhere, that would also allow setting other accessibility attributes on the root if needed.

The other possible solution is switching to apply native props to the root (and adding separate inputProps) as part of version 8. However that's a pretty disruptive change which wouldn't be detected at all by typings and would require manual work to pick up.

[paulgildea]

@ecraig12345 Thanks for analysis. Sounds like we need to make a decision on whether this is something we address in v7, v8, or when we converge SearchBox correct?

[ayuspark]

Hi, there is an issue that is resulted in the hardcoded SearchBox's role.

When we use SearchBox in the CommandBar, it's role is hardcoded, hence the "menuitem" role wouldn't be added to the tag. Then the screenreader wouldn't include the SearchBox when announcing the menuitems.

For instance, a CommandBar like this, if user were on the first item,

the screenreader would say, "item 1 of 5", instead of "1 of 6". User who uses screenreader then would be misled on the number of menuitems.

Wonder when there would be a fix?
Also aka.ms/BAF has dependency on it I think.

Follow up after 14 days @paulgildea sorry for mentioning you -- wanted to get some feedback/update :)

[ecraig12345]

When we were discussing this previously, @dzearing asked @smhigley about it and the suggestion was that since the search role is just a landmark role which doesn't directly do much, maybe we should remove it, so then using it or not is the concern of the app. Though if people specifically need the ability to add custom attributes to the root element for other reasons, it doesn't solve that problem.

[dzearing]

Couldn't we just default to search unless provided?

[dzearing]

Would seem like a non breaking change that could be made now.

[ecraig12345]

It would be a bit weird to pull out just role (from native props) and apply that to the root when other native props are being applied to the input. But we could do it.

[ecraig12345]

For reference

fluentui/packages/react-internal/src/components/SearchBox/SearchBox.base.tsx

Lines 157 to 176 in 1eff0e0

	return (
	<div role="search" ref={mergedRootRef} className={classNames.root} onFocusCapture={onFocusCapture}>
	<div className={classNames.iconContainer} onClick={onClickFocus} aria-hidden>
	<Icon iconName="Search" {...iconProps} className={classNames.icon} />
	</div>
	<input
	{...nativeProps}
	id={id}
	className={classNames.field}
	placeholder={placeholder}
	onChange={onInputChange}
	onInput={onInputChange}
	onBlur={onBlur}
	onKeyDown={onKeyDown}
	value={value}
	disabled={disabled}
	role="searchbox"
	aria-label={ariaLabel}
	ref={inputElementRef}
	/>

[ayuspark]

When we were discussing this previously, @dzearing asked @smhigley about it and the suggestion was that since the search role is just a landmark role which doesn't directly do much, maybe we should remove it, so then using it or not is the concern of the app. Though if people specifically need the ability to add custom attributes to the root element for other reasons, it doesn't solve that problem.

If you can remove it, it allows the commandBar to assign "menuitem" role to the SearchBox when passed in as a commandBar menu item, then it'd resolve the accessibility bug for us.

Currently it's blocking us from passing the benchmark test.

[dzearing]

My recommendation would just be to remove role="search" from the outer DIV as a default, and if role prop is provided, put it on that DIV. There is no reason to put a landmark role on a control like this; that should be an app concern. This recommendation changes the attributes, which might be deemed as "breaking" to some. There is a workaround if you want the landmark back.

The alternative would be to default role to search but let it be provided. I think this is quirky behavior, but technically does not change any defaults now. I would prefer to do what's suggested above.

@smhigley Are you ok with removing the default role=search and letting the role of the container root DIV be definable through role prop? Or better suggestion?

[smhigley]

Removing the default role and letting the app define search landmarks makes sense to me 👍

[dzearing]

PR is up!

[msft-github-bot]

🎉This issue was addressed in #15450, which has now been successfully released as [email protected].:tada:

Handy links:

• Release Notes
• Official NPM Release
• Test the release with Developer Demo Site

[msft-github-bot]

🎉This issue was addressed in #15450, which has now been successfully released as @fluentui/[email protected].:tada:

Handy links:

• Release Notes
• Official NPM Release

[paulgildea]

Sounds like this issue has been fixed. Closing. Feel free to reopen if needed. Thanks!