Normalize on using “accessibility child” — not “child elements” #2697
Conversation
This file contains hidden or 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
This makes the following changes: - Replace all occurrences of “child element(s)” or “child(ren)” with “accessibility child(ren)”. - Make ever occurrence of “accessibility child(ren)” a hyperlink to where that term is defined in the spec. - Do similarly for “allowed child(ren)” — make those all actual hyperlinks to #mustContain.
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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 makes the following changes:
#mustContain.Rationale: To typical readers of the spec, it is ambiguous and misleading for the spec to be referring to something as a “child element” — or simply a “child” — in cases where that might not actually be a child in the DOM.
For a typical reader who sees the term “child element” or “child” on its own, it is completely reasonable for that reader to assume that what’s meant by that term is the same as what “child element” and “child” mean in the DOM spec and the HTML spec — and in basically every single other spec for the web platform, everywhere.
Readers cannot reasonably be expected to realize that only when they are reading this spec, “child element” and “child” do not have their normal meaning but instead actually mean “accessibility child”.
So instead always consistently using the (hyperlinked) term “accessibility child” makes the intended meaning unambiguous to readers.
Preview | Diff