Is this proper semantic html?

45 views Asked by At

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?

1

There are 1 answers

0
Sean On

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:

Because the <summary> element has a default role of button (which strips all roles from child elements), this example will not work for users of assistive technologies such as screen readers. The will have its role removed and thus will not be treated as a heading for these users.

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:

{#each principe.richtlijnen as richtlijn}
  <section>
    <hgroup>
      <p>Richtlijn {richtlijn.index}</p>
      <h3>{richtlijn.titel}</h3>
    </hgroup>
    <ol>
      {#each richtlijn.succescriteria as succescriterium}
        <li>
          <article>
            <hgroup id={succescriterium.id}>
              <p>Criteria {succescriterium.index} ({succescriterium.niveau})</p>
              <h4>{succescriterium.titel}</h4>
            </hgroup>
            <input aria-labelledby={succescriterium.id} type="checkbox" checked={checkedSuccescriteria.find((e) => e.id === succescriterium.id)} />
            <details>
              <summary>Beschrijving van {succescriterium.titel}</summary>
              <div>{@html richtlijn.uitleg.html}</div>
            </details>
          </article>
        </li>
      {/each}
    </ol>
  </section>
{/each}