Fix accessible-name computation for table, fieldset, image input elements, and for “encapsulation” cases #2438
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7883aa3 to
e85812a
Compare
|
This has conflicts. |
e85812a to
d508d0c
Compare
Thanks for the heads-up — fixed now ✅ |
9281014 to
6c5cfdf
Compare
gmta
reviewed
Nov 25, 2024
This change makes Ladybird conform to the requirements in the HTML-AAM spec at https://w3c.github.io/html-aam/#accname-computation for the cases of HTML table, fieldset, and input@type=image elements. Otherwise, without this change, Ladybird fails to expose the expected accessible names for those cases.
This change makes Ladybird conform to the requirements in the HTML-AAM spec at https://w3c.github.io/html-aam/#accname-computation for the cases of HTML input@type=button, input@type=submit, and input@type=reset elements. Otherwise, without this change, Ladybird fails to expose the expected accessible names for those cases.
This change makes Ladybird correctly handle all “encapsulation” tests in the https://wpt.fyi/results/accname/name/comp_host_language_label.html set of tests in WPT. Those all test the requirement that when computing the accessible name for a <label>-ed form control, then any content (text content or attribute values) from the control itself that would otherwise be included in the accessible-name computation for it ancestor <label> must instead be skipped and not included. The HTML-AAM spec seems to try to achieve that result by expressing specific steps for each particular type of form control. But what all that reduces/optimizes/simplifies down to is just, “skip over self”. Otherwise, without this change, Ladybird includes that “self” content from those “encapsulated” elements when doing accessible-name computation for the elements — which results in AT users hearing unexpected extra content in the accessible names for those elements.
6c5cfdf to
b9897f1
Compare
gmta
approved these changes
Nov 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR branch contains three commits:
e85812a LibWeb: Fix accessible-name computation for “encapsulation” cases
This change makes Ladybird correctly handle all “encapsulation” tests in the https://wpt.fyi/results/accname/name/comp_host_language_label.html set of tests in WPT.
Those all test the requirement that when computing the accessible name for a
<label>-ed form control, then any content (text content or attribute values) from the control itself that would otherwise be included in the accessible-name computation for it ancestor<label>must instead be skipped and not included.The HTML-AAM spec seems to try to achieve that result by expressing specific steps for each particular type of form control. But what all that reduces/optimizes/simplifies down to is just, “skip over self”.
Otherwise, without this change, Ladybird includes that “self” content from those “encapsulated” elements when doing accessible-name computation for the elements — which results in AT users hearing unexpected extra content in the accessible names for those elements.
This change causes Ladybird to pass an additional 6 subtests in the
comp_host_language_label.htmlset of tests at https://wpt.fyi/results/accname/name?product=ladybird.20375dd LibWeb: Fix input@type=button|submit|reset accessible-name computation
This change makes Ladybird conform to the requirements in the HTML-AAM spec at https://w3c.github.io/html-aam/#accname-computation for the cases of HTML input@type=button, input@type=submit, and input@type=reset elements. Otherwise, without this change, Ladybird fails to expose the expected accessible names for those cases.
This change causes Ladybird to pass an additional 3 subtests in the
comp_host_language_label.htmlset of tests at https://wpt.fyi/results/accname/name?product=ladybird.48c639b LibWeb: Fix accessible-name computation for table, fieldset, image input
This change makes Ladybird conform to the requirements in the HTML-AAM spec at https://w3c.github.io/html-aam/#accname-computation for the cases of HTML
<table>,<fieldset>, and<input type=image>elements. Otherwise, without this change, Ladybird fails to expose the expected accessible names for those cases.This change causes Ladybird to pass an additional 4 subtests in the
comp_host_language_label.htmlset of tests at https://wpt.fyi/results/accname/name?product=ladybird.So these two changes together cause Ladybird to pass all 78 tests in the
comp_host_language_label.htmlset of tests at https://wpt.fyi/results/accname/name?product=ladybird.