RE: Accessible Survey Creation - Authoring Mechanism

All.

I have developed an accessible survey system using perl for the web.

All the code, as far as possible, is XHTML 1.1 valid, css and valid and WCAG compliant.

Of course, it is difficult to control the way a person might write questions, so readability will always be an issue, but I have not included any controls on this as I do not want to pose restrictions on a researcher forming questions in the ways they need in order to answer their research question (i.e. it might be a study on readability etc.).

The system is a bunch of perl scripts using CGI to feed web pages to the user agents.  the surveys are generated on the fly from text files that are formatted in a particular way in terms of item numbers and types for the form controls.  the results are saved in text files.  Databases such as MySQL can be used here.  Administrators can upload new surveys remotely as well as download data, remove surveys etc.  There is username / password authentication so that particular user groups can only see the surveys on the system that are appropriate for them.

The survey creator is required to only provide the text for the survey item, the type of control it is (text, textarea, checkbox, radio, select, etc), a small amount of formatting etc.  When the code is generated, all sets of radios and related checkboxes are placed in field sets, all form controls have labels etc.  in this way, the code is valid and accessible and there is only a few things that the survey creator could stuff up.

At this stage, outputs are in csv files ready to be used in excel.  The next step for this project is to provide results display pages etc. which present results in the web page to the surveyor so they can see some statistics and trends.

Mat.




> -----Original Message-----
> From: Matthew Smith [mailto:matt@kbc.net.au]
> Sent: Tuesday, December 16, 2003 9:24 AM
> To: WAI Interest Group
> Subject: 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 19:13:00 UTC