[Athen] Keyboard focus and layout tables

Karlen Communications info at karlencommunications.com
Mon Sep 23 05:54:33 PDT 2019


You can use columns, section breaks and column breaks to get the same effect
and a logical reading order.



I have an example that I use for my Tables and Columns tutorial that I've
attached. The sample is also an attachment to the PDF.



Cheers, Karen



From: athen-list <athen-list-bounces at mailman12.u.washington.edu> On Behalf
Of Joseph Sherman
Sent: Friday, September 20, 2019 4:17 PM
To: 'Access Technology Higher Education Network'
<athen-list at u.washington.edu>
Subject: Re: [Athen] Keyboard focus and layout tables



In lieu of a table, what is the best way to format instructions where it has
two columns of text and the text is meant to be read across and then down?
Something like:






Step One

Do This stuff

here


Step Two

Do This stuff

Here

and this too


Step Three

and Four

Do This stuff

here



Columns do not really work since it is meant to read across and then down.
Perhaps you could use column breaks and section breaks for each step? That
seems like a lot of code, and I am not sure it would work.





Joseph



From: athen-list <athen-list-bounces at mailman12.u.washington.edu
<mailto: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 <mailto: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
document.



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
difference.


<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.karlencommunicatio
ns.com_adobe_TablesAndColumnsOptimizeWordDocuments.pdf&d=DwMFAg&c=mRWFL96tuq
j9V0Jjj4h40ddo0XsmttALwKjAEOCyUjY&r=NS7sMOEYVINwm3e4REboGQG-NnI841o0NWYqtIwW
J4U&m=3qyGbABG_uktBcGwge7IWwObGyfBS-rT1mtBZJzxypw&s=c9gD9QJhU1i7OTYvhorRXOjb
AC_pim7vL2KQnRFhN3I&e=>
https://www.karlencommunications.com/adobe/TablesAndColumnsOptimizeWordDocum
ents.pdf



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



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
Pham
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,



Khoa





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190923/11994bc2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ColumnsInWordDocuments.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 14457 bytes
Desc: not available
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190923/11994bc2/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TablesAndColumnsOptimizeWordDocuments2019.pdf
Type: application/pdf
Size: 999897 bytes
Desc: not available
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20190923/11994bc2/attachment-0001.pdf>


More information about the athen-list mailing list