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> 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> 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]
>> *Sent:* Wednesday, June 15, 2016 5:22 PM
>> *To:* GLWAI Guidelines WG org <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

Advancing the mission of digital accessibility and inclusion