[html-aam PR 359] Change figure & figcaption accName computation #2224
Conversation
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
cc @cookiecrook to make sure i got this right. thank you
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
changed the title
|
Now pointing to main. |
|
Re-adding reviewers @cookiecrook @aleventhal @jcsteh. |
rahimabdi
added
the
waiting for implementations
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Details relationships have been removed from this PR. So, what this PR does now is
With these changes, screen readers probably SHOULD, if they don't do so already, make sure that
Obviously, i'm not saying any screen reader 'must' do what i outlined, but it seemed the simplest enough way to indicate that some sort of changes to make sure people can effectively understand the figure's content vs caption can be made - since now the overly verbose/redundancy of figcaptions as names to figures is removed - and we will no longer be asking a details relationship to be exposed, since that had the unintended effect of trying to solve one verbosity issue with a different once. |
|
Landed the removal of the auto details relation for Chrome/Edge in https://chromium-review.googlesource.com/c/chromium/src/+/5891779 |
This is a quick and dirty hack to prevent screen readers from reading the content inside the `<figure>` tag twice. Credit to @jcsteh (Jamie) at https://matrix.to/#/!jmuErVonajdNMbgdeY:mozilla.org/$Esj2fvpJ5e2cJPZKQrCyzPBS8lnL0ZQc25vMMvW4lAM?via=mozilla.org&via=matrix.org&via=tchncs.de
a figcaption should not provide a name to a figure element per w3c/aria#2224
|
created web platform test for this PR (also added to OP) - web-platform-tests/wpt#49647 |
| <div class="general"> | ||
| Accessible name derived from `figcaption` according to the <a href="#figure-element-accessible-name-computation">`figure` Element Accessible Name Computation</a> | ||
| </div> |
There was a problem hiding this comment.
Sorry I missed this...
removes figcaption from the name calculation steps in that section of the spec, and explicitly states in that section that figcaption does not contribute to name or description unless specified by the author (e.g., via aria)
What's the reason for this removal? WebKit and Safari implementations agree on using figcaption as the name if none other is provided via ARIA. Seems logical to me to keep this.
There was a problem hiding this comment.
here is one of the examples that was referenced as rational for this change specifically the link to the wicg thread where people are using figcaption to provide transcripts for a video within a figure
There was a problem hiding this comment.
yeah, that's a good example
There was a problem hiding this comment.
Scott and I chatted, and are working on a update that will account for this HTML text:
- If the image is a descendant of a figure element that has a child figcaption element, and, ignoring the figcaption element and its descendants, the figure element has no flow content descendants other than inter-element whitespace and the img element, then return the contents of the first such figcaption element.
Moved from w3c/html-aam#359
closes: w3c/html-aam#564
Edit: wpt - web-platform-tests/wpt#49647