WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Word documents and tables

for

From: Michael.Moore@dars.state.tx.us
Date: Oct 27, 2010 12:57PM


Hi Cliff,

Thanks for the questions, also I need to clear up one item that I got wrong yesterday.

Clearing up the mistake: If you have more than one table in work then you need to use "Title1, Title2..." I added a dot between the bookmark name and the number yesterday, which will not work. It is something that you do with cell names in Excel when you have multiple worksheets in a workbook. The differences between the programs can get confusing, which is why we have to test every document after we implement the hacks.

Now to answer your questions.

What's the difference between a hack and standard practice?

In my mind a hack is taking advantage of a feature or a bug to accomplish something that is not supported natively. Bookmarks and named cells which can be exploited to make JAWS recognize row and column headings in Word and Excel are intended to provide support for formulas and hyperlink anchors. A standard practice would be for Word and Excel provide a programmatic method of identifying table headers similar to the TH tag in HTML and PDF preferably with header and id support as well. In word styles are used to identify heading elements and this works well with most commercial screen readers and it makes semantic sense.

What would it take to get other screen readers to follow JAWS in this respect?

The other screen reader manufacturers would probably need to make sure that implementing that feature would not violate a Freedom Scientific patent or license the feature from Freedom Scientific. If you don't think this is an issue read article linked below from NFB. <http://www.nfb.org/images/nfb/Publications/bm/bm09/bm0911/bm091107.htm>; Even if this were implemented it does not get around the hack issue. Bookmarks and Cell names are just not semantically correct elements for creating row and column headers.


What would it take to get Word and other word processing applications to robustly support this technique?

Implementing the bookmarks and cell names in the same manner that they are implemented in Word would probably involve software patent issues. Perhaps someone from MS could speak up about this. Much better would be to extend the XML specifications for MS Office docs and Open Office docs to support semantic tags that differentiated between data cells and header cells and provide support for header and id attributes. Implementation for the AT developers would then be similar to support in PDF and HTML.


Mike Moore
(512) 424-4159

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Cliff Tyllick
Sent: Wednesday, October 27, 2010 1:13 PM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Word documents and tables

One other thought, Mike. You said:

>The use of bookmarks to add table header support in Word is a JAWS-specific hack. It does not work with other screen readers and is very fragile. You must name the bookmark "Title", "RowTitle", or "ColumnTitle" [plus a number, if more than one bookmark of that type]. If you change the table or add additional tables you may need to redo the bookmarks.
My thought:

What's the difference between a hack and standard practice? Sometimes, it's the level of acceptance and the robustness of support.

What would it take to get other screen readers to follow JAWS in this respect? That would address acceptance.

And what would it take to get Word and other word processing applications to robustly support this technique?

Ideally, creation of the bookmark would trigger from a setting in the Table Properties. The author could check off whether the table has a header row, header column, or both, and the bookmark would be created accordingly. The number in each bookmark's name could match the table number, and the bookmark names could be updated either dynamically as tables are added and removed or on command -- for example, as part of "Update all fields."

And when a PDF is created, Acrobat Pro could read that property and tag not only the header row but also a header column when appropriate.

Even without these suggested improvements, and in spite of its problems and limitations, this strikes me as an elegant solution to the problem of tagging table structure in word processing documents.

Cliff

>>> On 10/27/2010 at 8:00 AM, in message < <EMAIL REMOVED> >, < <EMAIL REMOVED> > wrote:
That is correct, you can only provide support for complex tables in HTML and PDF and PDF has a serious resource issue when using JFW which can cause a lot of lag time. We are currently experimenting with changes in the tag tree and the content tree to see if we can find a way to reduce this but it is a very time consuming process. Best practice is still to keep all tables as simple as possible since it makes the information more understandable for everyone. We plan to present our findings and any new techniques that we have learned at AccessU in May.

Mike Moore

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Cliff Tyllick
Sent: Tuesday, October 26, 2010 4:22 PM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Word documents and tables

Mike, thanks for the additional information. I'm always eager to learn more.

To clarify, your last sentence, "You can also add headers and IDs to support complex tables," refers to what can be done in Acrobat Pro or Dreamweaver, not what can be done in Office 2007 and 2010, right?

Cliff

>>> On 10/26/2010 at 3:05 PM, in message < <EMAIL REMOVED> >, < <EMAIL REMOVED> > wrote:
Just a word of caution - pun intended. The use of bookmarks to add table header support in Word is a JAWS specific hack. It does not work with other screen readers and is very fragile. You must name the bookmark "Title, RowTitle, or ColumnTitle" If you change the table or add additional tables you may need to redo the bookmarks. You will definitely need the version of JFW that your JAWS users will be working with to test and make sure things are working. Freedom Scientific has information in the release notes for JFW 6 http://www.freedomscientific.com/fs_products/software_jaws60fea.asp What is left out in that documentation is how to deal with multiple tables in a document. Bookmarks must all be unique so adding a .1, .2 will usually keep things working, at least in JFW 9, 10, and 11. We have not tested in JFW 12 yet.

The basics of MS Word table accessibility are: Use the insert table command to create the table, keep the tables simple, one row of column headings and one column of row headings is preferred. Do not use merged cells. Uncheck allow rows to break across columns, and check repeat as header row for the header row(s). This second item will provide the column headers when you convert the document to PDF or HTML. Most screen readers allow their users a method to mark rows and columns as headers but many screen reader users do not know how to do this. If you are planning for public distribution of the document, HTML and PDF offer much more robust support for tables. You cannot make complex tables directly accessible in Word. At least not to my knowledge.

If you have Office 2007 or 2010 you can use more than one row of column headers and these will transfer to PDF or to HTML using Adobe's Acrobat Pro or Dreamweaver products. You will need to add the row headers once the conversion is complete. You can also add headers and IDs to support complex tables.


Mike Moore


-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Christophe Strobbe
Sent: Tuesday, October 26, 2010 1:49 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Word documents and tables

Hi,

At 20:06 26/10/2010, Cliff Tyllick wrote:
>Hi, Chris.
>
>When this was mentioned at Access U, we were in a class on how to make
>Word documents accessible. We tested it immediately with Word 2007 or
>2010 and, I believe, JAWS 11. The instructor added the bookmark, turned
>JAWS on, and clicked into a cell in the middle of the table. The whole
>class cheered on hearing JAWS read the two headings and then the cell
>data.

Excellent.
The bookmark technique for table headings is not mentioned in the
"Accessible Digital Office Documents (ADOD) Guidance" for MS Word or
OpenOffice at <http://adod.idrc.ocad.ca/node/1>;.
I should test how screenreaders deal with tables in OpenOffice.org /
LibreOffice, but if anyone else has experience with this, please send
a comment to <EMAIL REMOVED> .


>I really do like your sample document.

Before anyone gets a wrong impression I would like to add that I did
not create that document, CEN did.
Last year I sent CEN instructions on how to create a more accessible
version of Guide 6; instead of doing that, they just sent me a
Microsoft Word version of the document.


>I scrolled until I saw a table and found this:
>
>"Table 1 * Factors to consider in clauses on information
>The best designed products or services avoid the need for any
>explanatory information, signalling the way they should be used by form
>and appearance."
>
>And, below this introduction, Table 1 has column headings, row
>headings, and empty cells. Some of the cells are shaded gray; others are
>white.
>
>No explanatory information needed there, eh?


Precisely. Convincing standards bodies to create accessible documents
is an uphill battle.

Best regards,

Christophe


>
>Cliff
>
>Cliff Tyllick
>Usability assessment coordinator
>Agency Communications Division
>Texas Commission on Environmental Quality
>512-239-4516
> <EMAIL REMOVED>
>
>
> >>> On 10/26/2010 at 12:02 PM, in message
>< <EMAIL REMOVED> >, Christophe
>Strobbe < <EMAIL REMOVED> > wrote:
>Hi Cliff,
>
>
>At 16:55 26/10/2010, Cliff Tyllick wrote:
> >(...)
> >You can designate column and row headings in Word documents, and
> >JAWS (and, I assume, other screen readers) will pick it up. But
> >nowhere in Word's documentation have I found this procedure. Here's
> >how you do it:
> >
> >To make it possible for screen readers to recognize the headings in
> >your table, add a bookmark to the first cell of each table:
> >- If the first row contains column headings *and* the first column
> >contains row headings, name the bookmark "Title#," where "#" is the
> >number of the table.
> >- If the first row contains column headings but the rest of the
> >first column is data, not row headings, name the bookmark
> >"ColumnTitle#," where # is the number of the table. (A decision
> >table might be formatted this way.)
> >- If the first column contains row headings but the rest of the
> >first row is data, not column headings, name the bookmark
> >"RowTitle#," where # is the number of the table.
>
>I once used a similar bookmark technique, but with a bookmark in
>every column header cell and every row header cell. I can't remember
>where that advice came from, and maybe that is a good thing because
>it did not work. A blind trainee who used the document complained
>that the tables were still not accessible. However, transferring
>those tables to Microsoft Excel turned out to be much better, even
>though the tables contain a header row with merged cells. (I am
>referring to the tables in Clause 7 of CEN/CENELEC Guide 6:
><ftp://ftp.cen.eu/BOSS/Reference_Documents/Guides/CEN_CLC/CEN_CLC_6.pdf>;.
>
>Guide 6 contains "Guidelines for standards developers to address the
>needs of older persons and persons with disabilities" but is not
>accessible...)
>
>
> >
> >When JAWS encounters such a table, it will, at the appropriate
> >verbosity setting, behave just like it does in a properly tagged
> >table in an html or PDF document. For example, if the bookmark is a
> >"Title" bookmark:
> >- If you move the cursor directly into a data cell, you will hear
> >JAWS announce the column heading and then the row heading, followed
> >in a different tone of voice by the contents of that cell.
> >- Move the cursor to the next row (same column), and JAWS will
> >announce the new row heading and, in the different tone of voice,
> >the contents of that cell.
> >- Move the cursor to the next column (same row), and JAWS will
> >announce the new column heading and, in the different tone of voice,
> >the contents of that cell.
> >All the "Repeat as header row" does is display (to people who can
> >see) the header row on each new page when the table extends across
> >more than one page. It does not affect what JAWS announces -- at
> >least, it hasn't in any demonstration that I have witnessed. But, of
> >course, redisplaying the header row is important for cognitive
> >accessibility, even for people whose only "impairment" is a moment's
> >distraction as they flipped the page.
> >(...)
>
>Best regards,
>
>Christophe
>
>
>--
>Christophe Strobbe
>K.U.Leuven - Dept. of Electrical Engineering - SCD
>Research Group on Document Architectures
>Kasteelpark Arenberg 10 bus 2442
>B-3001 Leuven-Heverlee
>BELGIUM
>tel: +32 16 32 85 51
>http://www.docarch.be/
>Twitter: @RabelaisA11y
>---
>"Better products and services through end-user empowerment"
>www.usem-net.eu - www.stand4all.eu
>---
>Please don't invite me to Facebook, Quechup or other "social
>networks". You may have agreed to their "privacy policy", but I
>haven't.
>
>