WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Query on heading hierarchy

for

Number of posts in this thread: 32 (In chronological order)

From: Vemaarapu Venkatesh
Date: Tue, Mar 20 2018 1:01AM
Subject: Query on heading hierarchy
No previous message | Next message →

Hi,

Can we say that the heading hierarchy is maintained if h1 is followed by
h3's directly skipping h2's. Will this comply with WCAG 2.0.

Thanks,
Venkatesh

From: Osmo Saarikumpu
Date: Tue, Mar 20 2018 1:31AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
> Can we say that the heading hierarchy is maintained if h1 is followed by
> h3's directly skipping h2's. Will this comply with WCAG 2.0.

At least I can't think of a situation where a h3 would be justified
without a preceding h2. See e.g.:

https://webaim.org/techniques/semanticstructure/#contentstructure

--
Best wishes, Osmo

From: Birkir R. Gunnarsson
Date: Tue, Mar 20 2018 2:39AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

All that WCAG 1.3.1 requires is that semantic information mirrors
visual information.
If you have a largest heading followed by a small heading followed by
a heading that looks somewhere in the middle, marking the first as h1,
and the others as h2 is misleading, it does not reflect their visual
weight, but marking the first has h1, then h3 and h2 would reflect
their visual emphasis and comply with WCAG 1.3.1.

So the first step is to make sure the heading levels mirror the visual
weight of the headings on the page.
An ideal step would be to ensure that both visual weight and heading
level correctly describes the content structure, but my reading of
WCAG 1.3.1 does not show me that this is required.
Maybe my view goes against the popular view, but I think there are
plenty of situations where an h1 can be followed by an h3 and then h2.

WE often have content with a main heading, a small subsection or note
with no descendants and then categories.
Think of a page of bank accounts.
The main heading is "your accounts".
It could be followed by a small section such as "quick overview" or
"your transactions in the last 24 hours".

Then you have headings for credit card accounts, checking accounts and
other accounts, inside those you have headings for individual accounts
within those categories.

I think the structure that best describes this is to have the heading
of the small section an h3 or h4, the heading of account categories as
h2s and headings for individual accounts h3s.
The section at the top does not have its own subsection, and it takes
up a small area of the page. I think marking it as an h2 does not
describe the way the page is structured.




On 3/20/18, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
> On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
>> Can we say that the heading hierarchy is maintained if h1 is followed by
>> h3's directly skipping h2's. Will this comply with WCAG 2.0.
>
> At least I can't think of a situation where a h3 would be justified
> without a preceding h2. See e.g.:
>
> https://webaim.org/techniques/semanticstructure/#contentstructure
>
> --
> Best wishes, Osmo
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Tue, Mar 20 2018 8:28AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

+1 to Birkir. The purpose of the guideline is to make sure the semantic
heading levels match the visual presentation. It doesn't say it has to be
h1 followed by h2 followed by h3. While that's certainly ideal, there are
lots of situations where it makes sense to skip a level.

On Tue, Mar 20, 2018 at 2:39 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> All that WCAG 1.3.1 requires is that semantic information mirrors
> visual information.
> If you have a largest heading followed by a small heading followed by
> a heading that looks somewhere in the middle, marking the first as h1,
> and the others as h2 is misleading, it does not reflect their visual
> weight, but marking the first has h1, then h3 and h2 would reflect
> their visual emphasis and comply with WCAG 1.3.1.
>
> So the first step is to make sure the heading levels mirror the visual
> weight of the headings on the page.
> An ideal step would be to ensure that both visual weight and heading
> level correctly describes the content structure, but my reading of
> WCAG 1.3.1 does not show me that this is required.
> Maybe my view goes against the popular view, but I think there are
> plenty of situations where an h1 can be followed by an h3 and then h2.
>
> WE often have content with a main heading, a small subsection or note
> with no descendants and then categories.
> Think of a page of bank accounts.
> The main heading is "your accounts".
> It could be followed by a small section such as "quick overview" or
> "your transactions in the last 24 hours".
>
> Then you have headings for credit card accounts, checking accounts and
> other accounts, inside those you have headings for individual accounts
> within those categories.
>
> I think the structure that best describes this is to have the heading
> of the small section an h3 or h4, the heading of account categories as
> h2s and headings for individual accounts h3s.
> The section at the top does not have its own subsection, and it takes
> up a small area of the page. I think marking it as an h2 does not
> describe the way the page is structured.
>
>
>
>
> On 3/20/18, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
> > On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
> >> Can we say that the heading hierarchy is maintained if h1 is followed by
> >> h3's directly skipping h2's. Will this comply with WCAG 2.0.
> >
> > At least I can't think of a situation where a h3 would be justified
> > without a preceding h2. See e.g.:
> >
> > https://webaim.org/techniques/semanticstructure/#contentstructure
> >
> > --
> > Best wishes, Osmo
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Karlen Communications
Date: Tue, Mar 20 2018 10:33AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

First a disclaimer: I support sequential headings. I "preach" sequential headings!

To the argument and the example given of following the visual representation of structure using headings that appear to be out of sequence. I've seen document authors choose a heading style/formatting because of the way it looks, not because it represents any type of structure. I've remediated documents in PDF and then received the Word document and what appeared visually as a smaller font or lower heading level was really a modified H2 with a smaller font than the H3, not a visual H3 which had a larger font than the H2. I've also remediated Word and PDF documents where all headings were the same size but had different attributes such as bold, italic and underline...sometimes all three.

As document authors we have to use sequential headings whenever possible and as document remediators we are tasked with providing a "logical reading order" or "logical structure to the document."

If we abdicate logical document structure/logical reading order, then we can just accept whatever heading Tags are produced in PDF and whatever headings are used in source applications. While this cuts down on the remediation time, it does not improve the accessibility of the content.

Taking this further, if we accept whatever headings are used in the document as the "right of the document author" then we should also be accepting any other structures as being the right of the author which again reduces remediation time to just looking for missing Alt Text...until we can make all images Artifacts in all applications.

There is a trend to winnow the accessibility of documents to its bare minimum. Not sure what is driving this trend but for me, this is a step backward not forward.

Part of accessible document design is "design." Part of our role as accessible document remediation professionals is to ensure a logical reading order/logical structure to digital content.

I would really like my role as an accessible document remediator to be obsolete because we've provided the training/education to document authors and we have the tools we need, not that we simply accept whatever is presented to us as "garbage in/garbage out."

Cheers, Karen


From: glen walker
Date: Tue, Mar 20 2018 10:58AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I would guess that the majority of a11y sme's would prefer sequential
headings but it's not against wcag to not have them. I think that was the
main point.


On Tue, Mar 20, 2018 at 10:33 AM, Karlen Communications <
= EMAIL ADDRESS REMOVED = > wrote:

> First a disclaimer: I support sequential headings. I "preach" sequential
> headings!
>
> To the argument and the example given of following the visual
> representation of structure using headings that appear to be out of
> sequence. I've seen document authors choose a heading style/formatting
> because of the way it looks, not because it represents any type of
> structure. I've remediated documents in PDF and then received the Word
> document and what appeared visually as a smaller font or lower heading
> level was really a modified H2 with a smaller font than the H3, not a
> visual H3 which had a larger font than the H2. I've also remediated Word
> and PDF documents where all headings were the same size but had different
> attributes such as bold, italic and underline...sometimes all three.
>
> As document authors we have to use sequential headings whenever possible
> and as document remediators we are tasked with providing a "logical reading
> order" or "logical structure to the document."
>
> If we abdicate logical document structure/logical reading order, then we
> can just accept whatever heading Tags are produced in PDF and whatever
> headings are used in source applications. While this cuts down on the
> remediation time, it does not improve the accessibility of the content.
>
> Taking this further, if we accept whatever headings are used in the
> document as the "right of the document author" then we should also be
> accepting any other structures as being the right of the author which again
> reduces remediation time to just looking for missing Alt Text...until we
> can make all images Artifacts in all applications.
>
> There is a trend to winnow the accessibility of documents to its bare
> minimum. Not sure what is driving this trend but for me, this is a step
> backward not forward.
>
> Part of accessible document design is "design." Part of our role as
> accessible document remediation professionals is to ensure a logical
> reading order/logical structure to digital content.
>
> I would really like my role as an accessible document remediator to be
> obsolete because we've provided the training/education to document authors
> and we have the tools we need, not that we simply accept whatever is
> presented to us as "garbage in/garbage out."
>
> Cheers, Karen
>
>
>

From: Wolfgang Berndorfer
Date: Tue, Mar 20 2018 12:12PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

You'll agree that we have to examine such constructions for potential
missuse of markup to highlight visually. Especially if the H2-element
follows the H3 immediatelly, it smells likely as abuse. And this would
affect 1.3.1. Right?

Wolfgang


-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von glen walker
Gesendet: Dienstag, 20. März 2018 15:29
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Query on heading hierarchy

+1 to Birkir. The purpose of the guideline is to make sure the semantic
heading levels match the visual presentation. It doesn't say it has to be
h1 followed by h2 followed by h3. While that's certainly ideal, there are
lots of situations where it makes sense to skip a level.

On Tue, Mar 20, 2018 at 2:39 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> All that WCAG 1.3.1 requires is that semantic information mirrors
> visual information.
> If you have a largest heading followed by a small heading followed by
> a heading that looks somewhere in the middle, marking the first as h1,
> and the others as h2 is misleading, it does not reflect their visual
> weight, but marking the first has h1, then h3 and h2 would reflect
> their visual emphasis and comply with WCAG 1.3.1.
>
> So the first step is to make sure the heading levels mirror the visual
> weight of the headings on the page.
> An ideal step would be to ensure that both visual weight and heading
> level correctly describes the content structure, but my reading of
> WCAG 1.3.1 does not show me that this is required.
> Maybe my view goes against the popular view, but I think there are
> plenty of situations where an h1 can be followed by an h3 and then h2.
>
> WE often have content with a main heading, a small subsection or note
> with no descendants and then categories.
> Think of a page of bank accounts.
> The main heading is "your accounts".
> It could be followed by a small section such as "quick overview" or
> "your transactions in the last 24 hours".
>
> Then you have headings for credit card accounts, checking accounts and
> other accounts, inside those you have headings for individual accounts
> within those categories.
>
> I think the structure that best describes this is to have the heading
> of the small section an h3 or h4, the heading of account categories as
> h2s and headings for individual accounts h3s.
> The section at the top does not have its own subsection, and it takes
> up a small area of the page. I think marking it as an h2 does not
> describe the way the page is structured.
>
>
>
>
> On 3/20/18, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
> > On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
> >> Can we say that the heading hierarchy is maintained if h1 is followed
by
> >> h3's directly skipping h2's. Will this comply with WCAG 2.0.
> >
> > At least I can't think of a situation where a h3 would be justified
> > without a preceding h2. See e.g.:
> >
> > https://webaim.org/techniques/semanticstructure/#contentstructure
> >
> > --
> > Best wishes, Osmo
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: glen walker
Date: Tue, Mar 20 2018 12:52PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

An h2 immediately following an h3 is likely to be an issue, but not
necessarily. It all depends, of course, on the situation. It could be
that the h2 just happens to follow the h3 in the DOM and the two are
unrelated. That would be ok. However, if the h2 is a subsection of h3,
then that would be confusing.

Glen


On Tue, Mar 20, 2018 at 12:12 PM, Wolfgang Berndorfer <
= EMAIL ADDRESS REMOVED = > wrote:

> You'll agree that we have to examine such constructions for potential
> missuse of markup to highlight visually. Especially if the H2-element
> follows the H3 immediatelly, it smells likely as abuse. And this would
> affect 1.3.1. Right?
>
> Wolfgang
>
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
> von glen walker
> Gesendet: Dienstag, 20. März 2018 15:29
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] Query on heading hierarchy
>
> +1 to Birkir. The purpose of the guideline is to make sure the semantic
> heading levels match the visual presentation. It doesn't say it has to be
> h1 followed by h2 followed by h3. While that's certainly ideal, there are
> lots of situations where it makes sense to skip a level.
>
> On Tue, Mar 20, 2018 at 2:39 AM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > All that WCAG 1.3.1 requires is that semantic information mirrors
> > visual information.
> > If you have a largest heading followed by a small heading followed by
> > a heading that looks somewhere in the middle, marking the first as h1,
> > and the others as h2 is misleading, it does not reflect their visual
> > weight, but marking the first has h1, then h3 and h2 would reflect
> > their visual emphasis and comply with WCAG 1.3.1.
> >
> > So the first step is to make sure the heading levels mirror the visual
> > weight of the headings on the page.
> > An ideal step would be to ensure that both visual weight and heading
> > level correctly describes the content structure, but my reading of
> > WCAG 1.3.1 does not show me that this is required.
> > Maybe my view goes against the popular view, but I think there are
> > plenty of situations where an h1 can be followed by an h3 and then h2.
> >
> > WE often have content with a main heading, a small subsection or note
> > with no descendants and then categories.
> > Think of a page of bank accounts.
> > The main heading is "your accounts".
> > It could be followed by a small section such as "quick overview" or
> > "your transactions in the last 24 hours".
> >
> > Then you have headings for credit card accounts, checking accounts and
> > other accounts, inside those you have headings for individual accounts
> > within those categories.
> >
> > I think the structure that best describes this is to have the heading
> > of the small section an h3 or h4, the heading of account categories as
> > h2s and headings for individual accounts h3s.
> > The section at the top does not have its own subsection, and it takes
> > up a small area of the page. I think marking it as an h2 does not
> > describe the way the page is structured.
> >
> >
> >
> >
> > On 3/20/18, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
> > > On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
> > >> Can we say that the heading hierarchy is maintained if h1 is followed
> by
> > >> h3's directly skipping h2's. Will this comply with WCAG 2.0.
> > >
> > > At least I can't think of a situation where a h3 would be justified
> > > without a preceding h2. See e.g.:
> > >
> > > https://webaim.org/techniques/semanticstructure/#contentstructure
> > >
> > > --
> > > Best wishes, Osmo
> > > > > > > > > > > > > > >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > > > > >
> > > > >
> > > > >

From: Duff Johnson
Date: Tue, Mar 20 2018 1:39PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

You have put your finger on the issue. When the unambiguous utilization of heading-levels requires awareness of a "situation" we can already smell a problem.

If you have reason to believe that the document is "properly structured" (i.e., no skips), then h2 following h3 would invariably mean that the h2 content just happens to follow h3 content - no ambiguity.

If it's not a "good tree" to begin with (i.e., there are skips for whatever reason), then ambiguity is baked-in (with exceptions for some specific cases).

In general, if skipping is acceptable, then it's impossible to assess an apparent h2 following an h3. Maybe the h2 somehow belongs to the h3? Maybe not! You can't tell.

It's a mistake to overload "headings" with the idea of "visual emphasis" in any event. Consider an operating manual. Alerts in the manual may be styled with a high degree of visual emphasis, but that does not imply a high heading level.

HTML is a lousy way to think about semantics. But, since HTML pervades the way we think, it seems, authors should be required to use proper heading structures. Just don't use a technology standard to insist on the point; use a content standard instead.

Duff.


> On Mar 20, 2018, at 14:52, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> An h2 immediately following an h3 is likely to be an issue, but not
> necessarily. It all depends, of course, on the situation. It could be
> that the h2 just happens to follow the h3 in the DOM and the two are
> unrelated. That would be ok. However, if the h2 is a subsection of h3,
> then that would be confusing.
>
> Glen
>
>
> On Tue, Mar 20, 2018 at 12:12 PM, Wolfgang Berndorfer <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> You'll agree that we have to examine such constructions for potential
>> missuse of markup to highlight visually. Especially if the H2-element
>> follows the H3 immediatelly, it smells likely as abuse. And this would
>> affect 1.3.1. Right?
>>
>> Wolfgang
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
>> von glen walker
>> Gesendet: Dienstag, 20. März 2018 15:29
>> An: WebAIM Discussion List
>> Betreff: Re: [WebAIM] Query on heading hierarchy
>>
>> +1 to Birkir. The purpose of the guideline is to make sure the semantic
>> heading levels match the visual presentation. It doesn't say it has to be
>> h1 followed by h2 followed by h3. While that's certainly ideal, there are
>> lots of situations where it makes sense to skip a level.
>>
>> On Tue, Mar 20, 2018 at 2:39 AM, Birkir R. Gunnarsson <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> All that WCAG 1.3.1 requires is that semantic information mirrors
>>> visual information.
>>> If you have a largest heading followed by a small heading followed by
>>> a heading that looks somewhere in the middle, marking the first as h1,
>>> and the others as h2 is misleading, it does not reflect their visual
>>> weight, but marking the first has h1, then h3 and h2 would reflect
>>> their visual emphasis and comply with WCAG 1.3.1.
>>>
>>> So the first step is to make sure the heading levels mirror the visual
>>> weight of the headings on the page.
>>> An ideal step would be to ensure that both visual weight and heading
>>> level correctly describes the content structure, but my reading of
>>> WCAG 1.3.1 does not show me that this is required.
>>> Maybe my view goes against the popular view, but I think there are
>>> plenty of situations where an h1 can be followed by an h3 and then h2.
>>>
>>> WE often have content with a main heading, a small subsection or note
>>> with no descendants and then categories.
>>> Think of a page of bank accounts.
>>> The main heading is "your accounts".
>>> It could be followed by a small section such as "quick overview" or
>>> "your transactions in the last 24 hours".
>>>
>>> Then you have headings for credit card accounts, checking accounts and
>>> other accounts, inside those you have headings for individual accounts
>>> within those categories.
>>>
>>> I think the structure that best describes this is to have the heading
>>> of the small section an h3 or h4, the heading of account categories as
>>> h2s and headings for individual accounts h3s.
>>> The section at the top does not have its own subsection, and it takes
>>> up a small area of the page. I think marking it as an h2 does not
>>> describe the way the page is structured.
>>>
>>>
>>>
>>>
>>> On 3/20/18, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
>>>> On 20/03/2018 09:01, Vemaarapu Venkatesh wrote:
>>>>> Can we say that the heading hierarchy is maintained if h1 is followed
>> by
>>>>> h3's directly skipping h2's. Will this comply with WCAG 2.0.
>>>>
>>>> At least I can't think of a situation where a h3 would be justified
>>>> without a preceding h2. See e.g.:
>>>>
>>>> https://webaim.org/techniques/semanticstructure/#contentstructure
>>>>
>>>> --
>>>> Best wishes, Osmo
>>>> >>>> >>>> >>>> >>>>
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> >>> >>>
>> >> >> >> >>
>> >> >> >> >>
> > > >

From: Osmo Saarikumpu
Date: Wed, Mar 21 2018 8:24AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

On 20/03/2018 16:28, glen walker wrote:
> +1 to Birkir. The purpose of the guideline is to make sure the semantic
> heading levels match the visual presentation.

"The intent of this Success Criterion is to ensure that information and
relationships that are implied by visual or auditory formatting are
preserved when the presentation format changes." (Understanding SC 1.3.1)

If I read you both correctly, you'd be saying that the underlying code
should "support" or "confirm" the visual presentation? The way I read it
is: it's all about the underlying information and it's relationship to
the context, where visual formatting is just an aid for the visually
capable. Or as the prose in
<https://webaim.org/techniques/semanticstructure/#contentstructure> says:

"When encountering a lengthy web page, sighted users often scroll the
page quickly and look for big, bold text (headings) to get an idea of
the structure and content of the page. Screen reader and other assistive
technology users also have the ability to navigate web pages by heading
structure, assuming true headings are used (as opposed to text that is
styled to be big and/or bold). This means that the user can view a list
of all of the headings on the page, or can read or jump by headings, or
even navigate directly to top level headings (<h1>), next level headings
(<h2>), third level headings (<h3>), and so on."

> It doesn't say it has to be
> h1 followed by h2 followed by h3.

Right, not in the "Success Criterion", but in the "Semantic Structure"
article (referenced URL) it says:

"Pages should be structured in a hierarchical manner, generally with one
1st degree headings (<h1>) being the most important (usually page titles
or main content heading), then 2nd degree headings (<h2> - usually major
section headings), down to 3rd degree headings (sub-sections of the
<h2>), and so on. Technically, lower degree headings should be contained
within headings of the next highest degree (i.e., one should not skip
heading levels, such as from an <h2> to an <h4>, going down the document)."

The "WAVE Web Accessibility Tool" reflects the former quote. When I
navigate to a page that skips a heading level, it says:

*Alerts*
Skipped heading level

*What It Means*
A heading level is skipped.

*Why It Matters*
Headings provide document structure and facilitate keyboard navigation
by users of assistive technology. These users may be confused or
experience difficulty navigating when heading levels are skipped.

*How to Fix It*
Restructure the document headings to ensure that heading levels are not
skipped.

*The Algorithm... in English*
A heading level is skipped (e.g., an <h1> is followed by an <h3>, with
no intermediate <h2>).

> While that's certainly ideal, there are
> lots of situations where it makes sense to skip a level.

I'd argue that no such cases exist. This is due to the underlying markup
language, that says:

"Subsequent headings of equal or higher rank start new implied
subsections that are part of the previous section's parent section.
Subsequent headings of lower rank start new implied subsections that are
part of the previous one. In both cases, the element represents the
heading of the implied section.

h1–h6 elements must not be used to markup subheadings, subtitles,
alternative titles and taglines unless intended to be the heading for a
new section or subsection."

<https://www.w3.org/TR/html52/sections.html#headings-and-sections>

--
Best wishes, Osmo

From: glen walker
Date: Thu, Mar 22 2018 12:59PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

That's one of the fun things about accessibility. We all have opinions on
how things should be interpreted and can share with each other.


On Wed, Mar 21, 2018 at 8:24 AM, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = >
wrote:

> On 20/03/2018 16:28, glen walker wrote:
>
>> +1 to Birkir. The purpose of the guideline is to make sure the semantic
>> heading levels match the visual presentation.
>>
>
> "The intent of this Success Criterion is to ensure that information and
> relationships that are implied by visual or auditory formatting are
> preserved when the presentation format changes." (Understanding SC 1.3.1)
>
> If I read you both correctly, you'd be saying that the underlying code
> should "support" or "confirm" the visual presentation? The way I read it
> is: it's all about the underlying information and it's relationship to the
> context, where visual formatting is just an aid for the visually capable.
> Or as the prose in <https://webaim.org/techniques
> /semanticstructure/#contentstructure> says:
>
> "When encountering a lengthy web page, sighted users often scroll the page
> quickly and look for big, bold text (headings) to get an idea of the
> structure and content of the page. Screen reader and other assistive
> technology users also have the ability to navigate web pages by heading
> structure, assuming true headings are used (as opposed to text that is
> styled to be big and/or bold). This means that the user can view a list of
> all of the headings on the page, or can read or jump by headings, or even
> navigate directly to top level headings (<h1>), next level headings (<h2>),
> third level headings (<h3>), and so on."
>
> It doesn't say it has to be
>> h1 followed by h2 followed by h3.
>>
>
> Right, not in the "Success Criterion", but in the "Semantic Structure"
> article (referenced URL) it says:
>
> "Pages should be structured in a hierarchical manner, generally with one
> 1st degree headings (<h1>) being the most important (usually page titles or
> main content heading), then 2nd degree headings (<h2> - usually major
> section headings), down to 3rd degree headings (sub-sections of the <h2>),
> and so on. Technically, lower degree headings should be contained within
> headings of the next highest degree (i.e., one should not skip heading
> levels, such as from an <h2> to an <h4>, going down the document)."
>
> The "WAVE Web Accessibility Tool" reflects the former quote. When I
> navigate to a page that skips a heading level, it says:
>
> *Alerts*
> Skipped heading level
>
> *What It Means*
> A heading level is skipped.
>
> *Why It Matters*
> Headings provide document structure and facilitate keyboard navigation by
> users of assistive technology. These users may be confused or experience
> difficulty navigating when heading levels are skipped.
>
> *How to Fix It*
> Restructure the document headings to ensure that heading levels are not
> skipped.
>
> *The Algorithm... in English*
> A heading level is skipped (e.g., an <h1> is followed by an <h3>, with no
> intermediate <h2>).
>
> While that's certainly ideal, there are
>> lots of situations where it makes sense to skip a level.
>>
>
> I'd argue that no such cases exist. This is due to the underlying markup
> language, that says:
>
> "Subsequent headings of equal or higher rank start new implied subsections
> that are part of the previous section's parent section. Subsequent headings
> of lower rank start new implied subsections that are part of the previous
> one. In both cases, the element represents the heading of the implied
> section.
>
> h1–h6 elements must not be used to markup subheadings, subtitles,
> alternative titles and taglines unless intended to be the heading for a new
> section or subsection."
>
> <https://www.w3.org/TR/html52/sections.html#headings-and-sections>
>
> --
> Best wishes, Osmo
> > > > >

From: chagnon
Date: Thu, Mar 22 2018 2:20PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I have to laugh right now as our shop works on one document created by several people, each with their own version of how Heading 2 should look, or their own "very special" bullets.

With every page bringing a new visual appearance of the headings, lists, and body text (all manually formatted, of course, without styles), I'm not sure it's possible to meet the SC 1.3.1 definition quoted below: ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.

In this sample, there's no rhyme or reason to why one heading looks one way, another looks a different way. The multiple author's didn't create a structured, logical relationship anywhere in the document.

In umpteen decades of writing, editing, typesetting, designing, and programming documents (from SGML to XML and HTML), nowhere does the publishing industry say that structure must follow visual presentation.

It's the other way around: Logical structure comes first, then the visual formatting to make the structure clear.

SC 1.3.1 needs to be rewritten.

—Bevi
— — —
Bevi Chagnon, founder/CEO | = EMAIL ADDRESS REMOVED =
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting ' training ' development ' design ' sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —

> On 20/03/2018 16:28, glen walker wrote:
>
>> The purpose of the guideline is to make sure the
>> semantic heading levels match the visual presentation.
>
> "The intent of this Success Criterion is to ensure that information
> and relationships that are implied by visual or auditory formatting
> are preserved when the presentation format changes." (Understanding SC
> 1.3.1)

From: KP
Date: Thu, Mar 22 2018 2:34PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

1.3.1 is fine. That doc in your shop needs an editor and a mandatory style guide :)

Kevin

Sent from my iPhone

> On 23/03/2018, at 09:20, < = EMAIL ADDRESS REMOVED = > < = EMAIL ADDRESS REMOVED = > wrote:
>
> I have to laugh right now as our shop works on one document created by several people, each with their own version of how Heading 2 should look, or their own "very special" bullets.
>
> With every page bringing a new visual appearance of the headings, lists, and body text (all manually formatted, of course, without styles), I'm not sure it's possible to meet the SC 1.3.1 definition quoted below: ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.
>
> In this sample, there's no rhyme or reason to why one heading looks one way, another looks a different way. The multiple author's didn't create a structured, logical relationship anywhere in the document.
>
> In umpteen decades of writing, editing, typesetting, designing, and programming documents (from SGML to XML and HTML), nowhere does the publishing industry say that structure must follow visual presentation.
>
> It's the other way around: Logical structure comes first, then the visual formatting to make the structure clear.
>
> SC 1.3.1 needs to be rewritten.
>
> —Bevi
> — — —
> Bevi Chagnon, founder/CEO | = EMAIL ADDRESS REMOVED =
> — — —
> PubCom: Technologists for Accessible Design + Publishing
> consulting ' training ' development ' design ' sec. 508 services
> Upcoming classes at www.PubCom.com/classes
> — — —
>
>>> On 20/03/2018 16:28, glen walker wrote:
>>>
>>> The purpose of the guideline is to make sure the
>>> semantic heading levels match the visual presentation.
>>
>> "The intent of this Success Criterion is to ensure that information
>> and relationships that are implied by visual or auditory formatting
>> are preserved when the presentation format changes." (Understanding SC
>> 1.3.1)
>
> > > >

From: chagnon
Date: Thu, Mar 22 2018 3:07PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Kevin wrote: That doc in your shop needs an editor and a mandatory style guide :)

You're absolutely right! However, we're stuck with hundreds of pages of pure crap that we can't edit.

But getting back to SC 1.3.1.
Speaking as an editor, it really isn't correct to have structure follow visual formatting. That's what causes the problems throughout the entire workflow for everyone, regardless of the technology used to publish and access the content.

Like the structure of a house, it has to be done correctly or there will be problems in using the house. Doesn't really matter how you decorate the house, that's your choice. But a door must be a door and must function as a door. Otherwise it's not really a door.

So in the plans, you architect the building for a 36-inch wide door and the owners buy any door they want to fit in the opening, be it glass, wood, red, green, Colonial, modern, whatever.

It's still a 36-inch door that everyone understands how to use and can use, regardless of its appearance.

Form follows function. That means we must create items that must perform their intended function...and make them look good.

It also means the SC 1.3.1 has it backwards.

—Bevi
— — —
Bevi Chagnon, founder/CEO | = EMAIL ADDRESS REMOVED =
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting ' training ' development ' design ' sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —

From: KP
Date: Thu, Mar 22 2018 3:58PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

True Bevi, I would assume 1.3.1 requires the visual formatting to be logical too. It should probably refer to logical rather than visual

Sent from my iPhone

> On 23/03/2018, at 10:07, < = EMAIL ADDRESS REMOVED = > < = EMAIL ADDRESS REMOVED = > wrote:
>
> Kevin wrote: That doc in your shop needs an editor and a mandatory style guide :)
>
> You're absolutely right! However, we're stuck with hundreds of pages of pure crap that we can't edit.
>
> But getting back to SC 1.3.1.
> Speaking as an editor, it really isn't correct to have structure follow visual formatting. That's what causes the problems throughout the entire workflow for everyone, regardless of the technology used to publish and access the content.
>
> Like the structure of a house, it has to be done correctly or there will be problems in using the house. Doesn't really matter how you decorate the house, that's your choice. But a door must be a door and must function as a door. Otherwise it's not really a door.
>
> So in the plans, you architect the building for a 36-inch wide door and the owners buy any door they want to fit in the opening, be it glass, wood, red, green, Colonial, modern, whatever.
>
> It's still a 36-inch door that everyone understands how to use and can use, regardless of its appearance.
>
> Form follows function. That means we must create items that must perform their intended function...and make them look good.
>
> It also means the SC 1.3.1 has it backwards.
>
> —Bevi
> — — —
> Bevi Chagnon, founder/CEO | = EMAIL ADDRESS REMOVED =
> — — —
> PubCom: Technologists for Accessible Design + Publishing
> consulting ' training ' development ' design ' sec. 508 services
> Upcoming classes at www.PubCom.com/classes
> — — —
>
> > > >

From: Vemaarapu Venkatesh
Date: Thu, Mar 22 2018 10:51PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Hi,

For my quick understanding let me consider this heading structure.
Countries(h1)
State1(h2)
City(h3)
State2(h2)
City(h3)
This naturally seems to be well structured and can find no issues if visual
appearance of headings matches with screen reader announcement of headings
also.
Now if the structure is like
Countries(h1)
State1(h2)
City(h2)
State2(h2)
City(h2)
Assume these are h2's visually also and screen reader speaks out the same.
Obviously it's a bad structure but screen reader conveys the same visual
formatting as they are real h2's.
Can I understand this context passes SC1.3.1. Am I getting the things right?

Regards,
Venkatesh

From: Birkir R. Gunnarsson
Date: Thu, Mar 22 2018 11:15PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Yes, this passes the WCAG 1.3.1 requirements.
FAct is, if all that 1.3.1 is asking (which it is), that structure
reflects visual presentation, there is no guarantee the heading
structure needs to be well thought out, or even logical.
People do not pay that much attention to minute difference in visual
weight, spacing or size of heading text, they just see a heading is a
heading and often can barely tell between an h2 and an h4, and the
WCAG SC does not require the structure be any clearer to someone who
does not see the page.
That's the difference between accessibility and usability right there.
Accessibility only asks that people with disabilities do not get a
proportionately worse interface, it does not require usability to be
great and accessibility to follow.
I am not saying we shouldn't work hard to improve both when we see
issues, I thihk well structured headings that are clearly formatted
are not a usability fix, but we have to realize where we can claim
something is an accessibility violation whereas things that are
usability recommendations that benefit all users.
There are situations where skipping a heading level is logical and
accurately describes the structure of the content. That is up to each
and everyone of us accessibility experts to decide and I see no reason
to argue about it.



On 3/23/18, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> For my quick understanding let me consider this heading structure.
> Countries(h1)
> State1(h2)
> City(h3)
> State2(h2)
> City(h3)
> This naturally seems to be well structured and can find no issues if visual
> appearance of headings matches with screen reader announcement of headings
> also.
> Now if the structure is like
> Countries(h1)
> State1(h2)
> City(h2)
> State2(h2)
> City(h2)
> Assume these are h2's visually also and screen reader speaks out the same.
> Obviously it's a bad structure but screen reader conveys the same visual
> formatting as they are real h2's.
> Can I understand this context passes SC1.3.1. Am I getting the things right?
>
> Regards,
> Venkatesh
> > > > >


--
Work hard. Have fun. Make history.

From: KP
Date: Fri, Mar 23 2018 12:07AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

But you would surely advise that the visual structure was sub-optimal.

I'd fail it on the grounds that the visual structure didn't reflect the logical heirarchy and the HTML structure must surely reflect the logical for this to be useful. If you're just ticking boxes on the other hand....

The visual structure is an access issue too for low vision, cognitive and the like.

Sent from my iPhone

> On 23/03/2018, at 17:51, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi,
>
> For my quick understanding let me consider this heading structure.
> Countries(h1)
> State1(h2)
> City(h3)
> State2(h2)
> City(h3)
> This naturally seems to be well structured and can find no issues if visual
> appearance of headings matches with screen reader announcement of headings
> also.
> Now if the structure is like
> Countries(h1)
> State1(h2)
> City(h2)
> State2(h2)
> City(h2)
> Assume these are h2's visually also and screen reader speaks out the same.
> Obviously it's a bad structure but screen reader conveys the same visual
> formatting as they are real h2's.
> Can I understand this context passes SC1.3.1. Am I getting the things right?
>
> Regards,
> Venkatesh
> > > >

From: glen walker
Date: Fri, Mar 23 2018 6:36AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Advise, yes, but it's not an a11y issue. Sadly, when the UX is bad for
everyone, it's generally accessible. All users get the same terrible
experience. As Kevin said, if you're checking off boxes on the SC list,
1.3.1 would get checked off, albeit begrudgingly.

I had a really hard time with this when I was doing a11y audits. I really
wanted to fix the UX but was told to just check the box because that's all
the client wanted. But you try to sneak in some UX advice to make it
better for everyone.


On Fri, Mar 23, 2018 at 12:07 AM, KP < = EMAIL ADDRESS REMOVED = > wrote:

> But you would surely advise that the visual structure was sub-optimal.
>
> I'd fail it on the grounds that the visual structure didn't reflect the
> logical heirarchy and the HTML structure must surely reflect the logical
> for this to be useful. If you're just ticking boxes on the other hand....
>
> The visual structure is an access issue too for low vision, cognitive and
> the like.
>
> Sent from my iPhone
>
> > On 23/03/2018, at 17:51, Vemaarapu Venkatesh <
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Hi,
> >
> > For my quick understanding let me consider this heading structure.
> > Countries(h1)
> > State1(h2)
> > City(h3)
> > State2(h2)
> > City(h3)
> > This naturally seems to be well structured and can find no issues if
> visual
> > appearance of headings matches with screen reader announcement of
> headings
> > also.
> > Now if the structure is like
> > Countries(h1)
> > State1(h2)
> > City(h2)
> > State2(h2)
> > City(h2)
> > Assume these are h2's visually also and screen reader speaks out the
> same.
> > Obviously it's a bad structure but screen reader conveys the same visual
> > formatting as they are real h2's.
> > Can I understand this context passes SC1.3.1. Am I getting the things
> right?
> >
> > Regards,
> > Venkatesh
> > > > > > > > >
> > > > >

From: Karlen Communications
Date: Fri, Mar 23 2018 8:46AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

That may be the true issue. Is accessibility just checking a box that says everything has Tags/markup and therefore is good to go or does accessibility include education and training on accessible document design? And remediating documents to provide structure and navigation.

When I look at a PDF document with Tags, do I just say, OK, it has Tags, we're good to go? I can add the PDF/UA identifier because technically it does have Tags and since PDF/UA is a technical standard, not a content standard, it really has nothing to do with my job as a remediator to ensure the content is accessible.

This would save a lot of time in that we wouldn't have to remediate any website or document to be "accessible" and we wouldn't need to purchase any expensive tools to help us do that...we just accept the garbage as the will and intent of the document author and push it out the door.

This seems to be where we are rapidly headed.

Cheers, Karen

From: glen walker
Date: Fri, Mar 23 2018 9:56AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I agree, Karen. But just so it's not a gray rainy day, I also get cases
where clients want to do the right thing and really make it accessible and
usable. They want to be educated to understand the real principal (not
just the principles, so to speak) behind making things accessible. (Silent
cheers in my head when that happens :-)) In your PDF example, the client
would want to know the right tags to use. They'd want to know the right
headings to use.


On Fri, Mar 23, 2018 at 8:46 AM, Karlen Communications <
= EMAIL ADDRESS REMOVED = > wrote:

> That may be the true issue. Is accessibility just checking a box that says
> everything has Tags/markup and therefore is good to go or does
> accessibility include education and training on accessible document design?
> And remediating documents to provide structure and navigation.
>
> When I look at a PDF document with Tags, do I just say, OK, it has Tags,
> we're good to go? I can add the PDF/UA identifier because technically it
> does have Tags and since PDF/UA is a technical standard, not a content
> standard, it really has nothing to do with my job as a remediator to ensure
> the content is accessible.
>
> This would save a lot of time in that we wouldn't have to remediate any
> website or document to be "accessible" and we wouldn't need to purchase any
> expensive tools to help us do that...we just accept the garbage as the will
> and intent of the document author and push it out the door.
>
> This seems to be where we are rapidly headed.
>
> Cheers, Karen
>
>

From: Kevin Prince
Date: Sun, Mar 25 2018 4:09PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Well said Karen. I'm far less bothered by a jump in heading level which makes sense than I am by slavishly saying all is good because the sighted and mark-up are equally as illogical.. If the document using confused visual styles (in the broadest sense - ie larger text/bold/underline/actual h levels) then there is clearly a cognitive issue in following the content which needs remediation before applying 1.3.1 to it.

Interestingly this doesn't appear to be addressed in any specific point in WCAG 2.0 - perhaps the time is right to move beyond merely technical checkpoints?

A colleague and I used to refer to the kind of issue we are discussing as ‘equal opportunity inaccessibility' - the page in question was accessible but equally unusable whether you can see it or not.

Kevin
Access1in5
0212220638
Independent Accessibility and IT Consultancy

From: Fernand van Olphen
Date: Mon, Mar 26 2018 3:00AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

If you take a look at this website: http://inclusivedesignprinciples.org/

The heading "The principles" (h2) is set in a smaller font than the headings below, like "Provide comparable experience" (h3). The visual weight of the latter is clearly different.

According to 1.3.1, and the discussion in this thread, is this wrong? Which, if it is, feels awkward to me, because the headings on this website logically follow one another.

Fernand van Olphen
Accessibility Advisor
Municipality of the Hague
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer

From: Vemaarapu Venkatesh
Date: Mon, Mar 26 2018 6:26AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I have seen the font sizes as 18pts, 14pts for h2 and h3 headings
respectively marking up them up using h2, h3 HTML tags. It seems the size
of headings are customized in the given website and one expects smaller
size for h3's as they are subtopics under "The principles". For sure
there's a conflict and it impacts sighted users but not screen reader users
hopefully. Though it's not troubling screen reader users as there is a
conflict between visual presentation and sr announcement I feel it should
violate SC1.3.1.
But as per the discussion if "The principles" is h3 and "Provide
comparisions" etc, are h2's, for sure it might have passed SC1.3.1 sadly if
I am not wrong.

Thanks,
Venkatesh

From: Osmo Saarikumpu
Date: Mon, Mar 26 2018 6:29AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

On 22/03/2018 23:58, KP wrote:
> True Bevi, I would assume 1.3.1 requires the visual formatting to be logical too. It should probably refer to logical rather than visual

I really hope that 1.3.1 just took for granted that the visual
presentation matched the semantics under the hood. After all it speaks
of information and relationships that are *implied* by visual or
auditory formatting" (emphasis mine). The above "implied" meaning: "as a
logical consequence" (due to default formatting styles of the
semantically used elements).

I really can't see but two reasons for skipping heading levels:

1) the author has made an unintentional mistake
2) the used header element reflects the author's idea about the
element's default stylistic formatting rather than the semantics it conveys

And alas! I've certainly been guilty of the latter.

--
Best wishes, Osmo

From: Philip Kiff
Date: Mon, Mar 26 2018 7:15AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

On 2018-03-25 6:09 PM, Kevin Prince wrote:
> A colleague and I used to refer to the kind of issue we are discussing as ‘equal opportunity inaccessibility' - the page in question was accessible but equally unusable whether you can see it or not.
I have had many situations that called for the phrase, "equal
opportunity inaccessibility," and I'm going to use it moving forward,
thanks!

Also, on 2018-03-20 12:33 PM, Karlen Communications wrote:
> Part of accessible document design is "design." Part of our role as accessible document remediation professionals is to ensure a logical reading order/logical structure to digital content.
Well said!

Phil.

From: glen walker
Date: Mon, Mar 26 2018 9:33AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

If I had to audit this site, I would **not** flag the headings as a
violation. The h3's are subheadings under the h2, and the h2 is a
subheading under the h1. The logical structure is available to a screen
reader.

Visually, yes the h2 has a smaller point size than the h3, although it's
using all caps. But that's a design discussion, not an accessibility
discussion.

You could argue it's a cognitive accessibility issue, but you'd have to
provide references on usability studies on why you think that's true. Are
all caps harder to read than mixed case? I think so, but would have to
find credible references on why I think that's so. Does a larger font
imply something is more important than a smaller font? We've kind of been
trained to think that. Look at any consumer good on the market with
packaging with large bold fonts exclaiming the products virtues, and then
the small fine disclaimer print.

If this were the only issue on the website, I would jump for joy. But I
imagine there are more important problems that are causing barriers to
access that would benefit from your time.



On Mon, Mar 26, 2018 at 3:00 AM, Fernand van Olphen <
= EMAIL ADDRESS REMOVED = > wrote:

> If you take a look at this website: http://inclusivedesignprinciples.org/
>
> The heading "The principles" (h2) is set in a smaller font than the
> headings below, like "Provide comparable experience" (h3). The visual
> weight of the latter is clearly different.
>
> According to 1.3.1, and the discussion in this thread, is this wrong?
> Which, if it is, feels awkward to me, because the headings on this website
> logically follow one another.
>
> Fernand van Olphen
> Accessibility Advisor
> Municipality of the Hague
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> op: http://www.denhaag.nl/disclaimer
> > > > >

From: Osmo Saarikumpu
Date: Mon, Mar 26 2018 11:22AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I'd fail it, but certainly not on the grounds that the font size of <h2>
is smaller than in <h3>. I see (sic!) larger font size for higher
ranking headings *just* as the *default* visual cue of their rank. And,
btw, lower ranking headings have by default smaller font sizes than body
text. In a word, font size, as such, should be a non issue in this
discussion thread.

As authors may, and rightfully so, choose other means to express
visually the underlying logical hierarchy. After all, the styling the
author chooses is just a suggestion, which the user can override with
his or hers preferred styles *if the underlying structure permits it*,
which in my view is all 1.3.1 is about. In a word, as "G141 Organizing a
page using headings"
<https://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141> says:
"Success Criterion 1.3.1 requires that the headings be marked such that
they can be programmatically identified."

And the above criterion is the reason of the failure: the several
sub-optimally named <h4>Examples</h4> have several subsections that
should be programmatically identified, but the STRONG element is used
instead of H5. See an interpretation of it in action:

https://validator.w3.org/nu/?showoutline=yes&useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&acceptlanguage=&doc=http%3A%2F%2Finclusivedesignprinciples.org%2F

In which the outliner has no idea about umpteen existing subsections.

Very sadly, your example page mimics the HTML 5.2 Rec
<https://www.w3.org/TR/html52/textlevel-semantics.html#elementdef-strong>
which uses the same structure and even gives advice according to it's
use in the prose:

"<strong>Importance</strong>: The strong element can be used in a
heading, caption, or paragraph to distinguish the part that really
matters from other parts that might be more detailed, more jovial, or
merely boilerplate.

For example, the first word of the previous paragraph is marked up with
strong to distinguish it from the more detailed text in the rest of the
paragraph."

But that is not all: the STRONG element may be used (among other uses)
to mark up a warning, caution notice, or to denote contents that the
user needs to see sooner than other parts of the document.

At least the two mentioned document authors chose to use the ambiguous
STRONG, which has changed it's meaning from spec to spec (I bet nobody
knows it's meaning anymore) over H5, which has maintained semantics
quite nicely. I've done that also, for reasons that might have been
justifiable about two decades ago.

--
Best wishes, Osmo

On 26/03/2018 12:00, Fernand van Olphen wrote:
> If you take a look at this website: http://inclusivedesignprinciples.org/
>
> The heading "The principles" (h2) is set in a smaller font than the headings below, like "Provide comparable experience" (h3). The visual weight of the latter is clearly different.
>
> According to 1.3.1, and the discussion in this thread, is this wrong? Which, if it is, feels awkward to me, because the headings on this website logically follow one another.
>
> Fernand van Olphen
> Accessibility Advisor
> Municipality of the Hague
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
> > > > >

From: glen walker
Date: Mon, Mar 26 2018 11:54AM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Nice point, Osmo. I didn't really look at the details of the expanded
sections. Just the h1-h3 headings that are visible by default.

However, upon further look, I still wouldn't fail it. The "Full
Description" and "Examples" have an appropriate h4. Yes, there are several
occurrences of each one, but each one is correctly nested under the
appropriate h3.

The strong text under examples is more like a definition list
(<dl>/<dt>/<dd>), but definition lists aren't very well supported by AT. I
wouldn't fail the page just because the definition terms aren't marked as
headings. The terms are contained in a list and are easily navigable.
Now, if each term had a bunch of information below it then maybe it should
be a heading, but as the page currently stands the term is just followed by
a short paragraph definition, not really worth a heading. This is, of
course, just my subjective opinion.

From: KP
Date: Mon, Mar 26 2018 12:57PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

I can definitely see a case for skipping where elements have similar weighting within a page (eg h4) under an h2 but some of thise sections don't require a subheading within an h2 section.

You are meeting consistency where similarly important things are weighted the same but not adding unnecessary guff just to neet an arbitrary ‘must not skip'

Kevin

Sent from my iPhone

> On 27/03/2018, at 01:29, Osmo Saarikumpu < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 22/03/2018 23:58, KP wrote:
>> True Bevi, I would assume 1.3.1 requires the visual formatting to be logical too. It should probably refer to logical rather than visual
>
> I really hope that 1.3.1 just took for granted that the visual presentation matched the semantics under the hood. After all it speaks of information and relationships that are *implied* by visual or auditory formatting" (emphasis mine). The above "implied" meaning: "as a logical consequence" (due to default formatting styles of the semantically used elements).
>
> I really can't see but two reasons for skipping heading levels:
>
> 1) the author has made an unintentional mistake
> 2) the used header element reflects the author's idea about the element's default stylistic formatting rather than the semantics it conveys
>
> And alas! I've certainly been guilty of the latter.
>
> --
> Best wishes, Osmo
> > > >

From: Bourne, Sarah (MASSIT)
Date: Mon, Mar 26 2018 2:21PM
Subject: Re: Query on heading hierarchy
← Previous message | Next message →

Why would you want to skip a heading level? I came across an example the other day. Content is created as a collection of components in a content management system. There are components that can be re-used in different contexts, such as the location information for a specific office. When the component was first created, it needed an H4 heading for where it was used. And then new page types were created and somebody wanted to use it in a place that had no H3 headings. It turns out that this is a non-trivial problem to fix - for all the same reasons that HTML5 automatic heading outlines have never been implemented.

My advice was that it was better to skip a level on some pages, than to have it be at too high a level on others. Not optimum, but it's not the worst thing that can happen.

sb
Sarah E. Bourne
Director of IT Accessibility
Executive Office of Technology Services and Security (EOTSS)
1 Ashburton Place, 8th Floor, Boston, MA 02108
Office: (617) 626-4502
= EMAIL ADDRESS REMOVED = | www.mass.gov/eotss

From: Karlen Communications
Date: Tue, Mar 27 2018 11:58AM
Subject: Re: Query on heading hierarchy
← Previous message | No next message

This is getting interesting in terms of mapping out a future standard. In PDF 2 we now have the concept of both a <Document> and a <DocumentFragment> Tag.

If we were to create an international content standard, we could specify that document authors/PDF remediators use sequential Headings, but if you are bringing content together from other places, or if you are only using a fragment of a document, then the use of sequential Headings is an exception to the specification. This would provide a mechanism to let people know whether they are viewing/accessing a document or a document fragment. We would need to work with developers to be able to make the distinction clear to those using adaptive technology.

The point of <DocumentFragment> as a Tag is to provide a way for chapters or segments of publications to be tagged without starting with an <H1> Tag. However, the same designation could be used for those few and far between exceptions of skipped Headings while preserving good document design principles for training/education.

In the meantime, we could add this concept to a best practices document...but I would like to see us work toward a standard rather than guidelines/best practices. And we still need a way to designate something as either a full document or <Document>or a <DocumentFragment>.

With standards committees moving away from content provisions, we need to move our best practices into standards we can point to for legal and procurement purposes.

Thoughts?

Cheers, Karen