E-mail List Archives
Thread: empty cells in data tables
Number of posts in this thread: 4 (In chronological order)
From: Trafford, Logan
Date: Thu, Feb 14 2013 1:42PM
Subject: empty cells in data tables
No previous message | Next message →
What is the generally accepted best practice for dealing with large blocks of empty data cells in tables (i.e. if there is actually no data for that appropriate cell, based on properly labelled header etc.)
For example, suppose you have a report with 5 columns and 50 rows (each row represents a different building location for example). Now under one column, perhaps only 5 of the 50 buildings have a value associated with that category, while the other 45 do not.
Should the cell(s) be left blank, or should some kind of value be put in (like nil, n/a etc.)?
Logan Trafford
This e-mail originates from the City of Ottawa e-mail system. Any
distribution, use or copying of this e-mail or the information it
contains by other than the intended recipient(s) is unauthorized.
If you are not the intended recipient, please notify me at the
telephone number shown above or by return e-mail and delete
this communication and any copy immediately. Thank you.
Le présent courriel a été expédié par le système de courriels de
la Ville d'Ottawa. Toute distribution, utilisation ou
reproduction du courriel ou des renseignements qui s'y trouvent
par une personne autre que son destinataire prévu est interdite.
Si vous avez reçu le message par erreur, veuillez m'en aviser par
téléphone (au numéro précité) ou par courriel, puis supprimer
sans délai la version originale de la communication ainsi que
toutes ses copies. Je vous remercie de votre collaboration.
From: Jukka K. Korpela
Date: Thu, Feb 14 2013 2:24PM
Subject: Re: empty cells in data tables
← Previous message | Next message →
2013-02-14 22:42, Trafford, Logan wrote:
> What is the generally accepted best practice for dealing with large
> blocks of empty data cells in tables
Years ago, I wrote a treatise on empty cells, primarily to address some
styling problems:
http://www.cs.tut.fi/~jkorpela/html/emptycells.html
It's a bit dusty, but I think the basic reasoning is still relevant: we
should try to avoid leaving cells empty in data tables. It is not just a
matter of nonvisual access, which may or may not have trouble with empty
cells. In general, when a table cell is presented as empty, visually or
otherwise, the question arises what the emptiness means. It can mean a
wide variety of things, from simple oversight or data error to absence
of data due to security restrictions, logical impossibility, lack of
anything to report, or just lack of data.
Depending on the nature of the data and the table, as well as the human
language, different notations can be used, and may need to be explained.
A fairly common convention is that an en dash indicates absence of data
without disclosing a reason; but in some conventions, it indicates an
exact value of zero.
> For example, suppose you have a report with 5 columns and 50 rows
> (each row represents a different building location for example). Now
> under one column, perhaps only 5 of the 50 buildings have a value
> associated with that category, while the other 45 do not.
In this case, en dashes might be suitable, possibly along with CSS
settings that set e.g. the background of those cells to gray.
> Should the cell(s) be left blank, or should some kind of value be put
> in (like nil, n/a etc.)?
The dummy values, or metadata, to be used depends on the context. This
often tricky, since the notations should be compact. The notation n/a or
N/A is now used even when the language is not English, but this might
not be suitable in documents for a general audience. Moreover, "n/a" is
very ambiguous. "Not applicable" and "not available" can be very
different things.
Yucca
From: Lucy Greco
Date: Thu, Feb 14 2013 2:29PM
Subject: Re: empty cells in data tables
← Previous message | Next message →
Well said
Lucia Greco
Web Access Analyst
IST-Campus Technology Services
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jukka K.
Korpela
Sent: Thursday, February 14, 2013 1:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] empty cells in data tables
2013-02-14 22:42, Trafford, Logan wrote:
> What is the generally accepted best practice for dealing with large
> blocks of empty data cells in tables
Years ago, I wrote a treatise on empty cells, primarily to address some
styling problems:
http://www.cs.tut.fi/~jkorpela/html/emptycells.html
It's a bit dusty, but I think the basic reasoning is still relevant: we
should try to avoid leaving cells empty in data tables. It is not just a
matter of nonvisual access, which may or may not have trouble with empty
cells. In general, when a table cell is presented as empty, visually or
otherwise, the question arises what the emptiness means. It can mean a
wide variety of things, from simple oversight or data error to absence of
data due to security restrictions, logical impossibility, lack of anything
to report, or just lack of data.
Depending on the nature of the data and the table, as well as the human
language, different notations can be used, and may need to be explained.
A fairly common convention is that an en dash indicates absence of data
without disclosing a reason; but in some conventions, it indicates an
exact value of zero.
> For example, suppose you have a report with 5 columns and 50 rows
> (each row represents a different building location for example). Now
> under one column, perhaps only 5 of the 50 buildings have a value
> associated with that category, while the other 45 do not.
In this case, en dashes might be suitable, possibly along with CSS
settings that set e.g. the background of those cells to gray.
> Should the cell(s) be left blank, or should some kind of value be put
> in (like "nil", "n/a" etc.)?
The dummy values, or metadata, to be used depends on the context. This
often tricky, since the notations should be compact. The notation n/a or
N/A is now used even when the language is not English, but this might not
be suitable in documents for a general audience. Moreover, "n/a" is very
ambiguous. "Not applicable" and "not available" can be very different
things.
Yucca
messages to = EMAIL ADDRESS REMOVED =
From: Trafford, Logan
Date: Fri, Feb 15 2013 6:44AM
Subject: Re: empty cells in data tables
← Previous message | No next message
Thanks for this response and the link to your article. I'm trying to formulate policy for the large (gov't) organization I work for and it's essentially excel documents that report statistics where the issues lie. Your section on "Conventional notations in statistics" confirmed the direction I was heading in.
Thanks again.
Logan
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jukka K. Korpela
Sent: February 14, 2013 4:25 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] empty cells in data tables
2013-02-14 22:42, Trafford, Logan wrote:
> What is the generally accepted best practice for dealing with large
> blocks of empty data cells in tables
Years ago, I wrote a treatise on empty cells, primarily to address some styling problems:
http://www.cs.tut.fi/~jkorpela/html/emptycells.html
It's a bit dusty, but I think the basic reasoning is still relevant: we should try to avoid leaving cells empty in data tables. It is not just a matter of nonvisual access, which may or may not have trouble with empty cells. In general, when a table cell is presented as empty, visually or otherwise, the question arises what the emptiness means. It can mean a wide variety of things, from simple oversight or data error to absence of data due to security restrictions, logical impossibility, lack of anything to report, or just lack of data.
Depending on the nature of the data and the table, as well as the human language, different notations can be used, and may need to be explained.
A fairly common convention is that an en dash indicates absence of data without disclosing a reason; but in some conventions, it indicates an exact value of zero.
> For example, suppose you have a report with 5 columns and 50 rows
> (each row represents a different building location for example). Now
> under one column, perhaps only 5 of the 50 buildings have a value
> associated with that category, while the other 45 do not.
In this case, en dashes might be suitable, possibly along with CSS settings that set e.g. the background of those cells to gray.
> Should the cell(s) be left blank, or should some kind of value be put
> in (like nil, n/a etc.)?
The dummy values, or metadata, to be used depends on the context. This often tricky, since the notations should be compact. The notation n/a or N/A is now used even when the language is not English, but this might not be suitable in documents for a general audience. Moreover, "n/a" is very ambiguous. "Not applicable" and "not available" can be very different things.
Yucca
This e-mail originates from the City of Ottawa e-mail system. Any
distribution, use or copying of this e-mail or the information it
contains by other than the intended recipient(s) is unauthorized.
If you are not the intended recipient, please notify me at the
telephone number shown above or by return e-mail and delete
this communication and any copy immediately. Thank you.
Le présent courriel a été expédié par le système de courriels de
la Ville d'Ottawa. Toute distribution, utilisation ou
reproduction du courriel ou des renseignements qui s'y trouvent
par une personne autre que son destinataire prévu est interdite.
Si vous avez reçu le message par erreur, veuillez m'en aviser par
téléphone (au numéro précité) ou par courriel, puis supprimer
sans délai la version originale de la communication ainsi que
toutes ses copies. Je vous remercie de votre collaboration.