RE: Headings and ARIA substitutes

Ø  ...) 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.

I am not in favor of such a requirement.  If users want larger they can do that through CSS in many cases but mandating size seems over reaching.

Jonathan


From: John Foliot [mailto:john.foliot@deque.com]
Sent: Thursday, June 16, 2016 2:07 PM
To: Wayne Dick; public-low-vision-a11y-tf
Cc: Repsher, Stephen J; GLWAI Guidelines WG org
Subject: Re: Headings and ARIA substitutes

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