This section covers the development of asynchronous communication and collaboration tools including:
- threaded message boards.
- e-mail and listserv messaging.
- document repositories.
- organizers, schedulers, and calendars.
- presentation tools.
Asynchronous communication and collaboration tools such as threaded message boards, e-mail messaging, listservs, document repositories, calendar systems and presentation tools must be rendered in formats that facilitate the full participation of learners with disabilities in online interactions. The navigation system for these utilities should allow users of assistive technologies (AT) to operate without encountering barriers to any aspect of the functionality. Specifically, the software should all them to:
- Scan items and locate content easily.
- Follow the thread of an ongoing discussion topic.
- Post responses, or add additional information.
Users must have flexibility in their choice of browser, input and output modalities, and be able to use assistive technologies. All web-based components of asynchronous communication and collaboration tools should be compliant with the W3C Web Content Accessibility Guidelines 1.0.
For discussion forums, bulletin boards, and other utilities that allow posting of text messages, content providers should render both the navigation system and the content of the messages in standard XHTML. Requiring use of proprietary client software or non-standard file formats may create barriers by preventing users from establishing individual preferences, as described in the introduction.
Common threaded message board accessibility problems include:
- navigation systems using complex framesets that fail to include title or name attributes.
- form fields that do not accommodate keyboard navigation.
- illogical tab sequence when moving between elements on the page.
Learning system developers may enhance the accessibility of threaded message board applications for all users by following these practices:
- Ensure that all actions can be completed using the keyboard.
- Provide easy-to-use features that allow users to configure the interface according to individual preferences.
- Provide help files, including an orientation to the interface and its functionality.
- Use text instead of images of text for navigation links or buttons.
- Use stylesheet attributes and text to create attractive form buttons instead of using images.
- Provide bypass links or some other method to allow users to skip repetitive navigation links and go directly to the main content of the page.
Content creators or educators may enhance the accessibility of threaded message board applications for all users by following these practices:
- Provide informative names to identify discussion threads and message subject lines.
- Examples of accessible threaded message boards are available on the Internet Accessibility Discussion.
E-mail systems may be used either for one-to-one exchanges, or used to distribute and receive messages to a larger user group via a listserv. To use an e-mail system, the user selects proprietary client software according to their individual needs and according to the compatibility needs of their preferred AT hardware and software. To ensure accessibility, developers should make the interface of their e-mail clients compliant with the latest W3C Authoring Tool Accessibility Guidelines.
To further ensure that e-mail messages are accessible, users must always have the option to send plain ASCII text.
Common e-mail accessibility problems include:
- non-plain text components within the body of the e-mail. Non-plain text components include XHTML markup code for fonts, colors and bold formatting.
- inclusion of background images that obscure text for users who are low-vision.
- attachment of non-standard file formats that cannot be accessed by the recipient of the e-mail.
Learning system developers may enhance the accessibility of e-mail applications for all users by following these practices:
- Ensure that e-mail clients allow e-mail content in a plain text format that does not allow fonts, colors, bold formatting, background images, and so on.
- Provide easy-to-use features that allow the users to configure the interface according to their individual preferences (e.g. a simple or expert option).
- Provide help files that include an orientation to the interface and its functionality.
- Follow the latest version of the WAI Authoring Tool Accessibility Guidelines.
Content creators or educators may enhance the accessibility of e-mail applications for all users by following these practices:
- Ensure that the subject line accurately reflects the content of the message.
- Do not attach files to listserv messages. Some recipients may not be able to access the content.
- Use a signature file or Vcard to provide information about the sender's name, title, and address.
Designers of document repositories must ensure that the indexing system is accessible to all users and that it follows logical document structure. Where possible, store documents in standard XHTML format. Using proprietary or non-standard file formats may create barriers. Other formats are less accessible and might limit the user's ability to access information according to individual needs or preferences. Search functions and display options must be accessible to users of ATs.
Common document repository accessibility problems include:
- indexing or navigation systems use complex frames that do not include the title or name attributes.
- form fields in search utilities do not accommodate keyboard navigation.
- display options are hard to locate or are not accessible via the keyboard.
Learning system developers may enhance the accessibility of document repository applications for all users by following these practices:
- Ensure that all actions can be completed from the keyboard.
- Provide easy-to-use features that allow users to configure the interface according to individual preferences.
- Provide help files, and include an orientation to the interface and its functionality.
Content creators or educators may enhance the accessibility of document repository applications for all users by following these practices:
- Ensure that document titles accurately reflect the content of the document.
- Provide documents in standard XHTML format. Avoid the use of proprietary or non-standard file formats.
- Examples of accessible document repositories are available on the WAI Mail Archives.
Some applications, such as organizers, schedulers, and calendars allow users to post shared information. To make these utilities accessible, developers and content providers should seek to structure posted information in a logical manner, encoded using standard XHTML. Non-visual users are at a disadvantage when confronting complex tables or scripting languages. For these and other users, information must linearize correctly in order to be translated accurately into other forms, such as audio output. When providers fail to properly format structured data, dates and events can become improperly juxtaposed. Traditional calendar layouts are particularly susceptible to this sort of error, so content providers ought to include alternative linear output whenever possible.
Common organizer, schedule and calendar accessibility problems include:
- scripts that use event handlers that are device-dependent (i.e., require a mouse).
- the use of incorrect markup that inhibits the users ability to navigate among table cells and access headers and other cell information.
- table cells whose content does not linearize correctly.
Learning system developers may enhance the accessibility of organizers, schedules and calendars for all users by following these practices:
- Ensure that tools are usable even when scripts are not supported.
- Provide equivalent information on an alternative accessible page.
- For data tables, identify row and column headers. Use abbreviations for header labels and identify structural groups of rows or columns.
- Test table content to ensure it linearizes correctly. If it does not, provide a linear alternative.
Content creators or educators may enhance the accessibility of organizers, schedules and calendars for all users by following these practices:
- Provide informative names for events or other posted items.
The Wave is an accessibility evaluation tool that analyzes the linearized reading order.
Microsoft PowerPoint has been widely adopted because it is easy to use. With a little practice, most authors can easily create presentations that look "professional". One of its strengths is the fact that Microsoft PowerPoint allows users to mix and match, to drag and drop all sorts of objects into their presentations. The resulting collection of elements often contain no reference to their origins, how they came to be included, what relationship they have to each other and so on. That is a problem for those who require accessibility. It is certainly possible that a presentation slide contains only a set of text outline statements that are easily accessed by a person with vision impairments. But in fact it's all too likely that a given slide will include many inaccessible objects.
This same problem makes converting Microsoft PowerPoint slides to web pages difficult. If the screen presentation of the Microsoft PowerPoint display is simply converted into a single graphic image and is then connected by links from one screen to another, all embedded information is lost. Often it is just this information that those with disabilities depend on.
For these reasons, the gains made by presenters using Microsoft PowerPoint that allow them to present their material visually often come at a cost to those with special needs or who rely on alternative access technologies.
Below are three possible alternative approaches. Accessibility Wizard, which provides a way to convert Microsoft PowerPoint slides into accessible HTML. The second, W3C Slidemaker, which converts HTML into slides and finally WimpyPoint, a tool that replaces Microsoft PowerPoint.
Accessibility Wizard software was created at the University of Illinois. It provides an alternative to Microsoft PowerPoint's built-in Web Publishing feature.
Using Microsoft PowerPoint's web-publishing feature creates content that can only be viewed using Microsoft's Internet Explorer. Even if non-XML options are selected, users cannot easily add information that is required for accessibility. Accessibility Wizard simplifies the task of converting Microsoft PowerPoint presentations into text pure HTML.
W3C Slidemaker converts a single long HTML or XHTML page into a set of slides. It makes it easy for the author to separate text from presentation, which it handles using stylesheets. Slidemaker's ease of use also encourages good use of Meta-data and helps presenters ensure that their presentation will be accessible to alternative devices.
ArsDigita has created an open source alternative to Microsoft PowerPoint called WimpyPoint (this prdocut was recently purchased by another company and may no longer be supported).
WimpyPoint replaces Microsoft PowerPoint and allows users to build a slide presentation using their preferred browser. Presentations are stored remotely and can be accessed from anywhere. WimpyPoint allows multiple users, even when separated geographically, to share presentations and to collaborate in their creation.
WimpyPoint is ideal for creating accessible presentations since it is based on HTML and supports cascading stylesheets.