- From: Jason White <jasonw@ariel.ucs.unimelb.EDU.AU>
- Date: Mon, 30 Jun 1997 11:33:39 +1000 (AEST)
- To: w3c-wai-wg@w3.org
I would be interested in receiving feedback from members of this list with respect to my proposal for adding parameters to the braille media type for designating (1) whether the output is to be embossed or presented on a refreshable display; and (2) the dimensions of the braille device. The form of the relevant media declaration would thus be as follows: media="braille embossed [x] [y]" or media="braille displayed [x] [y]" where the optional x and y values represent, respectively, the number of cells per line and the number of lines per page available on the braille device. The concept of a "page" is not directly applicable to braille displays, since most of them can present only a single line of text at once. However, larger displays have recently been developed, although they are not as yet widely available and are the subject of ongoing research. Rationale: The principal reason for distinguishing between embossed and displayed braille is that some stylistic features which are useful on paper, are not applicable when reading a document with a braille display. These include headers and footers, page numbering and block protection (to keep related text on a single page), all of which may potentially be controlled by style sheets. The formatting of tables may also differ depending upon whether the document is being embossed or displayed dynamically by the HTML user agent. The justification for the optional x and y parameters that specify the dimensions of the output device, is not so clear. The motivation for this concept stemmed from consideration of the problems associated with the formatting of tables in braille, and the need for tables to be presented differently depending upon whether or not they exceed the line length of the braille line. If the presentation of tables is to be controlled via style sheets, then it may be desirable to create alternative styles, with different parameters, for producing tables on devices with various line lengths. For example, some braille embossers support narrow paper and thus generate output of 32 cells per line, and braille displays vary in size between 20 and 80 cells. The treatment of tables in braille is a complex issue which in my opinion needs to be considered and discussed thoroughly. I am aware that other subscribers to this list are much better qualified in this area than I am, and would be interested to know whether a solution has yet been proposed. The number of lines per page may also be a useful parameter that would affect the formatting of tables, especially if they were presented in paragraph form and there was a need to keep all of the contents of a particular element in the table on a single output page. One difficulty which is also relevant in this context is that the number of lines per page varies depending upon whether six-dot or eight-dot braille is being used. Although most braille codes available today employ a six-dot system, eight-dot braille is becoming more common. For example, in Denmark, it is being used to increase the correspondence between print and braille character sets, thereby facilitating the deployment of software-based translation schemes. For further details, see ch. 9 of Lars Christensen's AITIIB research project report, details of which can be found at http://www.sensus.dk/aitiib.htm. An eight-dot code is also proposed by the Science Access Project at Oregon State University: http://dots.physics.orst.edu/. Furthermore, it is theoretically possible that six-dot and eight-dot codes may both occur within a single document, thus resulting in different numbers of lines per output page in different parts of the same text. The specification of page dimensions may not be so important when reading a document with a braille display, since the controls on the display, in conjunction with controlling software, should provide ample means of traversing a document. However, in formatting tables, it may still be desirable for style sheets to be able to ensure that a certain item of text is presented on a single line, in which event the line length parameter is once again crucial. As is evident from the foregoing discussion, I have not reached firm conclusions in relation to these issues. Nevertheless, I thought that it would be appropriate to seek input from others rather than to continue pondering these questions alone. Regards, Jason White.
Received on Sunday, 29 June 1997 21:33:47 UTC