Skip to content

Conversation

@pkra
Copy link
Member

@pkra pkra commented May 24, 2024

Moved from w3c/html-aam#359

closes: w3c/html-aam#564
closes: w3c/html-aam#325

Edit: wpt - web-platform-tests/wpt#49647

Test, Documentation and Implementation tracking

Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.

scottaohara and others added 24 commits January 20, 2022 08:30
resolves #325

This PR revises the mappings for `figure` and `figcaption` to remove the "labelled by" relations, changing them to "details for".
The accessible name computation for `figure` removes `figcaption`, a note is added to further reference this change.

TODO: 
- [ ] need to check on updates to UIA mapping, if any.
- [ ] do we want `figcaption` to map to `caption`? 
- [ ] regardless of above, [`caption`](https://w3c.github.io/aria/#caption) will need to be updated in regards to its referencing `figure` and `figcaption` relationships
- [ ] [`aria-details`](https://w3c.github.io/aria/#aria-details) definition should be updated to reference this change
verified the UIA mappings with help from @benbeaudry 
made some of the wording consistent between mappings
added in a SHOULD to indicate that if a figure is explicitly provided an accessible name from its figcaption, then do not expose the details relationship, as that'd add redundancy.
saying it doesn't know what accname is... so, replacing the instances of the links which may be causing the issue?
see https://bugs.chromium.org/p/chromium/issues/detail?id=1426613#c4

aria-details with an empty string could be useful to authors if there was a specific need to _not_ expose a child figcaption - e.g., if the elements need to have remapped roles for whatever reason.
@pkra pkra changed the base branch from monorepo_history--html-aam to main June 12, 2024 19:19
@pkra pkra changed the title [Monorepo] [html-aam PR 359] Change figure & figcaption accName computation [html-aam PR 359] Change figure & figcaption accName computation Jun 12, 2024
@pkra
Copy link
Member Author

pkra commented Jun 12, 2024

Now pointing to main.

@rahimabdi
Copy link
Contributor

rahimabdi commented May 11, 2025

@scottaohara I've added an implementation tracker to this issue, and a link to the WebKit bug. I'm landing a WebKit PR (WebKit/WebKit#45222) and came across a question during implementation for <img> accname:

If the accessible name is still empty and there are no alt or title attributes, and the img is a descendant of a figure element with a child figcaption but no other flow content or whitespace descendents, then use the text equivalent computation of the figcaption element's subtree.

Should this be "but no other flow content or non-whitespace descendants"? I believe whitespace counts as flow content (and as text nodes), so curious if those should not factor here and should be stripped to ensure the <figure> only has an <img> and <figcaption> as descendants in this particular accname step.

@scottaohara scottaohara dismissed cookiecrook’s stale review June 5, 2025 14:07

dismissing this change request flag as the content in question has been updated

@spectranaut spectranaut moved this from All PRS to Waiting For Implementation in ARIA Normative PR Tracking Jun 13, 2025
@scottaohara
Copy link
Member

these updates are in chromium browsers and webkit, so we are merging this PR (finally)

@scottaohara scottaohara merged commit 8194ea6 into main Jul 25, 2025
7 checks passed
@scottaohara scottaohara deleted the monorepo_history--html-aam-pr359 branch July 25, 2025 17:51
@scottaohara
Copy link
Member

bug filed on chromium specifically for the figcaption not providing an image an accessible name - https://issues.chromium.org/issues/434213625

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

Labels

spec:html-aam waiting for implementations Cannot be merged until there are two browser impls or one impl + impl commit

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Stop automatically exposing details relation for figure -> figcaption Should figcaption participate in name/desc computation?

8 participants