Re: Forwarding explanation of "available in text" in SC 1.3.1

My two cents -- I hold headings and unordered list items to a higher standard for semantic markup because unlike labels they are used for navigation.     So if the content was html would require heading markup to meet 1.3.1. 

Ordered list items that are not nested and not in list markup would likely pass 1.3.1 IMO. 

Jon

Sent from my iPhone

> On Nov 20, 2015, at 10:01 AM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> ---------- Forwarded message ----------
> From: Gregg Vanderheiden <gv@trace.wisc.edu>
> Date: Fri, 29 Aug 2014 23:56:57 -0500
> Subject: Re: Heading techniques
> To: Sailesh Panchang <sailesh.panchang@deque.com>
> Cc: Andrew Kirkpatrick <akirkpat@adobe.com>,
> "lorettaguarino@google.com Guarino-Reid" <lorettaguarino@google.com>,
> Joshue O Connor <joshue.oconnor@cfit.ie>
> 
> On Aug 29, 2014, at 5:46 PM, Sailesh Panchang
> <sailesh.panchang@deque.com> wrote:
> 
>> Andrew,
>> About  a text label that serves as a heading without being so marked
>> up and is placed before the related content separated by a hyphen,
>> colon or line and looks the same as the related text in terms of font,
>> size etc.:
>> 
>> A non-PWD user will read through the content and interpret that text
>> label as a heading even though it does not look like one i.e. does not
>> have a heading role visually .
> 
> I think there is a little confusion here.
> 
> If a non_PWD user will interpret text as a heading — then it is by
> definition formatted to look like a heading.
> 
> the question isn’t whether it is formatted to look like an HTML
> standard heading — the question is — “is it formatted in any manner
> that would cause someone with vision to understand that it was a
> heading”
> 
> if so that fact needs to be programmatically determinable - in order
> to meet SC 1.3.1.
> NOW - It is important to note that marking something with a header tag
> is not the only way to make it programmatically determinable.  But in
> HTML it is the surest and best way.    If you don’t want it to look
> like an HTML formatted header - you can always use style to change it
> to look like anything you like.
> Again - this is technically what is required to meet SC 1.3.1.    On
> any page it may not be difficult for users or create any particular
> barrier.  But on another page it might be very confusing if it is not
> PD.
> 
>> The info is available in text though it is not PD, so it meets SC 1.3.1.
> 
> No it is not.   SC 1.3.1 does not mean the header text is available —
> it means  the fact that it is a header needs to be available in text.
> If you put   “(header)” after every header - then the fact that it
> was a header would be available in text.
> 
>> Sure in SC 1.3.1, PD is stronger than being available in text and I
>> always press for heading markup.
> 
> Good.
> 
>> Also, Greg had explained: "Text, if it is not an image, is
>> programmatically determinable. So any information given in text would
>> be programmatically
>> determinable if it is on the page and visible to all”.
> 
> Correct.   So the Header text is PD.   But the fact that it IS a
> header is not available in text unless it says  “(header)” in text
> after (or before) the header.    The information that needs to be in
> text and that is not in text is “this is a header”.
> 
>> I hope I have conveyed my reasoning and am able to influence your thinking.
> 
>> Also, this happens not infrequently and is not an "edge" case. I see
>> it on pages that detail legal terms , privacy policy or  sometimes as
>> a label for groups of links in the footer section.
> 
> Yes it does happen a lot.   And in some places it is not only a
> violation of SC 1.3.1 but it is a significant barrier to usability.
> for example
> 
> Spices
>   onions
>   garlic
>   thyme
> 
> Here it is a header but it is not clear with a SR that this is not a
> list of 4 things that begins with Spices  (rather than a header with
> three things under it)
> 
> Both the header and the list are in text — but the fact that they ARE
> a header and text are not in text - and are not PD
> 
> 
> Here they are in text and the fact that they are header and list items
> are in text.
> 
> Spices (header)
> (item) onion
> (item) garlic
> (item) Thyme
> 
> but who would want to do that?
> 
> Now - the following is also a violation of SC 1.3.1  but it really
> isn’t much of a barrier to reading.   It IS a barrier to navigation
> though unless the SR is very intelligent and can ID the text as a
> header itself.  (If the user can ID it - but not the SR - then it is
> not PD and violate SC 1.3.1.
> 
> 
> INTRODUCTION
> 
> This is one of the times that I really wanted……
> 
> 
> Doest this help?
> 
> 
> 
>> Thanks,
>> Sailesh
>

Received on Friday, 20 November 2015 15:14:27 UTC