HTML: Consider replacing <section>s with <article>s about web-app HOT 10 CLOSED

Where a section is appropriate, we should aria-label or (probably better because it is auto-translatable) aria-labelledby.

I can only see one instance of a <section> with an aria-label attribute, and that’s for Definitions. Would it be sensible to just expose that text in a heading? Then we don’t have to worry about translation issues either…

I personally prefer section oder div to structure pages. But that’s my personal preference speaking. The important things are the labels.

With you on that. I’m a big fan of avoiding <div>s as much as possible. However, it seems that (right now, at least) using <section> is really only valuable for developers knowing the role of the container, as it has no real semantic impact. (Though maybe having value for readability for developers is a good reason anyway?!)

I tried nested articles but that still showed only the first one. This seems kind of … wrong to me.

Agreed. <article>s should each have a header too, and there’s no point tying ourselves up trying to make that work.

PS @ovlb it is so delightful to chat about HTML in this way, thanks!

from web-app.

Hi, @laurakalbag, @ovlb, and @tatianamac!

This discussion makes me so happy! Thank you, Laura, for bringing it up.

Laura said:

Would it be sensible to just expose [the "Definitions" label] in a heading?

I think so!

Oscar said:

I would argue for <section>s with role="region" and a descriptive label, to have semantics and higher readability.

As you noted: It Depends™! Too many sections clutter the rotor, and thereby defeat the purpose of the rotor. In its current state, the SelfDefined landing page is terse enough that we should be fine. The best change we can make is to add headings, more than anything else.

I'm envisioning a structure that looks a bit like this:

<section aria-labelledby="term-heading">
  <h2 id="term-heading">Terms</h2>
  <ol role="list">
    <li>Pulchritudinous</li>
    <li>Obsequious</li>
  </ol>
</section>

I say "Terms" here because these are really terms now, not definitions, right?

We need this list role because, in VoiceOver MacOS, list-style-type=none rips the list role off the element.

We could label each sub-list with ARIA so that its meaning is understood, or make sub-list heading itself an h3 and use that to label the list. The rotor digest might then look like this:

Terms h2
# h3
A-E h3
// etc

...and users can navigate those as lists, which will then have those descriptive labels.

This is me spitballing; I have never had to solve the problem of segmenting out a very large list such as this.

I welcome any thoughts, and would like to thank my freiend and fellow accessibility wonk @smhigley for letting me use her as a soudboard while I thought about this thread.

from web-app.

This might be my favourite thread about HTML in the history of ever. Thanks for the additional nuance, EJ.

I think that labelling the first level sub lists (F–L and so forth) is something we should implement and test with some screen-readers. It could make sense if you jump from list to list. Given that we have a lot of lists it’s a way of navigating the page I consider essential.

Another kind of sub lists that we have are the sub terms. Labelling them as «Sub terms of {{main term}}» might make sense too.

Re sections: totally agree that we need to make sure to keep navigation by labelled sections usable. Paramount here is probably to keep divide pages that become too crowded into smaller sub pages (as we did with the definition detail pages).

from web-app.

@ovlb after suggesting labelled subsections, I edited my comment to suggest proper h3 elements in the list, rather only than ARIA labels. Just want to be sure you saw that. I'm still organizing my thoughts so I should have spent longer thinking before posting. :)

I do agree that we can try itemizing sub-lists in some way. We can test it as long as we are appropriately cautious of our tendency as sighted people to do Too Much™ or to drift from the way people actually use screen readers.

from web-app.

Thanks for this, Laura! The semantics/page structure is a bit messy, having another person look into it is much appreciated.

Some quick feedback:

I think we might be able to get rid of some <section>s altogether. E.g. the definition list is a nav that is wrapped in a totally useless section. Where a section is appropriate, we should aria-label or (probably better because it is auto-translatable) aria-labelledby. I personally prefer section oder div to structure pages. But that’s my personal preference speaking. The important things are the labels.

Re Safari reader mode: That’s a weird one. To fix it, we would have to wrap all definitions in an article and change the root element of a single definition to be a section. I tried nested articles but that still showed only the first one. This seems kind of … wrong to me.

This would fix it:

• Change the root of the definitions to be a ol
• Change the root of a single definition to be a li

Changing the semantics to a list makes sense here, I guess. Plus, users of assistive technology would be able to navigate the list by headlines and list items, however they prefer.

from web-app.

I can only see one instance of a

with an aria-label attribute, and that’s for Definitions. Would it be sensible to just expose that text in a heading? Then we don’t have to worry about translation issues either…

I put together a quick demo to test this question, and it seems like:

• iOS VoiceOver with Safari adds only the labelled elements to the landmarks menu
• NVDA with IE11 does only recognise divs/sections with role="region" set
• NVDA with EdgeHTML/EdgeChromium/Firefox recognises only the labelled elements

Unfortunately, NVDA announces label and headline of the region, which makes for some redundant output if the headline is the label.

So, the answer – as always – is «it depends». In general, I would argue for <section>s with role="region" and a descriptive label, to have semantics and higher readability. :)

P.S. I share the delight. Thanks to you, too :)

from web-app.

@ovlb Do you have final closing thoughts on this issue? I'd like to either be able to resolve either way?

from web-app.

@dengeist I'd love your weigh in here if you have a moment!

from web-app.

@dengeist Ah, Right. Good point. If I remember correctly WebAIM’s last Screen Reader usage study found that the prevalence of users navigating by headline is way higher than those navigating by landmarks. Marking them up as headlines might help.

Maybe we can implement a solution and ask for feedback in the Web A11y slack channel to get an outside perspective :) We could use the deploy preview of the PR to get this before merging to live.

from web-app.

FWIW I had A-F, G-L, M-P, Q-Z or some arbitrary "I don't know how to count letters" breakdown at one point. I agree that it's sensible to do so, particularly if we can balance the number of terms visually/contextually (some letters may end up having way more terms than others).

I agree with @dengeist 's recommendation of revealing more h-hevel hierarchies.

To be explicit, could we summarise this task now as:

• Break words into lists
• Label list headings for letters, then terms with subterms
• Implement aria grande labels wherever necessary
• Screenreader test
• Put out deployed branch to A11y Slack for feedback
• Implement any feedback
• Deploy

I want to make sure we leave this Issue with an actionable way to close or to wontfix it if a conclusion can't be reached.

from web-app.