Add lint rule to make sure <details> elements have a <summary> element
#23
Conversation
|
@koddsson thank you for this 💪 Would you mind adding a corresponding rule doc in docs/rules/accessibility and linking to it in the README? (side note: we should introduce a workflow action to check this) |
| assert_equal @linter.offenses.count, 1 | ||
| end | ||
|
|
||
| def test_does_not_warn_if_only_disabled_attribute_is_set |
There was a problem hiding this comment.
I think this test description needs to be updated.
| # Find the details element index in the AST | ||
| index = processed_source.ast.to_a.find_index(tag.node) | ||
|
|
||
| # Get the next element in the AST |
There was a problem hiding this comment.
Do you know if there's any reason to support <summary> not being the immediate next element? I don't know it's valid anyways but worth verifying.
<details>
<p> some text </p>
<summary>Toggle</summary>
</details>There was a problem hiding this comment.
There isn't an easy way for getting the children of a element with erblint since we only have access to the tag nodes without the actual HTML tree structure.
One approach we've taken is keeping track of the opening/closing tag with variables. Here is an examples where we do this in dotcom:
This approach might make sense if we wanted to allow <summary> that isn't a first child, or if we wanted to give a specific warning message for <summary> that isn't first child.
There was a problem hiding this comment.
Do you know if there's any reason to support
<summary>not being the immediate next element? I don't know it's valid anyways but worth verifying.<details> <p> some text </p> <summary>Toggle</summary> </details>
Hmm, I thought it needed to be the first element but that doesn't seem to be true. I wonder if it's worth supporting or if we should also validate that <summary> is the first element for consistency 🤔
I'll change this to allow <summary> to be anywhere within <details> for now.
| MESSAGE = "<details> elements need to have explict <summary> elements" | ||
|
|
||
| def run(processed_source) | ||
| tags(processed_source).each do |tag| |
There was a problem hiding this comment.
| tags(processed_source).each do |tag| | |
| tags(processed_source).each_with_index do |tag, index| |
then you could get rid of line 21!
We have a meta test in https://github.com/github/eslint-plugin-custom-elements/blob/main/test/check-rules.js that makes sure that each rule is documented in a specific way and that the documentation is linked from the README if you're looking for inspiration. |
koddsson
changed the title
<details> elements have a <summary> element<details> elements have a <summary> element
| ```erb | ||
| <details> | ||
| <div><summary>Expand me!</summary></div> | ||
| I have a invalid summary tag! The summary tag needs to be a direct child of the details tag. |
There was a problem hiding this comment.
I like that you call this out!
lib/erblint-github/linters/github/accessibility/details_has_summary.rb
Outdated
Show resolved
Hide resolved
| # This assumes that the AST provided represents valid HTML, where each tag has a corresponding closing tag. | ||
| # From the tags, we build a structured tree which represents the tag hierarchy. | ||
| # With this, we are able to know where the tags start and end. | ||
| def build_tag_tree(processed_source) |
There was a problem hiding this comment.
This is awesome!!
This assumes that the AST provided represents valid HTML
What happens when the AST doesn't represent valid HTML? I'm guessing ERB lint rules like SelfClosingTag and ParserErrors ensures we don't end up in that state?
Should we add tests for this method, either in this PR or as a follow up?
There was a problem hiding this comment.
What happens when the AST doesn't represent valid HTML? I'm guessing ERB lint rules like
SelfClosingTagandParserErrorsensures we don't end up in that state?
Yes, I believe this is the case. cc @manuelpuyol for confirmation.
Should we add tests for this method, either in this PR or as a follow up?
Good shout. I'll add some tests.
Co-authored-by: Kate Higa <16447748+khiga8@users.noreply.github.com>
|
Running this on I feel like I gotta fix those before merging. |
|
Removing my assignment. cc @github/accessibility-reviewers (this project’s CODEOWNER) |
Hey 👋🏻
Here's a rule that makes sure that
<details>elements have a<summary>element as well. While a<details>element doesn't need to have a<summary>element, it's good practice to provide one and not let the user agent inject one. Details elements should have a descriptive<summary>element instead.I haven't written a rule that checks the child elements of a element before so I'm happy to make revisions if I'm doing the child querying incorrectly.