-
Notifications
You must be signed in to change notification settings - Fork 137
[html-aam PR 359] Change figure & figcaption accName computation #2224
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
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.
|
Now pointing to main. |
|
@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
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 |
dismissing this change request flag as the content in question has been updated
|
these updates are in chromium browsers and webkit, so we are merging this PR (finally) |
|
bug filed on chromium specifically for the figcaption not providing an image an accessible name - https://issues.chromium.org/issues/434213625 |
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.