RE: Headings and ARIA substitutes

It would be a somewhat ambiguous and incomplete statement to say only that “Headings are distinguished visually by one or more of the following…”.  Ambiguity is inherent by not defining from what they should be visually distinct, and incompleteness stems from not defining the negative situation of when they should not be distinct.  Consider the following as a draft off the top of my head:

“A heading within a page region should be visually distinct from all other text content in the same region, including, but not limited to, paragraphs, tables, captions, input labels, and any other headings not of the same level.  Multiple headings at the same level within the same or identical page regions should be visually consistent.”

Glossary definitions would then be needed for “visually distinct as begun in previous emails)”, “visually consistent”, and “page region” (perhaps there’s already better terminology for the lattermost that I’m missing?).  The mention of regions attempts to cover situations such as unnecessarily restricting the <h3> within a main article to be styled exactly like an appropriate <h3> in a sidebar or footer area.

Of course, although I think headings are at the top of the priority list, I’m already wondering if this should be generalized further.  For example, for the same accessibility reasons you’d want headings to be visually distinct (or consistent), you might also want all captions or paragraph text to be distinct (or consistent), effectively addressing all converse situations.

PS – Wayne, I have no idea how my suggestion on simplifying the COGA document headings led to this discussion, but I’m glad it did as it is certainly important!

Steve

From: Bradley Montgomery, Rachael L. [mailto:rbradley@mitre.org]
Sent: Thursday, June 16, 2016 4:42 PM
To: WCAG <w3c-wai-gl@w3.org>
Subject: RE: Headings and ARIA substitutes

+1 to capturing a more generic set of options

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Thursday, June 16, 2016 4:29 PM
To: James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>
Cc: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Headings and ARIA substitutes

I agree with you James, that other visual cues can be provided in 2.4.6, and we should capture it in a perhaps more generic fashion than just text size. Maybe as a list of possibilities?
Headings are distinguished visually by one or more of the following:

-Text size
-Text weight
-Line spacing
-Border
-Dedicated font type (risky unless in combination)
-Capitalization (Kind of weak)
-(Not colour or background colour alone, unless there are other indicators such as border)
Of course all headings need heading markup as required in 1.3.1
Note: I don't fail unmarked heading <p class=bigBold">  in 4.1.2 because I think that SC is more for custom built widgets, as per the description in the Understanding

Cheers,
David MacDonald



CanAdapt Solutions Inc.
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Thu, Jun 16, 2016 at 3:59 PM, James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>> wrote:

I would disagree that headings always have to be larger than the standard text size. Other techniques can also indicate that things are headings. For example, line spacing, capitalization, font weight, colour and background colour, borders etc. In combination these things can visually show something as a header even if it is the same size (or even smaller) than the body text.

For example, the heading for Paragraph 1 below is 120% of the size of the body text, bold and just meets the 4.5:1 luminosity contrast ratio, whereas Paragraph 2 is 100% of the body text, capitalized, and inversed (white on black).

I would be opposed to defining something based on text size only as a requirement for headers as the different techniques that can be used to make something visually a header are varied.

For those not viewing in HTML email (or whose email has eaten the styling) you can see at http://jsbin.com/sabedalugu


Paragraph 1

Bacon ipsum dolor amet labore enim occaecat, pastrami short ribs fugiat proident shankle aliqua lorem. Adipisicing culpa ground round, pork chop beef ribs ut ex. Meatball jerky leberkas, rump ea cupidatat short loin. Aliquip et ad veniam tempor bacon, sirloin proident pariatur filet mignon sed doner cillum cow consectetur. Reprehenderit in shank cillum ut short loin.

Paragraph 2

Chuck id est ribeye rump cillum cupidatat corned beef sirloin excepteur picanha proident. Shoulder occaecat cillum, tail cow venison voluptate duis. Tail turkey mollit, pancetta aliquip venison nisi. In fatback cillum, sed ex tempor proident filet mignon. Lorem enim voluptate shankle velit irure brisket. Corned beef sirloin qui, veniam minim incididunt sed jerky. Enim occaecat filet mignon bacon turducken brisket, pork belly swine boudin frankfurter do.

Regards,

james



On 6/16/2016 11:07 AM, John Foliot wrote:
Hi Wayne,

While I wholeheartedly agree that including proper heading navigation is critical, and developers SHOULD (in the RFC 2119 sense) be using semantic headings in their markup, I've also sadly seen CSS similar to this:  h4 {font-size:10pt;} - which also defeats the point you are making (as I believe this would be effectively useless to low-vision users as a means of content navigation).

While I've not actually gone and looked at the emergent work of the Low Vision TF (yet), I'm curious whether or not there has been any thought towards proposing a new Success Criteria that sought to address this kind of issue? Perhaps a SC that suggested (total spitballing here...) that headings at level 4 or higher (a.k.a. h1, h2, h3) maintain a visual styling that ensures that the text is at least XX % larger than the body text (??). I'd be curious to hear other's thoughts on this, as I'm not sure how something like that would be received, but it sort of sounds like what Wayne is suggesting is needed. Equally, would increased size alone be the proposed requirement, or would something like increased font-weight also meet the functional need you are describing? (i.e. the heading text would remain at the same size as body/paragraph text, but have an increased weight instead. Wayne, would that also work?)

Curious to hear others chime in here as well.

JF



On Thu, Jun 16, 2016 at 12:24 PM, Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
Hi,
I did read Stephen's comment, and realize that those were extremely complex headings. That is why I did not include this in the COGA thread.
I really just wanted to remind the community that for visual users that don't see wai-aria roles, states and properties, headings are important and really the only thing we have.  UA's don't give us heading navigation, but clear visible heading can really help.
There has been a discussion as to whether you need to use headings if you already use landmarks. Screen reader users often want one or the other to reduce chatter. So it is a problem for everyone.
If we could just display and navigate wai-aria roles, states and properties at the UA level this could be addressed.
That is all.
Wayne

On Thu, Jun 16, 2016 at 9:10 AM, Repsher, Stephen J <stephen.j.repsher@boeing.com<mailto:stephen.j.repsher@boeing.com>> wrote:
Hi Wayne,

I’m confused as to what your email below is in response to…. Could you please clarify or point me to the originating discussion?  I ask because I too would strongly oppose any downplay in the need for heading navigation.

Thanks,
Steve

From: Wayne Dick [mailto:wayneedick@gmail.com<mailto:wayneedick@gmail.com>]
Sent: Wednesday, June 15, 2016 5:22 PM
To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Headings and ARIA substitutes

I really depend on headings. It is not my experience that ARIA attributes display visibly. I have even tried [aria-label]::before {content: attr(aria-label);}. Maybe when user agents start showing ARIA accessible names on request, I would be comfortable dropping heading navigation. Until then I need headings. This is no debate.
Wayne
Note: Please don't tell me that there is some magic AT that will fix this for me. I've probably tried many more ATs than you.




--
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

--
Regards, James

[Oracle]<http://www.oracle.com/>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[Green              Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment