view printer-friendly version (opens in new window)
Matching content to learners
The one year old IMS Accessibility for Learner Information Profile (ACCLIP) specification allows you to store the accessibility preferences of learners in a flexible way. Which is handy, but a less than complete solution until the content a learner wants to look at can be matched to those preferences. With the new IMS Accessibility for Meta-Data (ACCMD) spec, that circle is now being closed.
The principles behind the AccessForAll profile are refreshingly simple. A learner uses a wizard to capture how learning content needs to look, sound or feel for her to be able to use it. If necessary, that can be specified by context.
Content can be authored for a variety of different needs, with alternatives modalities rolled in where it's needed. All the content then gets marked up for its accessibility properties in the exact same terms as those of a learner's ACCLIP preferences.
Using an IMS defined 'ACCLIP-ACCMD Check' by the Virtual Learner Environment (VLE) the learner is then presented with the right content. This is done either by separating or hiding content in search return lists that she won't be able to access, or by finding good alternatives for a particular piece of content or by transforming or controlling the content in a way that suits her preferences.
A deaf learner, for example, can specify that she prefers visual over auditory representations. After that's recorded, searches will present learning objects that contain videos without captioning as inaccessible. Or present equivalent bits of content or whole learning objects with just text that someone else may have made. Or, if the learning object does have captions, make sure that these are presented automatically.
Not that this is restricted to learners with disabilities; a learner with no hearing impediments may still want to specify a context where she wants content to be visual or textual only: a computerlab where the PCs don't have speakers or easily accessible earphone sockets, for example.
Technically, the new bit is a combination of the ACCMD metadata spec and a workflow description of how ACCLIP preferences are to be matched with ACCMD metadata. ACCMD itself has both an information model and a binding of its own, even though formats suitable for use with the popular IEEE Learning Object Metadata (LOM) and qualified Dublin Core specs are also available.
Delving a little deeper, one curious use of the whole AccessForAll profile has already appeared: enforcing and controlling house styles across all content used in an organisation. This works because there is no requirement that the entity for which an ACCLIP profile is compiled needs to be (a) human, combined with the facility for creating several contexts. I.e. many aspects of a housestyle can be captured in an ACCLIP profile and rolled out as the default for everyone. Individual contexts would still take precedence over a corporate one, of course.
From a strategic business point of view, this certainly has its attractions: the requirement to be able to easily apply a house style across all e-learning content is a long held ambition of many. Making content accessible is a legal requirement. Solving both in one go is a bit of a win - win, then.
Likewise, from the accessibility experts point of view, anything that is more likely to have the one accessibility metadata spec implemented widely is desireable.
Even technically, there is something to be said for concentrating all run-time content modification in one spec, and therefore one function. But it still smells of a hack. It may not have any immediately obvious drawbacks, but using a technology for a purpose for which it wasn't designed has a habit of running into difficulties sooner or later. It's certainly hard to imagine how style enforcement can go much beyond font and colour control, without seriously mangling the semantics of ACCMD. Better that than vice versa, though.
As ACCMD is a public draft, the principles are pretty much fixed, but the details may change as bug fixes come in.
All IMS accessibility specifications and their parts can be seen or downloaded from the IMS accessibility page.