IDRC - Celebrating 25 Years

1993 - 2018

Continuing Our Work During COVID-19

Read the letter regarding COVID-19 by IDRC Director, Jutta Treviranus.

Courseware Accessibility Study 2000: Inclusion

Inclusion in an Electronic Classroom - 2000:
The Role of the Courseware Authoring Tool Developer

This email address is being protected from spambots. You need JavaScript enabled to view it.
Adaptive Technology Resource Centre, University of Toronto

  • Introduction
  • Courseware And Accessible Authoring Support
  • Inclusion In An Electronic Classroom Study
  • Review Of Authoring Tool Accessibility Guidelines Compliance
  • Summary

Introduction

When recommended design strategies are implemented, any web-based learning program can potentially be made accessible to students with disabilities. Screen readers or braille displays can provide audio access for students who are blind, while alternative pointing devices, onscreen keyboards and voice recognition and other adaptive technologies offer a choice of input and output methods. At present, one of the greatest barriers to access is the lack of authoring tools that support course content developers in adhering to existing accessibility guidelines. Increasingly, courseware authoring environments are being used to make the process more efficient, and could easily include utilities to support developers in making their online resources accessible as well.

In the US, legislation is a new force in the arena of online learning, as in many educational contexts web-based resources must be compliant with the Web Content Accessibility Guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)i. Web editing software such as HoTMetaL Pro, and recently Macromedia's Dreamweaver have moved forward by including an accessibility validator and support within the authoring tool. A proactive developer may further utilize tools such as Bobbyii, SSB Technologies Softwareiii or the A-Prompt Tool Kitvi to validate the accessibility of individual web pages. However, all of these strategies for validation and repair may prove fruitless if the Web pages are then uploaded into a courseware environment that generates an interface that in itself creates barriers to access.

Courseware and Accessible Authoring Support

Within the context of the research outlined below, the term "courseware" refers to a server-based course management system that allows integration of a complete course site, including password protection, uploaded course materials, interactive activities, tracking of student progress, etc. Typically, the design occurs via a browser interface catering to the non-programmer, using templates and wizards extensively to assist in course content creation. Step-by-step guides support creation of a range of components, including course home pages, bulletin boards, quizzes and marking systems. Core course content and multimedia components, such as images or audio files, are generally created externally in a specialized software program, and imported to the courseware environment.

In recent years the education sector has witnessed an exponential growth in the area of courseware authoring tools to assist in creation of Web-based curriculum and in performing class management tasks. A preliminary study conducted at the Centre for Academic Technology at the University of Toronto (1998) revealed that none of the Web-based courseware tools available at that time addressed accessibility issues in a comprehensive manner. Our subsequent study Inclusion in an Electronic Classroom (2000) v did show improvement, as courseware developers are becoming more aware of accessibility issues.

However, further significant gains can be made if courseware authoring tool developers take steps to eliminate barriers to access in the web pages generated automatically by their programs, as well as those uploaded from an external source. Fortunately courseware tools or applications used to teach at a distance are still in the relatively early stages of development and new versions are released on a frequent basis.

Considerable work in this area has already been completed by WAI in the form of the Authoring Tool Accessibility Guidelines 1.0vi. The premise of the WAI document is that:

the authoring tool be accessible to authors regardless of disability; it produce accessible content by default; and it support and encourage the author in creating accessible content.vii

The associated guidelines and checkpoints in the WAI document provide a useful framework for consideration of the current challenges and the opportunities at hand for courseware authoring tool developers.

Inclusion in an Electronic Classroom Study

The premise of the Inclusion in an Electronic Classroom study parallels that of the Authoring Tool Accessibility Guidelines document:

"To achieve these goals, authoring tool developers must take steps such as ensuring conformance to accessible standards (e.g., HTML 4), checking and correcting accessibility problems, prompting, and providing appropriate documentation and help."viii

It should be noted that the authoring tools referred to in the WAI Authoring Tool Accessibility Guidelines include HTML editors, conversion tools, multimedia production software, in addition to site management and publication tools. However, specific aspects of the document can be applied to the development of courseware authoring tools in particular. Qualitative data collected within the context of the Inclusion in an Electronic Classroom research project highlights barriers that are evident in one or more products reviewed in this study. Courseware programs reviewed include:

  • Blackboard CourseInfo v 4.0 (http://www.blackboard.com/)
  • Web Course in a Box (http://www.wcbcourses.com)
  • Mallard (v 2000b) (http://www.cen.uiuc.edu/Mallard/)
  • WebCT v 2.1 (http://www.webct.com/)
  • Virtual-U v 2.5 (http://www.vlei.com/)
  • Topclass v 3.1.2 (http://www.wbtsystems.com)
[ top ]

Review of Authoring Tool Accessibility Guidelines Compliance

The following summary uses the WAI Authoring Tool Accessibility Guidelines as a framework for analysis of barriers to accessibility and opportunities for improvement. Each guideline is followed by the associated checkpoints and commentary on its applicability within the context of the courseware environment.

Guideline 1. Support accessible authoring practices.

1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]
1.2 Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1]

Compliance with checkpoints 1.1, 1.2 and 1.3 related to two types of HTML authoring. In some cases the products reviewed allow online editing of HTML through a text field in the client browser, allowing the author complete control of the HTML markup. Each of these products also allows the course designer to upload documents authored outside of the courseware tool without alteration to the HTML markup or compromising of the accessibility information inherent in the pages. Hence in each of these processes the author determines how the HTML code will be written or edited.

1.3 Ensure that when the tool automatically generates markup it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]

1.4 Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]

Checkpoints 1.3 and 1.4 are indeed one of the main areas where developers of courseware authoring tools need to focus their efforts. In most cases, material generated through automatic functions or templates cannot be easily edited by the designer, if at all. The designer is dependent on the courseware tool's automated programming to provide an accessible format. Potentially, this may act as a barrier to accessible design. However, with some further effort, it could as easily become an important support in the creation of accessible resources, with no need for specialized knowledge or training on the part of the designer.

Examples of Problematic HTML Generated by Courseware

The following are some specific examples of problematic HTML automatically generated by the courseware studied in the Inclusion in an Electronic Classroom project:

     

  • A serious barrier was discovered in the "Workspace" image map in Virtual-U which does not have ALT text associated with any of the image map hotspots (links). Text equivalents for an image map in the courseware interface should be automatically generated by the courseware. Typically, there is no methodology for the course designer to manually add this information. ix

    •  

  • It was noted in CourseInfo that the product opens a new browser window to present the "Student Help" page without informing the user. This was found to be problematic for both a screen reader user and a student with a learning disability.x

    •  

  • With at least three of the products tested, participants in the study found it difficult to use the Assignment Drop-box. This was particularly true for users who are blind or low vision, but was identified as a potential barrier to a student with a learning disability due to the complexity of the interface. In the case of Top Class and WebCT, users with disabilities found the order of the steps in the process to be illogical, and the terminology to be unclear and ambiguous. While this is not a specific technical issue, clearly the usability for all students may affected.xi

    •  

  • In addition, screen readers are not currently able to correctly read "browse" buttons through the browser interface. Until such time as user agents can perform this function, alternatives, such as emailing the assignment, should be provided.xii

    •  

  • Further problems were noted in the "Electric Blackboard" in CourseInfo, as the new window launched by this utility was smaller than the interface, hiding the form buttons used to enter data or exit the window. In addition, the focus does not move into the text editing area.xiii

    •  

  • The automated layout of the quiz function was found to be cause potential difficulties in two or the products tested, WebCT, and Top Class. In the case of WebCT, the screen reader did not read the entire page, and the participant was required to tab through the links, using the mouse cursor to read the questions. Radio buttons were read as "1" and "2", rather than as "True" and "False." As a result, the subject did not know which button was associated with which choice. In the case of Top Class, the radio buttons proved to be a barrier for a learner with low vision, who had difficulty seeing the interface to confirm which was selected.xvi

    •  

  • Additional concerns were related to the complexity of multi-frame rendering of materials and navigation tools within the courseware environment. While frames are potentially very usable (provided a TITLE is provided), frequently "fallback" methods are note provided. For example, WebCT offers only the text: "Your browser does not support frames" as NOFRAME content. A "noframes" site map might provide an alternative that would benefit all users.xv

    •  

  • Tools for synchronous communication or collaboration and note-taking on-the-fly are also a potential barrier to access for students who are blind or low vision, or those who are limited to keyboard access. This is particularly true if the utility is rendered using Java technologies. For example "chat rooms" in CourseInfo and WebCT were both inaccessible using the keyboard rather than a mouse. If no warning is given that a new window has opened, in combination with an "Exit" button that is generated through Java, a user may become disoriented or frustrated. In both of these products, the chat functions were found to be poorly labeled and non-intuitive, increasing the cognitive load for all users.xvi

At present there are few examples of accessible, text-based chat utililities. A model may be found withinin the "Learning to Learn" course on the SNOW (Special Needs Opportunity Windows) site, hosted by the Adaptive Technology Resource Centre, University of Toronto. Another is available at Naken Chat, providing a telnet based equivalent to a Java chat client. xvii

Another promising avenue is the Java Accessibility API provided by Sun Microsystems. This API allows to create Java applications that can "interact with assistive technologies such as screen readers, speech recognition systems and refreshable braille displays."xviii Sun's web site states that the API toolkit provides "boiler plate" interfaces for UI components that allows third party software, such as a screenreader to "obtain information that is common to all "accessible" components (such as AccessibleName and AccessibleDescription), as well as information that is more component specific (such as AccessibleValue and AccessibleSelection)."xix

White boards present a unique problem for students who are blind or low vision, as they are essentially a "visual" tool. As in any educational setting, accommodations need to be made for students with special needs. In this instance, course designers should be advised that use of this tool should not be required for participation in a course, and other accessbile communciation tools suggested as an alternative.xx

Nevertheless, improvements could be made in terms of warning users that a new window is about to open, and providing an "Exit" button in HTML rather than Java. Keyboard access should also be provided for users who are sighted, but may have a mobility impairment.

Courseware authoring tool developers are in a unique position to control the automated programming and ensure that utilities and program generated content is provided an accessible format. While many of the products have shown improvement over the last two years, there are many further accessibility features that could be integrated into the student interface.

[ top ]

Guideline 2. Generate standard markup.

2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]

Some of the W3C standards recommended in the context of Checkpoint 2.1 may be seen by courseware authoring tool developers as unfeasible because they are not yet well supported by mainstream browsers. Standards mentioned in this section of the Authoring Tool Guidelines include: MathML, XHTML, CSS and SVG. Even if mainstream browsers are unable to render new standards, they facilitate support accessibility by non-standard browsers and alternative output formats. By ensuring that the authoring tool recognizes and preserves elements that are defined in the relevant specification(s), usability may be enhanced for all users, as legacy documents are used in contexts that support newer standards.

2.2 Ensure that the tool automatically generates valid markup. [Priority 1]
2.3 If markup produced by the tool does not conform to W3C specifications, inform the author.
[Priority 3]

Checkpoint 2.2 is another crucial signpost for courseware authoring tool developers. While deprecated elements and nonstandard mark up may produce graphical rendering in a satisfactory manner for visual rendering on mainstream browsers, accessibility issues may arise if content is transformed to an alternative modality based on the users preferences. Common practices include use of tables for layout, a header to change the font size, or BLOCKQUOTE to indent a paragraph. Using markup improperly may create a barrier preventing users with specialized software or preferences from understanding the organization of a page, and navigating through it effectively.

For example, the learner may choose to adapt the material using a user-defined Cascading Style Sheet, or convert the text to an audio output format. While the original visual appearance of the Web page may reflect the hierarchical structure and relationship of various components on the page, this meaning may be lost in alternative formats if elements are formatted using non-standard mark up or deprecated elements. For this reason, it is important that content generated by courseware programs conforms to current HTML standards, or if it does not for any reason, that the user be informed of this fact.

In this study, the output generated by the products tested was not reviewed or analyzed with specific attention to use of standard markup. However, by ensuring that valid HTML is used throughout the documents created by their product, courseware developers can contribute to the accessibility for learners with disabilities and usability for everyone.

Guideline 3. Support the creation of accessible content.

3.1 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority]

In addition to supporting authors in creation of materials using standard markup Checkpoint 3.1 recommends support through tools and prompts that further enhance accessibility for students with disabilities. Consider the case of home page creation tool found in WebCT, which allows designers to enter a banner image for the page. While a title may be added under the image, there is no opportunity to add ALT text for the banner itself, which in all likelihood will contain important information as a graphic including text. A prompt for ALT text could easily be added to the interface.

At the same time, it should be acknowledged that WebCT has taken steps in their most recent release to prompt the author for a text title for navigational icons. This text is used both as ALT text, and as a redundant text link for graphical icons. This type of prompt guides the author to make a more accessible navigation system, with no extra effort or knowledge of workarounds.

3.2 Help the author create structured content and separate information from its presentation. [Relative Priority]

Checkpoint 3.2 suggests that courseware developers use new standards such as Cascading Style Sheets, XHTML and XML to separate information from its presentation. While these technologies are relatively recent, it is anticipated that they will become more and more common, as we are faced with management of large web sites and dynamic, database driven resources. As courseware products keep a database of records of the content to be displayed on the client browser and records for students participating in courses, it is anticipated that these new approaches to authoring will be incorporated in coming releases.

3.3 Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]

At the time that the "Inclusion in an Electronic Classroom" study was undertaken, none of the products tested offered "prepackaged" content. However, recent developments in the publishing industry may increase the significance of this guideline for courseware developers as they are called upon to partner with companies that have traditionally provided educational resources in print formats. Recognizing the need to move digitize educational materials to meet the demands of today's learner, publishing companies such as McGraw-Hill Ryerson have taken steps to offer textbooks as content within a courseware environment. If both the courseware utilities, as well as digitized text, images and any multimedia components are in accessible formats, students with disabilities will make considerable gains in access to education.

3.4 Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

For example, prompt the author for a text equivalent of an image. If the author has already provided a text equivalent for the same image used in another document, offer to reuse that text and prompt the author for confirmation. If the tool automatically generates a "Search" icon, it would be appropriate to automatically reuse the previously authored text equivalent for that icon.

3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3]

Issues related to Checkpoints 3.4 and 3.5 may be very simple, or quite complex, depending on the nature of the graphical or multimedia components included in the course. The products tested in the Inclusion in an Electronic Classroom study all allow the designer to upload files to be used as course content. Examples where alternative equivalent would be required may range from simple ALT text for an image file to captioning or text transcripts for a video or audio file.

As mentioned above, WebCT has demonstrated a model for adding ALT text to simple image icons. However, in the case where a complex media element such as an audio or video file is added to the content area, none of the products reviewed provided a utility or prompt for alternative equivalents to be included. For example, a prompt for entry of a text version of audio components could be included if upload of an audio file type is detected. This is another opportunity to support authors in providing text equivalents.

[ top ]

Guideline 4. Provide ways of checking and correcting inaccessible content.

4.1 Check for and inform the author of accessibility problems. [Relative Priority]

4.2 Assist authors in correcting accessibility problems. [Relative Priority]

4.3 Allow the author to preserve markup not recognized by the tool. [Priority 2]

4.4 Provide the author with a summary of the document's accessibility status. [Priority 3]

4.5 Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets. [Priority 3]

The checkpoints found in the Authoring Tools Accessibility Guidelines related to automation and provision of a validation and repair process are as yet unresolved by courseware products currently on the market. As mentioned previously, Web editing software such as HoTMetaL Pro, and recently Macromedia's Dreamweaver have moved forward by including an accessibility validator and support within the authoring tool. Online tools such as Bobbyxxi, or standalone utilities such as SSB Technologies Softwarexxii or the A-Prompt Tool Kitxxiii demonstrate the feasibility of providing such support.

Developers of at least one of the products tested have indicated plans to incorporate a validation process into the upload utility for content added to their courseware. This strategy would meet the checkpoints found in Section 4, automating the process and at the same time educating designers regarding accessibility issues.

Guideline 5. Integrate accessibility solutions into the overall "look and feel".

5.1 Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]

5.2 Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the most obvious and easily initiated by the author. [Priority 2]

At such time as prompts, validation tools and repair tools are integrated into a courseware product, it is hoped that, as recommended by Section 5 of the Guidelines, the interface will be integrated with the overall look and feel of the program. Accessibility should be seen as an essential part of the authoring process, not as an add on to the program or an "extra" external step in the process. HTML authoring utilities such as Macromedia Dreamweaver's Accessibility Checker extension, or HTML Kit's online validators exemplify the inclusion of such utilities. In the future, courseware products should use models such as these as they move to include tools to support accessible authoring practices.

Guideline 6. Promote accessibility in help and documentation.

6.1 Document all features that promote the production of accessible content. [Priority 1]

6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2]

6.3 In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3]

Checkpoints 6.1, 6.2 and 6.3 indicate that, in addition to automation of accessible design, validation and repair processes through integration of prompts and utilities to support the page author, help and documentation must include explanations of accessibility problems, and should demonstrate solutions with examples. This will support Web authors who may not be familiar with accessibility issues that arise when creating Web content.

Among the products tested, it should be noted that WebCT is the leader in terms of provision of documentation on accessible design in the instructor's "Help" files. Information on disability issues, adaptive technology, design strategies and a resource list is provided through the online help utility, accessed from the designer's browser.xvi Examples and tips have been included in the documentation, as well as specific references to use of these strategies in the WebCT designer interface. This support for authors is a model that other products need to emulate.

Guideline 7. Ensure that the authoring tool is accessible to authors with disabilities.

7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions that are essential to accessibility; Priority 2 for those that are important to accessibility; Priority 3 for those that are beneficial to accessibility).

7.2 Allow the author to change the presentation within editing views without affecting the document markup. [Priority 1]

7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1]

7.4 Ensure that the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1]

7.5 Enable editing of the structure of the document in an accessible fashion. [Priority 2]

7.6 Allow the author to search within editing views. [Priority 2]

This final section of the Authoring Tool Accessibility Guidelines addresses issues related to the designer user interface, emphasizing the importance of providing components and utilities that can be accessed by an author using assistive technology. While it is critical to ensure inclusion of learners with disabilities in development of the student interface, it is equally as important to provide support for the educator, instructor or designer with a disability.

While development of "offline" HTML editing software requires consideration of traditional user interface design standards and conventions, provision of the authoring process through a browser instead requires consideration of Web content accessibility standards. A client browser authoring tool offers many of the access advantages inherent in Web-based delivery, including flexibility in presentation, input and output modalities. Using their browser or adaptive software, the author can enlarge the font, navigate the content and utilize authoring utilities, provided the interface has been designed in compliance with WAI Web Content Accessibility Guidelines.

Given that the Inclusion in an Electronic Classroom study focused specifically on the student interface, no comprehensive evaluation of this aspect of courseware product designer interfaces is currently available. Perhaps future iterations of our courseware accessibility review will allow us to examine this important issue. [ top ]

Summary

The challenges in evaluating the accessibility of courseware authoring tools are much the same as those faced by those involved in the process of developing those same tools. The formidable task of keeping up with changes in Web technology and has been described by accessibility expert Skip Stahl (CAST), and others, as being similar to "trying to change a wheel on a moving car."xxv In addition, improvements to adaptive technology capabilities and the frequent new releases of courseware products, add to the complexity of the process.

Courseware authoring tool developers face challenges, but also have a great opportunity to improve access for all learners. Given that content developers and instructors rely on these tools to create and delivery content, they play an essential role in ensuring the accessibility of the Web. As noted in the Authoring Tool Accessibility Guidelines it must be recognized that the Web is "both a means of receiving information and communicating information," and "it is important that both the Web content produced and the authoring tool itself be accessible."

Endnotes:

i WAI Web Content Accessibility Guidelines 1.0 from Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) (http://www.w3.org/TR/WAI-WEBCONTENT/)

ii Bobby online validation from CAST (Center for Applied Special Technology), (http://www.cast.org/bobby/)

iii SSB Technologies ( http://www.ssbtechnologies.com/software/)

iv A-Prompt Tool Kit from the Adaptive Technology Resource Centre, University of Toronto (http://aprompt.snow.utoronto.ca)

v Inclusion in an Electronic Classroom (http://www.snow.utoronto.ca/initiatives/inclusion.html)

vi Authoring Tool Accessibility Guidelines 1.0 from WAI of W3C (http://www.w3.org/TR/2000/REC-ATAG10-20000203/)

vii Authoring Tool Accessibility Guidelines 1.0 from WAI of W3C (http://www.w3.org/TR/2000/REC-ATAG10-20000203/)

viii Inclusion in an Electronic Classroom - Proposal (http://snow.utoronto.ca/initiatives/oltproposal.html)

ix Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1] (http://www.w3.org/TR/WAI-WEBCONTENT/#gl-provide-equivalents

x Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2] ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-interim-accessibility)

xi Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 14.1 Use the clearest and simplest language appropriate for a site's content. [Priority 1] (http://www.w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-comprehension)

xii Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1] http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c

xiii Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3] For example, in HTML, do this for TEXTAREA and INPUT. ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-interim-accessibility)

xiv Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2] ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-interim-accessibility)

xv Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2] For example, in HTML, use NOFRAMES at the end of each frameset. ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-new-technologies)

xvi Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] (http://www.w3.org/TR/WAI-WEBCONTENT/#gl-own-interface) Checkpoint 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2] ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-device-independence)

xvii Learning to Learn chat utility (at: http://snow.utoronto.ca/cgi/Chat/chat.cgi) and Naken Chat (at: http://nakenchat.naken.cc)

xviii Java Accessibility - Sun Microsystems Inc. ( http://java.sun.com/j2se/1.3/docs/guide/access/)

xix Java Accessibility - Sun Microsystems Inc. ( http://java.sun.com/j2se/1.3/docs/guide/access/)

xx Reference: WAI Web Content Accessibility Guidelines 1.0 Checkpoint 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.] (http://www.w3.org/TR/WAI-WEBCONTENT/#gl-own-interface) Checkpoint 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2] ( http://www.w3.org/TR/WAI-WEBCONTENT/#gl-device-independence)

xxi Bobby online validation from CAST (Center for Applied Special Technology), (http://www.cast.org/bobby/)

xxii SSB Technologies ( http://www.ssbtechnologies.com/)

xxiii A-Prompt Tool Kit from the Adaptive Technology Resource Centre, University of Toronto (http://aprompt.snow.utoronto.ca)

xxiv WebCT Help Files for Version 2.x and 3.x can be downloaded as PDF files at: ( http://about.webct.com/v2/help/)

xxv Skip Stahl (2000), quote from discussion at AHEAD conference as co-presenters of seminar on Accessible Curriculum Design. [ top ]