Elearning with AICC

AICC cross domain tracking


The AICC standard was a breakthrough in online learning. With the AICC standard the communication between items of learning content and systems that managed that learning (Learning Management Systems – LMSs) was standardized. This came from the need in the airline industry for a method of allowing different airlines to use common standards for online learning, and hence the name AICC – Aviation Industry CBT Committee. To explain that a little further – CBT stands for Computer Based Training. Way before there was online training there was Computer Based Training too – usually distributed on floppy disks, or later on CD-ROM.

Nowadays it is rare enough to hear about AICC as the SCORM standard really took off with version 1.2 and since 2015 the AICC group ceased to exist. Yet even with the rise of SCORM and the end of the AICC as an active body, there is one part of the AICC standard which is still extremely useful to online learning – its ability to deal with the cross domain problem that has plagued LMS developers and e-learning managers for decades.


The LMS cross domain issue comes about when you have more than one system in place and you want them to talk to each other. That is a relatively easy thing to do on the network level – it is the whole basis of how the internet works: one server talks to another, passing the information you need to you, pulling and pushing information to facilitate interactions.

The problem comes when you have a JavaScript based protocol for e-learning such as SCORM 1.2. Internet browsers are built with the privacy and security of the person using them in mind, and to help achieve this they allow information to be passed by JavaScript between pages on one website (domain) but do not allow this information to be passed between different domains. At a very simple level, a lot of eLearning works by having a frameset of pages – that is, a number of different pages in one –  where one frame holds the learning content and another holds the functionality that communicates with the Learning Management System (LMS) to store tracking, scores, etc.

A lot of eLearning structures work by having a frameset of pages – that is, basically, a number of different pages in one –  where one frame holds the learning content and another holds the functionality that communicates with the Learning Management System (LMS) to store tracking, scores, etc. This works well in most cases because those frames can ‘speak’ to each other, but when the different frames (pages) are on different domains the browser will (correctly) prevent them passing information between the two domains.

Side note: Why do browsers stop cross domain scripting? They do so to prevent a website you visit being able to carry out actions on your behalf on other websites you visit (like say transferring out of your online bank account) and they prevent websites being able to read your data related to different websites (think saved passwords, cookie data, etc.).


In 1998 the AICC standard added a web interface called HACP (HTTP-based AICC/CMI Protocol). AICC’s HACP can work across different domains because it uses HTTP requests rather than JavaScript/ECMAScript requests as SCORM does. That is simplifying the solution, as many AICC instances actually overcome it with signed Java Applets too, but in essence, they don’t need to.

With AICC you have two call types: getParam and putParam. They are used similarly to SCORM calls getValue and setValue, one for getting a value and one for setting a value. The difference between the two standards is in where and how they call. SCORM is reliant on finding the LMS API relative to itself in JavaScript, and so is unable to get or set values if the target is on a different domain. AICC HACP, however, is able to make the call to a totally different location altogether – it does not even need to be visible in the browser stack.

I have made a lot of different cross domain scripting solutions to cross domain communication using AICC, AICC and SCORM hybrids, and even ones to bypass the limitations of SCORM 1.2 (although to do so you break the ‘self-contained’ idea of SCORM because you do need server side scripting). If you would be interested in seeing an article outlining how any of those can be achieved let us know in the comments and we will try to provide an article that solves your problem.