[Athen] Keyboard focus and layout tables

Larry L. Lewis, Jr. llewis at paciellogroup.com
Wed Sep 18 06:15:56 PDT 2019

As another screenreader user echoing Karen's sentiment, please don't use
tables for layout-only data, please?


Larry L. Lewis, Jr.

Director of Government Sales and Strategic Partnerships

<https://www.paciellogroup.com/> The Paciello Group

<https://vispero.com/> A Vispero Company

17757 US Highway 19 N, Suite 560

Clearwater, FL 33764

Phone: +1(727) 803-8000, EXT 1909

<mailto:llewis at paciellogroup.com> E-Mail

From: athen-list <athen-list-bounces at mailman12.u.washington.edu> On Behalf
Of Karlen Communications
Sent: Wednesday, September 18, 2019 8:51 AM
To: 'Access Technology Higher Education Network'
<athen-list at u.washington.edu>
Subject: Re: [Athen] Keyboard focus and layout tables

Tables should NEVER be used for design layout.

The first problem is that those of us who use screen readers have different
keyboard commands for the text layer of the document and for tables. When
our adaptive technology comes across a table, it thinks it is going to read
data. If there are parts of the document that are normally in the text layer
of the document, the screen readers often get confused. As someone who uses
a screen reader, if there is a list and a paragraph in a single table cell,
I can read all of the cell contents or none of the cell contents by default.
If I then try to use my text layer keyboard commands to go paragraph by
paragraph or list item by list item, often the first line in the cell is
repeated, lines and list items are skipped over, my screen reader will go
silent in protest and I am unable to read in a natural flow of content or in
any meaningful manner, the content in that cell. Also, if the contents of
one cell do not fit on one page, the content should not be in a table.

Even people without disabilities find that tables for design layout lack one
specific element.design.

Often people are taught that the only way to "design" a document is to
immediately put it in a table. WRONG! We need to use the tools we have in
the authoring tools to create more accessible documents.

The other problem with using tables for design layout is that Headings in
documents are navigational points. If we "navigate" to a table cell, we have
to then figure out where the actual associated content begins. For example,
if there is a Heading in cell B1, does the content begin in cell C2 or B3?
What is the logical reading order of the content? Is that logical reading
order consistent throughout the "table/document"?

Another problem with using tables for design layout happens when you have a
table in the document. Do you then split, merge, delete columns to
accommodate the data table or do you nest the table. Either method is
confusing to someone using a screen reader or Text-to-Speech tool.
Additionally, if the table is nested, the screen reader or Text-to-Speech
tool can only deal with one table at a time. It can't stand back and say
"OK, this table still needs to use some of the column and row titles from
the larger table so that's what I'll do." The adaptive technology can only
look at, deal with one table at a time so if there is any relationship
between the nested table and the larger table, it is lost which again affect
the ability to understand what we are reading and where we are in the

I do have a tutorial with an example of a 68 page document that I had to
remediate so anyone can try to read it with a screen reader or
Text-to-Speech tool. As part of that Tables and Columns tutorial document, I
also have the same document laid out without tables so that you can see the


It is an accessible PDF with the sample documents attached/under the

Tables for design layout.just say NO!

Cheers, Karen

From: athen-list <athen-list-bounces at mailman12.u.washington.edu
<mailto:athen-list-bounces at mailman12.u.washington.edu> > On Behalf Of Khoa
Sent: Tuesday, September 17, 2019 6:22 PM
To: Access Technology Higher Education Network <athen-list at u.washington.edu
<mailto:athen-list at u.washington.edu> >
Subject: [Athen] Keyboard focus and layout tables

Hello everyone,

My apologies if these questions have already been asked.

1. What are the standard or criteria for an acceptable visible keyboard
focus indication?
2. Should tables be used to for page content layout such as in Canvas,
word documents, and PDFs regardless of the number of table cells used?

I've found that some keyboard focus indications are clear and very easy to
see when navigating with the keyboard, while other makes me wonder if they
are sufficient enough to be considered accessible. Please see the attached
images for examples.

For table layouts, I've seen a few being used with a minimum of two cells to
provide an image of an instructor adjacent to the cell that contains their
information. Would this be acceptable?

Thanks in advance,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190918/ab0c78c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 14150 bytes
Desc: not available
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190918/ab0c78c1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 4630 bytes
Desc: not available
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190918/ab0c78c1/attachment.jpg>

More information about the athen-list mailing list