E-mail List Archives
Thread: Tables and Excel: merged or unmerged cells?
Number of posts in this thread: 10 (In chronological order)
From: Bevi Chagnon
Date: Sat, Apr 14 2012 7:26PM
Subject: Tables and Excel: merged or unmerged cells?
No previous message | Next message →
I have a question for our list members who use assistive technologies.
Do you want cells in a Word table or Excel spreadsheet merged or unmerged?
I'm asking because I've received conflicting information from government
clients. A few years ago I worked directly with an accessibility tester at
the National Federation of the Blind to test Excel spreadsheets for a
federal government agency. The tester wanted merged cells that spanned
appropriate columns or rows.
But many U.S. government agencies have guidelines requiring cells to be
unmerged in Word tables and Excel spreadsheets.
Here's a quick sample (also in the Word and Excel attachments). The header
"Apples" spans 2 columns, Macintosh and Red Delicious. "Pears" spans 2
columns, Bosc and Bartlett. (Please note that TD tags will be applied in the
actual Word documents).
Sales of produce for 2011 and 2012 by variety
Apples
Pears
Macintosh
Red Delicious
Bosc
Bartlett
2011
2000
2500
3000
3500
2012
1000
1500
2000
2500
Some government agencies require this version below, where "Apples" is
repeated above each column, making the table ridiculously complex for
sighted users.
Sales of produce for 2011 and 2012 by variety
Apples
Apples
Pears
Pears
Macintosh
Red Delicious
Bosc
Bartlett
2011
2000
2500
3000
3500
2012
1000
1500
2000
2500
WCAG 2.0 has notes about the scope attribute, but that is for HTML webpages
only and is not available (at this time) for Word, Excel, PowerPoint, and
other non-web documents.
Thanks for any guidance you can give.
-- Bevi
--
Bevi Chagnon | = EMAIL ADDRESS REMOVED =
PubCom - Trainers, consultants, designers, and developers
Print, Web, Acrobat, XML, eBooks, and Federal Section 508
--
* It's our 31st Year! *
From: Birkir R. Gunnarsson
Date: Sat, Apr 14 2012 7:56PM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
When you can avoid merging, please always do so (from a screen reader
user who made a living as a risk analyst working in Excel for 3
years).
I think having a heading for a merged column cells is ok, but screen
reader (at least Jaws, who generally works best with Excel), easily
get confused and unwieldy with merged columns.
Definitely *never* put numerical information in merged cells, just please no.
Heading in merged cells are ok, though you should always supply the
download link for these documents with a link or article on how to
unmerge cells with various screen readers.
I personally don't see why you need to repeat a heading above each
column, if there is a:
fruit cars
apples pairs toyotas
..
it's usually very obvious which column belongs to each super-heading.
To summarize:
unmerged is better, numerical information provided in a merged field
is nearly impossible to work with as a screen reader user.
Provide quick hints on how to unmerge cells in Excel in screen readers
(I can dig this up and send to list if wanted), with the download link
to spreadsheets, or provide a link to the page that explains it.
Thanks
-B
On 4/15/12, Bevi Chagnon < = EMAIL ADDRESS REMOVED = > wrote:
> I have a question for our list members who use assistive technologies.
>
> Do you want cells in a Word table or Excel spreadsheet merged or unmerged?
>
> I'm asking because I've received conflicting information from government
> clients. A few years ago I worked directly with an accessibility tester at
> the National Federation of the Blind to test Excel spreadsheets for a
> federal government agency. The tester wanted merged cells that spanned
> appropriate columns or rows.
>
> But many U.S. government agencies have guidelines requiring cells to be
> unmerged in Word tables and Excel spreadsheets.
>
> Here's a quick sample (also in the Word and Excel attachments). The header
> "Apples" spans 2 columns, Macintosh and Red Delicious. "Pears" spans 2
> columns, Bosc and Bartlett. (Please note that TD tags will be applied in the
> actual Word documents).
>
>
> Sales of produce for 2011 and 2012 by variety
>
>
>
>
> Apples
>
> Pears
>
>
>
>
> Macintosh
>
> Red Delicious
>
> Bosc
>
> Bartlett
>
>
> 2011
>
> 2000
>
> 2500
>
> 3000
>
> 3500
>
>
> 2012
>
> 1000
>
> 1500
>
> 2000
>
> 2500
>
> Some government agencies require this version below, where "Apples" is
> repeated above each column, making the table ridiculously complex for
> sighted users.
>
>
> Sales of produce for 2011 and 2012 by variety
>
>
>
>
> Apples
>
> Apples
>
> Pears
>
> Pears
>
>
>
>
> Macintosh
>
> Red Delicious
>
> Bosc
>
> Bartlett
>
>
> 2011
>
> 2000
>
> 2500
>
> 3000
>
> 3500
>
>
> 2012
>
> 1000
>
> 1500
>
> 2000
>
> 2500
>
> WCAG 2.0 has notes about the scope attribute, but that is for HTML webpages
> only and is not available (at this time) for Word, Excel, PowerPoint, and
> other non-web documents.
>
> Thanks for any guidance you can give.
>
> -- Bevi
>
> --
>
> Bevi Chagnon | = EMAIL ADDRESS REMOVED =
>
> PubCom - Trainers, consultants, designers, and developers
>
> Print, Web, Acrobat, XML, eBooks, and Federal Section 508
>
> --
>
> * It's our 31st Year! *
>
>
>
>
From: Bevi Chagnon
Date: Sat, Apr 14 2012 8:13PM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Since neither the email nor the attachments came through with the test
tables, I've uploaded them to:
http://www.pubcom.com/508tests/
--Bevi
-----------------------------------------------------
Bevi Chagnon | = EMAIL ADDRESS REMOVED =
PubCom - Trainers, consultants, designers, and developers
Print | Web | Acrobat | XML | eBooks | Section 508
-----------------------------------------------------
Classes: www.PubCom.com/classes
Publishing Blog: www.pubcom.com/blog
-----------------------------------------------------
*** It's our 31st Year! ***
From: Duff Johnson
Date: Mon, Apr 16 2012 7:41AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Birkir,
Thank you for the fascinating explanation.
I can certainly believe that simpler tables (no merged cells, fewest possible heading levels, etc) are easier to read under any circumstances, AT included. I have a few questions.
- What's the problem (specifically) with numerical values in merged cells?
- Why does JAWS "get confused" when processing a table? Assuming the right attributes are in place, it's a programmatically determinable structure after all, regardless of the heading levels, merged cells (TH and/or TD) and so on.
- Assuming JAWS (and others) do get confused, why isn't this simply a bug in the software to be fixed rather than a "fact of life" with implications for document authors (as opposed to AT software developers)?
Duff.
On Apr 14, 2012, at 9:56 PM, Birkir R. Gunnarsson wrote:
> When you can avoid merging, please always do so (from a screen reader
> user who made a living as a risk analyst working in Excel for 3
> years).
> I think having a heading for a merged column cells is ok, but screen
> reader (at least Jaws, who generally works best with Excel), easily
> get confused and unwieldy with merged columns.
> Definitely *never* put numerical information in merged cells, just please no.
> Heading in merged cells are ok, though you should always supply the
> download link for these documents with a link or article on how to
> unmerge cells with various screen readers.
> I personally don't see why you need to repeat a heading above each
> column, if there is a:
>
> fruit cars
> apples pairs toyotas
> ..
> it's usually very obvious which column belongs to each super-heading.
> To summarize:
> unmerged is better, numerical information provided in a merged field
> is nearly impossible to work with as a screen reader user.
> Provide quick hints on how to unmerge cells in Excel in screen readers
> (I can dig this up and send to list if wanted), with the download link
> to spreadsheets, or provide a link to the page that explains it.
> Thanks
> -B
>
> On 4/15/12, Bevi Chagnon < = EMAIL ADDRESS REMOVED = > wrote:
>> I have a question for our list members who use assistive technologies.
>>
>> Do you want cells in a Word table or Excel spreadsheet merged or unmerged?
>>
>> I'm asking because I've received conflicting information from government
>> clients. A few years ago I worked directly with an accessibility tester at
>> the National Federation of the Blind to test Excel spreadsheets for a
>> federal government agency. The tester wanted merged cells that spanned
>> appropriate columns or rows.
>>
>> But many U.S. government agencies have guidelines requiring cells to be
>> unmerged in Word tables and Excel spreadsheets.
>>
>> Here's a quick sample (also in the Word and Excel attachments). The header
>> "Apples" spans 2 columns, Macintosh and Red Delicious. "Pears" spans 2
>> columns, Bosc and Bartlett. (Please note that TD tags will be applied in the
>> actual Word documents).
>>
>>
>> Sales of produce for 2011 and 2012 by variety
>>
>>
>>
>>
>> Apples
>>
>> Pears
>>
>>
>>
>>
>> Macintosh
>>
>> Red Delicious
>>
>> Bosc
>>
>> Bartlett
>>
>>
>> 2011
>>
>> 2000
>>
>> 2500
>>
>> 3000
>>
>> 3500
>>
>>
>> 2012
>>
>> 1000
>>
>> 1500
>>
>> 2000
>>
>> 2500
>>
>> Some government agencies require this version below, where "Apples" is
>> repeated above each column, making the table ridiculously complex for
>> sighted users.
>>
>>
>> Sales of produce for 2011 and 2012 by variety
>>
>>
>>
>>
>> Apples
>>
>> Apples
>>
>> Pears
>>
>> Pears
>>
>>
>>
>>
>> Macintosh
>>
>> Red Delicious
>>
>> Bosc
>>
>> Bartlett
>>
>>
>> 2011
>>
>> 2000
>>
>> 2500
>>
>> 3000
>>
>> 3500
>>
>>
>> 2012
>>
>> 1000
>>
>> 1500
>>
>> 2000
>>
>> 2500
>>
>> WCAG 2.0 has notes about the scope attribute, but that is for HTML webpages
>> only and is not available (at this time) for Word, Excel, PowerPoint, and
>> other non-web documents.
>>
>> Thanks for any guidance you can give.
>>
>> -- Bevi
>>
>> --
>>
>> Bevi Chagnon | = EMAIL ADDRESS REMOVED =
>>
>> PubCom - Trainers, consultants, designers, and developers
>>
>> Print, Web, Acrobat, XML, eBooks, and Federal Section 508
>>
>> --
>>
>> * It's our 31st Year! *
>>
>>
>>
>>
> > >
From: Birkir R. Gunnarsson
Date: Mon, Apr 16 2012 7:59AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Hi Duff et al
I'll try to find and give a specific example with a document later.
The short answer is that I have had major issues with documents where
there is a large set of merged columns with information.
Let us say there is a set of merged column a through l.
May be this is done to isolate a specific area of information, such as
departmental revenues.
Jaws usually treats all of this area as one cell, and will not allow
me to jump into specific columns within it unless I instruct it to go
to a particular cell (say k3).
Jaws will read all the departmental info sitting in a row in this area
as values of a single cell, and will not allow me to use arrow keys to
browser through each column within the merged area either.
I have seen this in multiple forms I have worked with (though it has
been a few months, and I don't have a form handy right at this very
moment).
Whether the problem stems from the fact that the author actually
tagged the merged area incorrectly .. may be the merging should only
have applied to the first row or the header itself, not to the
information below, or whether this is a Jaws bug I can't say for sure.
The more general question of who is responsible for accessibility,
document and web page authors who follow standards, or Assistive
Technology vendors, is an age old one and subject to much broader
discussion.
I agree with you that you cannot and shold not expect mainstream
document authors to have to anticipate problems with specific screen
reading technology, and that the A.T. vendors need to do a much better
job with their software.
I will try and find a particular document and describe precisely what
happens with its use and Jaws later today or early tomorrow.
Thanks
-Birkir
On 4/16/12, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir,
>
> Thank you for the fascinating explanation.
>
> I can certainly believe that simpler tables (no merged cells, fewest
> possible heading levels, etc) are easier to read under any circumstances, AT
> included. I have a few questions.
>
> - What's the problem (specifically) with numerical values in merged cells?
>
> - Why does JAWS "get confused" when processing a table? Assuming the right
> attributes are in place, it's a programmatically determinable structure
> after all, regardless of the heading levels, merged cells (TH and/or TD) and
> so on.
>
> - Assuming JAWS (and others) do get confused, why isn't this simply a bug in
> the software to be fixed rather than a "fact of life" with implications for
> document authors (as opposed to AT software developers)?
>
> Duff.
>
>
>
>
> On Apr 14, 2012, at 9:56 PM, Birkir R. Gunnarsson wrote:
>
>> When you can avoid merging, please always do so (from a screen reader
>> user who made a living as a risk analyst working in Excel for 3
>> years).
>> I think having a heading for a merged column cells is ok, but screen
>> reader (at least Jaws, who generally works best with Excel), easily
>> get confused and unwieldy with merged columns.
>> Definitely *never* put numerical information in merged cells, just please
>> no.
>> Heading in merged cells are ok, though you should always supply the
>> download link for these documents with a link or article on how to
>> unmerge cells with various screen readers.
>> I personally don't see why you need to repeat a heading above each
>> column, if there is a:
>>
>> fruit cars
>> apples pairs toyotas
>> ..
>> it's usually very obvious which column belongs to each super-heading.
>> To summarize:
>> unmerged is better, numerical information provided in a merged field
>> is nearly impossible to work with as a screen reader user.
>> Provide quick hints on how to unmerge cells in Excel in screen readers
>> (I can dig this up and send to list if wanted), with the download link
>> to spreadsheets, or provide a link to the page that explains it.
>> Thanks
>> -B
>>
>> On 4/15/12, Bevi Chagnon < = EMAIL ADDRESS REMOVED = > wrote:
>>> I have a question for our list members who use assistive technologies.
>>>
>>> Do you want cells in a Word table or Excel spreadsheet merged or
>>> unmerged?
>>>
>>> I'm asking because I've received conflicting information from government
>>> clients. A few years ago I worked directly with an accessibility tester
>>> at
>>> the National Federation of the Blind to test Excel spreadsheets for a
>>> federal government agency. The tester wanted merged cells that spanned
>>> appropriate columns or rows.
>>>
>>> But many U.S. government agencies have guidelines requiring cells to be
>>> unmerged in Word tables and Excel spreadsheets.
>>>
>>> Here's a quick sample (also in the Word and Excel attachments). The
>>> header
>>> "Apples" spans 2 columns, Macintosh and Red Delicious. "Pears" spans 2
>>> columns, Bosc and Bartlett. (Please note that TD tags will be applied in
>>> the
>>> actual Word documents).
>>>
>>>
>>> Sales of produce for 2011 and 2012 by variety
>>>
>>>
>>>
>>>
>>> Apples
>>>
>>> Pears
>>>
>>>
>>>
>>>
>>> Macintosh
>>>
>>> Red Delicious
>>>
>>> Bosc
>>>
>>> Bartlett
>>>
>>>
>>> 2011
>>>
>>> 2000
>>>
>>> 2500
>>>
>>> 3000
>>>
>>> 3500
>>>
>>>
>>> 2012
>>>
>>> 1000
>>>
>>> 1500
>>>
>>> 2000
>>>
>>> 2500
>>>
>>> Some government agencies require this version below, where "Apples" is
>>> repeated above each column, making the table ridiculously complex for
>>> sighted users.
>>>
>>>
>>> Sales of produce for 2011 and 2012 by variety
>>>
>>>
>>>
>>>
>>> Apples
>>>
>>> Apples
>>>
>>> Pears
>>>
>>> Pears
>>>
>>>
>>>
>>>
>>> Macintosh
>>>
>>> Red Delicious
>>>
>>> Bosc
>>>
>>> Bartlett
>>>
>>>
>>> 2011
>>>
>>> 2000
>>>
>>> 2500
>>>
>>> 3000
>>>
>>> 3500
>>>
>>>
>>> 2012
>>>
>>> 1000
>>>
>>> 1500
>>>
>>> 2000
>>>
>>> 2500
>>>
>>> WCAG 2.0 has notes about the scope attribute, but that is for HTML
>>> webpages
>>> only and is not available (at this time) for Word, Excel, PowerPoint, and
>>> other non-web documents.
>>>
>>> Thanks for any guidance you can give.
>>>
>>> -- Bevi
>>>
>>> --
>>>
>>> Bevi Chagnon | = EMAIL ADDRESS REMOVED =
>>>
>>> PubCom - Trainers, consultants, designers, and developers
>>>
>>> Print, Web, Acrobat, XML, eBooks, and Federal Section 508
>>>
>>> --
>>>
>>> * It's our 31st Year! *
>>>
>>>
>>>
>>>
>> >> >> >
>
>
>
> > > >
From: Paul J. Adam
Date: Mon, Apr 16 2012 8:55AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Hi Bevi, it's ok to merge the header cells like in your Excel example. The important thing is to not merge the cells in the actual data section of the table. I used to do training on Word & Excel accessibility and I have heard people recommend not to merge any cells at all but it's not a problem unless you merge the data cells which could mess up the users ability to navigate with the up/down/right/left arrow keys.
Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter
On Apr 14, 2012, at 9:13 PM, Bevi Chagnon wrote:
> Since neither the email nor the attachments came through with the test
> tables, I've uploaded them to:
> http://www.pubcom.com/508tests/
>
> --Bevi
>
> -----------------------------------------------------
> Bevi Chagnon | = EMAIL ADDRESS REMOVED =
> PubCom - Trainers, consultants, designers, and developers
> Print | Web | Acrobat | XML | eBooks | Section 508
> -----------------------------------------------------
> Classes: www.PubCom.com/classes
> Publishing Blog: www.pubcom.com/blog
> -----------------------------------------------------
> *** It's our 31st Year! ***
>
>
>
From: Birkir R. Gunnarsson
Date: Mon, Apr 16 2012 9:03AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Paul
Thanks for rewording my email more eficiently :) that is precisely
what I meant to say.
On 4/16/12, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Bevi, it's ok to merge the header cells like in your Excel example. The
> important thing is to not merge the cells in the actual data section of the
> table. I used to do training on Word & Excel accessibility and I have heard
> people recommend not to merge any cells at all but it's not a problem unless
> you merge the data cells which could mess up the users ability to navigate
> with the up/down/right/left arrow keys.
>
> Paul J. Adam
> Accessibility Evangelist
> Deque Systems
> = EMAIL ADDRESS REMOVED =
> www.PaulJAdam.com
> @pauljadam on Twitter
>
> On Apr 14, 2012, at 9:13 PM, Bevi Chagnon wrote:
>
>> Since neither the email nor the attachments came through with the test
>> tables, I've uploaded them to:
>> http://www.pubcom.com/508tests/
>>
>> --Bevi
>>
>> -----------------------------------------------------
>> Bevi Chagnon | = EMAIL ADDRESS REMOVED =
>> PubCom - Trainers, consultants, designers, and developers
>> Print | Web | Acrobat | XML | eBooks | Section 508
>> -----------------------------------------------------
>> Classes: www.PubCom.com/classes
>> Publishing Blog: www.pubcom.com/blog
>> -----------------------------------------------------
>> *** It's our 31st Year! ***
>>
>>
>>
From: Bevi Chagnon
Date: Mon, Apr 16 2012 10:26AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Duff wrote: "Assuming JAWS (and others) do get confused, why isn't this
simply a bug in the software to be fixed rather than a "fact of life" with
implications for document authors (as opposed to AT software developers)?"
Wow, Duff, you just opened a Pandora's box of questions on "why doesn't AT
technology do a better job at [fill-in-the-blank]."
I'm sure the solution involves any of the following:
-- More funding to AT software companies.
-- More funding and training for AT users to actually purchase upgraded
versions of their technology and training.
-- Better tools for accessing common documents, not just web pages, such as
Word, PowerPoint, Excel, and Acrobat PDF.
-- Better coordination between AT software companies and Adobe, Microsoft,
W3.org, Amazon, and other key players in our various publishing
technologies.
-- Expanded accessibility standards that cover more than just garden-variety
text and graphics.
Here are a few questions I have from my clients just this morning:
1) Why doesn't AT correctly read superscripts, subscripts, and several dozen
other common characters? Why does it read 10-3 as 10 to the third power but
10-4 as one hundred four? (sorry, can't do super/subscripts in this ASCII
email.) And why doesn't AT access the thousands of characters (glyphs) in
Unicode fonts? It's been 12 years since the computer industry adopted
Unicode but AT can access only a small portion of a font's glyphs.
2) How can I provide sufficient Alt-text for highly complex graphics, such
as military maps, floor plans, 3-D schematic drawings, and complex
charts/graphs in a Word, PowerPoint, or PDF document? The recommended
Alt-text limit is 160 characters, Long-Desc attribute is only for HTML web
pages and is being deprecated by the W3.org, and writing the detailed
description in the main narrative forces sighted users to read redundant
information that they can quickly see in the graphic.
3) Why doesn't AT correctly read the formulas in Excel spreadsheets?
Spreadsheets have been around since VisiCalc in the early 1980's. They
haven't changed THAT much in 30 years. One would assume that AT
manufacturers would have made better progress in accessing them during the
past 3 decades.
4) Why doesn't AT recognize a link or other actions in Alt-text? That would
help with question #2: I could embed a link in a brief Alt-text to a
detailed description someplace else in the document.
Is it time to start a wish-list for AT manufacturers?
Are there any AT representatives on this list?
--Bevi Chagnon
(Who is waiting to see what questions her clients ask this afternoon <grin>)
--
Bevi Chagnon | = EMAIL ADDRESS REMOVED =
PubCom - Trainers, consultants, designers, and developers
Print, Web, Acrobat, XML, eBooks, and Federal Section 508
--
* It's our 31st Year! *
From: Randy Pope
Date: Mon, Apr 16 2012 10:50AM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | Next message →
Bevi,
Another question to add to your list:
Why the AT software cannot read caption on the video?
There are some attempts in addressing this issue. But still many DeafBlind
people who read in braille are having problem access the caption with their
screen readers.
Randy Pope
From: Duff Johnson
Date: Mon, Apr 16 2012 7:09PM
Subject: Re: Tables and Excel: merged or unmerged cells?
← Previous message | No next message
Bevi,
On Apr 16, 2012, at 12:26 PM, Bevi Chagnon wrote:
> Duff wrote: "Assuming JAWS (and others) do get confused, why isn't this
> simply a bug in the software to be fixed rather than a "fact of life" with
> implications for document authors (as opposed to AT software developers)?"
>
> Wow, Duff, you just opened a Pandora's box of questions on "why doesn't AT
> technology do a better job at [fill-in-the-blank]."
Delighted to be of service. :-)
> I'm sure the solution involves any of the following:
> -- More funding to AT software companies.
> -- More funding and training for AT users to actually purchase upgraded
> versions of their technology and training.
> -- Better tools for accessing common documents, not just web pages, such as
> Word, PowerPoint, Excel, and Acrobat PDF.
> -- Better coordination between AT software companies and Adobe, Microsoft,
> W3.org, Amazon, and other key players in our various publishing
> technologies.
> -- Expanded accessibility standards that cover more than just garden-variety
> text and graphics.
I'm sure it involves all of what you've suggested.
None of this seems to me to complicate the basic question, which is simply that in the case of properly structured content AT has simply *no excuse* for getting it wrong.
I'm not seeking to lay blame here. AT developers have a variety of good and substantial reasons for how they run their businesses. The pressure for new features can readily exceed the pressure for bug fixes. As someone in the software business I have a healthy appreciation of this fact.
The solution, it seems to me, is to arrange things such that both authoring software and AT developers understand that adherence to applicable standards IS a "feature" - indeed, it's the ultimate "feature" because it enables everything else.
Duff.