Updated 2014-12-27 09:36:43 by dkf

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:


  • 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)?


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


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:
 <form action="#" method="get">

 <legend>Example Form 1</legend>

   <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" />

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

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

   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>

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


Given CSS, compliant browsers will render it something like this:

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