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

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

Closed
1 task done
ITenthusiasm opened this issue Aug 8, 2023 · 10 comments
Closed
1 task done

Comments

@ITenthusiasm
Copy link

ITenthusiasm commented Aug 8, 2023

System info

  • Playwright Version: @playwright/[email protected],
  • 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.

@ITenthusiasm
Copy link
Author

ITenthusiasm commented Aug 8, 2023

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

Okay this should be good to go.

@ITenthusiasm ITenthusiasm changed the title [BUG] Unable to Locate the <summary /> Element by Its Implicit button Role Aug 8, 2023
@ITenthusiasm 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
Copy link
Contributor

dgozman commented Aug 8, 2023

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
Copy link
Author

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
Copy link
Contributor

dgozman commented Aug 9, 2023

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

@dgozman dgozman self-assigned this Aug 9, 2023
@dgozman dgozman added v1.38 and removed triaging labels Aug 9, 2023
@ITenthusiasm
Copy link
Author

@dgozman Sounds good! Thanks for considering!

@ITenthusiasm
Copy link
Author

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
Copy link
Contributor

dgozman commented Aug 28, 2023

@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
Copy link
Author

@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).

@aslushnikov aslushnikov added v1.39 and removed v1.38 labels Aug 30, 2023
@ITenthusiasm
Copy link
Author

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

@pavelfeldman
Copy link
Member

Why was this issue closed?

Thank you for your contribution to our project. This issue has been closed due to its limited upvotes and recent activity, and insufficient feedback for us to effectively act upon. Our priority is to focus on bugs that reflect higher user engagement and have actionable feedback, to ensure our bug database stays manageable.

Should you feel this closure was in error, please create a new issue and reference this one. We're open to revisiting it given increased support or additional clarity. Your understanding and cooperation are greatly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants