WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: using ABBR for headers in tables

for

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

From: Brid Deely
Date: Wed, Aug 27 2008 4:40AM
Subject: using ABBR for headers in tables
No previous message | Next message →

Hi there,

I would just like to ask for feedback on using the abbr tag in table
headers.

This relates to WCAG 1.0, Guideline 5.6, priority 3.

If anyone has advice on whether users of assistive technologies find it
useful etc., either from personal experience or from the results of user
testing, I would be interested in hearing from you.

Also do you have any recommendations about how it should be used, e.g. only
for longer headers?

Many thanks,
Bríd


From: Jukka K. Korpela
Date: Wed, Aug 27 2008 5:00AM
Subject: Re: using ABBR for headers in tables
← Previous message | Next message →

Brid Deely wrote:

> I would just like to ask for feedback on using the abbr tag in table
> headers.

Just don't use the abbr tag. It helps, at most, a very small fraction of
users. It may hurt many, and most importantly it makes you think you have
explained an abbreviation when you haven't.

> Also do you have any recommendations about how it should be used,
> e.g. only for longer headers?

Huh? Do you actually mean the abbr _attribute_, not the abbr _tag_? There's
a big difference.

Here you have an abbr tag:

<abbr title="Useless Initialism">UI</abbr>

which could be used inside a table header or elsewhere. Just don't.

Here you have an abbr attribute:

<th abbr="predicted">Predicted outcome in 2009"></th>

I think the idea is pretty simple, and useful (though not as useful as it
could with wider support):

1) Use it whenever the table header would be too long when pronounced while
reading a large number of cells, speaking first the row and column header
and then the cell content.

2) The abbr value should be short and understandable in the context of the
table, assuming that the user has access to the full header texts (and an
eventual caption for the table).

3) The name of the attribute is really a misnomer. The value need not be an
abbreviation of the content, i.e. something you get by omitting something
from it; it can be just any short expression that serves the purpose of
identifying a column or a row in the context of a table. Typically, however,
it's a word or a few words (not abbreviations!) extracted from the full
content of the cell.

Yucca

From: Brid Deely
Date: Wed, Aug 27 2008 5:20AM
Subject: Re: using abbr for headers in tables
← Previous message | No next message

Hi,

Yes, I meant the abbr attribute on the header element (as in the subject
line).

I realised that I had incorrectly used the term "tag" in the email after
hitting the send button and hoped that readers would be forgiving of the
transgression.

Thanks for your insightful comments.

I had looked into the usage but found it curious that many references on
creating accessible tables leave this item out.

Any further insights relating to usefulness/use by end-users would be of
interest.

thanks again,

Bríd


-----Original Message-----
From: Jukka K. Korpela [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: 27 August 2008 11:57
To: WebAIM Discussion List
Subject: Re: [WebAIM] using ABBR for headers in tables


Brid Deely wrote:

> I would just like to ask for feedback on using the abbr tag in table
> headers.

Just don't use the abbr tag. It helps, at most, a very small fraction of
users. It may hurt many, and most importantly it makes you think you have
explained an abbreviation when you haven't.

> Also do you have any recommendations about how it should be used,
> e.g. only for longer headers?

Huh? Do you actually mean the abbr _attribute_, not the abbr _tag_? There's
a big difference.

Here you have an abbr tag:

<abbr title="Useless Initialism">UI</abbr>

which could be used inside a table header or elsewhere. Just don't.

Here you have an abbr attribute:

<th abbr="predicted">Predicted outcome in 2009"></th>

I think the idea is pretty simple, and useful (though not as useful as it
could with wider support):

1) Use it whenever the table header would be too long when pronounced while
reading a large number of cells, speaking first the row and column header
and then the cell content.

2) The abbr value should be short and understandable in the context of the
table, assuming that the user has access to the full header texts (and an
eventual caption for the table).

3) The name of the attribute is really a misnomer. The value need not be an
abbreviation of the content, i.e. something you get by omitting something
from it; it can be just any short expression that serves the purpose of
identifying a column or a row in the context of a table. Typically, however,

it's a word or a few words (not abbreviations!) extracted from the full
content of the cell.

Yucca