- Wireless Application Protocol (WAP)
- Accessibility for the disabled
- Two examples of use of wireless devices in motion
- Accessibility for Wireless Internet
- Proposed Tools for Multimedia Presentations
- Pocket C3I: hand held terminal for a robot surveillance aircraft
- Further Information
Technological developments look inevitable only in hindsight. Many commentators agree that wireless digital devices will be the next communications revolution. However, they don't necessarily agree what these devices will look like, what they will be used for, who will use them or what technology will be used.
Two divergent points of view are: the WAP (Wireless Application Protocol) approach from the mobile telephone industry, and the wireless Internet approach from the computer industry. With the first approach mobile telephone handsets have computing capacity added, to become wireless data devices. With the second approach hand held computers have wireless communications added to become multi-function phones. The result should be convergence, with telephones growing to be computers and computers shrinking to pocket size. However, the different points of view of the developers can result in devices with different capabilities. The author of this document is firmly in the computer industry category and will therefore argue why the WAP approach will not work and the wireless Internet will.
Often forgotten in debates over technology are the end users of the technology. In the case of wireless technology a rare "win win" is possible with techniques for providing access to disabled people also improving wireless devices. The usability of a hand held device is particularly important when it is used to control a physical device, such as a garage door or a robot surveillance aircraft.
- What is WAP?
- The Wireless Application Protocol (WAP) is an open, global specification that empowers mobile users with wireless devices to easily access and interact with information and services instantly...
- What type of devices will use WAP?
- Handheld digital wireless devices such as mobile phones, pagers, two-way radios, smartphones and communicators -- from low-end to high-end.
From WHAT IS WAP AND WAP FORUM?, Wireless Application Protocol Forum Ltd, 2001
- Which wireless networks does WAP work with?
- WAP is designed to work with most wireless networks such as CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, Mobitex.
- What operating systems are compatible with WAP?
- WAP is a communications protocol and application environment. It can be built on any operating system including PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JavaOS etc. It provides service interoperability even between different device families.
As currently conceived WAP is unlikely to become the mainstream technology for wireless Internet applications. The limitations of current WAP devices require content to be specially designed in the Wireless Markup Language (WML).
<wml> <card> <p> <do type="accept"> <go href="/submit?f=$(fname)&l=$(lname)&s=$(sex)&a=$(age)"/> </do> <fieldset title="Name"> First name: <input type="text" name="fname" maxlength="32"/> <br/> Last name: <input type="text" name="lname" maxlength="32"/> </fieldset> <fieldset title="Info"> <select name="sex"> <option value="F">Female</option> <option value="M">Male</option> </select> <br/> Age: <input type="text" name="age" format="*N"/> </fieldset> </p> </card> </wml>
From "184.108.40.206 Fieldset Element Examples" in Wireless Application Protocol Wireless Markup Language Specification Version 1.3, WAP WML WAP-191-WML 19 February 2000
WML is defined using the Extensible Markup Language (XML), which is being promoted for new web content. This code will actually run on most modern web browsers, although the formatting may look a little odd on a larger screen than it was design for:
Code running from "220.127.116.11 Fieldset Element Examples" in Wireless Application Protocol Wireless Markup Language Specification Version 1.3, WAP WML WAP-191-WML 19 February 2000
However, WML is different to the HTML currently used for most web pages and XHTML as proposed for new web pages. So while WAP content might work on new web browsers, old web pages will probably not work on new WAP devices.
WAP has been designed to fit within the limitations of a low speed (9600bps or slower) dial-up mobile telephone link and a low capacity hand held client device. The result is a set of specifications which follow Internet standards as much as possible and meet the limitations set for them.However, the result is an additional set of standards, different to existing Internet and web use.
I-mode provides a different, and more promising approach to a web service on a hand held device. I-mode uses a proprietary mark-up language based on HTML:
First introduced in Japan in February 1999 by NTT DoCoMo, i-mode is one of the world's most successful services offering wireless web browsing and e-mail from mobile phones. Whereas until recently, mobile phones were used mostly for making and receiving voice calls, i-mode phones allow users also to use their handsets to access various information services and communicate via email.
In Japan, i-mode is most popular among young users, 24 to 35 years of age. The heaviest users of i-mode are women in their late 20s. As of November 2000, i-mode had an estimated 14.9 million users.
When using i-mode services, you do not pay for the time you are connected to a website or service, but are charged only according to the volume of data transmitted. That means that you can stay connected to a single website for hours without paying anything, as long as no data is transmitted.
From I-mode FAQ, WestCyber Corporation, 2000 (no longer on-line)
W3C is working on adapting standard HTML for mobile devices, to provide a less proprietary approach:
A new class of electronics devices with Internet access capability called "Information Appliances" was recently born. This Internet access capability is embedded in devices such as televisions, set top boxes, home game machines, telephone-based terminals, PDAs, car navigation systems and cellular phones. These Internet appliances will drive the merger of wireless and wired Internet world that will eventually create a much larger industry than today's predominantly wired Internet industry.
From HTML 4.0 Guidelines for Mobile Access, W3C Note, 15 March 1999
However, it may be some years (or never) before a suitable standard for mobile devices is adopted. An alternative approach by the CSIRO, here on the ANU campus, is to render the web content in a format to suit the display device:
Combining XML, ASP and database technology provides a powerful mechanism for the development of mobile applications. We describe the development of an application that provides name, rank and phone number information for an organization. The information is accessible from a web browser or a WAP browser on a mobile phone. It uses ASP scripting to query a database and build an XML document satisfying the search criteria. We’ll detect the browser type then apply an XSLT style sheet to format the information for display on the detected device. A generic windows scripting component (WSC) derived from that described by Mike D. Jones in a February 7 2000 Active Server Developers Journal article is used to query the database and return the result to an ASP script as an XML document. You can view a working copy of the application at http://mobile.act.cmis.csiro.au and download the files to implement the application
The WAP approach of building a new set of standards for hand held devices goes against the Internet approach of adding new capabilities while retaining backward compatability. More capable hand held web terminals with larger screens, more processing capacity and continuous Internet access are becoming available. These can be pocket size devices, similar to today's PDAs, and no much bigger than a mobile telephone. As these devices increase in capability they will be able to use standard Internet protocols and will not require special WAP services.
However, hand held devices will be inherently limited by their small screen size, limited keyboard and lower bandwidth connection, than fixed units. Serendipitously, accessibility features designed for the disabled can be used to overcome some of these limitations.
Web accessibility guidelines have been developed to assist designers to make web sites which can be used by the greatest range of people. The most respected guidelines are those from the World Wide Web Consortium. Last year I used those guidelines to assess accessibility for the blind to the SOCOG Sydney Olympic Web site, in a case before the Human Rights and Equal Opportunity Commission.
There is a common misconception that accessibility issues are exclusively to do with a small section of the community who have physical disabilities. However, as the W3C guidelines make clear, they can provide benefits to the wider community:
For those unfamiliar with accessibility issues pertaining to Web page design, consider that many users may be operating in contexts very different from your own:
They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
They may have difficulty reading or comprehending text.
They may not have or be able to use a keyboard or mouse.
They may have a text-only screen, a small screen, or a slow Internet connection.
They may not speak or understand fluently the language in which the document is written.
They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.).
They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.
Content developers must consider these different situations during page design. While there are several situations to consider, each accessible design choice generally benefits several disability groups at once and the Web community as a whole. For example, by using style sheets to control font styles and eliminating the FONT element, HTML authors will have more control over their pages, make those pages more accessible to people with low vision, and by sharing the style sheets, will often shorten page download times for all users.
From Recommendation Web Content Accessibility Guidelines 1.0, World Wide Web Consortium, 5-May-1999.
These issues are particularly relevant to wireless mobile devices. A hand held device may be used in a situation where it is difficult to see or hear, where the user's hands are needed for other tasks or where they are distracted. These devices tend to have small screens, limited graphics, limited keyboards and pointing devices. The wireless connection makes the connection slow and the device may have a less capable browser. In effect the user of the handheld device suffers a temporary disability which can be overcome by applying the guidelines.
Two examples of use of wireless devices in motion
... Gus' Cafe was opened by Augustin "Gus" Petersilka, advicate of the outdoor Viennese cafe. ... Well after Gus' time the cafe has changed from using pencils and note paper for taking orders and now has wireless PDAs. The staff were a bit busy taking orders to stop and explain the system to me, but it appears to use standard Palm III personal digital assistants (PDAs) for taking the orders.
From Networking at Gus' Cafe, 26 January 2001
... visit Philippe Quéau Director of Information Society Division UNESCO. This was a good excuse to try the Eurostar train through the Channel Tunnel from London to Paris .... Mobiles don't work during Channel Tunnel transit (20 minutes) and in shorter tunnels en-route (mostly in the UK). I noticed that phones do work in the London Underground. As soon as we existed the tunnel in France, I received a message on the phone from SFR welcoming me to their mobile service, which is a nice touch. I uploaded the first draft of this web site, using an GSM infrared interface. This was only just done when the battery went flat in my computer...
From London to Paris By Eurostar, 19 October 2000
Accessibility features can be added most easily when web content is created. Conversion of content later is much more difficult. It is attempted with devices such as Web to WAP gateways, designed to allow web content to be converted into a limited form for display on a WAP device.
There are already accessibility features built into the web. The simplest example is alternative text for images. The HTML image command (IMG) includes an optional alternate text (ALT) tag. This allows a text caption to be entered, which is displayed when the image can not be. This option is available in just about every web authoring tool and is supported by just about every web browser. It is just a matter of the web author typing in the captions when adding images.
Simply designed web pages will display well on a hand held device. The text can be enlarged for reading on a small screen, images can be omitted or selectively downloaded as required. However, this assumes the designer is familiar with accessibility issues and is willing to apply them, sacrificing some design options in the process. Also this approach becomes much more difficult for maintaining multi-format multimedia documents. Tools which implement accessibility features and allow components of a multimedia document to be kept in step would greatly simplify the process.
Even a simple document, such as a seminar presentation, can have multiple components in different formats, which need to be maintained in step. For example "Will The World Go Wireless" has:
- Eight minute audio accompanied slide show
- Web page version
- Full slides and notes (MS Power Point format)
These consist of hundreds of separate files containing redundant copies of the same basic information. The ddocuments are created using different tools and making consistent changes to all versions of the content is a complex and error prone process. It would be feasible to build all of the required functions into one package using open source software and web based standards to provide:
Authoring: Document creation and editing functions equivalent to a word processor, presentation package and web authoring tool. The one "document" could be edited using multiple different views, to display as a printed document for typesetting, a "slide show" for live presentation with speaker's notes, a web page for on-screen viewing, audio accompanied graphics and video. Opening the presentation function with an existing WP document would automatically generate a default presentation using the heading and graphics from the WP document.
Editing: Consistency between information elements of the document would be retained during editing. Correcting the spelling of a word in a slide also would also change the word in the print version, in a script and mark the point in the audio and video renderings which would require re-recording. Replacing a word with an abbreviation in a presentation side would creates a new version of the information element alongside the full word in the print version.
Rendering: Versions of the document would be rendered to suit the capabilities of the display device and user. Layout "hints" would be used to redesign layouts dynamically to suit screen size. A large web screen could have multiple frames with graphics, while a small PDA screen has one page of text with links. Inherent accessibility would be provided by selecting suitable representations of the information elements. As an example subtitles for audio and video renderings would be automatically generated from the text of the document. Audio captions would be rendered for the text and graphics automatically from the audio version.
Display: Client and server software cooperate to send information at a rate which suits the communications link and user. A slow wireless link would take advantage of accessibility features, (such as text captions for graphics and video) to provide a low bandwidth option.
To demonstrate the technique of a multi-format document, this document has been designed to be a rendered for individual reading or for live audience presentation as "slides". By default the document is viewed as a conventional web page. To view as a presentation slides, set your web browser to use the accompanying style sheet "http://www.tomw.net.au/2001/slide.css". This instructes the browser to omit sections of the document marked with the class definition "optional" and leave a large margin before titles marked "newslide". Set your browser to use a large font size to suit the audience. For an index to slides use the frames version of the document: http://www.tomw.net.au/2001/wislds.html
While usually thought of for presenting the equivalent of static document, or pre-recorded video, it should be remembered that a web interface can be used for a more active control of a physical device. As an example a Pocket C3I device is proposed. This would provide a wireless hand held terminal for controlling a robot aircraft and displaying surveillance information transmitted from the aircraft.
An example of a conventional unmanned aerial vehicle (UAV) is the Northrop Grumman Global Hawk, deployed for Exercise Tandem Thrust 01 in Australia in early 2001. Global Hawk is equivalent in wing size to a Boeing 737. It requires a portable shelter for flight, communications, sensor processing and aircraft and mission payload control. Set-up for commencement of operations takes 24 to 48 hours after arrival at the operating site.
An alternative is smaller, lower cost and more rapidly deployable UAVs, such as the Australian made Aerosonde. While these have been proposed for surveillance and might provide more flexibility for small scale use, its designer still envisages a portable shelter would be needed for control and at least a lap-top computer for sensor processing.
In place of the one or two truck transported shelters needed for a UAV, it is suggested that a wireless PDA could be used to control the aircraft and display sensor information, via ordinary web pages using the technology discussed above. Multi-format Document Standards would allow the same interface to be used for displaying training and maintenance information for the UAV, as well as to control and display imagery from the aircraft. Server/Browser Protocols for Available Bandwidth would allow a low bandwidth link to transmit sensor information from the aircraft to the hand-held device. Automatic Web Page Layout would allow the interface to be adjusted to suit the available display device, with more information displayed on a larger screen, but still have usable on a smaller hand-held device.
As well as control of a UAV, the same hand held device could be used for video conferences and multimedia presentations. These are commonly used for military and civilian command and control, but are limited by bandwidth and cost considerations from portable pocket size equipment.
A presentation version of this document is available: For an example of the multi-format technique proposed in this document, set your web browser to use the accompanying style sheet "http://www.tomw.net.au/2001/slide.css". This will omit sections of the document marked with the class definition "optional" and leave a large margin before titles marked "newslide". Set the browser is set to use a large font size and select the frames version of the document, for a slide-show type of presentation: http://www.tomw.net.au/2001/wislds.html
See also: Author's home page
This document is Version 2.0 – 2 April 2001: http://www.tomw.net.au/2001/wi.html
Comments and corrections to: firstname.lastname@example.org
Copyright © Tom Worthington 2001.