Notes: "Show more" collapse is not exposed correctly to screen reader and keyboard users

[adamsilverstein]

Claude did the digging here, findings below:

Description

Long notes collapse to three lines with a "Show more" / "Show less" toggle, added in #77446. The collapse is done with CSS line-clamp, which hides the text visually but leaves it in the DOM and in the accessibility tree. @joedolson reported unpredictable NVDA behavior in #72822 (comment) - reading went past the visible boundary but not all the way to the end.

Digging into it turned up three separate problems, one of which reproduces without a screen reader at all.

1. The collapse hides nothing from assistive tech.

Dumping Chromium's accessibility tree over a clamped container (CDP Accessibility.getFullAXTree) returned 1418 characters against 1418 characters of DOM text - nothing was dropped. So a screen reader user hears the entire note, then runs into a "Show more" button that toggles nothing they can perceive. The partial reading @joedolson saw in NVDA looks more like the virtual buffer navigating -webkit-box layout than the accessibility tree truncating, but either way the result is inconsistent across AT.

2. The toggle has no disclosure semantics.

The button carries no aria-expanded and no aria-controls, so the collapsed/expanded state is never announced:

gutenberg/packages/editor/src/components/collab-sidebar/note.js

Lines 227 to 236 in 74dd7dc

	{ isOverflowing && 'edit' !== actionState && (
	<UIButton
	className="editor-collab-sidebar-panel__show-more-button"
	variant="unstyled"
	size="small"
	onClick={ () => setIsExpanded( ! isExpanded ) }
	>
	{ ! isExpanded ? __( 'Show more' ) : __( 'Show less' ) }
	</UIButton>
	) }

3. Content clipped by the clamp stays in the tab order.

Notes allow links through comment kses, and a link past the clamp boundary is still focusable. In a reduced test case with the same CSS as the sidebar:

• the link lays out at y=1263, the clamp boundary is at y=132
• document.elementFromPoint at the link's center returns null, so it is not painted
• one Tab press from the preceding control moves focus to it anyway
• focusing it sets scrollTop: 1152 on the overflow: hidden container

So keyboard focus lands on invisible content, and the container silently scrolls - the collapsed note then shows an arbitrary middle slice of text while the button still reads "Show more". That is a 2.4.7 Focus Visible problem independent of any screen reader.

Worth noting the stylesheet sets both -webkit-line-clamp and the standardized line-clamp, so browsers that have shipped the standard property take the newer code path, which is where the behavior @joedolson describes is still settling:

gutenberg/packages/editor/src/components/collab-sidebar/style.scss

Lines 98 to 104 in 74dd7dc

	&.is-collapsed {
	-webkit-line-clamp: 3;
	line-clamp: 3;
	display: -webkit-box;
	-webkit-box-orient: vertical;
	overflow: hidden;
	}

Step-by-step reproduction instructions

For the keyboard issue, which needs no assistive tech:

1. Open the post editor and add a paragraph block.
2. Add a note on the block with several paragraphs of text, and include a link near the end - eg. paste https://wordpress.org on the last line.
3. Save and reload so the note renders collapsed with the "Show more" button visible.
4. Put focus on the note author's avatar or the note's action button, then press Tab repeatedly.
5. Focus moves to the link that is clipped below the three visible lines, and the note body scrolls to reveal a middle portion of the text while the button still reads "Show more".

For the screen reader issue:

1. With the same collapsed note, read the note with NVDA, JAWS or VoiceOver.
2. The reader continues past the three visible lines. How far it gets varies by reader and browser.

Expected behavior

The collapsed state should be predictable across browsers and assistive tech, the toggle should announce its state, and nothing hidden by the collapse should be reachable by keyboard while it is hidden.

Current behavior

The collapse is visual only, its effect on screen readers varies, and clipped focusable content is still in the tab order.

Environment info

• Gutenberg trunk at 74dd7dc
• Chromium accessibility tree checked via Playwright + CDP; Gecko and WebKit native trees were not tested, so the JAWS / VoiceOver / Orca testing @joedolson asked for still needs someone with those tools

Please confirm that you have searched existing issues in the repo.

• Yes

Related: #72822, #77446, #79261

cc: @joedolson @t-hamano

[joedolson]

Thanks for the detailed research, @adamsilverstein.

I'll add some further testing on your PR, although I won't be able to get to it today.