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



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

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

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