WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Left Column and Heading Level Order

for

From: Bryan Garaventa
Date: Jul 6, 2012 3:17PM

Speaking personally as a screen reader user, I do find that headings are
very helpful when properly nested to convey structure, especially within
complex pages where hierarchy is important.

There are some occasions when pages include header or right/left navigation
panels where the use of headings are relevant however, and these typically
are positioned in the DOM above the main content of the page, which is
desirable. It would cause confusion to give such headings H1 markup since
this would imply that this is the start of the main content of the page, and
that all side navigation headings are nested within this hierarchy.

So I can see why it would be acceptable to have some higher level headings
above the H1 on the page in such cases as these, where a screen reader user
could simply press 1 to skip past the undesired content and directly
navigate to the main content, after which headings should be nested
properly.

----- Original Message -----
From: "Duff Johnson" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Friday, July 06, 2012 1:19 PM
Subject: Re: [WebAIM] Left Column and Heading Level Order


> This response is not directed at Jared. He and David have simply raised a
> good and frequently-heard point which I'd like to address.
>
> On Jul 5, 2012, at 11:51 PM, Jared Smith wrote:
>
>> I've never seen a real strong argument against having <h2>s come
>> before the <h1>. I see no accessibility or validation reasons why this
>> would be bad. Certainly this would be preferable to restructuring the
>> code order so that content does not match the visual presentation
>> order.
>
>
> I will leave assessment of the relative "strength" of the argument to the
> reader, but here it is, in any event...
>
> For the user who wants to know: "what's on this page", encountering H2
> before H1 creates an instant quandary: Do I read the first heading(s)
> encountered (after all, if H2 is OK, why not H3 or H4? Why not 2 H2s and
> some H3s as well?), or the first H1 heading?
>
> Once the door is open to illogical heading levels the quandary cannot be
> resolved programmatically. Ergo, the user is stuck reading ALL headings,
> or else choosing to skip to H1 heedless of the preceding content.
>
> Placing H2 before H1 is effectively an announcement that headings are
> being used for "importance" or styling rather than organizational
> purposes. In such cases, heading levels can't really be trusted for little
> things like "navigation". That's a bad outcome, right?!
>
> [ Notable sidenote: HTML 5 *redefines* headings in HTML to something
> that's a lot more like the PDF definition. Minimally, HTML 5's definition
> does not include the idea of "importance" from HTML 4. Hmm. ]
>
> Many users really do leverage headings for navigation (certainly according
> to WebAIM's latest survey of screen reader users).
>
> For these users, encountering H2 (or H4, why not?) before H1 simply gives
> them less reason to trust that the heading levels they encounter will
> usefully represent logical subsections of content. Instead, they conclude
> that the page's author must be of the sort who thinks that "Our H3 style
> is the perfect font, size and color to be used for the company's name in
> an address block in the footer," or some such. Yes, I know, many of us
> (myself included) labor under various CSS limitations, inline editing
> restrictions, etc. Ok... but at least we should be able to agree on what
> right (or wrong) looks like!
>
> When heading levels are used for purposes other than structure, end users
> are generally consigned to troll through every heading to find content of
> interest rather than being able to use heading levels to "drill down" to
> content of interest.
>
> The only salve is that web-pages are usually relatively small bits of
> content - maybe two or three thousand words. For this reason alone one
> might grant that heading levels in general are less important in typical
> HTML settings. It's acceptable, I guess, to force the AT user to grind
> from heading to heading and to train them not to expect real utility from
> heading levels.
>
> Well, maybe that's cool in HTML, but it's not a generalizable point.
> Please do not bring that mentality to PDF! PDF files often contain far,
> far more content than a single web-page. Most PDFs are *not* riddled with
> links, especially internal links, and internal links have very low utility
> to AT users in today's PDF for certain specific technical reasons.
>
> As such, Headings are the only way for AT users to get around PDFs with
> any alacrity.
>
> I'd like to put the shoe on the other foot: What's the "strong argument"
> for tolerating illogical structure? Surely it can't be to accommodate a
> coding convenience? That's not a reason accessibility folks would accept
> anyplace else: why here?
>
> I'm not asking for argument's sake. I'm genuinely interested to know the
> background on why rigor in heading levels isn't a "big deal"
> (historically). Is it because HTML's definition for heading was fuzzy?
> Maybe various implementations didn't bother with decent utilization of
> heading levels back in the early days? I'm no HTML guru; someone feel free
> to help me out here...
>
> Best regards,
>
> Duff Johnson
>
> President, NetCentric US (Creators of CommonLook)
> ISO 32000 Intl. Project Co-Leader, US Chair
> ISO 14289 US Chair
> PDF Association Vice-Chair
>
> Office: +1 617 401 8140
> Mobile: +1 617 283 4226
> <EMAIL REMOVED>
> www.commonlook.com
>
> > >