Add aria-expanded to getAccessibilityTree and <details>/<summary>
#451
Conversation
…g for `<details>`/`<summary>`
| expect(await getAccessibilityTree(page)).toMatchInlineSnapshot(` | ||
| document | ||
| group | ||
| button "Click me! Tags in summary do not preserve their semantic meaning" (expanded=true) (focused) |
There was a problem hiding this comment.
This behavior is according to spec (the <h1> inside of <summary> loses its semantic meaning). But, the behavior does not match voiceover in safari, or chrome or firefox's accessibility tree.
According to the spec:
<summary>implicitly gets thebuttonrole- The
buttonrole is "children presentational" - "children presentational" elements should not directly expose their children in the accessibility tree
It would be more difficult for us to diverge from the spec and implement it the way browsers do. Chrome accessibility tree, firefox accessibility tree, and safari voiceover all chose not to use the button role for <summary> elements. We could add a special override here but I would rather not.
There was a problem hiding this comment.
Here are what browsers use for <summary> elements:
- Chrome devtools accessibility tree:
DisclosureTriangle - Firefox devtools accessibility tree:
summary - Safari VO:
summary, group
There was a problem hiding this comment.
I think it's reasonable to leave this matching the spec. Might be good to add a "known issues" section in the README, though, outlining things like this that might otherwise trigger bug reports.
There was a problem hiding this comment.
👍
I would be open to people opening issues for their use cases where they run into this difference, where we can continue the conversation of whether it makes sense to match the spec here
calebeby
changed the title
aria-expanded support to getAccessibilityTree and fix handling for <details>/<summary>aria-expanded to getAccessibilityTree and <details>/<summary>
Closes #347