WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Header levels

for

From: Chagnon | PubCom
Date: Aug 3, 2016 12:56PM

Are we discussing headers or headings?
There's a big difference!

Just to clarify, <H1>, <H2>, etc. refer to heading levels, not headers.

This discussion, like so many on this topic before in this forum, indicates that we really don't have a good enough solution yet for this type of material. We keep discussing it over and over on this list and others.

To me, that means we might have a problem with the standards if it's so unclear what to do with sidebars.

Joseph, in your example, I think your sidebar is barely related to the main content of the webpage. In theory, it could stand alone without the rest of the page's main content, or it could appear on any other webpage, too.

No matter how short or long it is, or whether it's labeled with <aside> or not, it really is its own distinctive, unique, stand-alone piece of content.

Therefore, maybe tagging its title "Latest News" with <H1> is appropriate, and its stories below with <H2> tags.

Or, if you think it really does belong nested, theoretically, within the main content, then it's top-most heading could be <H2> with <H3>s for the sub-stories.

I believe our standards must be strong and definitive enough so that it's clear how they should be used. But on the other hand, our standards must give enough wiggle room so that we can apply them to all kinds of content and make the system work for webpages, documents, PDFs, EPUBs, and other types of digital content.

Maybe it's time for the WAI to consider some alternatives for tagging sidebars, asides, call-out boxes, and all the other types of doohickeys that are designed mainly for sighted users but end up confusing the heck out of screen reader users who are stymied by <H5> suddenly appearing when there isn't an <H4> before it.

Heading tags <H1> through <H5> not only label the content, but also connote its location within the document's hierarchy. They help define the document's structure.

The problem brought out with this post, is that sidebars, asides, and other boxed doohickeys often don't fit into any hierarchy or structure. They are not visually designed to fit a "structure" and they aren't intended to do that by the author. So why are we forcing them into a hierarchical structure with our code?

Maybe we need a better solution for this type of material, maybe a new heading level called "Aside Heading" and let it fall wherever it wants to fall within the structure. It really doesn't matter whether it falls under a previous <H2> or <H1> or <H5> for that matter. It falls where it's most logical to fall within the document's main hierarchy and structure, and everyone understands that it's an aside and it just sticks out or in whether it happens to be.

I know I'm getting tired of forcing square pegs into round holes, or splitting hairs about the structure for sidebars. Very frustrating experience!

Id' rather find a better way of meeting the goals for accessibility.

--Bevi Chagnon

— — —
Bevi Chagnon | www.PubCom.com
Technologists, Consultants, Trainers, Designers, and Developers
for publishing & communication
| Acrobat PDF | Print | EPUBS | Sec. 508 Accessibility |
— — —