[Rule_Bug]: The tabbable element’s role ‘region’ is not a widget role

[Mahalakshmivignesh]

Project

other

Browser

Chrome

Operating System

MacOS

Automated testing tool and ruleset

IBM Equal accessibility checker

Assistive technology

No response

Description

In my UI page, i have two

that are scrollable depending on the content length. the accessibility error that i got ‘The scrollable element

with non-interactive content is not tabbable’ as fixed by adding tab index to both of these div. But only for the div in the right hand side, i am getting new accessibility error ’The tabbable element’s role ‘region’ is not a widget role’.

• What would be the reason i get this error only for one of the scrollable panes?
• If region is not a valid widget role, what else should i give?
• any other suggestion on fixing this error?

Steps to reproduce

Project specific. css definitions are as below:
.inputSchemaJSON {
position: relative;
float: left;
height: 332px;
max-height: 332px;
width: 50%;
border-right: 1px solid #E0E0E0;
border-top: 1px solid #E0E0E0;
padding-left: 20px;
padding-right: 20px;
padding-bottom: 20px;
overflow-y: auto;
}

.outputSchemaJSON {
position: relative;
float: right;
max-height: 332px;
height: 332px;
width: 50%;
border-top: 1px solid #E0E0E0;
padding-left: 20px;
padding-right: 20px;
padding-bottom: 20px;
overflow-y: auto !important;

slack discussion link - https://ibm-systems-z.slack.com/archives/C036P1CTN/p1726218784246219

[philljenkins]

What would be the reason i get this error only for one of the scrollable panes?

The left region has overflow-y: auto;, and the right (second) region has overflow-y: auto !important;. Without access to the full page, it’s not clear if this is dynamically set or not.

Besides using !important for standard reasons, such as overriding other "inherited" or parent/child CSS settings and avoiding bugs in non-Chromium IE (neither may not be applicable in this case), it's also considered to be a "good trick" to automatically force the browser to display the otherwise disabled vertical scroll bar even when the region is not vertically very long. Accessibility is impacted when scroll bars appear or are absent depending on the content.

!important also prevents your pages from shifting left or right when user either goes from a shorter page to a longer one or expands/collapses a tab or section. Without access to the page we can't test this.

There several RuleIDs at play, two of which are:

1. element_scrollable_tabbable: Scrollable elements should be tabbable or contain tabbable content. The scrollable element <{0}> with non-interactive content is not tabbable
2. element_tabbable_role_valid: A tabbable element must have a valid widget role. The tabbable element's role '{0}' is not a widget role

Depending on the dynamic state of the page and scrollable regions when loaded, a rule will flag an error on regions that have scroll bars but that do not contain keyboard tabbable content (or tab index) because users in some browsers, such as Firefox (if I remember correctly), will not be able to navigate using the keyboard tab key to the region and then use the keyboard to scroll the content into view. The opposite is also true, which I think is your case, that tabbing to a region that contains non-interactive content that doesn’t need to be scrollable or the role (widget type) is wrong/unknown will confuse the user.

The Learn more link includes this explanation:

… When users reach elements by tabbing with the keyboard, the element's role provides context about the expected interaction, and assistive technologies like screen readers can provide additional information about ways to interact. The only elements that should be in the tab order should be operable widgets. Inoperable elements, such as headings, can be given focus by developers; however, they should not be tabbable by the user. …
The Checker also detects content blocks that get keyboard focus to enable scrolling of the area using arrow keys when coding CSS overflow: scroll or overflow: auto. Both attributes could be valid. However, if the element should not be operable with the keyboard, then it should not be tabbable and get keyboard focus.

@Mahalakshmivignesh

• Why is the design set to always include the scroll bar on the second region?
• Can you provide access/link to the page so we can dynamic test and check rule logic?