WebAIM - Web Accessibility In Mind

E-mail List Archives

Scope on TD

for

From: YOUNGV5@nationwide.com
Date: May 19, 2011 2:48PM

I have a multi-level row heading table. Does anyone have experience
putting scope="row" on a TH that is actually marked up as a TD? A
developer is insisting we do it this way because of a library constraint.
The HTML specification makes mention of the using this technique:

http://www.w3.org/TR/html4/struct/tables.html#h-11.4

I'm just not certain of the practical accessibility. Of course this works
in JAWS 12 and IE 8, but what about sufficient backwards compatibility for
this technique and with various assistive technology? Also, it seems the
scope attribute is not available on TD in HTML5:

http://dev.w3.org/html5/spec/Overview.html#the-td-element

Any advice would be much appreciated.

Thanks.

-Vinnie

Vincent Young
Accessibility Manager
User Experience Team
Nationwide®
o | 614·677·5094
c | 614·607·3400
e | <EMAIL REMOVED>




From:
"John Foliot" < <EMAIL REMOVED> >
To:
"'WebAIM Discussion List'" < <EMAIL REMOVED> >
Date:
05/17/2011 03:05 PM
Subject:
Re: [WebAIM] headings for links list
Sent by:
<EMAIL REMOVED>



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