Technical standards for digital education: 21C Content and accessibility demonstrator project outcomes report

Owen ONeill & Kristena Gladman, eWorks

Table of Contents

© Copyright 2010 University of Southern Queensland

---

1. Background

This activity was funded through the Technical Standards for Digital Education project: a program of work funded by the Department of Education, Employment and Workplace Relations (DEEWR) to support the Australian Government's Digital Education Revolution (DER). The project is working with the Australian school education community to implement technical standards relevant to the Australian schools digital environment. The technical standards project also provides mechanisms for the Australian school education community to influence the development of global technical standards.

The standards work in the project is split into seven themed activities: 21st Century Curriculum Content, Engage with W3C Accessibility Guidelines, Curriculum Description, Lesson Plans, Learning Content Discovery and Exchange, e-Portfolio technology, and Integrated Learning Environments and 21st Century Learning. Each of these themed activities is supported by a focus group of experts from the schools sector and beyond. This demonstrator work was primarily overseen by the 21st Century Curriculum Content and W3C Accessibility Guidelines focus groups.

2. Project outcomes

The purpose of the demonstrator activity was to work with a minimum of three existing authentic digital resources and investigate the following challenges facing Australian schools:

• Outcome 1: Understanding accessibility compliance requirements and challenges
• Outcome 2: Exploring integration of collaborative Web 2.0 technologies with e-learning content.

3. Methodology

Sourcing content

The project team worked with The Learning Federation to source e-learning content to use in this project. The Learning Federation (TLF) maintains a large national collection of e-learning resources for schools in Australia and New Zealand, and oversees rigorous development, testing and quality assurance processes. An e-learning resource suitable for VET in Schools learners was also selected which was produced by the Australian Flexible Learning Toolbox activity. The content is a mixture of HTML, Flash, images, video, audio and text.

Analysing the learning design

An instructional designer (ID) analysed the resources together with applicable supplementary materials such as lesson plans to determine how any proposed changes would impact the learning design of the content. The ID’s expertise was also used to identify how and where collaborative functionality would be best utilised to benefit learners and create an appropriate lesson or unit of work. From an accessibility viewpoint, our instructional designer’s expertise facilitated a better understanding of how the content could be modified to meet WCAG 2.0 requirements to achieve equivalent learning outcomes for users with disabilities.

Executing technical modifications

A technical team based at eWorks was responsible for planning and executing modifications to the content to add collaborative functionality and meet WCAG 2.0 requirements. This process was documented, and key outcomes are outlined in this report.

Testing

The development team undertook testing of the e-learning content against WCAG 2.0 and IMS Common Cartridge requirements using both manual and automated testing processes. Part of this conformance testing process was also to evaluate the testing processes themselves.

Documenting outcomes

This report documents the initial outcomes of this work. The findings from this work, and any recommendations agreed by the focus groups will be incorporated into the final reports for each activity.

4. E-learning content outputs

*WCAG 2.0 requirements have been implemented in the first 4 screens of the learning object only

5. Understanding accessibility compliance requirements and challenges (Outcome 1)

A new international standard for accessible web content the ‘Web Content Accessibility Guidelines 2.0’ (WCAG 2.0) was endorsed for implementation by the Australian Government Information Management Office (AGIMO) in February 2010. AGIMO indicated that web content developed with government monies must be compliant to WCAG 2.0 “level A” success criteria by 2012 and “level AA” by 2015.

A position on WCAG 2.0 from the Australian Human Resources Commission (AHRC) is also expected in the forthcoming months. In the VET sector, the Australian Flexible Learning Framework released a report on the potential impact of WCAG 2.0 on e-learning content in February 2010.

With the transition to WCAG 2.0 now officially underway, the Australian schools sector will also need to consider the impact of the transition, ensure compliance for new e-learning content, and plan for maintenance of existing content.

To explore the potential impact of WCAG 2.0, we selected a number of existing schools-focused e-learning resources and modified them to comply with WCAG 2.0 requirements.

WCAG Background

WCAG 1.0 was adopted as the W3C resolution in 1999 and adopted by the Australian Government and Australian Human Rights Commission in 2000. Subsequently it was expected that all content developed by projects funded or owned by the government, produced for Australian users or hosted would meet the requirements of WCAG 1.0.

At the end of 2008, the W3C adopted the Web Content Accessibility Guidelines version 2.0 (WCAG 2.0) as the new recommendation for web content accessibility. The release of a new version of the WCAG specification prompted examination and exploration by governments and developers worldwide and resulted in a need to examine what impact the implementation for WCAG 2.0 will have upon content creators, teachers and students in Australia.

WCAG 2.0 documentation and best practice examples

There is extensive WCAG 2.0 documentation available and in fact one of the major criticisms levelled at WCAG 2.0 is that there are too many verbose documents and it can be difficult to find the information you need.

It is possible to find information if you refer to the W3C WCAG 2.0 Overview and its outline of the available documentation. The documentation is divided into technical, educational and transitional sections and covers in detail the rationale for WCAG 2.0 using the POUR (Perceivable, Operable, Understandable, Robust) principles. There is also a comparison with WCAG 1.0, mapping the requirements from one specification to the other.

Several accessibility groups and proponents have also produced documents that map WCAG 2.0 requirements to WCAG 1.0. Together with the official documentation, this information enabled us to assess potential changes to current development processes and practices, and how much effort may be required for future development. There is however, a significant gap in terms of documentation about how to make existing materials WCAG 2.0 compliant. Existing documentation does not specifically address converting content built for WCAG 1.0 to WCAG 2.0, and there is no evidence that there has been an investigation of the effort required.

Resources selected for this project

The resources assessed for conversion to WCAG 2.0 compliance include an HTML based learning resource, a Flash learning object and an MPEG4 animated clip. This content was of a high quality to begin with and was sourced from The Learning Federation and the VET Flexible Learning Toolboxes project. The TLF content meets all accessibility requirements as per a standing agreement between TLF and the Australian Human Rights Commission (AHRC) (formerly Human Rights and Equal Opportunity Commission - HREOC)¹. Where technical changes were required to meet WCAG 2.0 requirements, we also considered the impact on the learning design in collaboration with an instructional designer.

Example 1: Show and tell: that cat

Show and tell: that cat is an Adobe Flash object that was built in 2003/4 for Flash Player 6 in ActionScript 1.0. The original object had a good level of base accessibility and met all TLF mandatory requirements, but was not built to meet any specific TLF accessibility profile. This object was selected because with advances in Flash accessibility we thought there was potential to make it meet WCAG 2.0 requirements with minimal impact on the learning design.

Flash-based content cannot be checked with automated tools and as Flash is not assumed to be accessible, the WCAG techniques are not specifically framed for Flash content. Prior to testing the Flash object, the techniques for each success criteria were assessed and an equivalent Flash ‘technique’ for each criteria was identified and documented. Subsequently the Flash content was evaluated against the checklist with reference to those Flash specific techniques.

Modifications were made to the first four pages of the learning object to address the accessibility issues identified. The following changes were made:

• Introduction of video controls
• Removal of the auto play function of the animation to make it user controlled
• Removal of the replay function as it was superseded by the audio controls
• Conversion of all static text boxes to dynamic text with applicable text rendering
• Inclusion of all dynamic text areas in the read order, ensuring that the read/tab order remained logical
• Addition of assistive descriptive text to all MSAA objects to provide users of screen readers providing synthetic speech or electronic Braille output with scaffolding
• Correction of the keyboard trap created by the embed syntax
• Introduction of closed captions describing the cartoon, the captions are only accessible with assistive devices.

Appendix 1 provides a complete list of related WCAG success criteria and the modifications made to this content to address the success criteria.

Learning Design considerations

The primary activity in Show and tell: that cat involves the user providing a recount of the information contained in an animation. The original LO was not built to provide access to users with any form of sight impairment as the cartoon contains vital information that is only conveyed visually. The reliance on conveying information visually means that the original LO fails to meet a number of WCAG 2.0 success criteria including those for guidelines 1.1 and 1.2 related to text alternatives for time-based media. These issues could be addressed through several techniques:

• a full text alternative
• user controlled, screen reader accessibility and captions displayed onscreen
• Hidden screen reader accessible captions that automatically play on activation of the video controls but are not visible to sighted users
• an audio alternative providing a full description.

The ID was asked to determine the most educationally suitable option and noted that an alternative literacy outcome could be achieved by vision impaired users if the information was conveyed in a format that could be accessed by a screen reader (outputting synthetic speech or electronic Braille). The full text alternative and onscreen captions were deemed to be inappropriate because they would decrease the value of the activity for sighted users (it is essential that the user derives the applicable information from the animation).

As a result we considered the two remaining options, the first being screen reader accessible captions that were hidden onscreen (feasible because there is no audio for the animation and other users would not need to see captions), the second was a full audio description of the animation. We proceeded with the first option because the second would potentially have required a text based alternative of its own, which could have been accessed by sighted users.

Technical considerations

Whilst the existing keyboard access and TAB order in the original LO is quite reasonable, it had to be reworked to include all text as Flash’s TAB and read order are now uniform. TLF content from 2004 onwards uses dynamic text boxes and embedded character outlines with text drawn in from XML but Show and tell: that cat predated those requirements and used static text boxes that are not recognised as text by MSAA so all of the text areas needed to be converted to dynamic text boxes (with embedded font outlines to ensure that the object still scaled).

In the majority of the object, the user controls the content and their progression but the original automatically played the video and didn’t have any controls for the animation. The auto play was removed, as was the replay control and a set of video controls was added. Colours used in the object are compliant with WCAG 1.0 and 2.0 requirements so no change was required. A number of the significant changes are only visible if accessed with a screen reader. The logical operation of existing functionality was assessed to ensure each element would be logical to someone who has not seen them. Figure 1 shows the text instructions that are available to users to each piece of functionality using a tool called the Accessible Explorer.

In testing the Flash object with two screen readers, JAWS and NVDA, differences in the way the two products navigate and interpret the content added further complexity to the task of meeting WCAG 2.0 requirements and making it user-friendly. This was an issue that we were not able to fully resolve, and certainly requires further consideration.

Example 2: Lift off: teacher eater

This content is a video containing a voice-over story. It is a single MPEG4 file.

Learning design considerations

As this content is a single video file, the technical modifications required to meet WCAG 2.0 conformance were not deemed to impact the learning design.

Technical considerations

The original MPEG4 has video controls and is accompanied by a description and educational value statements, but doesn’t have any form of captioning. To add the playback controls with user controlled timed captions, the animation was converted to Flash video and a player added (see Figures 2 and 3). For cases where the player does not expose the captions to the screen reader, a full transcript has also been supplied.

Example 3: Sample and test water sources and quality

This resource was originally developed as a VET Toolbox learning object. It teaches students about how to take water samples and test water quality. It may be relevant for VET, VET in schools and High School science students.

Learning design considerations

Again the modifications required for the content to be made conformant to WCAG 2.0 requirements did not impact the learning design.

Technical considerations

The content was built to meet WCAG 1.0 Priority 1 requirements plus an additional five Priority 2 checkpoints². It is predominantly HTML/CSS content with some XML, Flash, still images and PDF content. The selected pages were analysed with AChecker and one issue of definite non-compliance was identified – there was no close mechanism for the series of HTML glossary pop-up windows (Figure 4 shows the fixed version). In addition a number of possible issues were flagged but after working through them manually, these issues were either addressed or deemed not applicable.

The HTML content was tested with the AChecker web accessibility evaluation tool produced by the University of Toronto’s Adaptive Technology Resource Centre. The tool flags elements that it cannot test and it was useful to compare the potential issues it flagged with the results of our manual evaluation, which was conducted using the W3C ‘How to meet WCAG 2.0’ customisable checklist (which displays the sufficient techniques for all of the applicable success criteria) and the AIS Toolbar.

Evaluation and summary

WCAG 2.0 is a significant improvement on WCAG 1.0 from an implementation perspective, and the migration to the new requirements should bring benefits to all learners. The technology-neutral approach and greater options for testing conformance should also be of benefit to e-learning content developers, but careful planning is required to ensure a smooth transition. Our experience with this demonstrator content indicates that there are a number of implications for schools e-learning content.

Impact on content developers

Content developers will need support to transition to the new standard, given that the current documentation available for WCAG 2.0 is verbose and generic. Implementation guidance should be developed that is specific to the Australian schools context and the requirements specified by the Australian government. With the development of good quality guidelines and the timeframes specified by the Australian government, developers who are experienced with WCAG 1.0 requirements should be able to make the transition to WCAG 2.0 successfully. Developers who are unfamiliar with existing accessibility requirements will naturally require more support.

Impact on existing content

Our experience highlights that the effort required to make existing e-learning (or web) content conform to WCAG 2.0 is particularly dependent on:

• the type of content (HTML, Flash, Video, etc)
• the age, version of the authoring environment and script language/code
• the availability of documentation and source files for the content
• the current level of conformance to WCAG 1.0.

Whilst in theory all web content produced since 2000 should meet minimum WCAG 1.0 requirements, actual adherence to WCAG 1.0 is variable and dependant upon the age of the content, the content creator and the technologies used.

The majority of our efforts in this activity were focused on the Flash learning content, which required much greater effort than was previously anticipated. This was because of the need to include screen reader support, which required much of the existing accessible functionality to be reworked.

Based on our experiences, the effort to upgrade existing Flash content to meet WCAG 2.0 requirements would be considerable, particularly for older Flash content. In contrast, HTML/CSS based e-learning content already conforming to WCAG 1.0 should be reasonably straightforward to convert to WCAG 2.0 given that developers have an understanding of WCAG 2.0 and access to user-friendly documentation, although time and effort is still required.

Impact of user-generated content

Although not directly addressed in this activity, the increase in user-generated content on the web through the use of collaborative Web 2.0 tools and services should also be considered by Australian jurisdictions and governments. As more and more teachers and learners adopt web-based collaborative tools and social networks, the tools and subsequent content produced should also be considered from an accessibility perspective. New approaches to meeting accessibility requirements will need to be considered in such distributed environments.

6. Exploring integration of collaborative Web 2.0 technologies with e-learning content (Outcome 2)

There is growing demand in schools for utilising Web 2.0 style collaborative functionality in learning and teaching practice. There is also a massive and ever growing range of tools available to teachers to use with their learners, which also presents a number of unresolved issues and challenges for those wanting to utilise such tools.

Australian and international research indicates concerns over the safety and security of using Web 2.0 tools is a significant barrier to implementation in schools³. Teacher, parent and government concerns over access control, computer network security, ownership and privacy also need to be addressed before the significant benefits that collaborative web 2.0 tools offer can be realised.

This activity evaluated a specification called IMS Common Cartridge as a way of integrating Web 2.0 collaborative tools and functionality with e-learning content. We converted existing e-learning content to the specification and experimented with embedding collaborative functionality.

IMS Common Cartridge background

The IMS Common Cartridge (IMS CC) specification was developed by IMS Global as a way of packaging and deploying e-learning content. Rather than being a completely new specification, IMS CC actually uses a number of existing IMS specifications and provides more prescriptive information on their implementation to give more certainty to software developers and implementers. An IMS CC cartridge is a portable package of content that can be imported and deployed into software such as a Learning Management System (LMS).

Like an IMS Content Package, technically a Cartridge is a zip file containing e-learning content and related XML files that contain descriptive information about the content (metadata) and information about the structure and navigation of the content. When the zip file is imported into software such as an LMS, the XML code is interpreted and a resulting navigation structure is created for the user.

Some of the functionality that IMS CC enables beyond a simple IMS Content Package includes:

• Integration of assessment functionality built into the e-learning content (using the QTI specification)
• Integration of content and/or services located on the web (including for example Web 2.0 collaborative services)
• Deployment of discussion board functionality which is automatically set up by the LMS when the IMS CC cartridge is imported.
• Deployment of access controls for content including restricting access to the entire cartridge, or specific parts of the content.

Software support for IMS Common Cartridge

Reflecting the relative newness of the IMS CC specification at the time of writing (April 2010), there is still a limited number of software tools that support the IMS CC specification. This situation is improving, and there appears to be some current momentum with software vendors adopting the specification.

Content creation tools

There are a number of tools that claim IMS CC conformance. We considered the following freely available tools: eXe, MIR Common Cartridge System and Common Cartridge Builder.

Conformance testing tools

For testing IMS CC content, IMS provides a Test System which performs a similar function to the ADL Test Suite for SCORM content. We found the Test System to be very useful, as it tests the content against the IMS schemas as well as running a number of other checks (defined with Schematron). The error messages do require knowledge of the specification, however they seem reasonably clear.

Deployment tools

The IMS CC format is not specific to any one software vendor or system, however it does require software that can interpret and render it to the user. Current support for playing/executing IMS CC content is also still somewhat limited, but the list of Learning Management Systems (LMS) that support IMS CC is growing. Moodle 1.9+ (with a patch), Moodle 2.0 and ATutor (which seems to have little market penetration in Australia) have support for IMS CC content. Blackboard has been slower to provide support for the specification, but recently made an announcement about it’s work on IMS CC import functionality.

International activity

The ASPECT project is documenting information on tool support for IMS CC, which provides useful information for content developers, and a partnership with this project would be valuable for Australia. The IMS Common Cartridge Alliance is run by IMS Global and provides members with access to the specification, documentation, testing software and example content.

Example: Sample and Test Water content

This e-learning content teaches students about obtaining water samples for analysis. Technically, it is largely HTML/CSS content with some Flash and still images. The team selected this resource because an initial analysis of the content revealed that it was particularly appropriate for embedding collaborative functionality.

Learning design considerations

Although there is no collaborative functionality in the original content, working with an instructional designer it was apparent that collaboration was often implicit in the learning design. Figure 5 shows an example of a reflection task which asks learners to consider questions relating to water sampling and testing such as “How can we dispose of samples safely after testing?”

The content shown in the example in Figure 5 does not provide the learner (or teacher deploying the content) with any functionality to record answers to such questions or to discuss this topic with others. In practice, this would be expected to happen in class, however it is also possible to utilise a discussion board or wiki to share and capture such discussions.

Technical considerations

There were a number of types of Web 2.0 functionality identified including:

• Blog functionality to enable the learner to progressively and document their water sampling activities
• Discussion board functionality to provide an asynchronous collaborative environment
• An interactive map to identify water sampling sites
• A number of external web-based services were added to the content including an interactive map, wiki and blog.
• Discussion board functionality was added, which was pre-populated with discussion topics of relevance to the content
• Authorisation controls were added to the teacher resources.

This functionality was successfully implemented in the content and made available via the resultant IMS CC cartridge. For creating the cartridge, we utilised a tool called the SCORM2CC conversion tool, which we found was effective and easy to use. However, once the content was in IMS CC format, the freely available tools we sampled had limited functionality and our developer preferred to directly edit the XML code. We tested the content in the Moodle LMS (version 1.9.7 with the IMS CC patch). The content imported and rendered without issue, however the LMS was sensitive to minor errors in cartridges.

Evaluation and summary

The IMS CC specification enables external web-based content to be linked to directly from the menu structure of the cartridge. This means it is easier to link/embed Web 2.0 functionality into e-learning content, but does require teachers to have access to user-friendly tools to customise functionality and resources for their learners. As discussed in the previous section, tool support remains an issue for the specification at this stage. The use of dynamic web-based content also raises issues of longevity as such resources may cease to be available after the content is published.

The use of such dynamic/collaborative functionality could also present a barrier for teachers without access to an LMS (eg. needing to use the content directly in a browser). We believe however that it should be possible to create IMS CC content that renders and can “degrade gracefully” (eg. provide a limited set of functionality) for users that only have access to a web browser. Such an approach would need to be specifically considered and planned for during the content design and development phase.

From an access and authentication point of view, the specification also offers some functionality to block access to either a part of the cartridge, or the cartridge as a whole. This is beneficial for teachers and developers in protecting content. However, it does not prevent direct access to the web-based resource, which still needs to be addressed as a separate issue.

7. Conclusions

As previously stated, there were two key outcomes expected of this work:

• Outcome 1: Understanding accessibility compliance requirements and challenges
• Outcome 2: Exploring integration of collaborative Web 2.0 technologies with e-learning content.

Outcome 1: Understanding accessibility compliance requirements and challenges

The schools sector has a significant body of existing content developed and owned by the commonwealth, state and territory governments, ministerial companies, initiatives, schools and individuals that will be affected by the implementation of WCAG 2.0. The extent to which content will need to become WCAG 2.0 compliant will be dependent upon the scope of the transition plans outlined by AGIMO in July and any subsequent adoption of WCAG 2.0 by the Australian Human Rights Commission (AHRC). The following factors directly impact the ability to modify e-learning content to conform to WCAG 2.0 including:

• the type of content (HTML, Flash, Video, etc)
• the age, version of the authoring environment and script language/code
• the availability of documentation and source files for the content
• the current level of conformance to WCAG 1.0.

We found that the Flash content we worked with took a significant effort to update to WCAG 2.0 requirements due largely to variations in different versions of Adobe Flash and the relative lack of information about developing Flash content to meet WCAG 2.0 requirements. Differences in the way different screen reader software interprets the content also caused numerous problems. These two issues could present significant barriers to developers trying to create accessible e-learning content. More targeted support materials are required for e-learning content developers.

Outcome 2: Exploring integration of collaborative Web 2.0 technologies with e-learning content

The IMS CC specification is a suitable approach for packaging e-learning content with collaborative web-based functionality in a portable reusable format. The IMS CC specification allows web-based services to be more easily integrated with e-learning content compared with standard IMS CP, as external content can be linked directly from the navigation structure. However, we believe there would be some barriers to utilising IMS Common Cartridge content with Web 2.0 collaborative functionality in Australian schools currently. These barriers include:

• Tool support for the IMS CC specification
• Longevity of linking to web-based functionality and services
• Authorisation and access considerations.

The first barrier is specific to the IMS CC specification, while the other two are more generic.

Teachers would require access to user-friendly software to create and modify content to adequately meet the needs of their students. Currently, tools support for the IMS CC specification is still somewhat lacking, although this situation seems to be improving.

The issue of longevity of links to web-based services needs further consideration, and this is not an issue that is directly addressed by the IMS CC specification.

The access control functionality in the specification may be useful for supporting teachers to control learner access to web based content and services. However, it does not protect the content or services themselves, and access and authorisation concerns would still need to be addressed separately.

Appendix 1: Show and tell: that cat accessibility issues identified

The Technical Standards for Digital Education project is funded by the Australian Government's Department of Education, Employment and Workplace Relations (DEEWR).

---