Skip to end of metadata
Go to start of metadata

Purpose

This project will involve implementing the AccessForAll metadata standard in ATutor, used to display content based on user preferences. This will involve implementing a utility to define user preferences, and/or import a user preference string created in another ACCLIP (Accessibility for Learning Information  Package) compatible System, such as the TILE Learning Objects Repository or the Web4All system, both developed by ATRC at the University of Toronto, as well as adapting the ATutor ContentManager class to implement the ACCMD (AccessForAll Metadata) which retrieves user specific content based on their ACCLIP preferences.

AccessForAll Standard

This project is being lead by the Computer Science Department at the University of Bologna

ACCLIP Implementation

Main issues:

  • editing the ACCLIP. New TABs will be added at the Preferences page, in order to allow users to declare preferences related to ACCLIP. Such a new part of the user's preferences could be manage as the current preferences are (saved as a string in the database and then "translated" in all the necessary information, see preference.php and vitals.inc.php). The new TABs will be (see the attached file "atutor_acclip.txt"): DISPLAY, CONTROL, CONTENT and SUPPORT TOOLS (when they are available and, moreover, when the instructor has set them). In the DISPLAY TAB the students will declare preferences related to text dimensions, colors and to any characteristic is involved in the appareance of ATutor Web pages. In the CONTROL TAB the students will declare preferences related to the visibility of single parts of the structural navigation (breadcrumbs, menu, etc) and they can choose if show or not such parts. In the CONTENT TAB the students will declare preferences related to the type and the format of content they prefer (these preferences will be mainly involved in the ACCMD matching). In the IMS ACCLIP DTD there are similar nodes (with the same name), but with different child nodes, or different parent node. This structure will be kept in the XML-based version of the ACCLIP, but will be shown in a different way in the ATutor editing Web page.
  • matching ACCLIP and ACCMD. It will be necessary to unserialize the ACCLIP string (see serialize/unserialize), in order to obtain a XML-based "version" of the ACCLIP. Certainly a double parsing should be implemented, in order to analyze ACCLIP and ACCMD XMLs, to find the resources which better match users' needs and preferences and to finally construct the related content. 
  • importing an external ACCLIP.
    • NOTE 1: the ACCLIP <accommodation> element defined below extends the <eligibility> element (defined by the IMS LIP). The <accommodation> element allows to specify accommodations for which a learner is eligible when using a learning object, particularly a test. Testing accommodations are generally approved in advance of administering the test. This model includes an element called <requestForAccommodations> which stores the student's request, and a separate element called <accommodationDescription> which stores information about the accommodations that the authorizer has agreed to; them may be the same as or different from the request. The idea is to keep all this information even if ATutor will not take into account in the actual next implementation (in order to maintain formal compliance with the ACCLIP standard specification). In the future, it could be necessary to cancel (or maybe just to edit) the content related to <accommodationDescription>, because of it could be different (certainly another instructor will accord accomodations to the student). 
    • NOTE 2: ATutor allows to set a certain number of preferences related to the navigation structure (breadcrumbs, menu, and so on). Also ACCLIP allow to define them. The idea is to create a CSS with such user's preferences and add it (as the last one, so the declared rules overwrite the rules in the previous stylesheets) in the <head> of ATutor Web pages. 

Still thinking about it.

ACCMD Implementation

Main issues are

  • editing resources types and relationships between primary resouces and their equivalent alternatives;
  • exporting content;
  • importing content;
  • matching ACCLIP.

Editing resources type and relationships 

Authors will be involved in the content creation and editing phases.

One solution could be to provide another TAB (as well as "Content", "Properties", "Glossary Terms", "Preview" and "Accessibility") in the "Edit Content" page, in which the author might specify the type of the primary resouces and, eventually, add equivalent resources to the primary ones (also specifying the type).

Maybe, portions of text could be identified (by the author) as primary resources (???), so the author could add non-textual alternative resouces as equivalent ones.

Maybe a new sort of mark-up should be defined in order to describe resources types and relationship between primary resources and their equivalents. (Still thinking about it).

It is necessary to enhance and extend editor/edit_content.php, include/lib/editor_tabs_funcion.inc.php and to add a file similar to html/editor_tabs/edit.inc.php, html/editor_tabs/properties.inc.php, html/editor_tabs/glossary.inc.php, html/editor_tabs/preview.inc.php, html/editor_tabs/accessibility.inc.php.

The name of this new tab could be "Alternative content". It will show the primary resources as a whole and for each one it will be possible to define the type, to edit and manage the alternatives already added (also by expressing their type) and to add new alternative.

The "Alternative Content" TAB will show a text box and an "upload" bottom, in order to upload alternative resources, and it works as well as the File Manager does (maybe it could be shown only the link to the File Manager, as it is the "Content" TAB, by selecting that link the pop-up File Manager opens). Below, the TAB will show the original resources on the left and all the added alternatives on the right (as in the Demo Test Drag'n'drop): by using "drag'n'drop" feature (using the Fluid Lightbox), it will be possible to define an association between a primary resource and an equivalent one.

Beside each alternative resouce there will be a list of 4 check boxes, they allow authors to define the type of the alternative (textual, visual, audio, tactile). 

In the very first implementation it will be possible only to define the association between one resource to many alternatives. No one alternative to many resources.

A drop-down menu it will also available on the right of each alternative resource, in order to show the file name of the primary resource associated. Such a menu will be used also to delete the previous association (see the same function in the Demo Test Drag'n'drop). 

Such associations will be stored in the DB, in its own "content alternative association" table (or something like that).

If the author changes the original content in the editing content TAB ("Content"), then all the related alternatives remain, but the associations are deleted. A warning message appeares informing the user that the association is broken and has to be reset. 

Below the file manager area, the top of the rest of TAB area will be devoted to define an alternative to the whole page. If the author chooses this option he/she will not be able to define single alternatives to the single original resources. (So the two options are mutually exclusive).

The rest of the TAB area will be devoted to the definition of association between single original resources and alternatives and of alternatives preferences. The area will be divided into two main columns: on the left the primary resources and on the right the alternatives with their properties. The box cointaining the alternatives will be divided in three columns: one displays the resource, one displays the type (4 check boxes) and one displays the associated primary resouce file name. A dragger or a "title bar" will be available to allow drag'n'drop.

An HTML page could be an alternative (to the whole page or to a single resource).

Exporting content

The generation of the imsmanifest.xml file will provide the ACCMD code related to what the content author have been declared about the involved resources (as well as TILE already does).

It is necessary to enhance and extend tools/ims/ims_export.php, include/ims/ims_template.inc.php.

Importing content

Compliant package will be imported and primary resources will be shown to default profile users. A parser will analyze the imsmanifest.xml, in order to identify primary resources and relationships between each provided resources.

It is necessary to enhance and extend tools/ims/ims_import.php, include/ims/ims_template.inc.php. 

When the profilation system will be ready, then each content page will be "constructed" (with output.inc.php) according to users' ACCLIP.   

Matching ACCLIP and ACCMD

The main part of the ACCLIP involved in matching ACCMD is the CONTENT part (CONTENT TAB), in which students declare preferences related to the type and the format of content they prefer.

  1. If the user has no CONTENT ACCLIP preferences then the system displays the primary resources to the user (we assume the user has no preferences about the type and the format of the content).
  2. If the user has CONTENT ACCLIP preferences and the content has no ACCMD then the system will advise the user that the content could be not compliant with her/his preferences.
  3. If the ACCMD and the CONTENT ACCLIP totally match then the system will construct a page (or a set of pages) with the equivalent resources.
  4. If the ACCMD and the CONTENT ACCLIP partially match then the system will advise the user and will construct a page (or a set of pages) with the correct equivalent resources (when they are available) and the primary resouruces if the correct equivalent ones are not available.
  5. If there is no match between CONTENT ACCLIP and ACCMD then the system will advise the user and will shwo the primary resources.

Resources

AccLIP
ACCMD
AccessForAll Standard
Guidelines for Developing Accessible Learning Applications

Notes

I've already taken a look to QTI: there is no mention about accessibility metadata and features. There are no intersections between ACCMD, ACCLIP and QTI, maybe a sort of "edge" between ACCLIP and QTI, where in ACCLIP students can ask for particular testing accomodation (extra time, for example), but it does not provide conflicts.

To Do

Take a look to Content Packaging 1.1.4 and try to identify differences with the previous version (which is the one ATutor currently applies, 1.1.2).

  • No labels