WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Lengthy Tables, Lists, and Screen Readers

for

Number of posts in this thread: 8 (In chronological order)

From: Alan Zaitchik
Date: Fri, Jul 13 2018 8:03AM
Subject: Lengthy Tables, Lists, and Screen Readers
No previous message | Next message →

I am working on a 150 page document that is mostly a series of long tables, one per state. The 50 tables have row headers but no column headers. Some tables can be fit onto a single page, most cannot. Occasionally a data cell spans a page boundary. This leads to awful problems with screen readers, as my testing shows. Restructuring the tables, essentially breaking them into pieces so that no table spans a page boundary is a lot of work! And it doesn't solve the problem of lengthy data cells that just cannot naturally fit into a page boundary, even with fancy editing.

SO: I'm thinking of getting rid of the table semantics altogether and replacing it with a linearized structure of a List, like so:
<List>
<LI>
<Lbl>text from the table header cell in row 1
<LBody>text from the table data cell in row 1, possibly including nested list structures
<LI>
<Lbl>text from the table header cell in row 2
<LBody>text from the table data cell in row 2, possibly including nested list structures
<LI>
<Lbl>text from the table header cell in row 3
<LBody>text from the table data cell in row 3, possibly including nested list structures
etc.

I think this will be much better for screen reader users, actually. I don't think the table semantics really adds anything given that there are only row headers.

Feedback most welcome!

A

From: glen walker
Date: Fri, Jul 13 2018 8:57AM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

Given the tags of your example, I presume you're creating a PDF document?
Are you creating it directly in acrobat or do you have a word doc (or some
other format) that you're saving as PDF?

Is there also an HTML equivalent? HTML obviously won't have a "page
boundary" problem.

Personally, I prefer navigating through a table rather than a list when
using a screen reader. I like the row/col header announcements before the
cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
walk the grid in any direction I want. (Or go into table mode and use the
plain arrow keys.) With a list, I'm sort of forced to navigate it
sequentially. I can't jump from the 3rd item in one list to the 3rd item
of the next list like I can with a table.

Is your table only 2 columns? The row header and the data cell? That's
the only scenario I can think of that wouldn't have column headers,
although even then I think column headers would be helpful as you navigate
horizontally between the data cell and the row header.

Have you confirmed that the tags for your data cells that span across a
page boundary are marked up properly?

If you happen to be using Word to create your tables and are saving the
document as PDF, just to rule out the obvious, have you turned OFF the
"allow row to break across pages" option?

I'm just trying to toss a few ideas out there that might spark other ideas.

From: Alan Zaitchik
Date: Fri, Jul 13 2018 1:47PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

Thank you, Glen. Unfortunately I have no access to the original Word document for this legacy pdf. It has to be delivered back to the client as a PDF, too.
Another (similar) pdf will be arriving soon together with its source Word doc. I will certainly try to restructure the tables in that case with the "do not span page boundary" setting for data cells. The problem I foresee is that some data cells in these documents contain lists that are just too "long". Shrinking fonts and making extra columns in a cell is likely to prove unacceptable visually to the client. I'll have to give it a try and judge the results.
As for my present document, I have just the PDF. Acrobat is pretty horrible for editing so I may have to go with Lists.
A

> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> Given the tags of your example, I presume you're creating a PDF document?
> Are you creating it directly in acrobat or do you have a word doc (or some
> other format) that you're saving as PDF?
>
> Is there also an HTML equivalent? HTML obviously won't have a "page
> boundary" problem.
>
> Personally, I prefer navigating through a table rather than a list when
> using a screen reader. I like the row/col header announcements before the
> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
> walk the grid in any direction I want. (Or go into table mode and use the
> plain arrow keys.) With a list, I'm sort of forced to navigate it
> sequentially. I can't jump from the 3rd item in one list to the 3rd item
> of the next list like I can with a table.
>
> Is your table only 2 columns? The row header and the data cell? That's
> the only scenario I can think of that wouldn't have column headers,
> although even then I think column headers would be helpful as you navigate
> horizontally between the data cell and the row header.
>
> Have you confirmed that the tags for your data cells that span across a
> page boundary are marked up properly?
>
> If you happen to be using Word to create your tables and are saving the
> document as PDF, just to rule out the obvious, have you turned OFF the
> "allow row to break across pages" option?
>
> I'm just trying to toss a few ideas out there that might spark other ideas.
>

From: Duff Johnson
Date: Fri, Jul 13 2018 1:50PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

Hi Alan,

I'm confused…

The problem is when table-cells span pages, yes?

Are you tagging the tables irrespective of the pages they span? If so I don't see why you should be having a problem.

Duff.

> On Jul 13, 2018, at 15:47, Alan Zaitchik < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thank you, Glen. Unfortunately I have no access to the original Word document for this legacy pdf. It has to be delivered back to the client as a PDF, too.
> Another (similar) pdf will be arriving soon together with its source Word doc. I will certainly try to restructure the tables in that case with the "do not span page boundary" setting for data cells. The problem I foresee is that some data cells in these documents contain lists that are just too "long". Shrinking fonts and making extra columns in a cell is likely to prove unacceptable visually to the client. I'll have to give it a try and judge the results.
> As for my present document, I have just the PDF. Acrobat is pretty horrible for editing so I may have to go with Lists.
> A
>
>> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Given the tags of your example, I presume you're creating a PDF document?
>> Are you creating it directly in acrobat or do you have a word doc (or some
>> other format) that you're saving as PDF?
>>
>> Is there also an HTML equivalent? HTML obviously won't have a "page
>> boundary" problem.
>>
>> Personally, I prefer navigating through a table rather than a list when
>> using a screen reader. I like the row/col header announcements before the
>> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
>> walk the grid in any direction I want. (Or go into table mode and use the
>> plain arrow keys.) With a list, I'm sort of forced to navigate it
>> sequentially. I can't jump from the 3rd item in one list to the 3rd item
>> of the next list like I can with a table.
>>
>> Is your table only 2 columns? The row header and the data cell? That's
>> the only scenario I can think of that wouldn't have column headers,
>> although even then I think column headers would be helpful as you navigate
>> horizontally between the data cell and the row header.
>>
>> Have you confirmed that the tags for your data cells that span across a
>> page boundary are marked up properly?
>>
>> If you happen to be using Word to create your tables and are saving the
>> document as PDF, just to rule out the obvious, have you turned OFF the
>> "allow row to break across pages" option?
>>
>> I'm just trying to toss a few ideas out there that might spark other ideas.
>>
> > > >

From: Ryan E. Benson
Date: Fri, Jul 13 2018 3:51PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

I agree with Duff, the page spans should be ignored and just tag it as one
long table. We would need know what you mean by awful problems.

--
Ryan E. Benson

On Fri, Jul 13, 2018 at 3:50 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Alan,
>
> I'm confused…
>
> The problem is when table-cells span pages, yes?
>
> Are you tagging the tables irrespective of the pages they span? If so I
> don't see why you should be having a problem.
>
> Duff.
>
> > On Jul 13, 2018, at 15:47, Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > Thank you, Glen. Unfortunately I have no access to the original Word
> document for this legacy pdf. It has to be delivered back to the client as
> a PDF, too.
> > Another (similar) pdf will be arriving soon together with its source
> Word doc. I will certainly try to restructure the tables in that case with
> the "do not span page boundary" setting for data cells. The problem I
> foresee is that some data cells in these documents contain lists that are
> just too "long". Shrinking fonts and making extra columns in a cell is
> likely to prove unacceptable visually to the client. I'll have to give it a
> try and judge the results.
> > As for my present document, I have just the PDF. Acrobat is pretty
> horrible for editing so I may have to go with Lists.
> > A
> >
> >> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = >
> wrote:
> >>
> >> Given the tags of your example, I presume you're creating a PDF
> document?
> >> Are you creating it directly in acrobat or do you have a word doc (or
> some
> >> other format) that you're saving as PDF?
> >>
> >> Is there also an HTML equivalent? HTML obviously won't have a "page
> >> boundary" problem.
> >>
> >> Personally, I prefer navigating through a table rather than a list when
> >> using a screen reader. I like the row/col header announcements before
> the
> >> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
> >> walk the grid in any direction I want. (Or go into table mode and use
> the
> >> plain arrow keys.) With a list, I'm sort of forced to navigate it
> >> sequentially. I can't jump from the 3rd item in one list to the 3rd
> item
> >> of the next list like I can with a table.
> >>
> >> Is your table only 2 columns? The row header and the data cell? That's
> >> the only scenario I can think of that wouldn't have column headers,
> >> although even then I think column headers would be helpful as you
> navigate
> >> horizontally between the data cell and the row header.
> >>
> >> Have you confirmed that the tags for your data cells that span across a
> >> page boundary are marked up properly?
> >>
> >> If you happen to be using Word to create your tables and are saving the
> >> document as PDF, just to rule out the obvious, have you turned OFF the
> >> "allow row to break across pages" option?
> >>
> >> I'm just trying to toss a few ideas out there that might spark other
> ideas.
> >>
> > > > > > > > >
> > > > >

From: Alan Zaitchik
Date: Sun, Jul 15 2018 6:59PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

Thank you Duff and Ryan. I apologize for not having explained in more detail.
The problems I referred to are, first, with table data cells that contain so much content that they span a (visual) page boundary, especially when the cell content is a very long list. In these cases no matter that my table tagging ignores the page boundary, JAWS does not see a single list in a single cell. It stops reading the list at the (visual) page boundary. So perhaps the issue is a JAWS shortcoming?
Another case: even when the table rows do not cross a page boundary there's a (different) problem with JAWS— it won't read the column headings when i moved to the next row on the next (visual) page.
Perhaps these issues are fixed in the latest release of JAWS, but I don't have it.
A

> On Jul 13, 2018, at 5:51 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>
> I agree with Duff, the page spans should be ignored and just tag it as one
> long table. We would need know what you mean by awful problems.
>
> --
> Ryan E. Benson
>
>> On Fri, Jul 13, 2018 at 3:50 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Hi Alan,
>>
>> I'm confused…
>>
>> The problem is when table-cells span pages, yes?
>>
>> Are you tagging the tables irrespective of the pages they span? If so I
>> don't see why you should be having a problem.
>>
>> Duff.
>>
>>> On Jul 13, 2018, at 15:47, Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>>
>>> Thank you, Glen. Unfortunately I have no access to the original Word
>> document for this legacy pdf. It has to be delivered back to the client as
>> a PDF, too.
>>> Another (similar) pdf will be arriving soon together with its source
>> Word doc. I will certainly try to restructure the tables in that case with
>> the "do not span page boundary" setting for data cells. The problem I
>> foresee is that some data cells in these documents contain lists that are
>> just too "long". Shrinking fonts and making extra columns in a cell is
>> likely to prove unacceptable visually to the client. I'll have to give it a
>> try and judge the results.
>>> As for my present document, I have just the PDF. Acrobat is pretty
>> horrible for editing so I may have to go with Lists.
>>> A
>>>
>>>> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>>>
>>>> Given the tags of your example, I presume you're creating a PDF
>> document?
>>>> Are you creating it directly in acrobat or do you have a word doc (or
>> some
>>>> other format) that you're saving as PDF?
>>>>
>>>> Is there also an HTML equivalent? HTML obviously won't have a "page
>>>> boundary" problem.
>>>>
>>>> Personally, I prefer navigating through a table rather than a list when
>>>> using a screen reader. I like the row/col header announcements before
>> the
>>>> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
>>>> walk the grid in any direction I want. (Or go into table mode and use
>> the
>>>> plain arrow keys.) With a list, I'm sort of forced to navigate it
>>>> sequentially. I can't jump from the 3rd item in one list to the 3rd
>> item
>>>> of the next list like I can with a table.
>>>>
>>>> Is your table only 2 columns? The row header and the data cell? That's
>>>> the only scenario I can think of that wouldn't have column headers,
>>>> although even then I think column headers would be helpful as you
>> navigate
>>>> horizontally between the data cell and the row header.
>>>>
>>>> Have you confirmed that the tags for your data cells that span across a
>>>> page boundary are marked up properly?
>>>>
>>>> If you happen to be using Word to create your tables and are saving the
>>>> document as PDF, just to rule out the obvious, have you turned OFF the
>>>> "allow row to break across pages" option?
>>>>
>>>> I'm just trying to toss a few ideas out there that might spark other
>> ideas.
>>>>
>>> >>> >>> >>> >>
>> >> >> >> >>
>

From: Ryan E. Benson
Date: Sun, Jul 15 2018 7:19PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | Next message →

I am willing to lean towards a bug in JAWS, but it is hard to say for sure
without the file in question. I would say that it should work fine for the
last few versions of JAWS.

Ryan E. Benson

On Sun, Jul 15, 2018, 20:59 Alan Zaitchik < = EMAIL ADDRESS REMOVED = > wrote:

> Thank you Duff and Ryan. I apologize for not having explained in more
> detail.
> The problems I referred to are, first, with table data cells that contain
> so much content that they span a (visual) page boundary, especially when
> the cell content is a very long list. In these cases no matter that my
> table tagging ignores the page boundary, JAWS does not see a single list in
> a single cell. It stops reading the list at the (visual) page boundary. So
> perhaps the issue is a JAWS shortcoming?
> Another case: even when the table rows do not cross a page boundary
> there's a (different) problem with JAWS— it won't read the column headings
> when i moved to the next row on the next (visual) page.
> Perhaps these issues are fixed in the latest release of JAWS, but I don't
> have it.
> A
>
> > On Jul 13, 2018, at 5:51 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > I agree with Duff, the page spans should be ignored and just tag it as
> one
> > long table. We would need know what you mean by awful problems.
> >
> > --
> > Ryan E. Benson
> >
> >> On Fri, Jul 13, 2018 at 3:50 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = >
> wrote:
> >>
> >> Hi Alan,
> >>
> >> I'm confused…
> >>
> >> The problem is when table-cells span pages, yes?
> >>
> >> Are you tagging the tables irrespective of the pages they span? If so I
> >> don't see why you should be having a problem.
> >>
> >> Duff.
> >>
> >>> On Jul 13, 2018, at 15:47, Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>>
> >>> Thank you, Glen. Unfortunately I have no access to the original Word
> >> document for this legacy pdf. It has to be delivered back to the client
> as
> >> a PDF, too.
> >>> Another (similar) pdf will be arriving soon together with its source
> >> Word doc. I will certainly try to restructure the tables in that case
> with
> >> the "do not span page boundary" setting for data cells. The problem I
> >> foresee is that some data cells in these documents contain lists that
> are
> >> just too "long". Shrinking fonts and making extra columns in a cell is
> >> likely to prove unacceptable visually to the client. I'll have to give
> it a
> >> try and judge the results.
> >>> As for my present document, I have just the PDF. Acrobat is pretty
> >> horrible for editing so I may have to go with Lists.
> >>> A
> >>>
> >>>> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>>>
> >>>> Given the tags of your example, I presume you're creating a PDF
> >> document?
> >>>> Are you creating it directly in acrobat or do you have a word doc (or
> >> some
> >>>> other format) that you're saving as PDF?
> >>>>
> >>>> Is there also an HTML equivalent? HTML obviously won't have a "page
> >>>> boundary" problem.
> >>>>
> >>>> Personally, I prefer navigating through a table rather than a list
> when
> >>>> using a screen reader. I like the row/col header announcements before
> >> the
> >>>> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys
> to
> >>>> walk the grid in any direction I want. (Or go into table mode and use
> >> the
> >>>> plain arrow keys.) With a list, I'm sort of forced to navigate it
> >>>> sequentially. I can't jump from the 3rd item in one list to the 3rd
> >> item
> >>>> of the next list like I can with a table.
> >>>>
> >>>> Is your table only 2 columns? The row header and the data cell?
> That's
> >>>> the only scenario I can think of that wouldn't have column headers,
> >>>> although even then I think column headers would be helpful as you
> >> navigate
> >>>> horizontally between the data cell and the row header.
> >>>>
> >>>> Have you confirmed that the tags for your data cells that span across
> a
> >>>> page boundary are marked up properly?
> >>>>
> >>>> If you happen to be using Word to create your tables and are saving
> the
> >>>> document as PDF, just to rule out the obvious, have you turned OFF the
> >>>> "allow row to break across pages" option?
> >>>>
> >>>> I'm just trying to toss a few ideas out there that might spark other
> >> ideas.
> >>>>
> >>> > >>> > >>> > >>> > >>
> >> > >> > >> > >> > >>
> >
>

From: Jonathan Cohn
Date: Sun, Jul 15 2018 7:49PM
Subject: Re: Lengthy Tables, Lists, and Screen Readers
← Previous message | No next message

This sounds like you hit the Adobe page limit. Adobe files that are over a threshold only load one page at a time instead of the entire document. I seem to remember the default being 25 pages, but not having any issues when I increased that value to 100.


Best wishes,

Jonathan Cohn



> On Jul 15, 2018, at 8:59 PM, Alan Zaitchik < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thank you Duff and Ryan. I apologize for not having explained in more detail.
> The problems I referred to are, first, with table data cells that contain so much content that they span a (visual) page boundary, especially when the cell content is a very long list. In these cases no matter that my table tagging ignores the page boundary, JAWS does not see a single list in a single cell. It stops reading the list at the (visual) page boundary. So perhaps the issue is a JAWS shortcoming?
> Another case: even when the table rows do not cross a page boundary there's a (different) problem with JAWS— it won't read the column headings when i moved to the next row on the next (visual) page.
> Perhaps these issues are fixed in the latest release of JAWS, but I don't have it.
> A
>
>> On Jul 13, 2018, at 5:51 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> I agree with Duff, the page spans should be ignored and just tag it as one
>> long table. We would need know what you mean by awful problems.
>>
>> --
>> Ryan E. Benson
>>
>>> On Fri, Jul 13, 2018 at 3:50 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> Hi Alan,
>>>
>>> I'm confused…
>>>
>>> The problem is when table-cells span pages, yes?
>>>
>>> Are you tagging the tables irrespective of the pages they span? If so I
>>> don't see why you should be having a problem.
>>>
>>> Duff.
>>>
>>>> On Jul 13, 2018, at 15:47, Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>>
>>>> Thank you, Glen. Unfortunately I have no access to the original Word
>>> document for this legacy pdf. It has to be delivered back to the client as
>>> a PDF, too.
>>>> Another (similar) pdf will be arriving soon together with its source
>>> Word doc. I will certainly try to restructure the tables in that case with
>>> the "do not span page boundary" setting for data cells. The problem I
>>> foresee is that some data cells in these documents contain lists that are
>>> just too "long". Shrinking fonts and making extra columns in a cell is
>>> likely to prove unacceptable visually to the client. I'll have to give it a
>>> try and judge the results.
>>>> As for my present document, I have just the PDF. Acrobat is pretty
>>> horrible for editing so I may have to go with Lists.
>>>> A
>>>>
>>>>> On Jul 13, 2018, at 10:57 AM, glen walker < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>>>
>>>>> Given the tags of your example, I presume you're creating a PDF
>>> document?
>>>>> Are you creating it directly in acrobat or do you have a word doc (or
>>> some
>>>>> other format) that you're saving as PDF?
>>>>>
>>>>> Is there also an HTML equivalent? HTML obviously won't have a "page
>>>>> boundary" problem.
>>>>>
>>>>> Personally, I prefer navigating through a table rather than a list when
>>>>> using a screen reader. I like the row/col header announcements before
>>> the
>>>>> cell value, and it just feels natural to me to use ctrl+alt+arrowkeys to
>>>>> walk the grid in any direction I want. (Or go into table mode and use
>>> the
>>>>> plain arrow keys.) With a list, I'm sort of forced to navigate it
>>>>> sequentially. I can't jump from the 3rd item in one list to the 3rd
>>> item
>>>>> of the next list like I can with a table.
>>>>>
>>>>> Is your table only 2 columns? The row header and the data cell? That's
>>>>> the only scenario I can think of that wouldn't have column headers,
>>>>> although even then I think column headers would be helpful as you
>>> navigate
>>>>> horizontally between the data cell and the row header.
>>>>>
>>>>> Have you confirmed that the tags for your data cells that span across a
>>>>> page boundary are marked up properly?
>>>>>
>>>>> If you happen to be using Word to create your tables and are saving the
>>>>> document as PDF, just to rule out the obvious, have you turned OFF the
>>>>> "allow row to break across pages" option?
>>>>>
>>>>> I'm just trying to toss a few ideas out there that might spark other
>>> ideas.
>>>>>
>>>> >>>> >>>> >>>> >>>
>>> >>> >>> >>> >>>
>>
> > > >