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 :)