Thread Subject: Re: tables in wiki?

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Jim Tobias
Date: Mon, Oct 30 2006 6:30 AM

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

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University