Javier Romañach - July 1997
As the use of Internet keeps growing exponentially all over the world, problems related to information accessibility seem to arise.
Users with disabilities surfing Internet would like to be able to select the way the information they receive is represented. A person with hearing impairments might not want to receive audio files, but would be glad to receive the same information in text format, if it is available. Besides that, he would rather receive videos with captioning and be alerted by a pop up graphic of any alert sound that may come through the net.
A blind user may find useless to receive a graphic image or a video, and would prefer to receive a text description of the contents of the images, or the indication that a graphic is an icon used for navigation.
On the other hand, a person may not be completely blind, or completely deaf, and would feel more comfortable receiving images or sounds sometimes. The same way, people working in noisy environments may wish to view the alert graphics, instead of making an effort to listen to the sounds.
In order to overcome accessibility problems, the binomial, user preferences vs. information media representation should be solved in the end to end connection.
The actual browser options that let a user choose the possibility of not showing videos or pictures is not good enough, as it does not provide alternate methods to convey information.
We should now distinguish the different information media representation that can be actually chosen by users and used to transfer information throng the net.
According to MIME there are the following top level media types
Out of these, only the first four should be considered related to information representation, as applications show also show their information using them.
All of the first four types would have as valid alternate media types the other three. That is, valid alternate media types for text could be either image, audio or video, although in this example video is not very likely to be used.
Another consideration is that the information sent in alternate media types could be used with different length pieces to achieve different goals, and could be placed in different places for the same reason. For example, a short description could be used to describe a simple image (a logo), and a long one could be used to describe other images such as pictures.
The short description could be included in the same HTML file (ALT tag) or in the graphic file (PNG description). The long description would reside in a different HTML file. Any combination of these should be accepted.
Furthermore, a file may include information on where alternate media could be found (e.g. a graphic oriented HTML file may include a header information stating the URL of an alternative text version).
We have delimited the problem to the following statements:
1. In an HTML file, a given included or embedded file (via SRC tag) may have alternate media to describe it.
2. Alternate media may reside in the "parent" HTML file, in the file, or in another file.
3. Information concerning alternate media descriptions files may be included in a file.
Mechanisms should be provided for protocols at all levels that guarantee the possibility to select alternate media type minimizing traffic ad maximizing g efficiency.
The HTTP protocol is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
Although HTTP is a very powerful protocol it may not be able to provide solution for all the scenarios previously stated.
1. If alternate media already reside in the "parent" HTML file, HTTP should not be aware or ready for solutions. (e.g. ALT tag).
2. If the URL or the name of the file where alternate media is included in the "parent" HTML file, HTTP should not be aware or ready for solutions. (e.g. D tag).
3. If the URL or the name of the file where alternate media is included in a file, HTTP should again be able to retrieve the URL or the name of the file using a HEAD method in which new metainformaion definitions could be used to return the values, in order to perform a better suited GET afterwards.
4. If alternate media information resides in the file, HTTP could be aware of the fact and provide solutions through a special new GET message, maybe something like "GETALT type", where "type" could specify text, image, audio or video. (e.g. text description in PNG graphics)
If entity header fields where extended to include Alt-text, Alt-video, Alt-audio, Alt-image, a client may issue a HEAD method to retrieve the names of the alternate files, and issue a GET method only to the file that would suit user preferences as stated in the browser.
Example:
The user has selected options that indicate to the browser that he/she prefers text to images.
1. The user clicks in a link to "http://www.heaven.org/holidays.html"
2. The client issues a HEAD method to get metainformation about "holidays.html".
3. Server returns metainformation from "holidays.html". This metainformation includes "Alt-text="holid_txt.html""
4. The client issues a GET method to retrieve only the file "holid_txt.html"
This way user needs would be satisfied rapidly and traffic through the net would be diminished.
If a file includes alternate in its own data alternate information, HTTP should be ready to retrieve that information without transferring the whole file.
Example:
The user has selected options that indicate to the browser that he/she prefers text to images.
1. The user clicks in a link to "http://www.heaven.org/picture.png"
2. Due to file name extension, the client presumes it may include internal alternate information. It issues a GETALT text method to retrieve just that information.
3. Server receives GETALT method, parses the file. If alternate information is found, just the text is sent, else the whole file is sent.
4. If text is received, text is shown, else the file is shown
Solutions should be provided by the server (e.g. clicking on the right button) to be able to perform a normal GET instead of a GETALT at any time.
Again user needs would be satisfied rapidly and traffic through the net would be diminished.
Future versions of HTTP should be prepared to collaborate in accessibility issues, providing different ways to approach different alternate media issues.
Modifications on header file types an the creation of a new GEALT method are proposed on this document and may suffice for short term accessibility solutions.
Nevertheless the protocol should never impose rules on how alternate media information may be specified or handled at any other level, and further modifications should be studied.
RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
RFC 2068 HTTP/1.1, January 1997