WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: requiring the use of headings

for

From: Cliff Tyllick
Date: Jan 10, 2015 2:47AM

Sarah, I now realize that I cut my earlier analysis short. They might read
further to:
Situation B: The technology in use does NOT provide the semantic structure
to make the information and relationships conveyed through presentation
programmatically determinable:
where they might point to item 3:

1.

(OK, that 1 should be a 3) Making information and relationships conveyed
through presentation programmatically determinable or available in text
using the following techniques:
-

T1: Using standard text formatting conventions for paragraphs
<http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/T1>; (Text)
-

T2: Using standard text formatting conventions for lists
<http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/T2>; (Text)
-

T3: Using standard text formatting conventions for headings
<http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/T3>; (Text)

The issue here isn't whether we can add white space around words to make
them look like headings or use asterisks as bullets in front of the items
in the list. It's whether the technology provides a way to label the
content semantically. HTML does. Text format does not. Each of the
techniques mentioned above begins with "T" because it is applicable to text
format only. So ignore Situation B. Your semantically rich technology is
dealt with by Situation A.

Actually, I do see one technique under Situation B that one could argue is
relevant:

1.

G117: Using text to convey information that is conveyed by variations in
presentation of text
<http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/G117>;.


Following that link to G117 and skimming down to the examples (all that
prefatory content bogs me down when a colleague is awaiting an answer so he
can hit "Publish"), I take note of Example 1. In that example, which
demonstrates a solution in HTML, we see that you can designate an item in a
list as new by making it bold when all the other items are roman. You can,
but it won't be accessible—until you add "(New!)" to the end of the item.
Then, because you have put in words the semantic relationship previously
conveyed by appearance alone, that information is available to all. (It's
especially available to me, who, lacking clairvoyance, would have no
earthly idea what that bold format was supposed to tell me, except that
someone didn't want me to miss that item.) And that's the technique—add a
few words that say, "Hey! This is what that change in appearance is
all about!"

So here's how that pertains to you, Sarah: Your authors, designers, and
developers don't need to use those bothersome tags, h1 through h6, to
designate their heading hierarchy. They can use words instead:
- For h1, add "(This is a main heading.)" after the heading.
- For h2, add "(This is a section heading.)"
- For h3, add "(This is a subheading.)" *unless* you are also using h4s, in
which case you should add, "(This is a heading within a section, not as
important as a section heading, but more important than a subheading. Maybe
we could call it a subsection heading.)"
- If you *are* using h4s, this is where you use "(This is a subheading.)"
- If you're using h5 and h6, you're on your own.

Isn't that easy? You could put a tab between the heading and its label,
right-align the label, fill some of that troublesome empty space between
paragraphs, and produce a somewhat more balanced design. Everybody would
know where each heading fits in your hierarchy, although people using
screen readers would have to wait a bit longer to hear the distinguishing
word announced. But I'm sure that Birkir and Jennison and Léonie and all my
other friends who use screen readers would agree that their inconvenience
is a modest price to pay to avoid offending the sensibilities of people who
can't be troubled to code semantically.

OK, I have exaggerated the point. (And, yes, I know that a tab has no
effect on the presentation of HTML. And that none of my screen-reader-using
friends would at all mind offending the ignorami.) But the simple fact is
that with WCAG set up as it is we can't always find the right answer
quickly, and too often the people we are trying to help will find the wrong
answer on their own and think it's right.

You can see from her signature block that Sarah is no lightweight in the
field of accessibility. And I've spent some time having fun with this, but
even without that playtime it took me far too long to find the answer—and
to *know* that I had found the answer—even *after* Jonathan and Joe
had told me where to look! Maybe I'm far from the sharpest tack in the box,
but I'm not the dullest one, either.

There's no reason for WCAG to be this hard. And we don't have to wreck WCAG
to fix this.

Cliff Tyllick
Accessibility Curmudgeon


On Saturday, January 10, 2015, Cliff Tyllick < <EMAIL REMOVED> > wrote:

> Sarah, on careful examination of Understanding SC 1.3.1, reading down to:
>
> Techniques and Failures for Success Criterion 1.3.1 - Info and
> Relationships
> > Sufficient Techniques
> Situation A: The technology provides semantic structure to make
> information and relationships conveyed through presentation
> programmatically determinable:
> I notice that the twenty-fourth bullet under item 10 mentions that one way
> to meet this success criterion is, indeed, to mark up headings using h1
> through h6. (That's technique H42.)
>
> Thanks for asking this question. In doing so, you have helped me improve
> my presentation for CSUN. <big grin>
>
> If, that is, you don't mind my using this discussion as a case in point.
>
> Cliff Tyllick
>
> On Friday, January 9, 2015, Krack, Joseph@DOR < <EMAIL REMOVED> >
> wrote:
>
>> Regarding Headings, in addition to 2.4.6 and 2.4.10, I point to 1.3.1 in
>> my standards.
>>
>> Joe
>>
>>