This document, which is presently in draft form, discusses various issues that are relevant to the design of a braille CSS specification. Cascading Style Sheets provide a mechanism by which formatting commands can be applied selectively to the elements of an HTML document, in accordance with rules that are defined either in an external file (a style sheet) or within the document itself. To extend this concept to the braille medium, it is necessary to develop a repertoire of style properties which, within the framework of CSS syntax, can be used to regulate the format of the braille output. Before proceeding to do so, however, it is necessary to identify those aspects of braille hardware, software, coding and formatting conventions which may need to be taken into account during the process of designing the specification. These issues are addressed in the present paper, which discusses the following topics:
In this document, it is assumed that the reader has a basic knowledge of braille, including familiarity with the concept of a braille cell and the difference between six-dot and eight-dot braille. For those who are not acquainted with these notions, several sources of introductory information have been made available on the web. [A list of references will be inserted here in the next draft.]
There are fundamentally two types of microprocessor-controlled equipment that can generate braille output, namely, embossers and refreshable displays. Their respective characteristics are described below.
A refreshable braille display is comparable to a video monitor in that it allows text to be presented dynamically to the user by means of an array of pins which can be raised and lowered under software control to form the braille characters. Due to the complexity and expense associated with this technology, the number of pins in the array, and hence the maximum number of characters that can be presented simultaneously, is highly restricted, generally comprising only a single line of text. Various types and models of such equipment are available from commercial manufacturers in Europe and North America. They include displays which are incorporated into custom-designed braille work stations (portable computers with braille keyboards that can typically perform word processing and other predefined functions), and those which are attached as peripheral devices to personal computers. The latter are usually controlled by screen access software which is executed on the host system, and offer a range of hardware features such as switches, buttons and optical sensors to facilitate interaction with the user, for example by activating navigational commands that allow a two-dimensional screen layout to be traversed efficiently.
The line lengths of currently available braille display devices vary from as few as 18, to as many as 80 cells. Eight- dot braille is normally used, so that in screen reading applications, the controlling software can employ a one-to-one mapping between the 256 characters of an extended ASCII character set and the 256 possible eight-dot braille cells. Such correspondences have not been standardised, however, and vary from one country to another. It would be possible for an HTML user agent to exercise total control over the operation of a braille peripheral device, thus bypassing screen access software, provided that the application developer could obtain the relevant technical specifications from the braille display manufacturer. No such HTML user agent is presently known to the author of this paper. Nor is the author aware of any braille work station which has been designed, or programmed, to process HTML documents. Thus, in the short term, it is likely that the interaction between application programmed (even specially designed HTML user agents) and braille display equipment will continue to be mediated by screen reading software. However, braille translation and formatting systems can still control the braille output under such circumstances by presenting the appropriate ASCII characters to the screen, pre-formatted so that they appear on the braille display as desired. Cursor movement and other keyboard controls offered by the application's interface, as well as the commands available in the screen access software itself, could be combined to enable WWW resources to be read and navigated easily and reliably. The author has been advised that the Document Object Model, which is currently being developed by W3C, may provide a method by which braille translation and formatting applications can gain access to the high-level semantic content of HTML documents and style sheets. This possibility is currently being investigated by the technical working group of the Web Accessibility Initiative, and it is to be hoped that the opportunities created by such an interface, when and if it becomes available, will be fully exploited by the developers of braille display software.
An embosser is the braille equivalent of a printer: it is generally connected to the host computer by means of a serial or parallel interface. Braille embossers are available from commercial sources in Europe and North America, and vary in the size of the paper that they will accept, as well as in the speed of their operations. The standard length of a braille line is 40 cells, although the width of a typical sheet of braille paper permits a line length of 42 cells (or possibly more). However, a few portable embossers are restricted to narrower paper, with a maximum of approximately 32 cells per line. Some devices can generate interpoint braille (that is to say, braille which is embossed on both sides of the paper), whilst others produce only single-sided output. On each side of a typical sheet, a maximum of 25 lines can be embossed, thus achieving standard page dimensions of 40 cells per line and 25 lines per page.
The text to be brailed is usually sent to the embosser as a sequence of ASCII characters, together with spaces, line feed and form feed codes to control the format. Specialised escape sequences may also be included. By default, six-dot braille is generated, although some embossers are also capable of producing eight-dot braille. As is the case for braille displays, there is no universally standard system of ASCII- braille equivalence used by all braille embossers, although the North American six-dot table, which maps the 64 possible six-dot braille cells onto the standard (non-extended) ASCII character set, is widely deployed. In addition, certain embossers offer a graphics mode, in which the spacing between the braille dots is reduced, thereby allowing low-resolution images to be constructed.
Braille embossers are usually driven by specialised translation and formatting software, which processes ASCII text and transforms it into one or more braille codes, in accordance with the applicable braille standards. The document is also formatted, and the resulting dot patterns are then output to the braille embosser as the required sequence of ASCII characters and control codes. Most modern braille translation systems can import documents which have been saved in the proprietary formatting schemes used by one or more word processing packages. Furthermore, they may offer their own editing and word processing tools which allow the user to customise the braille format prior to translation.
During the past few years, several research projects have been exploring the prospect of developing technologies that would enable the production of multiple-line refreshable braille displays at a reasonable cost. Using Piezoelectric techniques to drive the display elements, a prototype four-line device was recently designed and manufactured in the United States. Researchers at Fernuniversitaet Hagen in Germany have been investigating the possibility of using electrorheological fluid as the basis of a tactile tablet capable of displaying both text and graphics. Moreover, it was reported in early 1997 that a similar approach had led to a successful U.S. patent application: see U.S. patent no. 5,580,251.
Although the development of large refreshable displays with the capacity to present both text and low-resolution tactile graphics is still in its early research phases, the possible future availability of such technology should be borne in mind when designing technical specifications that pertain to the braille medium.
There is only one web client which is integrated with braille translation and formatting software, namely the Sensus Internet Browser. An HTML to Braille Transformation Service has been set up at the University of Technology in Dresden. This system presents the user with a form through which he or she can specify the URL of the document that is to be converted, as well as the braille code in which output is desired (the choices include English and German contracted braille, and French uncontracted braille). The document is then retrieved by the server, translated into braille and transferred to the user's web client for presentation via a braille display or transmission to an embosser.
Several braille translation packages are capable of reading HTML documents directly. These include products from Duxbury Systems Inc., Raised Dot Computing Inc. and Sensus ApS, as well as the Hagener Brailleschrift System which is used in the aforementioned HTML to Braille Transformation Service. When such importation occurs, the HTML tags are typically converted into the scheme of formatting codes which is used internally by the braille translator. The user may then be able to edit the text and alter its format prior to commencing the translation process. An example of the formatting commands which are available in a typical translation system is given in the CAPS report entitled ODA - UK Braille Conversion Design. See also the associated SGML To French Literary Braille Report.
As is evident from the preceding discussion, there is a need for the development of HTML user agents which can translate documents into braille and format them either for embossing or presentation via a refreshable display. The absence of web clients which directly support braille output is an issue which should be addressed as part of the Web Accessibility Initiative's research programmed, together with the development of a braille style sheet specification.
The diversity of currently available braille hardware and the prospects for the construction of large tactile display tablets, have several consequences which should be taken into consideration in the design of the braille style sheet system. Firstly, certain formatting characteristics which are applicable to embossed braille would be inappropriate for braille that is destined to be displayed dynamically. These differences parallel those which pertain to the print and screen media types. For example, such features as page numbering, running headers and footers, and commands to control pagination (such as block protection instructions which attempt to ensure that specified items of text are presented on a single page) would in most cases be suitable only for embossed output. Thus, to enable user agents to select different styles depending on whether displayed or embossed braille is intended, it is suggested that optional parameters be added to the braille media type as follows:
media="braille embossed"
media="braille displayed"
These parameters should be optional: any user agent which encounters a media type of media=braille should assume that the associated style or style sheet is equally relevant to both embossed and displayed output.
Another important variable which affects the formatting of braille is the number of available cells per line. As previously discussed, the line lengths permitted by braille devices differ significantly depending upon the design of the hardware. It may therefore be necessary to add a further parameter to the braille media type so that styles can be selected on the basis of the line length of the output device. Such a parameter might be particularly useful in the preparation of tables, since it would enable alternative styles, and hence alternative table formatting strategies, to be adopted according to the available line length. (This would be achieved by creating several alternate styles, each of which would correspond to a particular line length as indicated in the media type).
The capacity of many braille embossers to produce tactile graphics, and the ongoing research into the construction of large tactile displays, give rise to the possibility of including tactile graphics in braille documents. Due to the differences between visual and tactile perception and the often limited experience of braille readers with graphical means of representing information, it is generally necessary to simplify the content of a diagram before it can be meaningfully conveyed as a tactile graphic. A future research project may wish to investigate the usability requirements of braille graphics and to develop techniques for making them available via the web, perhaps even including rudimentary image simplification software. Formatting issues concerning the placement of graphics on a braille page may deserve consideration in the development of the braille CSS specification.
This section examines various topics related to braille coding and formatting which are relevant to the development of braille style properties.
The horizontal and vertical positioning of text, particularly by way of line spacing and indentation, comprises the most fundamental method through which documents can be formatted in braille. A new paragraph, for example, is often marked by the start of a new line, which is indented so as to commence in the third cell. Similarly, list items are often indicated by hanging indents, headings may be centred or indented by a prescribed number of spaces, etc. Skipped lines are generally used to distinguish major divisions within a document, and may occur for instance before and after first or second level headings.
It is recommended that style properties be established by which the number of skipped lines, if any, that precede and follow a block level element can be controlled. Furthermore, indentation commands should allow notional left and right margins to be established, thus preventing text from appearing in specified zones at the beginning and end of the line. For example, a minor heading may be indicated by setting symmetrical left and right margins of five cells each. On a 40-cell line, text would thus start at cell 5 and terminate at cell 35. The indentation of the first line in a block level element should be regulated by a separate style property, which would thereby enable the first line of a paragraph to be indented and permit the construction of hanging indents. Centring, left and right justification should also be available.
It should further be noted that, so far as the present author has been able to ascertain, all known literary braille codes are read from left to right, including those for the Hebrew and Arabic scripts. Left to right directionality can therefore be assumed in the development of the braille CSS specification.
Ordered lists (OL) elements provide a means whereby such constructs as outlines and tables of contents can be represented in HTML. Different levels in a hierarchy created by a nested series of ordered lists may be distinguished in braille through the appropriate use of indentation: each successive level would be indented further than its predecessor. However, given the limited line length of most braille devices, the number of hierarchical levels which can conveniently be marked by varying the indentation is somewhat limited. It is therefore suggested that style properties be developed so as to allow different numbering schemes to be associated with different levels in the hierarchy. For example, a style might specify that item numbers in the first level are to be represented by Arabic numerals, those in the second level by Roman numerals, and those in the third level by single parenthesised letters of the alphabet "(a)", "(b)", etc. Obviously, a full range of numbering schemes would need to be made available, and the outlining system should also be internationalised so far as possible.
Similarly, it should be possible to generate numbered section headings and paragraphs, which may serve as convenient references, particularly in long and complex documents.
The positioning of page numbers legitimately comes within the purview of stylistic preference. Page numbers may appear on any of the four corners of a page, and may also stand alone on the first or last line. Other possibilities for page number positioning, such as the inclusion of page numbers in running headers and footers, should also be considered in the design of the braille CSS specification. Braille page numbers may consist of either Arabic or Roman numerals. The type of braille page number (Arabic or Roman) should thus be under the control of a style property.
In braille transcripts of printed documents, particularly textbooks, there are often two separate series of page numbers: one pertains to the braille text itself and is incremented on each successive page. The other page number, however, specifies the number of the corresponding page in the print edition of the text, and is thus referred to as a print page number. CSS should allow the respective locations of the print and braille page numbers to be specified separately. For instance, it is common in Australia for the braille page number to appear in the upper right corner of the page, whereas the print page number occurs in the lower right corner. However, in North American braille, the reverse is the case.
In North American braille, the print page number is often preceded by a letter prefix on the second and subsequent braille pages which correspond to a given printed page. Furthermore, "print page indicators" are used whenever a new print page commences part way through a braille page. These indicators interrupt the flow of text at the point where the new print page begins, and normally occur on a new line. The precise format of print page indicators varies, however, for example between British and North American braille. Consideration should be given to whether the format of print page numbers and indicators should be regulated by style properties or left to the internal settings of the braille formatting software.
A means of specifying print page numbers within HTML documents has been developed by the Web Accessibility Initiative, in cooperation with the International Committee for Accessible Document Design (ICADD).
The bullet character which marks each item in an unordered list is represented in English braille by the symbol for an asterisk, and a similar convention is presumably adopted in other languages. It may be desirable, however, especially when formatting a hierarchies of unordered lists (Ul elements) to be able to associate a different bullet with each successive level. This option should be controlled by appropriate style properties.
Horizontal rules are sometimes employed to represent major divisions within a braille document. They are normally centred, although it would be possible, as in print, for horizontal rules to be left or right justified, or to extend across the entire line. Moreover, different braille signs may be used as horizontal rules to indicate different types of textual division. For instance, a rule consisting of ten centred dots 25 signs may be used in a document for a purpose which is different from that of a similar rule comprising ten dot 3's. Since the conventions relating to horizontal rules are of a stylistic nature and have not been defined in braille codes as such, it is appropriate that they be controlled by CSS styles. A comprehensive set of style properties should be defined which enable authors to specify the positioning of horizontal rules, as well as the braille dot patterns from which they are to be constructed.
As previously mentioned, running headers and footers constitute a valuable formatting device which is particularly beneficial in embossed documents. Braille CSS should, furthermore, allow such variables as section numbers to be included in the header or footer text. Difficulties may arise, however, from headers or footers which exceed the length of a single braille line. Consideration should be given to whether it is necessary to define a standard algorithm for truncating the text of the header or footer under such circumstances, or whether an alternative approach would be preferable (for instance, suppressing the header or footer altogether, or allowing it to extend beyond a single line of braille output).
Braille CSS should also provide a block protection command which ensures that the entire text of the selected element is presented, if possible, on a single page.
For purposes of the present discussion, a literary code can be defined as a braille code which is sufficient to represent the text of a particular natural language, but which does not include provision for such notations as those used in mathematics, linguistics (the International Phonetic Alphabet etc.) or computer program code. For instance, Standard English Braille can represent letters, numerals and punctuation characters, and also provides indicators for designating capitalisation and emphasised text. Most literary braille codes are six-dot systems, one exception being the eight-dot contracted code which, though not officially endorsed by the national braille authority, is nevertheless becoming increasingly popular in Denmark (see Lars Ballieu Christensen, Applying Information Technology as an Intelligent Interface for the Blind, ch. 9).
It is convenient to divide literary codes into two categories, namely, those which employ a system of contractions to abbreviate groups of letters and words that occur frequently in the relevant language, and those which are uncontracted, thus requireing that each character in the text be represented by a discrete braille sign. Contracted text is often referred to as being in "Grade II", braille, whereas uncontracted text is said to be in "Grade I". In order to avoid potential confusion, the terms "contracted" and "uncontracted" will be used exclusively throughout this document.
In practice, to every contracted code there corresponds an uncontracted code, which is in effect a subset of the former. Whether a document is to be translated into a contracted system in any particular case depends upon a number of circumstances, including the user's preferences, whether the braille reader is familiar with the contracted code for a particular language, and whether the code in question is supported by the braille translation software. With regard to the latter issue, several of the most popular braille translation programs are equipped with algorithms for converting text into the contracted codes of two or three languages. However, the software often allows several additional languages to be represented by means of uncontracted braille. Moreover, intermediate levels of contraction, which implement only a selected part of a given contracted code, are of benefit to those braille readers whose knowledge of the relevant system of contractions is limited. For example, the HTML to Braille Transformation Service mentioned above offers three levels of German literary braille: Grade I (uncontracted), Grade II (an intermediate level), and Grade III (the full contraction system).
The foregoing considerations motivate the conclusion that the question of whether a contracted code is to be used in the processing of a document should not be determined by style properties. Rather, the selection of an appropriate level of contraction should be regarded as an internal function of the HTML user agent which may be controlled by configuration settings and which is subject to the limitations of the braille translation software. Nevertheless, in special circumstances, authors may wish to ensure that certain parts of their documents are translated into uncontracted braille. For example, it may be deemed necessary that the defining instance of each term in a definition list be translated into uncontracted braille. Likewise, lists of vocabulary are generally not contracted, thus allowing the reader to learn the orthography without potentially being confused by the presence of contractions. With these requirements in mind, it is recommended that a style property be established which, when applied to an element in an HTML document, specifies that its contents are to be represented in uncontracted braille. Once the selected element and all of its child elements have been processed, the pre-existing contraction level in use by the braille translation software should be resumed. Thus, the operation of the HTML user agent with regard to literary code selection can be outlined as follows. Note that, for purposes of simplicity, it is assumed that all language changes are correctly indicated in the document by means of the LANG attribute. The importance of this condition can not be over-emphasised, since correct braille translation requires that the language of every part of the document be identified.
Firstly, the user agent must ascertain the initial language in which the text of the document is written. This information may be gleaned from HTTP headers, or acquired from any LANG attribute which is found at the start of the document (for example, in a META element occurring within the document's head). If no braille code corresponding to the initial language of the document is supported by the translation software, an error should be reported to the user. After having thus determined the initial language and selected an initial level of contraction (according to the user's preferences and the capabilities of the translation program), the user agent should then process the document. Elements which are designated by the LANG attribute as having been written in a different language should be translated, if possible, using a braille code that is applicable to the language in question. If this language is not supported by the translation software, an error should be reported. Typically, words and passages of text written in a language other than the initial language of the document are translated into uncontracted braille. If the style property recommended above, which ensures the use of uncontracted braille, is applied to any elements of the document, then those elements must be translated accordingly. After each such element has been translated, the initial level of contraction (whether it amounts to uncontracted, partly contracted or fully contracted code) must be re-established.
In this context, specialised braille codes can be understood, in broad terms, as those which represent such notations as are used in mathematics and linguistics. Furthermore, since the unusual sequences of letters, digits, punctuation and other symbols from the ASCII character set which occur frequently in program source code, are not to be found in ordinary text, they can not in general be unambiguously represented in literary braille. Thus, additional codes, which for the sake of brevity will henceforth be referred to as codes for computer notation have been defined for the specific purpose of unambiguously representing sequences of ASCII characters. These codes employ six-dot braille, and should not be confused with the related, though distinct, systems of ASCII-braille correspondence which are employed by braille output devices.
It is therefore apparent that, in order to generate a correct braille translation of HTML documents, the user agent must be able to identify and recognise all instances of mathematical notation, phonetic script (IPA etc.) and computer notation which are included in the text. This requirement is not a matter of stylistic preference; rather, it is necessitated by the nature of braille codes themselves. It should therefore be dealt with in the ongoing development of HTML markup rather than in the context of a braille style sheet specification. Accordingly, the requirements of the various braille mathematics codes which have been established in Europe, North America and elsewhere should be borne in mind when evaluating proposals for the representation of mathematics in HTML. Incidentally, it is noteworthy that the Maths Project, which is funded under the European Union's TIDE program, has conducted research into the use of SGML DTD's as a basis for the conversion of mathematical notation into the British and German braille mathematics codes. In general, it is suggested that issues surrounding mathematical markup, the International Phonetic Alphabet and any other specialised notations that may appear in HTML documents, be addressed at the level of HTML itself rather than in the design of the braille style sheet specification.
Nevertheless, in some circumstances it may not be possible to preserve the necessary semantic distinctions in the HTML markup, thereby creating a need for the application of specialised braille codes to be controlled via style properties. This approach would amount to a departure from the principle that all of the required semantic content should be unambiguously represented in the HTML document and that the role of styles is limited to the implementation of formatting preferences. However, for the purpose of providing maximum flexibility to both authors and users, consideration should be given to the question of whether to define style properties that would enable the contents of selected elements to be designated as comprising computer notation, mathematical expressions, phonetic script, etc. An illustration of the reason why such options might be desirable can be given by considering the VAR and KBD elements: in some instances, it may be preferable that the contents of these elements be rendered as emphasised text; under other conditions, however, they might need to be presented as computer notation. A more problematic case is that of the PRE element, which may contain computer notation, but, as exemplified in the HTML 4.0 draft, can equally well serve as a means of presenting poetry or other pre-formatted text. Unless the PRE element is modified to provide an attribute whereby the nature of its content can be indicated, another mechanism will need to be made available through which the braille translator can be instructed as to which code should be employed in the processing of this element. Code selection properties in braille styles would offer such a mechanism.
Incidentally, the PRE element raises further problems for braille formatting. Owing to the limited line lengths of most embossers and refreshable displays, it would often be impossible, or at least highly inappropriate, to preserve the spacing and line endings of the pre-formatted text. An alternative means of formatting such material as poetry and extracts from computer programs should be sought. Clearly, this is an HTML markup issue and ought therefore to be addressed in that context.
Some (most?) literary codes define special symbols which are used as indicators of emphasised text. The precise rules governing their application are specific to each literary braille code. In English braille, for instance, a sequence of three or fewer italicised words is represented by placing an italics indicator (dots 46) before each word. However, if a passage consisting of more than three words is to be italicised, a double italics indicator (dots 46,46) precedes the first words in the sequence, and a single italics indicator precedes the final word. In French braille, the italics indicators are different (dots 456 is the single italics sign; dots 25,456 is the double italics sign), but their use is similar to that in the English system. Codes for other languages may offer different schemes for indicating emphasis; this aspect of braille requires further research. Nevertheless, it is a legitimate role of style properties to specify which elements in an HTML document should give rise to emphasis indicators. For example, an author may decide, contrary to braille convention, that third level headings should be marked with italics indicators in the manner described above.
However, the need to distinguish different types of emphasis within a single document presents a serious problem. In English braille, there are presently two different types of emphasis indicators: one for italics, and another which represents bold face text. For the purpose of formatting HTML documents, it is apparent that at least three distinguishable emphasis indicators are needed. The HTML 4.0 draft defines two types of emphasis, namely the EM and STRONG elements, which are paralleled by the I (italics) and B (bold face) elements. However, a user agent must also be able to highlight links which occur in an HTML document, and can even be expected to distinguish ordinary links from special links such as those which refer to long descriptions of images (the "long description" link is currently being developed by the Web Accessibility Initiative). Consequently, the provisions of the existing English braille code with respect to emphasis indicators are inadequate, since they only allow two types of emphasis to be distinguished. French braille is even more problematic in this regard, since only the italics indicator is available. Thus, there is a need to develop better means of marking links and other emphasised text in braille, perhaps by adding further emphasis indicators to the literary codes of various languages. Correspondingly, a mechanism should be provided in Braille CSS by which the different types of emphasis can be associated with in-line elements in an HTML document. Needless to say, this entire issue requires a more detailed and extensive investigation.
As of this writing, the present author has been unable to conduct research into the complex questions which surround the task of designing a flexible and appropriate set of style properties for controlling the braille format of tables. For this reason, the following remarks are of a very preliminary character. As previously noted, the use of styles in the formatting of tables gives rise to the question of whether it is necessary to include optional parameters in the definition of the braille media type by which the line length of the output device can be specified so as to permit alternative table styles to be selected. This issue should be addressed along with the development of the table-related style properties themselves.
The problem can perhaps be analysed by briefly discussing three distinct scenarios. (1) The whole table, including its data and column headings, fits within the available line length. In this case, the table can be presented spatially; data may be left or right justified within their respective columns or aligned on a prescribed character such as a decimal point. In braille, guide dots are sometimes used instead of spaces to separate columns. (2) The column headings collectively exceed the available line length, but the tabulated data do not. A common solution to this difficulty is to specify the text of the column headings in a key which precedes the table. Each heading is associated with a label (usually a single letter). These labels, having thus been defined, are used as the actual column headings. The data themselves, of course, are formatted in rows and columns as in (1) above. (3) Both the column headings and the cells of the table exceed the permitted line length. In this case, the table may need to be reorganised and presented as a series of paragraphs. Alternatively, in embossed output (especially interpoint braille in which text appears on both sides of the paper), each row of a table may span the two opposite pages of a bound document (the row begins on the left hand page and continues onto the right hand page). In addressing the issue of table formatting, it is also important to consider the interactive nature of refreshable braille displays and the commands that may be available for moving the display across a virtual two-dimensional document structure.
The objective of developing a braille CSS specification is to allow style creators maximum flexibility and freedom of choice in the formatting of braille documents. Thus, existing formatting guidelines, such as those prepared by the national braille authorities of various countries, should not be taken as limiting the range of possibilities which it would be appropriate to make available via Braille CSS. However, it is important that the properties defined in the Braille CSS specification be sufficiently general and comprehensive to enable the implementation, so far as is possible, of existing stylistic guidelines. Thus, the available formatting manuals can provide a useful indication of what needs to be included in an adequate set of style properties. During the preparation of this document, no such manuals have been consulted by the author, but it is to be hoped that in the future development of Braille CSS, pre-established formatting guidelines from different countries will be taken into account in the design of style properties, particularly with respect to the formatting of tables.