- From: James Nurthen <james.nurthen@oracle.com>
- Date: Thu, 16 Jun 2016 12:59:05 -0700
- To: w3c-wai-gl@w3.org
- Message-ID: <fa93a23e-704f-c533-bc60-74ee0cc98cf3@oracle.com>
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
<sip: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
Received on Thursday, 16 June 2016 19:59:39 UTC