SCORM-SSS makes use of the dynamic rendering ability of modern browsers. By using a document.write function in Javascript at the head section of the SCO, we write the style sheet to modify the look and feel of the SCO.
Stating the obvious for those less technical, CSS style sheet is driven by style selectors which are used to select fragments of the document for style application. There are three different types of selectors for choosing:
1. existing HTML (or XHTML) elements /tags;
2. class attribute defined within any HTML tags; and
3. id attribute defined within any HTML tags.
The latter two selections give web designers great flexibility to control how a particular group of tags should look like. This is fine for your own document. However, for use of SCORM-SSS, I would advice against this practice. Basically, if we define special class or id attributes, it is difficult to expect other SCO producers will use the same class or id attribute. This is the similar argument and reservation I have with define a global set of tags to describe ALL possible learning material. HTML has its share of drawback, nevertheless, it is universally supported by all browsers and is quite rich to describe any look and feel one would like. By limiting the "display model" to this common set of tags, we would ensure inter-operability of any SCOs using this scheme.
So the first rule in designing CSS style sheet for SCORM-SSS is include selectors of standard HTML tags only.
CSS style sheet can be applied by referencing an external style sheet or applied inline by the style definitions. SCORM-SSS supports both.
However, if you are using external style sheet, make sure that the external style sheet is referenced ABSOLUTELY. Unless you are using a flat structure to store all your SCOs, the SCOs will be arranged in some directory structures. Relative referencing will break because of the different depths SCOs may be located.
Second rule in designing CSS style sheet for SCORM-SSS is use absolutely referenced external style sheet.
Since CSS can be inline, so the third rule is use inline style rules.
We can also mix external style sheet with inline styles. For example, Course Player (from http://www.scormplayer.com) will automatically apply any external style sheet BEFORE applying inline styles. This will allow for customisation of styles for individual course but still based on an institutional wide uniform style.
A collorary of rule one is for the SCO developer. Since the SCORM-SSS styles only select standard HTML, do not apply any class or id attribute.
Can SCORM-SSS support accessibility? Yes, but not just by itself.
Visual accessibility support depends on two factors: semantically meaningful mark-up of the content and rendering of the content.
For example, if images in the SCO do not have the appropriate alt attributes or descriptions, any style sheet will not improve the situation. Garbage in, garbage out!
However, for those semantically rich and correct mark-up material, style sheets offer the potential for different styles for different media. You may define a plain (or audio) style for visually impaired, a print style for print-out and a style for online reading.
In a future post, I will discuss how SCORM-SSS can support eye candies and the impact of eye candies on accessibility. At the meantime, please give me comment on whether SCORM-SSS is a feasible approach to solve an immediate need?
No comments:
Post a Comment