[BUG]: Unable to Locate the `<summary />` Element by Its Implicit `button` Role #26354

ITenthusiasm · 2023-08-08T19:05:47Z

System info

Playwright Version: @playwright/test@1.36.2,
Operating System: MacOS 12.6
Browser: Chromium

Source code

I provided exact source code that allows reproducing the issue locally.

Config File

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
	projects: [
		{
			name: 'chromium',
			use: { ...devices['Desktop Chrome'] },
		},
	],
})

Test File

test.describe('Accessible Elements', () => {
	test('Finding `summary` Button', async ({ page }) => {
		await page.goto('PATH_TO_HTML_FILE_BELOW')
		const list = page.getByRole('list', { name: /my-list/i })
		expect(await list.count()).toBe(1)

		const button = page.getByRole('button', { name: /expander/i })
		expect(await button.count()).toBe(1)

		const summary = page.getByRole('button', { name: /summary/i })
		expect(await summary.count()).toBe(1) // Fails Here
	})
})

Test Page

<!-- Basic Markup for Reproducing Bug -->
<!DOCTYPE html>
<html>
	<head>
		<title>This is a raw HTML File</title>
	</head>

	<body>
		<ul aria-label="my-list">
			<li>1</li>
			<li>2</li>
			<li>3</li>
		</ul>

		<button>
			<h1>My Element <span>Expander</span></h1>
		</button>

		<details>
			<summary>Summary</summary>
			Some Details
		</details>
	</body>
</html>

Steps

Create a details element in any browser environemnt
Look for the summary element via the button role.
Discover that the summary element is not discoverable. 😭

These steps are executed in the test file above.

Expected Behavior

According to the summary element specifications, the element should be discoverable under the button role.

Actual

Locator.getByRole() is not able to find summary elements by the button role.

The text was updated successfully, but these errors were encountered:

ITenthusiasm · 2023-08-08T19:06:16Z

~~I accidentally hit CMD + Enter. 😕 Still editing this.~~

Okay this should be good to go.

dgozman · 2023-08-08T22:12:03Z

According to the spec https://w3c.github.io/html-aam/#html-element-role-mappings, section summary:

[wai-aria-1.2]
  No corresponding role

Computed Role
  If the element is the first child of its type within a parent details element: html-summary
  Otherwise, if it is not the first child of its type of a parent details element, or it is not a child of a details element: generic role

That said, there is no summary or html-summary role in the list of roles: https://w3c.github.io/aria/#role_definitions, nor in the role mapping list: https://w3c.github.io/core-aam/#mapping_role.

Browsers also think differently:

Chromium: DisclosureTriangle
Firefox: summary
Safari: no role

ITenthusiasm · 2023-08-09T12:26:33Z

Interesting. MDN is usually right, but I guess their information was a little off this time. According to https://w3c.github.io/html-aria/#el-summary, it seems that there are user agents that expose summary as a button, but not all of them necessarily do that. The Testing Library Family currently defaults to button for summarys as well.

Is there a recommended approach for summary elements, then? The point of the getByRole selector is to help developers make sure their application is accessible. To that extent, searching for a summary by a CSS selector is not as reliable -- especially if you're trying to get something by its accessible name.

dgozman · 2023-08-09T15:41:47Z

@ITenthusiasm Perhaps it makes sense to expose summary as a button. We'll see in time for 1.38 release.

ITenthusiasm · 2023-08-09T16:04:42Z

@dgozman Sounds good! Thanks for considering!

ITenthusiasm · 2023-08-15T12:34:01Z

Minor update/correction. It seems that the Testing Library Family doesn't currently expose a role for the summary element -- though it may just be that this hasn't been brought to their attention yet. I'll ask. (What I thought was the summary element earlier was a <button /> belonging to some Accordion component.)

However, it still holds that many user agents use button for summarys, as the earlier link mentions. And we'll still need an accessible way to access <summary /> elements at some point. But in case that piece of information changes things, I figured it was worth mentioning.

dgozman · 2023-08-28T16:12:19Z

@ITenthusiasm

It seems that the Testing Library Family doesn't currently expose a role for the summary element -- though it may just be that this hasn't been brought to their attention yet. I'll ask.

Did you have a chance to raise this issue with Testing Library?

However, it still holds that many user agents use button for summarys, as the earlier link mentions.

Well, even though the link claims this, my manual checks in three browser engines show that none of them does that. So I'd like to be careful instead of inventing our own ideas about the accessible role of summary elements.

I hope that getByText() works for now, even if that's not always ideal.

ITenthusiasm · 2023-08-28T16:51:52Z

@dgozman

Did you have a chance to raise this issue with Testing Library?

Not yet because I got distracted with a busy project. 😕 I can ask them this week.

Well, even though the link claims this, my manual checks in three browser engines show that none of them does that.

Was this from looking at the developer tools or from working with a Screen Reader? Here's my experience on MacOS 12.6 with VoiceOver:

Safari: When navigating to the summary element, VoiceOver announces it has a "collapsed summary, group", but also identifies it as a button that can be clicked to expand the content.
FireFox: Same as above.
Chrome: Element is announced as a "collapsed, disclosure triangle, group". Besides that, same behavior as above.

Although it's old, this article seems to suggest that -- at least at some point in time -- JAWS and NVDA identified summary elements as buttons. I would be surprised if these Screen Readers changed how the element was perceived such that it was no longer viewed as a button in some way.

Ultimately, I think the results of the browser developer tools aren't necessarily going to be the greatest source of reliability. This is because sometimes the Screen Reader Tool that a user is relying on may not see what the browser devtools say, or it may alter/enhance what the browser devtools say (e.g., identifying the summary element as a group, but also as a collapsed, clickable button across all 3 browsers). The results from standard Screen Readers are the results that matter most [when trying to determine how user agents behave] because they represent the experiences that users [who need the a11y tree] will actually encounter. To that extent, the link seems accurate in claiming that many user agents identify the summary element as a button. Would you agree?

Having a role to identify summary elements can be helpful for pages whose summary.textContent is similar to something else on the page -- especially if that role is consistent with how popular Screen Readers behave. However, even with the Screen Readers being mentioned, I understand if there would be a desire to wait to see if a more specific role would emerge. That said, it might be a while since -- from the article (and VoiceOver) -- it seems like user agents have been aware of the element for quite some time and have been content to call it a button (likely because of existing practices with Accordions, and the lack of an explicit role from the standard).

ITenthusiasm · 2023-08-31T13:16:11Z

For Reference: testing-library/dom-testing-library#1252

ITenthusiasm changed the title ~~[BUG]~~ Unable to Locate the <summary /> Element by Its Implicit button Role Aug 8, 2023

ITenthusiasm changed the title ~~Unable to Locate the <summary /> Element by Its Implicit button Role~~ [BUG]: Unable to Locate the <summary /> Element by Its Implicit button Role Aug 8, 2023

dgozman added the triaging label Aug 8, 2023

dgozman self-assigned this Aug 9, 2023

dgozman added v1.38 and removed triaging labels Aug 9, 2023

aslushnikov added v1.39 and removed v1.38 labels Aug 30, 2023

ITenthusiasm mentioned this issue Sep 13, 2023

Accessible Role for summary Element A11yance/aria-query#546

Open

dgozman added P3-collecting-feedback and removed v1.39 labels Sep 22, 2023

dgozman added the feature-role label Jan 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG]: Unable to Locate the `<summary />` Element by Its Implicit `button` Role #26354

[BUG]: Unable to Locate the `<summary />` Element by Its Implicit `button` Role #26354

ITenthusiasm commented Aug 8, 2023 •

edited

ITenthusiasm commented Aug 8, 2023 •

edited

dgozman commented Aug 8, 2023

ITenthusiasm commented Aug 9, 2023

dgozman commented Aug 9, 2023

ITenthusiasm commented Aug 9, 2023

ITenthusiasm commented Aug 15, 2023

dgozman commented Aug 28, 2023

ITenthusiasm commented Aug 28, 2023

ITenthusiasm commented Aug 31, 2023

[BUG]: Unable to Locate the <summary /> Element by Its Implicit button Role #26354

[BUG]: Unable to Locate the <summary /> Element by Its Implicit button Role #26354

Comments

ITenthusiasm commented Aug 8, 2023 • edited

System info

Source code

Config File

Test File

Test Page

Steps

Expected Behavior

Actual

ITenthusiasm commented Aug 8, 2023 • edited

dgozman commented Aug 8, 2023

ITenthusiasm commented Aug 9, 2023

dgozman commented Aug 9, 2023

ITenthusiasm commented Aug 9, 2023

ITenthusiasm commented Aug 15, 2023

dgozman commented Aug 28, 2023

ITenthusiasm commented Aug 28, 2023

ITenthusiasm commented Aug 31, 2023

[BUG]: Unable to Locate the `<summary />` Element by Its Implicit `button` Role #26354

[BUG]: Unable to Locate the `<summary />` Element by Its Implicit `button` Role #26354

ITenthusiasm commented Aug 8, 2023 •

edited

ITenthusiasm commented Aug 8, 2023 •

edited