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

​I fail visual lists not marked up with list markup... either ordered or
unordered...

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

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

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 Fri, Nov 20, 2015 at 10:13 AM, Jonathan Avila <jon.avila@ssbbartgroup.com
> wrote:

> 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
> >
>
>
>