I'm making a component for a website where I need to make a checklist with the different W3C guidelines. I currently use a form as a parent element with an article and different details/summary elements inside but I feel like this is not correct semantic HTML. Outside of the component I already use a <h1> and <h2> so I'm not worried about that. I just feel like I'm using the <form> and <article> elements wrong.
<form action="">
{#each principe.richtlijnen as richtlijn}
<article>
<div>
<span>Richtlijn {richtlijn.index}</span>
<h3>{richtlijn.titel}</h3>
</div>
{#each richtlijn.succescriteria as succescriterium}
<details>
<summary>
<label>
<div>
<span>Criteria {succescriterium.index} ({succescriterium.niveau})</span>
<h4>{succescriterium.titel}</h4>
</div>
<input
type="checkbox"
checked={checkedSuccescriteria.find((e) => e.id === succescriterium.id)}
/>
</label>
</summary>
<div>{@html richtlijn.uitleg.html}</div>
</details>
{/each}
</article>
{/each}
</form>
This is the current live link for the component: https://dry-checklist-vervoerregio.vercel.app/ (It's the only component live because it's a school project).
Can anyone help me make my HTML more semantic?
Below are a number of suggestions. Some are partially subjective interpretations of semantics, others are more objective.
Forms
Only use a form element if data is being submitted. Form elements are for "submitting information". If the information in the form isn't being sent anywhere or processed somehow, a form element isn't required (and probably shouldn't be used). Input elements don't have to be children of form elements.
Section vs Article
Each criterion makes sense to be marked up as an article. Article elements are for "self-contained compositions" that are "intended to be independently distributable or reusable". Each of the criteria in the W3C accessibility checklist could stand alone as self contained, independently distributable piece of content.
Use section elements for the guidelines. While the criteria themselves are good candidates for article elements, the guidelines are mostly just a mode of grouping and organizing them as a "generic standalone section of a document"—so a section element seems most appropriate for them.
Indeed this is how the W3C itself marks things up in their How to Meet WCAG (Quick Reference) guide: article elements for criteria, section elements for the guidelines.
Headings and Input Elements in Summary Elements
While it is valid to put headings and input elements inside of summary elements according to the HTML specifications, in practice it can be problematic.
Headings in summary elements can cause accessibility issues. The MDN HTML Element Reference warns:
The same goes for inputs in summary elements. Similarly, since summary elements act like buttons, placing another interactive element (like a checkbox input) inside of it could cause issues for users of assistive technologies as well as the average user, depending on their browser.
These elements would be best placed outside of the summary and details elements.
Heading Groups
Consider using an hgroup for the supplementary headings. The recently undeprecated heading group element "allows the grouping of a heading with any secondary content, such as subheadings, an alternative title". This is a more semantic approach than marking up the supplementary headings with a span in a div. Note that the supplementary headings in an hgroup should be marked up with a paragraph, which isn't very intuitive. Refer to the usage notes for more info.
Example
Here's an alternative approach employing the suggestions above: