Accessible Survey Creation - Authoring Mechanism

Hi All

I'm about to embark on my first piece of work to follow both the WCAG (Web 
Content Accessibility Guidelines) and the ATAG (Authoring Tool Accessibility 
Guidelines), now that it has been pointed out to me that any form of Content 
Management System is, effectively, an authoring tool. (Thanks, Charles.)  Merely 
making the administration pages accessible is only part of the task.  I have 
decided to "learn through righting wrongs" and do the ATAG checks after, not 
during, the programming process, so I can get a feel for all the different 
problems that may be encountered.

The work in question is a Web-based survey tool for use in schools in this 
region.  The content authors will have no control over formatting, other than 
being able to break the questions into paragraphs.  (Text is presented inside 
<p> ... </p>; a single line break in the input will be substituted with <br /> 
at time of page display, more than one line break with </p><p>.)

A few regular expressions convert all appropriate characters into elements.

Despite having tight control over document structure, the content author can 
still 'break' the overall accessibility of the page.

The points that I have been pondering fall into two sections, readability (mean 
word length, sentence length) and use of abbreviations (including acronyms):

1) READABILITY

1.1)	There is a Perl module that can produce a Flesh-Kincaid readability score. 
  This could be used to provide feedback to the content author.

1.2)	A simple word count can ascertain if the question is too long and can 
provide a warning.  (This system is to be used by students of all abilities; 
literacy could be a fairly major issue.)

1.3)	Appropriate graphic representing the question to be provided for each 
question.  (The upload form will force a non-null alt value to be provided.)

1.4)	Readability information for 1.1 and 1.2 to be embedded as metadata so that 
we can 'crawl' the questions for possible readability problems.


2) ABBREVIATIONS (including ACRONYMS)

2.1)	Maintain an glossary of ALL abbreviation used in text.  There would be two 
levels - a simple expansion to populate the <abbr></abbr> and a longer textual 
description which would be accessed by hyperlinking the term in the text.  (The 
glossary mechanism would receive a query string which would allow the user to 
return to exactly where they left off, having read the full text.)

2.2)	As the content author enters questions, anything that looks like an 
abbreviation (rule: more than one capital in a word) will be checked against the 
glossary.  The author will be prompted to provide definitions for the term, 
including an option 'this is not an abbreviation/acronym'.  The mechanism is 
much like that of a spell-checker.

Any comments on the above would be much appreciated.  Please note that whilst 
the system as a whole will not be available to the public, Perl components 
written for the exercise will be made freely available under a suitable artistic 
license.

Cheers

M

-- 
Matthew Smith
Kadina Business Consultancy
South Australia
http://www.kbc.net.au

Received on Monday, 15 December 2003 17:24:16 UTC