E-mail List Archives
Thread: Links in tables and title attributes
Number of posts in this thread: 3 (In chronological order)
From: James Kennard
Date: Tue, Jan 05 2010 3:39AM
Subject: Links in tables and title attributes
No previous message | Next message →
Am trying to settle a debate.
In an HTML table in the first column there is an identifier, and in the
last column there is a bunch of links. The last column has the heading
"Actions". I tried using JAWS and found these links really difficult to
understand because there is no pause and no recognition that we have
reached the end of a row. Therefore I think that the titles for the
links should include the indentifier, for example: "Remove 123", "Edit
123".
A colleague of mine however thinks that the title should not include the
identifier because they feel the issue is with JAWS not informing the
user that it has reached the end of the row. Something which would make
it implicit as to which row/item the link refers to. I assume there is
probably a configuration option to make JAWS identify the start and end
of table rows?
Any thoughts?
thanks!
SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
* Before printing, please think about the environment.
From: Jared Smith
Date: Tue, Jan 05 2010 8:30AM
Subject: Re: Links in tables and title attributes
← Previous message | Next message →
On Tue, Jan 5, 2010 at 3:37 AM, James Kennard wrote:
> Therefore I think that the titles for the
> links should include the indentifier, for example: "Remove 123", "Edit
> 123".
The title attribute on links is rarely, if ever, read. It is not the
default setting for links, nor an option that is commonly enabled. So,
this approach wouldn't solve the problem any way.
> A colleague of mine however thinks that the title should not include the
> identifier because they feel the issue is with JAWS not informing the
> user that it has reached the end of the row.
It's not the developer's responsibility to present semantics that the
screen reader can and should be able to present itself. We don't
present to the user, "Hey, this is a heading!" or "This is the start
of a list." JAWS will identify the end of the row, but only when the
user is navigating by table cells. When the screen reader is simply
reading through the page, it is logical and appropriate that it not
present this information. The behavior you're encountering is correct
and expected.
> I assume there is
> probably a configuration option to make JAWS identify the start and end
> of table rows?
Yes, but only when navigating the data table by cells (assuming your
table headers are properly marked up and associated).
But back to the link issue. This poses a unique problem. The links
don't make sense by themselves, but only make sense when presented in
the context of the row headers. This would pass WCAG 2.0 success
criteria 1.4.4 (Level A), but would fail 1.4.9 (Level AAA - it should
be AA, but I digress) which requires that links make sense all by
themselves. Relying on the row headers may cause additional effort by
the screen reader user to determine what item the links will affect.
Of course the most clear solution is to expand the link text to
present the identifier, but this might be confusing or extraneous for
sighted users. So, I'd recommend expanding the link text, but visually
hiding the additional text in a way that a screen reader will still
read it (http://webaim.org/techniques/css/invisiblecontent/). Oh, and
still use the title attribute to provide the additional advisory
information for sighted users who might happen to hover their mouse
over the link. Just know that you can't rely on it for accessibility.
Jared Smith
WebAIM.org
From: Waltenberger, Lon (LNI)
Date: Tue, Jan 05 2010 1:36PM
Subject: Re: Links in tables and title attributes
← Previous message | No next message
We've found that placing a period at the end of each table row and each
bulleted item provides a natural break to screen readers. This natural
pause keeps the AT from droning on until it "runs out of breath."
It irritates some readers who were taught to not place periods after
anything but a complete sentence. Accessibility overrides the value of
tradition. Languages adapt to usage and need.
I remember something about periods being recommended after bulleted
items I think in a Plain Talk course. I can't find the documentation
right now.
Periods can be styled to not display but support is inconsistent among
screen readers.
I agree that title attributes are rarely read. I also consider them a
poor source of additional information for any Web site reader. There're
more obvious and useful ways to present information.