WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Lengthy Tables, Lists, and Screen Readers

for

From: Alan Zaitchik
Date: Jul 15, 2018 6:59PM

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