Fix accessible name calculation bug related to nested <label>
s
#1616
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.
A variable was incorrectly being shadowed causing the state to be set incorrectly in some cases. This caused some kind of explosion in the recursion which, if there were enough
<label>
s inside the outer label (more than 5 I think), would lead to the maximum number of stack frames being exceeded.In addition, if the number of inner labels was small enough, it would not crash, but the accessible name of the first
<input>
would be incorrect. This PR fixes that. The names of<input>
s inside the inner<label>
s are still computed differently than what Chrome computes. It's not completely clear yet, if Chrome is actually implementing the spec and if not, if we should follow chrome or the spec.Example
In this example the first
<input>
was getting the computed name of "Foo Foo BarBar" where Chrome would get "Foo Bar". With this PR we are aligned with Chrome for that element.I also updated some function descriptions with some examples to make it a little clearer what exactly referrer and referred means for
<label>
and<input>
s.To do
<input>
should be.