I'm interested in writing a Tcl package to aid in the generation of HTML that is accessible to users with disabilities. I'm already well-versed in writing accessible HTML, especially web-based forms, but
I'm unsure where to begin on the Tcl side of things:

'''Questions'''

   * I'd like this package to work well with the existing [HTML] package, what are some things to keep in mind when subclassing (if that's the proper term) a package in Tcl?
   * I'd like to generate the HTML through an XML interface, I'd prefer not to resort to [puts] except in cases where it's practical to do so. What XML interface(s) are useful (I think [Tdom] is one)?

'''Goals'''

   * Should work equally well in a CGI context and with Tcl-based web servers like [Tclhttpd].
   * Needs to take the drudgery out of writing accessible HTML, which is quite tedious due to the overhead imposed by the additional tagging.
   * A [perl] version is also required.
   * Should comply with existing accessibility recommendations, such as those at the [W3C].

- [WJR]

[AM] Have you had a look at the cgi.tcl package by [Don Libes]? This provides an excellent example to get started ...

[WJR] Yes, like [HTML], many of [cgi.tcl]'s methods can be used, but some methods output deprecated markup that attempts to define presentation, which should be represented in [CSS].

[AM] Excuse my ignorance, but what does this type of HTML/CSS look like?

[WJR] Here's a sample web-based form that illustrates the kinds of entities and attributes required:
======html
<form action="#" method="get">

 <fieldset>
 <legend>Example Form 1</legend>

 <p>
   <label for="first-name" accesskey="n">First <span class="accesskey">N</span>ame:</label>
   <input type="text" name="first-name" value="First Name" id="first-name" tabindex="1" />
 </p>

 <p>
   <label for="last-name">Last Name:</label>
   <input type="text" name="last-name" value="Last Name" id="last-name" tabindex="2" />
 </p>

 <p>
   <label for="fave-color">Favorite Color:</label>
   <select name="fave-color" id="fave-color" tabindex="3">
     <option value="Select an option" selected="selected">Select an option</option>
     <option value="Red">Red</option>
     <option value="Yellow">Yellow</option>
     <option value="Blue">Blue</option>
     <option value="Green">Green</option>
   </select>
 </p>

 <p>
   Your Pet:
   <input type="radio" name="pet" value="Dog" tabindex="4" id="Dog" />
   <label for="Dog">Dog</label>
   <input type="radio" name="pet" value="Non-dog" tabindex="5" id="Non" checked="checked" />
   <label for="Non">Non-dog</label>
 </p>

 <p>
   <input type="submit" class="form-button" value="Save" tabindex="6" />
   <input type="reset" class="form-button" value="Reset" tabindex="7" />
 </p>

 </fieldset>
</form>
======
Given CSS, compliant browsers will render it something like this:

[http://jrankin.ath.cx/tclerswiki/example-form-1.png]

Of course, the visual appearance is not as important as its ability to be rendered by aural browsers, braille-based browsers, etc.

----
[AM] Okay, correct me if I am wrong, but I deduce that the label in front of the entries or other controls are intimately connected to these controls, right? This means that if you
represent this structure as an [XML] file you get awkward connections between nodes.

My suggestion would be to use the [struct]::[tree] module from [Tcllib] (or some similar
implementation of a general tree):

This can easily be converted to an [XML] file by traversing the tree and its nodes,
you can associate as many XML nodes with a single tree node as necessary (struct::tree
allows you to associate arbitrary keys and values with each node).

The way back (from XML to tree) is a bit more complicated, but if the XML/[HTML] file is
structured in a straightforward way, it should not be that difficult.
----
[WJR] I've been looking for an example of struct::tree's usage. What would be the benefit of this approach?
----
[WJR] What about using something like [xmlgen] and doing it as shown in this basic example:
======
package provide htmlable 1.0
package require xmlgen
namespace import ::xmlgen::*
 
namespace eval htmlable {
     namespace export *
}
 
proc htmlable::widget {type name text id class} {
     declaretag label
     declaretag input
     
     # If no ID is supplied, use the name
     if {$id == ""} { set id $name }
     
     set widget [eval label for=$id $text]
     append widget [eval input type=$type name=$name id=$id class=$class]
 
     return $widget
}
======
Example tclsh session:
======
% package require htmlable 
1.0
% htmlable::widget text last-name {Last Name:} {} text-medium
<label for="last-name">Last Name:</label><input type="text" name="last-name" id="last-name" 
class="text-medium" />
======
----
[AM] There is no particular advantage of [struct]::[tree] in itself, it is just that it provides 
a more general structure than [XML]-trees, as it does not describe a particular structure
of the information. I think the above approach is very suitable too: you create a 
''semantic'' structure that gets translated into visibly distinct items. The fact that the items
are visibly distinct is only a coincidence (a rather nasty one, from the structural point
of view) which you solve by introducing another more coherent structure.


<<categories>> Package | Internet