[Athen] Keyboard focus and layout tables
Joseph.Sherman at cuny.edu
Fri Sep 20 13:17:05 PDT 2019
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:
Do This stuff
Do This stuff
and this too
Do This stuff
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.
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 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.
It is an accessible PDF with the sample documents attached/under the paperclip.
Tables for design layout...just say NO!
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
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...
More information about the athen-list