Thread Subject: tables in wiki?

Return to this mailing list's archives

From: Jim Tobias
Date: Sat, Oct 28 2006 6:45 AM
Subject: tables in wiki?

[note complete lack of capital letters in the word 'wiki' -- people from the
TRACE Center shouls know better! ;-)]

In reviewing a lot of the content of the subcommittees, I'm noticing a
possible need for displaying information in tables, as in "comparing 508 to
255", or "collating 508 with ISO", or "indicating for each provision,
whether it goes far enough in clearly stating a user need".

I see from the wiki documentation that tables are possible:
http://meta.wikimedia.org/wiki/Tables

1. How screen-reader-friendly are the resulting tables?
2. WikiCode is not very easy for new users to learn. Is there a way to
modify the editing toolbar so text can be single-click-converted to a table?

3. Do we want to encourage wiki tables, or use external documents like
spreadsheets?

***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com

From: Jared Smith
Date: Sat, Oct 28 2006 9:20 AM
Subject: Re: tables in wiki?

On 10/28/06, Jim Tobias < = EMAIL ADDRESS REMOVED = > wrote:
> I see from the wiki documentation that tables are possible:
> http://meta.wikimedia.org/wiki/Tables
>
> 1. How screen-reader-friendly are the resulting tables?

If they are marked up with the appropriate headers and are not overly
complex, they are quite accessible.

> 2. WikiCode is not very easy for new users to learn. Is there a way to
> modify the editing toolbar so text can be single-click-converted to a table?

No, but you can use HTML to generate the tables as well, if you're
more confortable with that (or have a tool that can generate the table
HTML).

> 3. Do we want to encourage wiki tables, or use external documents like
> spreadsheets?

I think most of this type of content could be put into the wiki (in
either wiki table syntax or HTML). I think there's probably at least
one person in each subcommittee that would be able to do this. Here's
a few options for other spreadsheets/documents:

1. Google Spreadsheets and Documents - this is a fantastic tool, but
the reports on accessibility haven't been great. I'll do some more
testing.
2. I could allow .xls and .doc uploads to the wiki. This brings up
concerns of the potential for viruses and the end user must of
Microsoft Office.
3. Individuals can post the documents to their own servers and provide
a link to them.

That's just a few ideas.

Jared

From: Bailey Bruce
Date: Mon, Oct 30 2006 5:15 AM
Subject: Re: tables in wiki?

In the absence of any evidence that it is not sufficient, I favor using
WikiCode, at least in for the short term. I will be converting the
Access Board notes on the background of 508 Subpart A provisions
(currently in a Word table) so we will see if I remain positive about
the technology after the first hand experience!

>> 2. WikiCode is not very easy for new users to learn.

It is much easier than HTML. It is probably easier to than most new
computer tasks, for example, learning to use a spreadsheet.

>> Is there a way to modify the editing toolbar so text can be
single-click-converted to a table?

I have never found a GUI tool that does this, is accessible, and results
in well structured tables. The W3C Amaya editor comes close in that it
is equally awkward for all users, so the screen reader user is hardly at
a disadvantage.

> No, but you can use HTML to generate the tables as well, if
> you're more comfortable with that (or have a tool that can
> generate the table HTML).

Of course, the tool has to generate well-structured data tables. In my
experience, cleaning up Word generated HTML is more work than just
marking up the plain text. My suspicion is that anyone who can generate
a well-structured data table (using whatever tools) can learn the table
WikiCode in minutes.

>> 3. Do we want to encourage wiki tables, or use external documents
like spreadsheets?

I like the former. There are, of course, many things that spreadsheets
do that HTML tables do not (like formulas). Many people who use
assistive technology find HTML data tables much easier to use than
spread sheets.

> 1. Google Spreadsheets and Documents - this is a fantastic tool, but
the reports on accessibility haven't been great.

If people are doing this in twos and threes, I guess it is not a
problem. I favor work methods that are accessible by design rather than
expecting an assistive technology user to ask for an accommodation.

> 2. I could allow .xls and .doc uploads to the wiki.

I would like to see us (the tools group) articulate what need this is
filling before facilitating it. Sure, people are more comfortable with
Word and Excel, but I find no evidence that it is the novelty of the
tools that is inhibiting more dynamic collaboration on articles.

> 3. Individuals can post the documents to their own servers and provide
a link to them.

Nothing is stopping this approach. Gregg has done this already with a
few files. This approach also makes it unambiguous who has the
responsibility for ensuring the documents are accessible.

From: Jim Tobias
Date: Mon, Oct 30 2006 6:30 AM
Subject: Re: tables in wiki?

> -----Original Message-----
> From: Bailey Bruce [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, October 30, 2006 7:09 AM
> To: TEITAC Communications Task Force
> Subject: Re: [teitac-tools] tables in wiki?
>
<snip>
>
> >> 2. WikiCode is not very easy for new users to learn.
>
> It is much easier than HTML. It is probably easier to than
> most new computer tasks, for example, learning to use a spreadsheet.

My point was regarding non-techies on TEITAC. I think wiki tables would be
daunting for them to create or edit.

> >> 3. Do we want to encourage wiki tables, or use external documents
> like spreadsheets?
>
> I like the former. There are, of course, many things that
> spreadsheets do that HTML tables do not (like formulas).
> Many people who use assistive technology find HTML data
> tables much easier to use than spread sheets.

This surprises me -- HTML tables are more accessible than Excel? Easier for
a screen reader user to use, including editing?

> > 1. Google Spreadsheets and Documents - this is a fantastic tool, but
> the reports on accessibility haven't been great.

But I'm sure all would agree that no complete accessibility eval has been
done, nor have workarounds been carefully pursued. Note that this is a
systemic problem, not just for TEITAC. It has to do with screwed up R&D
priorities and the failure to liaise properly with mainstream industry.

> If people are doing this in twos and threes, I guess it is
> not a problem. I favor work methods that are accessible by
> design rather than expecting an assistive technology user to
> ask for an accommodation.

Sure, but we have 2 competing goals: accessibility and collaborativity.
Neither uploaded nor linked documents addresses the latter at all. I'm not
just pushing Google S&D. I'm trying to collect options for us to decide
among. Right now it seems that the functionality requirements are unclear.


For collaborativity we could be looking for:

synchronous full co-editing (let a thousand cursors bloom!)
single-editor with real-time rendering for all "readers"
asynchronous full co-editing (wiki)
uploaded or linked source documents with embedded commenting
uploaded or linked source documents with external commenting (like via
listserv)

For accessibility, we could be looking for:

absolutely 100% accessible
accessible with workarounds for synchronous sessions (solve Google S&D
issues)
accessible with accommodations (provide static document so user can
participate in synchronous discussion, but cannot co-edit or even see
rendered changes)

To the extent that absolutism on one of these goals excludes workable,
"tolerable" solutions on the other goal, we have not done our job right.

From: Bailey Bruce
Date: Mon, Oct 30 2006 7:10 AM
Subject: Re: tables in wiki?

Just responding to the bits I can.

> This surprises me -- HTML tables are more accessible than Excel?

Speaking broadly, yes, although I am quite sure there are many assistive
technology users who prefer Excel. I will give just two examples of the
systemic problems.

Authors love to convey headings and other similar relationships
visually. Excel provides no mechanism for multi-level headings. The
screen reading software provides a keystroke for marking a particular
row or heading or column as a heading, but this is not 100% reliable,
and one first has to search for and determine that said row or column is
acting like a heading!

White space is another nightmare. How do you quickly tell non-visually
that you are at the end of a data area? How do you know there is not
notes or a new table below or to the right of the one you just finished
reading? Then there is the habit of authors inserting empty columns or
rows rather just than padding cells or adjusting column width or row
height.

> Easier for a screen reader user to use, including editing?

I think a good argument can be made that it is easier to edit wiki text
than a spreadsheet, especially in the case where one is not the original
primary author of the spreadsheet.

From: Jared Smith
Date: Mon, Oct 30 2006 10:10 AM
Subject: Re: tables in wiki?

Here's a couple of tools that might make going to wikitext a bit easier:

http://www.cnic.org/html2mediawiki.html
This tool converts HTML tables to wikitext tables. You could even save
a word processor document to HTML (In MS Word: File... Save as... Web
Page, Filtered) and then paste the table code into this form for
conversion. It's not perfect though and still may require a bit of
cleanup. http://www.uni-bonn.de/~manfear/html2wiki-tables.php does the
same thing.

http://area23.brightbyte.de/csv2wp.php
This online tool converts comma separated data to wikitext tables. You
can export your spreadsheet data to a comma separated format (In
Excel: File... Save as... CSV).

Here's how I see things ...

Wiki:
- Technically is quite accessible, but wikitext may be difficult for some.
- Full collaboration. Anyone can edit in near-synchronous manner.
- Documents are all publicly accessible and are found within the
existing set of tools.

Google Docs/Spreadsheets:
- Document author must provide an e-mail address for EACH editor, so
this tool is not an open collaboration tool. Editors must have a
Google Account.
- Much easier to edit documents, but the interface is not screen
reader or keyboard accessible.
- Spreadsheets cannot be made publicly viewable (author must provide
an e-mail addresses for each viewer). Documents can be made publicly
viewable, but are in an external tool and a link to them must be
provided.

Based on this, if accessibility and open collaboration are both high
priorities, I believe the wiki is better in both aspects. I don't
think this means that Google Docs could not be used for
non-collaborative content - it is very easy to create and publish
content (Documents only, not Spreadsheets) and the published Documents
content of is very accessible.

Jared Smith
NCDAE.org