E-mail List Archives

Search E-mail List Archives for

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

From: Angela French
Date: Mon, May 16 2011 3:21PM
Subject: headings for links list
No previous message | Next message →

Today I realized how hard it is to find something specific within the WCAG 2.0!

Can anyone tell me if there is anything that indicates that a heading should be used to introduce a list of links that would reside in the content of a page (as opposed to providing a heading on a navigation menu)? I thought there was, but now that I am looking for it specifically, it eludes me.

To those of you who are screen readers, how important is it to you that a list of links have some sort of introductory heading, as opposed to discovering the nature of the links list by its context in the page content?

Thank you.


Angela French
Internet Specialist
State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED =
http://www.checkoutacollege.com<;http://www.checkoutacollege.com/>;

From: Birkir R. Gunnarsson
Date: Mon, May 16 2011 3:36PM
Subject: Re: headings for links list
← Previous message | Next message →

Angela

I think your question comes down to a topic that requires further
research; how do screen reader users navigate a web page they do not
know for the first time. How does that differ from how they navigate
web pages they know better.
For me personally, I like html elements on a page that will get me
quickly to the element I need on that page.
To this end I can use pretty much any html element. For basic GMail
for instance, I use either x to get to the first check box (in front
of the first message in the inbox), or the alt-i AccessKey.
If there is a heading or a list I can get to quickly, I use that.
A key I use a lot, as a Jaws uer, is "n" which jumps to the first
piece of text after a group of links.
I use this a lot to navigate a page, and my biggest qualm with using
NVDA for browsing is their lack of support for this method (of course
we're all creatures of habit).
I hardly ever use navigation menus/same age links, too often they're
incorrectly implemented in any case. I find that breadcrum navigation
mens are confusing and take up a lot of space on a page, and I wish I
could get rid of them (again, I am clearly expressing my own opinions
as a user).
So, to this end, I would say the principle is to design a page in such
a way that elements people are likely to use often, can be reached
with the minimum number of keystrokes.
If this is the only list of links on the page, it does not require a
heading, since pressing l in most screen readers will take you
directly to it.
If it is one of many lists you may want to put a heading there to
allow for quick navigation (though if the page is full of headings,
you need to think about the level of your heading, try to make it so
that user can get there in under 5 key strokes, ideally 3 or less).
If there is a grou of links, then text, then the list, the n key will
get you to that text as well and arrow keys will get user to the list.
I navigate www.bbcnews.com this way. Pressing "n" in Jaws will get me
directly to the text of the first news item on the page.
Of course you could look into using landmarks as well if other html
elements do not fit with what you want to do.
hope this helps, and will start a larger discussion with the resident experts.
-Birkir


On 5/16/11, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
> Today I realized how hard it is to find something specific within the WCAG
> 2.0!
>
> Can anyone tell me if there is anything that indicates that a heading should
> be used to introduce a list of links that would reside in the content of a
> page (as opposed to providing a heading on a navigation menu)? I thought
> there was, but now that I am looking for it specifically, it eludes me.
>
> To those of you who are screen readers, how important is it to you that a
> list of links have some sort of introductory heading, as opposed to
> discovering the nature of the links list by its context in the page content?
>
> Thank you.
>
>
> Angela French
> Internet Specialist
> State Board for Community and Technical Colleges
> 360-704-4316
> = EMAIL ADDRESS REMOVED =
> http://www.checkoutacollege.com<;http://www.checkoutacollege.com/>;
>
>

From: Tim Harshbarger
Date: Mon, May 16 2011 3:42PM
Subject: Re: headings for links list
← Previous message | Next message →

Angela,

Here are my thoughts both as someone who uses a screen reader and someone who does accessibility work.

How crucial the heading is will depend on the context.

I think it would be fairly supportable for me to say that someone using a screen reader is more likely to use headings to jump from section to section on a page than other types of elements, like lists. So, if the list represents a section of the page or part of a section of a page that users might want quick access to, then the heading could be extremely useful.

I also think the heading can become more crucial depending on how easy it is for a user to figure out what the purpose of the list is. Sometimes, reading through a list, it is quite obvious how all the items are related. Other times, it can be much less so--because either the nature of the relationship is unclear or the items share more than one type of relationship.

apple, orange, watermelon.

Is the relationship I want to emphasize that they are fruits, edible, or spherical in nature? Sometimes I have seen lists of links where one list is sectional navigation and the other list of links are sub-sectional navigation. Because they were just lists, it was unclear to me what the purpose was...actually, the fact is, as a user, I made some bad assumptions about the purpose of the links which led to me making mistakes and having difficulty completing tasks on the site...so, it was less that I consciously thought the lists were unclear and more that I drew the wrong conclusions because the UI was unclear.

I am uncertain that means you always need headings before lists, just that their presence may be more necessary in certain circumstances where the list by itself might cause the user to make errors or be less effective.

Thanks!
Tim

From: Angela French
Date: Mon, May 16 2011 4:21PM
Subject: Re: headings for links list
← Previous message | Next message →

I'm going to step out here and give a practical example. This site is for the agency I work for. I have been asked to complete an informal accessibility review with suggestions for changes. While there are many problems with the site, this is one example that appears throughout:

http://168.156.9.142/college/d_facultycompensation.aspx

The page contains a table that has been used for layout purposes to contain links to PDFs. As you will see, it is impossible to navigate by links list as all the screen reader user will hear is "PDF, PDF......". I am thinking through a replacement technique for this purpose. I am leaning towards a list where each list item would be coded like this:

<li><a href="filename.pdf">Link Label (<img src="../../imgs/layout/icon_pdf.gif" alt="PDF" width="14" height="14" border="0" align="top"> 250KB)</a></li>
<li><a href="filename.doc">Another Link Label [<img src="../../imgs/layout/icon_word.gif" alt="WORD document" width="14" height="14" border="0"> 350KB]</a></li>

My quandary though, is the best way to put some sort of categorization heading for these lists (there would be three lists on this page). I would like them to look the same throughout the site (to the sited user). However, if they are headlines, then the heading number could vary from page to page if there was additional content on the page. For example, if no other content existed above these particular lists, then it would make sense to give them an h2 heading. On another page, such as this one http://168.156.9.142/college/s_runningstart.aspx , they could possibly be an h3.

This is what led me to ask what screen reader users like to see as a heading for lists of links - in this case links to documents.


Thanks,
Angela

From: Patrick H. Lauke
Date: Mon, May 16 2011 4:51PM
Subject: Re: headings for links list
← Previous message | Next message →

On 16/05/2011 22:10, Angela French wrote:
> Can anyone tell me if there is anything that indicates that a heading should be used to introduce a list of links that would reside in the content of a page (as opposed to providing a heading on a navigation menu)? I thought there was, but now that I am looking for it specifically, it eludes me.

Just wanted to mention that you're probably thinking of the made-up
extra warnings that the FAE (Functional Accessibility Evaluator) reports.

http://fae.cita.uiuc.edu/

"Each ul or ol element that precedes the last h1 element and appears to
be a navigation bar should be immediately preceded by a heading element,
preferably an h2."

This is one of the many reasons why I'm very skeptical of this tool, as
it codifies the *opinion* of the authors (rather than WCAG 2.0 advice).
Yes, things like the above are marked as "Best practices", but
nonetheless impact the score the evaluator gives...which again, it has
to be stressed, has nothing to do with WCAG 2.0 per se, but with
fictitious, made-up additional criteria.

</rant>

P
--
Patrick H. Lauke

From: John Foliot
Date: Mon, May 16 2011 5:21PM
Subject: Re: headings for links list
← Previous message | Next message →

Patrick H. Lauke
>
> Just wanted to mention that you're probably thinking of the made-up
> extra warnings that the FAE (Functional Accessibility Evaluator)
> reports.
>
> http://fae.cita.uiuc.edu/
>
> "Each ul or ol element that precedes the last h1 element and appears to
> be a navigation bar should be immediately preceded by a heading
> element,
> preferably an h2."
>
> This is one of the many reasons why I'm very skeptical of this tool, as
> it codifies the *opinion* of the authors (rather than WCAG 2.0 advice).
> Yes, things like the above are marked as "Best practices", but
> nonetheless impact the score the evaluator gives...which again, it has
> to be stressed, has nothing to do with WCAG 2.0 per se, but with
> fictitious, made-up additional criteria.
>
> </rant>

Amen.

JF

From: Tania
Date: Mon, May 16 2011 7:27PM
Subject: Re: headings for links list
← Previous message | Next message →

if it is a long list of links would like a heading
cheers
tania
----- Original Message -----
From: "Angela French" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, May 17, 2011 5:10 AM
Subject: [WebAIM] headings for links list


> Today I realized how hard it is to find something specific within the WCAG
> 2.0!
>
> Can anyone tell me if there is anything that indicates that a heading
> should be used to introduce a list of links that would reside in the
> content of a page (as opposed to providing a heading on a navigation
> menu)? I thought there was, but now that I am looking for it
> specifically, it eludes me.
>
> To those of you who are screen readers, how important is it to you that a
> list of links have some sort of introductory heading, as opposed to
> discovering the nature of the links list by its context in the page
> content?
>
> Thank you.
>
>
> Angela French
> Internet Specialist
> State Board for Community and Technical Colleges
> 360-704-4316
> = EMAIL ADDRESS REMOVED =
> http://www.checkoutacollege.com<;http://www.checkoutacollege.com/>;
>
>

From: Gunderson, Jon R
Date: Tue, May 17 2011 8:33AM
Subject: Re: headings for links list
← Previous message | Next message →

The rules are design oriented ruled developed in collaboration with web developers, people with disabilities and web accessibility experts defining and refining the rules to meet the accessible design challenges of rweb developers.

http://collaborate.athenpro.org/group/web/

The group is open for anyone to participate who is interested in best practices for web accessibility.

The major difference with these rules and other checkers is that the rules are design oriented, rather than repair oriented techniques promoted in WCAG techniques document.

Design rules are welcomed by many developer and easy for web developers to implement when designing new resources.

They are needed to codify the presence of navigation bars in web pages.

http://html.cita.illinois.edu/nav/menu/

It is an important design feature that WCAG seems to ignore, but real web designers spend a lot of time on.

Headings are very important and most web accessibility evaluation tools provide very little information to developers on how to include headers.

H1 for titling
http://html.cita.illinois.edu/nav/title/

use of sub headings
http://html.cita.illinois.edu/nav/heading/

HTML5 and ARIA provide new and better ways to mark up navigation bars (nav element and role='navigation') and these will be integrated into future versions of FAE.

ARIA
http://www.w3.org/TR/wai-aria/roles#landmark_roles

HTML5
http://www.w3.org/TR/html5/sections.html#the-nav-element


Jon

From: Hoffman, Allen
Date: Tue, May 17 2011 12:21PM
Subject: Re: headings for links list
← Previous message | Next message →

Angela:

In the most popular screen reader, links can be read based on screen
text, alt tag, and other attributes, or longest of the set. What
someone using a screen reader wants to know about each link is, "what
does this go to". The document description, or name is what the link
text should include, and then screen readers will read that. If there
are multiple formats on the same page, the solution is to just use a
consistent link order, e.g.

Document about topic #1 <link to word> <link to PDF> <link to other>.

Headers can be helpful for such lists, but on first pass there is no
perfect way to take a page layout in and figure it out without some
wasted effort.

It's kind of like asking visual readers how they rapidly assess
information--you'd get lots of answers for each person you ask.

From: John Foliot
Date: Tue, May 17 2011 1:03PM
Subject: Re: headings for links list
← Previous message | Next message →

Hoffman, Allen wrote:
>
> Angela:
>
> In the most popular screen reader, links can be read based on screen
> text, alt tag, and other attributes, or longest of the set. What
> someone using a screen reader wants to know about each link is, "what
> does this go to". The document description, or name is what the link
> text should include, and then screen readers will read that. If there
> are multiple formats on the same page, the solution is to just use a
> consistent link order, e.g.
>
> Document about topic #1 <link to word> <link to PDF> <link to other>.
>
> Headers can be helpful for such lists, but on first pass there is no
> perfect way to take a page layout in and figure it out without some
> wasted effort.
>
> It's kind of like asking visual readers how they rapidly assess
> information--you'd get lots of answers for each person you ask.

Hi Angela,

I think Allen has essentially given you the good answer, in the parts he
has provided.

Let's break it down:

THE GOAL:
The goal is to convey to the non-sighted user that a collection of links,
usually an unordered list, is in fact a navigation menu.

However, 'designers' also have other goals (aesthetics), and so in an
imperfect world we sometimes need to take some water with our wine: if a
visual layout design clearly suggests to sighted users that this list
"Foo" is a collection of menu items (satisfying the cognitive disability
requirement), then what we are left with is a need to plug the non-visual
hole. *INSISTING* that you use a <h2> heading to do that will often meet
with significant resistance from the graphic designers (and after all,
they get a say too, right?) or at best require bloated code and grumbling
from your developers (who will do whatever jus to shut up the validator).

The WCAG 2 Working Group realized that if all you do is generate a
tick-box list of do's and don'ts that it really didn't lead to better
accessibility, it led to content authors gaming the system to meet the
tick-boxes, regardless of the final outcome. Thus the final goal of WCAG 2
is to create documents that are Perceivable, Operable, Understandable, and
Robust (a.k.a. POUR) - and WCAG 2 *specifically* does not tell you that
you *MUST* use a specific technique: it defines the required outcome and
leaves it to you, the smart and caring content author, to come up with a
workable solution.

So let's look at some potential solutions.

SOLUTIONS:
1) *IF* you believe that using an <h2> to label your menu can work with
the other parts of your overall design, then great, you can use an <h2>.

2) However, you can also do things like use ARIA, and specifically ARIA's
role="navigation" (http://www.w3.org/TR/wai-aria/roles#navigation) to the
containing element: this now maps the name of that element to the
Accessibility API of the different browsers and operating systems, which
means it can be conveyed to the Assistive Technology. While it is true
that this is a 'forward' looking solution and not a 100% backward looking
solution (ie. It doesn't work in JAWS 5 <grin>), I think we as a community
can safely assume that most users keep their AT relatively up-to-date (a
point underscored in WebAIM's survey results), so for the most part this
is a safe and workable technique:

<div role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

...instead of *HAVING* to do this:

<div>
<h2 style="position:absolute; left:-999px; top:-999px;">Navigation
Menu</h2>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

********

3) Moving forward (and I would caution a bit of restraint as what I am
going to suggest does not have widespread support yet, but it's coming)...
anyway, moving forward, HTML5, realizing the importance of providing
concise and unambiguous "landmark" roles (which is what the solution above
is) are introducing a new series of landmark elements, including <nav>, so
that in the near future we will be able to do something like this:

<nav>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>

...and once again the important information (that the list is for
navigation) will be mapped to the Accessibility API, and passed on through
to the user and their AT. However, not all of the current browsers are
parsing <nav> as a discrete element today, and so it's a bit early to use
<nav> alone. However, if you want to think about moving towards HTML5 in
your development, you can use a "belt and suspenders" approach and write:

<nav role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>


CONCLUSION:
Informing non-sighted users (screen reader users) that a particular list
of links is intended to be a navigation list (as opposed to, say, a list
of recommended reading titles) is an important goal to meeting POUR.
Insisting that such a list be preceded by an <h2> is simply a reactionary,
'tickbox' solution that doesn't really think about the problem, but rather
just seeks to reach some form of "Bobby icon" status with no thought on
the part of the author. If that kind of mandate is what you require in
your environment, then you are of course free to adopt it, but as Patrick
Lauke noted earlier, it is a "made-up" rule, and not something that you
will see attached to WCAG 2.

Hope this helps.

JF

From: Angela French
Date: Tue, May 17 2011 1:21PM
Subject: Re: headings for links list
← Previous message | Next message →

Thank you JF for your contribution. I do want to clarify, in case it makes any difference, that I am not referring to a navigation list; navigation list being defined as a list of links to other web pages/sites. I am referring to a list of links to PDFs, Word, Excel, etc.

Angela




Hi Angela,

THE GOAL:
The goal is to convey to the non-sighted user that a collection of links, usually an unordered list, is in fact a navigation menu.


<div role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

...instead of *HAVING* to do this:

<div>
<h2 style="position:absolute; left:-999px; top:-999px;">Navigation Menu</h2>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

********

3) Moving forward (and I would caution a bit of restraint as what I am going to suggest does not have widespread support yet, but it's coming)...
anyway, moving forward, HTML5, realizing the importance of providing concise and unambiguous "landmark" roles (which is what the solution above
is) are introducing a new series of landmark elements, including <nav>, so that in the near future we will be able to do something like this:

<nav>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>

...and once again the important information (that the list is for
navigation) will be mapped to the Accessibility API, and passed on through to the user and their AT. However, not all of the current browsers are parsing <nav> as a discrete element today, and so it's a bit early to use <nav> alone. However, if you want to think about moving towards HTML5 in your development, you can use a "belt and suspenders" approach and write:

<nav role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>


CONCLUSION:
Informing non-sighted users (screen reader users) that a particular list of links is intended to be a navigation list (as opposed to, say, a list of recommended reading titles) is an important goal to meeting POUR.
Insisting that such a list be preceded by an <h2> is simply a reactionary, 'tickbox' solution that doesn't really think about the problem, but rather just seeks to reach some form of "Bobby icon" status with no thought on the part of the author. If that kind of mandate is what you require in your environment, then you are of course free to adopt it, but as Patrick Lauke noted earlier, it is a "made-up" rule, and not something that you will see attached to WCAG 2.

Hope this helps.

JF

From: John Foliot
Date: Tue, May 17 2011 1:27PM
Subject: Re: headings for links list
← Previous message | Next message →

Angela French wrote:
>
> Thank you JF for your contribution. I do want to clarify, in case it
> makes any difference, that I am not referring to a navigation list;
> navigation list being defined as a list of links to other web
> pages/sites. I am referring to a list of links to PDFs, Word, Excel,
> etc.

Ahh...

Perhaps then you might consider looking at aria-label, which also conveys
the accessible name to the accessibility API:

Document about topic #1 <a href="word.doc" aria-label="Word Document
Version">, <a href="pdf.pdf" aria-label="PDF Document Version">, <a
href="other.xxx" aria-label="Other Version">.

http://www.w3.org/TR/wai-aria/states_and_properties#aria-label

JF

From: David Farough
Date: Tue, May 17 2011 1:51PM
Subject: Re: headings for links list
← Previous message | Next message →

Hi Angela:
Given the context you are describing, One approach might be to provide
a Generic heading that might be used consistently throughout the site.
This way a user might be able to move directly to the heading to see the
provided resources. I am thinking of something like "relevant
documentation". I think that there are also ARIA Landmark roles that
might be used for this purpose..

David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: = EMAIL ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779

>>> Angela French < = EMAIL ADDRESS REMOVED = > 03:18 PM Tuesday, May 17, 2011
>>>
Thank you JF for your contribution. I do want to clarify, in case it
makes any difference, that I am not referring to a navigation list;
navigation list being defined as a list of links to other web
pages/sites. I am referring to a list of links to PDFs, Word, Excel,
etc.

Angela




Hi Angela,

THE GOAL:
The goal is to convey to the non-sighted user that a collection of
links, usually an unordered list, is in fact a navigation menu.


<div role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

...instead of *HAVING* to do this:

<div>
<h2 style="position:absolute; left:-999px; top:-999px;">Navigation
Menu</h2>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</div>

********

3) Moving forward (and I would caution a bit of restraint as what I am
going to suggest does not have widespread support yet, but it's
coming)...
anyway, moving forward, HTML5, realizing the importance of providing
concise and unambiguous "landmark" roles (which is what the solution
above
is) are introducing a new series of landmark elements, including <nav>,
so that in the near future we will be able to do something like this:

<nav>
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>

...and once again the important information (that the list is for
navigation) will be mapped to the Accessibility API, and passed on
through to the user and their AT. However, not all of the current
browsers are parsing <nav> as a discrete element today, and so it's a
bit early to use <nav> alone. However, if you want to think about moving
towards HTML5 in your development, you can use a "belt and suspenders"
approach and write:

<nav role="navigation">
<ul>
<li>Home</li>
<li>Menu item</li>
</ul>
</nav>


CONCLUSION:
Informing non-sighted users (screen reader users) that a particular
list of links is intended to be a navigation list (as opposed to, say, a
list of recommended reading titles) is an important goal to meeting
POUR.
Insisting that such a list be preceded by an <h2> is simply a
reactionary, 'tickbox' solution that doesn't really think about the
problem, but rather just seeks to reach some form of "Bobby icon" status
with no thought on the part of the author. If that kind of mandate is
what you require in your environment, then you are of course free to
adopt it, but as Patrick Lauke noted earlier, it is a "made-up" rule,
and not something that you will see attached to WCAG 2.

Hope this helps.

JF

From: Angela French
Date: Wed, May 18 2011 11:54AM
Subject: Re: headings for links list
← Previous message | Next message →

I wonder why they got rid of the list header that existed in html 3? Seems handy.
Angela French

From: Hoffman, Allen
Date: Wed, May 18 2011 12:21PM
Subject: Re: headings for links list
← Previous message | No next message

If the intent is to ease keyboard navigation, and associated screen reader output of topic text, you could always use multiple skip-nav and anchors to allow ease of jumping around. I think one of the best examples of a multi-format and multi-implemented example is the bookshare.org listing of books--you can view it at bookshare.org without logging in, just search for something and see that listing.