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

David / John,
That email I forwarded documents what "available in text" means. So
for instance, a heading that is not marked up as one but appears and
functions like one will need a prefix or suffix like "header". That
word conveys the structure / relationship in text  as referred to in
1.3.1 as explained by Greg in that email.
Best regards,
Sailesh


On 11/20/15, David MacDonald <david100@sympatico.ca> wrote:
> ​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
>> >
>>
>>
>>
>

Received on Friday, 20 November 2015 21:30:13 UTC