E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: screen reader usability and lists (was re: evaluating accessibility with WCAG 2.0 (Angela French))

Number of posts in this thread: 15 (In chronological order)

From: Jennison Mark Asuncion
Date: Sat, Apr 09 2011 8:12AM
Subject: screen reader usability and lists (was re: evaluating accessibility with WCAG 2.0 (Angela French))
No previous message | Next message →

Hello,

Speaking strictly as one screen reader user here, I see no incremental
value what so ever in encountering a list with one item. In fact, I see
such lists as unnecessary audio clutter needing to be taken in.

Jennison

--
Jennison Mark Asuncion
Co-Director, Adaptech Research Network <www.adaptech.org>
LinkedIn at <www.linkedin.com/in/jennison>

From: Birkir R. Gunnarsson
Date: Sat, Apr 09 2011 9:27AM
Subject: Re: screen reader usability and lists (was re: evaluating accessibility with WCAG 2.0 (Angela French))
← Previous message | Next message →

Agreed.
Lists with one items are simply annoying, speaking for myself, so are
too many AccessKeys and multiple lines or links inside of headings.
Excessive use of html structure elements makes them a lot less useful
for navigation.

On 4/9/11, Jennison Mark Asuncion < = EMAIL ADDRESS REMOVED = > wrote:
>
>
>
>
> Hello,
>
> Speaking strictly as one screen reader user here, I see no incremental
> value what so ever in encountering a list with one item. In fact, I see
> such lists as unnecessary audio clutter needing to be taken in.
>
> Jennison
>
> --
> Jennison Mark Asuncion
> Co-Director, Adaptech Research Network <www.adaptech.org>
> LinkedIn at <www.linkedin.com/in/jennison>
>
>

From: John Hicks
Date: Mon, Apr 11 2011 2:27AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Hello
I see from this exchange that my previous remark was perhaps too severe
and I buy the arguments given since.
Of course many screen readers do link listings also so the fact that
these links are not in an html list is not the end of the story

Nevertheless, using an ascii character (the pipe symbol) for formatting
still irks me.

If this "non-list" of links were vertical with a lower case "o" making a
bullet for each item .... which is basically the same thing, I bet the
reactions would be different.

In any event it would read like a romantic poem (O! site map, O!
Contact, O! Terms of Use...)

Interesting topic

best wishes,
John

e 09/04/2011 01:29, Angela French a écrit :
> Agreed.
>
>

From: Jason Kiss
Date: Mon, Apr 11 2011 4:15AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Thanks for rekindling the discussion, John. Agreed: it is an interesting
topic.

Success Criterion 1.3.1 does not seem to offer an absolute conclusion
either way with regard to a group of links displayed horizontally and
separated by the pipe character, even if we all seem to be in agreement
that best practice would have it marked up as an unordered list. I meant
to suggest in my earlier comments that, should one want to take a strict
approach in terms of enforcing best practice and semantic HTML, that it
could be considered a WCAG violation. In the end, however, the
application of the Success Criterion, at least in this scenario, is
certainly open to interpretation.

This is what I find most interesting about the discussion. While WCAG
2.0 has done much to provide more strongly testable guidelines, thereby
resulting in more decisive declarations of what does or does not comply,
there still remains room for argument and interpretation, particularly
with certain Success Criteria like 1.3.1. I'm not suggesting this is
necessarily a bad thing.

For argument's sake, let's assume that the main navigation is a group of
links visually presented in typical fashion as a distinct and
horizontally arranged grouping, with each link separated by a pipe. Is
it reasonable to suggest that this arrangement visually *implies* that
the structure of the overall grouping and the relationships among the
links are those of a list? Certainly, such a visual arrangement is not
the traditional presentation of a vertical list of bulleted list items,
but does a sighted user conceptually understand this arrangement as a
set or list of individual but related links? What are the reasons for
displaying them as a distinct group and of separating each link with a
pipe?

John correctly notes that a list of links so presented and marked up is
hardly an egregious accessibility barrier. Still, declaring such less
than ideal markup as a violation of WCAG, especially when more usable
and semantically correct markup exists, can be a nice bit of leverage in
certain contexts, at least in terms of requiring best practices and
accessible, semantic HTML.

Is such an interpretation even reasonable, or am I just muddying the
waters around the intent of Success Criterion 1.3.1 or of the
application of WCAG Success Criteria in general?

Jason

On 11/04/11 20:26, John Hicks wrote:
> Hello
> I see from this exchange that my previous remark was perhaps too severe
> and I buy the arguments given since.
> Of course many screen readers do link listings also so the fact that
> these links are not in an html list is not the end of the story
>
> Nevertheless, using an ascii character (the pipe symbol) for formatting
> still irks me.
>
> If this "non-list" of links were vertical with a lower case "o" making a
> bullet for each item .... which is basically the same thing, I bet the
> reactions would be different.
>
> In any event it would read like a romantic poem (O! site map, O!
> Contact, O! Terms of Use...)
>
> Interesting topic
>
> best wishes,
> John
>
>
> e 09/04/2011 01:29, Angela French a écrit :
>> Agreed.
>>
>>

From: Andrew Kirkpatrick
Date: Mon, Apr 11 2011 6:30AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

I find myself wondering where to draw the line. If the argument for the use of a list for any set of related links is based on the need for users to know that a set of items are in a group and how many items are in that group then perhaps lists should be used more - cnn.com has story after story on their home page, do we recommend that the story titles and short teaser blurbs be encased in a list item and the group of stories be marked up as a list? This would help people know how many stories there are, why don't we do this? Or even within a story, there may be nine paragraphs that are related information that is supposed to be presented in an ordered fashion - perhaps we need to put each paragraph into a list item and make the story an ordered list? Of course, I'm being deliberately difficult but I think that we may be overstating the importance of embedding simple sets of links into semantic lists and running the risk of creating an unnecessarily verbose audio UI for audio users.

Looking around, people that you'd think would be in tune with end-user needs seem perfectly content without using OL or UL for sets of links...

Freedom Scientific's navigation bar:
<a href="/default.asp"> Home </a> <img src="/images/vline.gif" alt=""><a href="/product-portal.asp" > Products </a><img src="/images/vline.gif" alt="" ><a href="/purchase.asp"> Purchase </a><img src="/images/vline.gif" alt=""><a href="/support.asp"> Support </a><img src="/images/vline.gif" alt=""><a href="/training.asp"> Training </a><img src="/images/vline.gif" alt=""><a href="/about/about.asp"> About Us </a><img src="/images/vline.gif" alt=""><a href="/about/vision-facts.asp"> Low Vision Facts </a>

GW-Micro's navbar:
<A HREF="#mainHeadingTitle" STYLE="position: absolute; left: -1000px; font-size: 0px;">Skip to Main Content</A><A CLASS="navBarLink" HREF="/Window-Eyes" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Window-Eyes</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/Notetakers" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Notetakers</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/DAISY_Readers" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >DAISY Readers</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/Braille_Displays" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Braille Displays</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/Low_Vision" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Low Vision</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/Support" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Support</A> <IMG SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A CLASS="navBarLink" HREF="/Training" onMouseOver="this.style.color='#230E75';" onMouseOut="this.style.color='#FFFFFF';" >Training</A>

National Federation of the Blind navbar:
<div id="HomeMenu"><a href="http://www.nfb.org/nfb/About_the_NFB.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_About.gif" alt="About NFB" width="128" height="38" border="0"></a><img src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38" alt="Line"><a href="http://www.nfb.org/nfb/Info_About_Vision_Loss_For.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_Information.gif" alt="Information About Vision Loss For" width="169" height="38" border="0"></a><img src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38" alt="Line"><a href="http://www.nfb.org/nfb/Members.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_Members.gif" alt="Members" width="103" height="38" border="0"></a><img src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38" alt="Line"><a href="http://www.nfb.org/nfb/Resources.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_Resources.gif" alt="Resources" width="117" height="38" border="0"></a><img src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38" alt="Line"><a href="http://www.nfb.org/nfb/Products_and_Technology.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_Products.gif" alt="Products and Technology" width="114" height="38" border="0"></a><img src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38" alt="Line"><a href="http://www.nfb.org/nfb/Publications.asp?SnID=1950147763"><img src="/images/nfb/Template/NFBHome_Publications.gif" alt="Publications" width="127" height="38" border="0"></a></div>

American Council of the Blind nav:

[<A HREF="index.html">ACB Home</A> |

<A HREF="profile.html">About ACB</A> |
<A HREF="washington/index.html">Washington Connection</A> |
<A HREF="magazine/index.html">Braille Forum</A> |
<A HREF="http://acb.org/store/index.php?option=com_content&;view=article&id=11&Itemid=14">Donate to ACB</A> |
 
<A HREF="affiliates/index.html">Affiliates</A> |
<A HREF="resources/index.html">Helpful Resources</A> |

<a href="conference/index.html">Conference and Convention</a> |
<a href="http://acb.org/store/index.html">ACB Store</a> ]


Worth noting that AFB and RNIB both use lists widely.

On Zeldman.com, there are items that seem like lists, but are not marked up as such:
e.g. "Filed under: A Book Apart, A List Apart, content, content strategy, Design, E-Books, editorial, Education, wordpress"

Same thing on the Yahoo! Accessibility blog:
"Tags: assistive technology, Closed Captions, Deaf, hard of hearing, sean zdenek, Television"

My gut is that we are calling things lists when the design aspects of web development work make it easy to do so, and that the connection to what users need is not clearly identified. I'd really like to see a description of what content types belong in lists and to what level of complexity an author should pursue in achieving that goal. Until we have that, when I see a set of links that are marked up inline within a simple paragraph I can't justify calling it a 1.3.1 failure.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

From: Angela French
Date: Mon, Apr 11 2011 9:21AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

From: Accessibility India
Date: Mon, Apr 11 2011 11:36AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Awesome discussion. I'd like to know how screen reader users
experience the tag. Is it transparent? Does it have semantic
meaning? Do you expect
a certain content when you encounter one? I am a sighted user. But
to me, harkening back to early days of elementary school grammar, a
paragraph is a
distinct portion of writing that contains a particular thought or
idea, and consists of at least one sentence, usually more. If a 
tag has that same
meaning to a screen reader user, wouldn't a bunch of hyperlinked words
separated by a pipe be a nonsense sentence?

For a screen reader such as JAWS a blank line is encountered before
and after the paragraph i.e . Alternately by using the short-cut
"p" with JAWS you can jump from one para to another. With NVDA you
cannot find much different with tag. I tried using the short-cut
"p" on webpage with NVDA but cannot find any any paragraphs.
So if the user wants to jump from one paragraph to another they can
use short-cut p. Its not possible tag is used. I recommend to use
scemantic HTML.

From: Birkir R. Gunnarsson
Date: Mon, Apr 11 2011 12:00PM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Hi

At lesat my set up of Jaws 12 and IE8 inserts a new line before links re read.
So, if I create a link of links and put | between the linka (anchor
tags) Jaws put the | on a new line between each link, except, for some
strange reason, after the first link, where the | actually is on the
same line, but after the link.
For all other links you get a link on a line by it self followed by a
| on the following line.
This is from a document that did not use any paragraphs or any other
tags, just the a tag, the closing a tag and | in between links.
Weird.
Thanks
-Birkir

On 4/11/11, Accessibility India < = EMAIL ADDRESS REMOVED = > wrote:
> Awesome discussion. I'd like to know how screen reader users
> experience the tag. Is it transparent? Does it have semantic
> meaning? Do you expect
> a certain content when you encounter one? I am a sighted user. But
> to me, harkening back to early days of elementary school grammar, a
> paragraph is a
> distinct portion of writing that contains a particular thought or
> idea, and consists of at least one sentence, usually more. If a 
> tag has that same
> meaning to a screen reader user, wouldn't a bunch of hyperlinked words
> separated by a pipe be a nonsense sentence?
>
> For a screen reader such as JAWS a blank line is encountered before
> and after the paragraph i.e . Alternately by using the short-cut
> "p" with JAWS you can jump from one para to another. With NVDA you
> cannot find much different with tag. I tried using the short-cut
> "p" on webpage with NVDA but cannot find any any paragraphs.
> So if the user wants to jump from one paragraph to another they can
> use short-cut p. Its not possible tag is used. I recommend to use
> scemantic HTML.
>

From: Keith (mteye)
Date: Mon, Apr 11 2011 3:18PM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

The p tag primarily is for denoting a new paragraph. Just as in writing on a
piece of paper, it's there to tell where the information changes to another
group of information. Simple.

In the world of html, it also has the handy feature of adding white space,
although the white space can be better dealt with by a style sheet when more
or less is needed. Or in creating other affects. Such as indents, hanging or
otherwise.

I suppose that a p tag could also be handy in separating an object. Wrapping
an element in it to make sure it stood out, with white space around it.
Although a div tag might be the better choice there.

In the case where someone placed a series of p tags, hoping that it has the
same affect as multiple carriage returns on a typewriter, a screen reader
only presents on blank line. As mentioned in another response, Jaws uses the
single key shortcut in browsers, and even html based email clients, for
jumping from paragraph to paragraph. Similar to the windows keystroke of
ctrl+down arrow. This command isn't necessarily based on the p tag, but the
white space on a page. It does the same if the whitespace comes from stacked
up br tags, or a div tag, or table tag, or any that inserts whitespace
before the information it presents.

from
Keith H

From: Keith (mteye)
Date: Mon, Apr 11 2011 3:42PM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

I'm assuming this is a document you coded yourself to play with? Possibly
you wrapped the first vertical bar in the tag. as in:

<a (stuff goes here) | </a>

To me the use of the vertical bar goes back to the days before graphic
technology was available. Remember making images by using ascii text
symbols, arranged in column and row placement to make an image of things. A
bicyclist, a car, a dog, a flower, etc. (oops, I should have put that list
in a ul tag, sorry.)

The technique of the horizontal links has real world similarity. Think of
file tabs on those manilla folders in a desk drawer, or the tabs on a
rolodex. The vertical bar harkens back to the ascii style of dividing one
choice from another, or as a representation of the gap between file tabs. It
is also helpful when such a choice of links contain more than a single word.
For example, if a simple web page has the options:

Home About Car Parts Service Support

Without any separation, or visual clues about the site areas, how many are
there? Six? Four? Maybe only three? A screen reader user will have the
advantage, since the software will separate the links, and you'll know what
the text is that's included in each link. The vertical bar then is
irrelevant. It's only there for the disadvantaged person with perfectly good
eyesight.

Of course, a vertical line can better, and more semantically be drawn with a
style sheet. It's invisible to the screen user, who it's irrelevant for, and
it appears to divid the links for the sighted person. Not to mention that
the style sheet can also tweak the color scheme, size, and certain other
dynamic actions as well.

from
Keith H

From: Jason Kiss
Date: Mon, Apr 11 2011 5:45PM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Being deliberately difficult can sometimes be useful :)

Despite my seeming protestations, I do echo your concerns, Andrew. It is
very easy to see lists everywhere, and I am sensitive to the fact that not
everything that is list-like should be marked up as a list, if only to avoid
unnecessary noise. I, too, would like a more definite account of what
content calls for list markup. Where my apparently demanding predilection
for marking up a set of links in a nav bar as a list comes from, I don't
know. I do think that list markup is semantically appropriate in this case,
but it could also be that I'm just a slave to that convention. Then again,
for some reason I'm okay with short lists of items that appear as part of a
sentence or a more sentence-like structure, as I would consider the
Zeldman.com and Yahoo! Accessibility Blog cases. I do the same thing on my
site.

Seeing how common the non-list markup approach is on sites like Freedom
Scientific's, GW Micro's, the NFB's and the ACB's, perhaps it's just not
something anyone should really get concerned about, at least from a screen
reader accessibility and WCAG perspective.

Then again, it's interesting to note that the HTML on those four sites is
quite poor to begin with, at least compared to the AFB and RNIB sites, which
have relatively decent markup and do use the list markup for their nav
links. Presumably these last two sites have the same concerns in terms of
accessibility and usability for screen reader users.

Also, while list markup does lead to additional UI audio for screen reader
users, isn't the point of HTML the structural and semantic markup of the
content? What assistive technologies do with this programmatic information
is to some degree up to them. Not applying more semantic markup for the sake
of one group of assistive technologies doesn't seem the ideal path to me.
But then these are the sorts of accommodations that we end up making all the
time, and especially for screen readers. Maybe the default verbosity of
screen readers around lists is just too great. What if lists were just
verbally introduced and closed with the words "List" and "List end", leaving
additional keyboard commands for users to interrogate the number of list
items, navigate by list item, etc., if they wished?

So, no easy answers here on the list markup question, it seems, but this is
where my other concern kicks in, and that is the place for interpretation in
WCAG and Success Criteria like 1.3.1. Is there a certain and definitive
answer in this case, or are interpretations, opinions and arguments all that
we have? Again, I'm not suggesting this is a bad thing.

Thanks,

Jason

--
Jason Kiss
Web: www.accessibleculture.org
Email: = EMAIL ADDRESS REMOVED =
Twitter: @jkiss

On Tue, Apr 12, 2011 at 12:31 AM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >wrote:

> I find myself wondering where to draw the line. If the argument for the
> use of a list for any set of related links is based on the need for users to
> know that a set of items are in a group and how many items are in that group
> then perhaps lists should be used more - cnn.com has story after story on
> their home page, do we recommend that the story titles and short teaser
> blurbs be encased in a list item and the group of stories be marked up as a
> list? This would help people know how many stories there are, why don't we
> do this? Or even within a story, there may be nine paragraphs that are
> related information that is supposed to be presented in an ordered fashion -
> perhaps we need to put each paragraph into a list item and make the story an
> ordered list? Of course, I'm being deliberately difficult but I think that
> we may be overstating the importance of embedding simple sets of links into
> semantic lists and running the risk of creating an unnecessarily verbose
> audio UI for audio users.
>
> Looking around, people that you'd think would be in tune with end-user
> needs seem perfectly content without using OL or UL for sets of links...
>
> Freedom Scientific's navigation bar:
> <a href="/default.asp"> Home </a> <img
> src="/images/vline.gif" alt=""><a href="/product-portal.asp" > Products
> </a><img src="/images/vline.gif" alt="" ><a href="/purchase.asp"> Purchase
> </a><img src="/images/vline.gif" alt=""><a href="/support.asp"> Support
> </a><img src="/images/vline.gif" alt=""><a href="/training.asp"> Training
> </a><img src="/images/vline.gif" alt=""><a href="/about/about.asp"> About
> Us </a><img src="/images/vline.gif" alt=""><a
> href="/about/vision-facts.asp"> Low Vision Facts </a>
>
> GW-Micro's navbar:
> <A HREF="#mainHeadingTitle" STYLE="position: absolute; left: -1000px;
> font-size: 0px;">Skip to Main Content</A><A CLASS="navBarLink"
> HREF="/Window-Eyes" onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Window-Eyes</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/Notetakers"
> onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Notetakers</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/DAISY_Readers"
> onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >DAISY Readers</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/Braille_Displays"
> onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Braille Displays</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/Low_Vision"
> onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Low Vision</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/Support" onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Support</A> <IMG
> SRC="/images/white_bullet.gif" ALT="" ALIGN="bottom"> <A
> CLASS="navBarLink" HREF="/Training"
> onMouseOver="this.style.color='#230E75';"
> onMouseOut="this.style.color='#FFFFFF';" >Training</A>
>
> National Federation of the Blind navbar:
> <div id="HomeMenu"><a href="
> http://www.nfb.org/nfb/About_the_NFB.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_About.gif" alt="About NFB" width="128"
> height="38" border="0"></a><img
> src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38"
> alt="Line"><a href="
> http://www.nfb.org/nfb/Info_About_Vision_Loss_For.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_Information.gif" alt="Information About
> Vision Loss For" width="169" height="38" border="0"></a><img
> src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38"
> alt="Line"><a href="http://www.nfb.org/nfb/Members.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_Members.gif" alt="Members" width="103"
> height="38" border="0"></a><img
> src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38"
> alt="Line"><a href="http://www.nfb.org/nfb/Resources.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_Resources.gif" alt="Resources" width="117"
> height="38" border="0"></a><img
> src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38"
> alt="Line"><a href="
> http://www.nfb.org/nfb/Products_and_Technology.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_Products.gif" alt="Products and
> Technology" width="114" height="38" border="0"></a><img
> src="/images/nfb/Template/NFBHome_MeniDivider.gif" width="1" height="38"
> alt="Line"><a href="
> http://www.nfb.org/nfb/Publications.asp?SnID=1950147763"><img
> src="/images/nfb/Template/NFBHome_Publications.gif" alt="Publications"
> width="127" height="38" border="0"></a></div>
>
> American Council of the Blind nav:
> 
> [<A HREF="index.html">ACB Home</A> |
>
> <A HREF="profile.html">About ACB</A> |
> <A HREF="washington/index.html">Washington Connection</A> |
> <A HREF="magazine/index.html">Braille Forum</A> |
> <A HREF="
> http://acb.org/store/index.php?option=com_content&;view=article&id=11&Itemid=14">Donate
> to ACB</A> |
> 
> <A HREF="affiliates/index.html">Affiliates</A> |
> <A HREF="resources/index.html">Helpful Resources</A> |
>
> <a href="conference/index.html">Conference and Convention</a> |
> <a href="http://acb.org/store/index.html">ACB Store</a> ]
> 
>
> Worth noting that AFB and RNIB both use lists widely.
>
> On Zeldman.com, there are items that seem like lists, but are not marked up
> as such:
> e.g. "Filed under: A Book Apart, A List Apart, content, content strategy,
> Design, E-Books, editorial, Education, wordpress"
>
> Same thing on the Yahoo! Accessibility blog:
> "Tags: assistive technology, Closed Captions, Deaf, hard of hearing, sean
> zdenek, Television"
>
> My gut is that we are calling things lists when the design aspects of web
> development work make it easy to do so, and that the connection to what
> users need is not clearly identified. I'd really like to see a description
> of what content types belong in lists and to what level of complexity an
> author should pursue in achieving that goal. Until we have that, when I see
> a set of links that are marked up inline within a simple paragraph I can't
> justify calling it a 1.3.1 failure.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
>

From: Tania
Date: Mon, Apr 11 2011 8:57PM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

view as a screenreader user:
- if it is a short list of items, I prefer 
- a long list, prefer a list so I know how many items there are and whether
I want to skip it to jump directly to content.

reason I don't like links listed when they are short is to cut down on
unnecessary info and go directly to the more relevant content quickly.
screenreader users couldn't read the same amount of info as quickly as the
sighted. therefore, I don't want to be presented with to much unnecessary
info as this would slow me down.

----- Original Message -----
From: "Angela French" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, April 11, 2011 11:22 PM
Subject: Re: [WebAIM] evaluating accessibility with WCAG 2.0 (Angela French)

Awesome discussion. I'd like to know how screen reader users experience the
 tag. Is it transparent? Does it have semantic meaning? Do you expect
a certain content when you encounter one? I am a sighted user. But to me,
harkening back to early days of elementary school grammar, a paragraph is a
distinct portion of writing that contains a particular thought or idea, and
consists of at least one sentence, usually more. If a tag has that same
meaning to a screen reader user, wouldn't a bunch of hyperlinked words
separated by a pipe be a nonsense sentence?

From: John Hicks
Date: Wed, Apr 13 2011 3:12AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

Hello
Best to let this thread disappear, I know, but "speak of the devil" ...
a site I am auditing today has this exact problem...

Except, instead of the pipe "|" symbol for separating the links... they
have used a lower-case letter " l " !!!

Just thought you might find that amusing.

Good day to all,
john

From: Angela French
Date: Wed, Apr 13 2011 9:24AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | Next message →

That's funny. What do screen readers read in breadcrumbs if the developers uses a > sign between links?

From: Patrick Burke
Date: Wed, Apr 13 2011 10:03AM
Subject: Re: evaluating accessibility with WCAG 2.0 (Angela French)
← Previous message | No next message

At 08:24 AM 4/13/2011, Angela French wrote:
>That's funny. What do screen readers read in breadcrumbs if the
>developers uses a > sign between links?
It's in the category of symbols that really depend on screen reader &
speech dictionary settings (e.g., the difference between a setting
for "Most" or "Some" punctuation to be verbalized).

I usually set > not to be spoken, to make reading emails with lots of
replies easier. Of course clever people could set the speech program
to behave differently in different applications. (I also use a
braille display most of the time, so having the >'s not spoken isn't
a hardship.)

The l separator is awesome...

Patrick

>