WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Header levels

for

From: _mallory
Date: Aug 4, 2016 9:24AM

Yeah, the specs assume every web page is a simple university document,
when in most cases our "average" web pages have two parts:

1. the "site chrome" as I call it-- stuff about the website, usually
found in banners/headers, sidebars and footers
2. the main unique-per-page content, which ought to start with an h1
and go down as needed from there.

There's no good solution for these, but what is most common in the wild
now (which means something as at least most people will have encountered
it) is how Bevi and others have described: start the site-chrome stuff
with something less than an h1 and, within those sections, go down from
there as needed.

If I have site-chrome navigation before my unique page content and for
whatever reason need a heading above that navigation (it's even
recommended that landmarks have headings), it's got to be an h2 or
smaller, otherwise it's incorrectly set as some sub-subject of the h1!

Would be nice if headings could have a <scope> or something.

_mallory

On Wed, Aug 03, 2016 at 02:56:28PM -0400, Chagnon | PubCom wrote:
> 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 |
> — — —
>
>
> > > >