Re: Accessible Survey Creation - Authoring Mechanism

Hi Matthew,

this looks like an interesting rpoject - not least as a personal 
learning exercise for you, since the way tolearn seems to be by doing 
:-)

Couple of comments below:

On Monday, Dec 15, 2003, at 23:24 Europe/Rome, Matthew Smith wrote:

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

I'm not a great fan of <br />, but I do like using lists. Have you 
looked at some other text-to-html converters to see if they'd do the 
job? (txt2html is a PERL script in some incarnation, and Wikis tend to 
do this too...)

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

Naturally :-) The point is to help them avoid this if they want to.

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

Are you interested in looking separately at the idea of linking a 
vocabulary, and checking that everything in the document is in the 
vocabulary? This is a similar approach, but potentially more powerful 
than a Flesh-Kincaid, since it can allow for things like automated 
dictionary lookup on uncommon terms or phrases.

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

I'd suggest that instead you have a separate button which says "this 
image adds nothing" which puts in a blank alt and a longdesc.

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

I'm interested in how you do this...

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

See my question above about applying this approach more generally to 
vocabulary...

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

cheers

Chaals
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org

Received on Sunday, 11 January 2004 18:05:19 UTC