- ACSS
Requirement document about which CSS/ACSS attributes should be part of a minimum accessible user profile where the user-agent can take precedence over the author setting and still have the UA be CSS compliant. Also provide exmaples of ACSS files.
Source materials: ACSS draft.
A suggested approach to the policy question is described below.
I want to negotiate regarding the scope and emphasis of examples.
Detailed comments on the 07 January 1997 draft on ACSS are available separately.
There are numerous notes; readers will please comment on which of these issues are important and how they would be able to help follow up on them.
For the latest version of this note please check the file status1.html at http://www.access.digex.net/%7Easgilman/web-access/ACSS/ .
The approach taken here subsumes all questions of style adjustments to accomodate disability under the more general issue of how reader and writer interests are reconciled in the area of styling. The following concept for reader's and writer's rights in style control, if implemented across the web, would provide sufficient responsiveness to user preferences so that special policies specific to disabled access are not required.
The user of the client software shall have ultimate control over the application or non-application of styles, whether the writer of the document considers them essential or cosmetic. In other words, the scope of user control is all styling transformations, without exception, and the fineness of control shall be by the class of applicand, not by the sheet of styles. The user has a right to a virtual style sheet of overriding priority and the full selectivity and power of the style rule writing model.
An example of the need for fine-grained control of effects is the fact that for Braille, one might want to kill centering.
The writer of a document shall be responsible for creating a document which communicates its content when all essential styles are applied and all cosmetic styles are replaced or overridden with reasonable defaults or alternates consistent with a variety of dialog modes.
HTTP servers shall not decline to serve a document to a client because of the display and control capabilities of the client. HTTP servers shall not make decisions how to deliver service based on client type other than standard display and control capabilities explicitly communicated from the client.
Styles designated as essential shall only be those which are freely available over the Internet.
An HTML proto-document, a Style sheet used to transform such a proto-document into a user-processable representation, and server-side processing supporting HTTP service of documents have no right nor need to know whether the control/display resource profile announced by the client software arises from limitations of the hardware environment of the client software, from motor/sensor/cognitive limitations of the human user, or from free choice. The Client software may disclose strict limitations or priority preferences as to the control/display capabilities to be used in the user session as a guide to the exercise of server-side discretion as to what data to transmit. The capability profile disclosed shall be under user control and the server-side discretion shall be overridden on explicit request from the client.
The defaults of client software as distributed by the manufacturer shall be to honor all style preferences the author puts in a document, within the limitations of the client software environment. Overt action by the client software user shall be required for the default presentation of a new document to differ from the styling indicated by the writer of the document. [Setting preferences different from the shipping defaults constitutes overt action in this sense.]
For a style which the document writer has designated as essential, the style will not be overridden by the client software without a warning to the user and explicit confirmation of the override by the user.
If the user of the client software overrides a style or transformation that the document writer has designated as essential, the document writer is not responsible for the content or accessibility of the resulting representation.
CSS examples will be helpful in building shared understanding of what we can hope to do. On the other hand, I don't see ACSS examples as high on the priority list.
I am encouraging Jason White to work on some CSS example material illustrating existing Braille practices because I think that what works for Braille now is a good starting point for the development of other cross-medium transforms to support accessibility. These transforms could possibly be expressed and distributed as style sheets.
A note on braille Jason wrote for me illustrates what is currently done to compress text effects in transliterating print texts to Braille.
There is no first-order issue here. ACSS is predicated on the idea that there is a textual base to the information representation, and that works first-order accessibility problems. Second-order issues are discussed below.
There is some possibility that authors who use ACSS will encode distinctions in the special ACSS effects that a hearing-impaired reader will miss and therefore not get the message. This is comparable to the low-level use of fonts and text effects to connote semantics that is not articulated in the markup and can be lost on the reader using any output which lacks the text styling capabilities assumed. The main remedy for this is somehow to make sure that the classes that the audio effects are keyed off are well structured and named.
There is an opportunity to use vocal effects such as those exploited in ACSS to map visual text styling into something in audio which captures more of the author's sense that a flat, un-inflected speaking of the text.
It will take a lot of work to determing mapping methods that can be applied without the author's help and render an acceptable result.
As noted above, one primary recovery method which affords information access when assumed display degrees of freedom are not available is to articulate the normally-implicit structure encoded in the markup. Particularly when, as in styling, the structure is discriminated by user-defined TITLEs and IDs, it is important that this infrastructure of nomenclature be mnemonic. simple rule that blankets all demands for intelligibility that different access-adaptation transforms will assert is that the HTML source be comprehensible and tell what is going on. At this point I am skeptical that high-tech solutions are going to obsolete this guideline in the near future.
The conventional wisdom is that developing Web content in an HTML text view will go away and be replaced by better things. One of the goals of the WAI has got to be to correct that mis-impression. Developing Web content in an HTML text view is what works today for blind web content developers, and it is highly unlikely that something else will be devised that will succeed in doing better.
The closest thing to an audio dialog mode that sighted users will have experienced (at least the old ones of us have) is the line-mode or TTY interface. High-order languages and development tools were developed for this interface and have achieved a very high level of capability. Blind access to software and Web development is more likely to succeed through strong cross-language compatibility profiles at the class library level and not through blind use of GUI-based tools with access bandaids.
This is one of the continuing sub-plots of the WAI.
The document medium can contain semantics by having rules that are enforced in the authoring session as well as by introducing additional markup in the document files. There are even things that can be done without overt enformement by aligning the structure of the markup better with the structure of the semantics, so that the voluntary free use of markup by authors will capture more semantics more often.
The concept of the "media" indication reflected in the HTML and Style Sheets draft is much too gross. There is presently a discrete enumeration of media: print, screen, audio, braille, etc. This fails to deal with quantitative issues that are involved with accomodating partial impairment and general equipment variability. There are more low-vision people than blind people. Low-vision people will want to exercise minimum-font-size style rules just as hearing-loss people will want to assert minimum volume and minimum SNR rules. Note that the user doesn't want to re-style the document. Review the "make it fit" function in WordPerfect for an example of what most users would want. The major market for styles adaptation is much finer tuning than that reflected in the current "media" data item. And intellegent re-styling functions will sell in preference to "here, write a CSS1 style sheet to tune your session look and feel."
The current media-types list omits the monospaced character-grid diplay and the TTY interface used in TTD devices. These need to be covered.
A class system with some depth is useful in understanding dialog-resources issues. Even though there are some conspicuous differences in what breaks the browse usability of web content for Braille and audio users, there is a common core of line-mode concerns shared among TTD, audio and braille users that it would be good to understand.
The reason that Lynx can't cope with Tables is not necessarily that it uses a monospaced display medium. If Lynx provided for scrolling the active, rendered page; I suspect that it would be doing recognizable table layouts today. It is the simultaneous inability to pan or zoom the table that provides enough straws to break the table rendering in Lynx. There is no way to say at this point which was the last straw.
Note that some fully-sighted people prefer the way HTML looks as rendered by Lynx. The monospaced or "console" display medium will be selected by some people without disabilities if it is available.
Lynx has an optional function which substitutes sets of radio buttons for "select" widgets. This creates a more static page which benefits many low-tech blind users. This is rewriting HTML at a level that the CSS architecture treats as "pure content" but it is reasonably easy to see that there is a common semantic core to the SELECT and RADIO representations of this dialog that captures all that is essential about the transaction.