Edited by Christopher Douce, Tuesday, 2 Dec 2008, 17:13
To really understand why things are the way they are today necessitates understanding what has happened in the past. This blog post is an attempt to build up an understanding of the current state of Moodle accessibility by looking into what has happened during parts of its development. My methodology is simple: begin with internet (and Moodle forum) searches, ask a few people to see what they know, and see where it takes me!
Initial results
A quick search using Cuil took me to some Moodle developer pages and the Moodle Accessibility Specification which has the headline, 'the document specifies improvements to the accessibility of the Moodle course management system for version 1.7’' This is useful. Both the page itself and the release number can point me towards some dates. Version 1.7 of Moodle dates from November 2006 onwards (until March 2007, when version 1.8 is released).
Digging a little further in the Moodle documentation, I discover the release notes for version 1.7. This provides a huge amount of information. Release notes are very often overwhealming for the casual reader. So, to help my search, I search this page for the term 'accessibility'.
Under Moodle 1.8 release notes, the words 'the Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards' catch my eye. This is interesting, but what does this mean? Thankfully, there is a link. I’ll try to uncover what the significance of XHTML Strict later. Let's continue with the search for discussions relating to 'major accessibility standards'.
It looks like I might be finding some very useful stuff! So much stuff, I need to focus down on what is often very important to me: source code. Code cannot lie, but on its own, it cannot always tell you its history... Thankfully, there are other ways to understand how (and why) things have changed.
Looking at the detail
To enhance the accessibility of Moodle, the developers have created tasks within a combined bug tracker and change management system. This is something that is common to loads of other software developments. Change management systems help developers to keep track of what has changed, when and by whom. If bugs are accidentally introduced as a result of changes, keeping records can help us to understand why. A side effect of a good tracker is that it can also tell you what changes are incorporated into individual releases.
Let’s have a look at a tracker entry to see what one of them says: Indicate type of resource in the name of the resource. This is an interesting one. For screen reader users, having advance warning about the file type is useful, particularly if a link is to a resource that is handled by an application outside of the browser, such as a PDF file, for example.
It’s also interesting to see that the tracker can also contain information about debates about the development of the software and, sometimes, its requirements. Clicking on the 'change history' may sometimes present you with a file that summarises the modifications that a Moodle developer has made to several files to make the accessibility enhancement.
Higher level advice
As well as the Accessibility Specification, one of the developers has created a useful page entitled Accessibility Notes (found within the developer area). This includes an executive summary of some of the guidelines, a roadmap for further accessibility developments, pointers towards future areas of development and a link to some accessibility 'patterns' which have been derived from the Web Content Accessibility Guidelines (WCAG).
Relationship to WCAG?
You often hear WCAG mentioned in relation to different levels of conformance, specifically A, AA and AAA. Whilst searching the terms Moodle and WCAG, I found myself back at the forum that I mentioned earlier which had the title, a forum to discuss 'planned conformance to standards/laws such as the Web Content Accessibility Guidelines (WCAG), Special Educational Needs and Disability Act (SENDA), Section 508 (USA)'
It should be said that there is no formal way to 'conform' to the WCAG guidelines. Whilst some of guidelines can be assessed by machine (by the use of a computer program), some sections of the guidelines require real people to determine whether or not a web page is accessible (according to the guidelines). It should be noted that even if something is accessible under one measurement, to some users, this might not be the case.
The issue of compliance is also complicated by the fact that Moodle (along with many other learning management systems) can make use of different blocks, modules or components in a range of different ways. The way that an application is use and configured can significantly influence its accessibility.
Although there is no definitive statement how Moodle adheres to the different WCAG 1.0 levels, but I have discovered a forum posting that relates to a question about the American Section 508 procurement legislation. But will there ever be a statement about WCAG? I decided to dig further by speaking to one of the contributors to the Moodle Accessibility Specification.
Whilst WCAG is great for content, it doesn’t work so well with interactive systems. The Moodle accessibility specification has been created by distilling accessibility principles and ideas from a number of different sources, WCAG as well as an organisation called IMS (see also the IMS Guidelines for Developing Accessible Learning Applications).
Future work?
It was recently announced that the latest version of the WCAG guidelines (version 2.0) will be soon released. One interesting piece of work would be to carry out an assessment of a 'vanilla' (or out of the virtual box) installation of Moodle against these new guidelines.
Strict!
Earlier on I mentioned that I might explore what is meant by the mysterious words XHTML Strict. Whilst browsing the Moodle accessibility pages, I discovered the Moodle tracker task that asked the developers to move to web pages that are 'marked up' in this way.
One part of this tracker jumps out at me, specifically: 'avoid using, within the markup language in which the page is coded, elements and attributes to define the page's presentation characteristics'. In essence, use semantic tagging on web pages as opposed to tagging that relates to the change of the visual characteristics of a display. Rather than using bold tags to indicate a heading, a developer should instead use heading tags. This way, the tags that 'add meaning' to a document can help users who have assistive technology navigate through a page more easily.
A further comment on the subject of semantic tagging is that if a developer needs to add visual formatting to a page, cascading style sheets should be used (CSS). CSS can be used to separate the structure of the content from how it appears on the users screen. A great illustration of what CSS is and what it is capable of can be found within the CSSZengarden.
There is another line within the tracker problem that was interesting: 'for all new sites, use at least version 4.01 of HTML, or preferably version 1.0 of XHTML'. What does this mean, and is there a difference between the two, and why is a difference preferred? Let’s have a look what they are in Wikipedia which contains a paragraph that explains how XHTML relates to HTML.
It seems there are little differences between the two, except that the HTML pages become well-formed XML documents. Not only can then the resulting pages be manipulated by programs that can manipulate XML (and more easily check for different types of conformance – page checking is mentioned in the tracker comments page), but by insisting that they are 'well formed' may prevent the possibility of 'ill-formed' pages confusing assistive technologies, such as screen readers.
The tracker provides more information about how XHTML relates to accessibility. WCAG states that content authors (and you could argue that a page generated by Moodle is content) should 'create documents that validate to published grammars' (checkpoint 3.2). Other useful WCAG checkpoints include guidance not to use deprecated (now obsolete or old) features, and select W3C technologies when they are available, and use the latest versions. In essence, take advantage of new technologies when they are available for use.
Summary
It seems that accessibility, as a subject, has been discussed on the Moodle forums since November 2005. Since this date, a lot of work has been carried out to improve the accessibility of Moodle, some by the Open University. Evidence of this work can be found documented within the Moodle project without too much difficulty. I hope this post has helped to show where (and how) to find information about Moodle accessibility.
Although it can be argued that no platform is totally accessible, strides have been made to make Moodle more suitable for users of assistive technology. Anyone who uses Moodle has to be aware that the accessibility of such a system does not only depend upon the programming code alone, but also how it is used, and what materials it presents to learners.
Acknowledgements are extended to those who I spoke to during preparation of this post. You know who you are!
Understanding Moodle accessibility
To really understand why things are the way they are today necessitates understanding what has happened in the past. This blog post is an attempt to build up an understanding of the current state of Moodle accessibility by looking into what has happened during parts of its development. My methodology is simple: begin with internet (and Moodle forum) searches, ask a few people to see what they know, and see where it takes me!
Initial results
A quick search using Cuil took me to some Moodle developer pages and the Moodle Accessibility Specification which has the headline, 'the document specifies improvements to the accessibility of the Moodle course management system for version 1.7’' This is useful. Both the page itself and the release number can point me towards some dates. Version 1.7 of Moodle dates from November 2006 onwards (until March 2007, when version 1.8 is released).
Digging a little further in the Moodle documentation, I discover the release notes for version 1.7. This provides a huge amount of information. Release notes are very often overwhealming for the casual reader. So, to help my search, I search this page for the term 'accessibility'.
Under Moodle 1.8 release notes, the words 'the Moodle interface is now compliant with XHTML Strict 1.0 and major accessibility standards' catch my eye. This is interesting, but what does this mean? Thankfully, there is a link. I’ll try to uncover what the significance of XHTML Strict later. Let's continue with the search for discussions relating to 'major accessibility standards'.
Moodle Accessibility Page
The link found on the 1.8 release notes takes me to the Moodle Accessibility page. The page provides several groups of other links: starting points, standards, legislation, tools and resources. A couple of things jump out at me: a link to the development tracker that relates to Accessibility Compliance in Moodle 1.8, a link to Italian Accessibility Legislation Compliance, and a link to an accessibility forum (guest login required).
It looks like I might be finding some very useful stuff! So much stuff, I need to focus down on what is often very important to me: source code. Code cannot lie, but on its own, it cannot always tell you its history... Thankfully, there are other ways to understand how (and why) things have changed.
Looking at the detail
To enhance the accessibility of Moodle, the developers have created tasks within a combined bug tracker and change management system. This is something that is common to loads of other software developments. Change management systems help developers to keep track of what has changed, when and by whom. If bugs are accidentally introduced as a result of changes, keeping records can help us to understand why. A side effect of a good tracker is that it can also tell you what changes are incorporated into individual releases.
Let’s have a look at a tracker entry to see what one of them says: Indicate type of resource in the name of the resource. This is an interesting one. For screen reader users, having advance warning about the file type is useful, particularly if a link is to a resource that is handled by an application outside of the browser, such as a PDF file, for example.
It’s also interesting to see that the tracker can also contain information about debates about the development of the software and, sometimes, its requirements. Clicking on the 'change history' may sometimes present you with a file that summarises the modifications that a Moodle developer has made to several files to make the accessibility enhancement.
Higher level advice
As well as the Accessibility Specification, one of the developers has created a useful page entitled Accessibility Notes (found within the developer area). This includes an executive summary of some of the guidelines, a roadmap for further accessibility developments, pointers towards future areas of development and a link to some accessibility 'patterns' which have been derived from the Web Content Accessibility Guidelines (WCAG).
Relationship to WCAG?
You often hear WCAG mentioned in relation to different levels of conformance, specifically A, AA and AAA. Whilst searching the terms Moodle and WCAG, I found myself back at the forum that I mentioned earlier which had the title, a forum to discuss 'planned conformance to standards/laws such as the Web Content Accessibility Guidelines (WCAG), Special Educational Needs and Disability Act (SENDA), Section 508 (USA)'
It should be said that there is no formal way to 'conform' to the WCAG guidelines. Whilst some of guidelines can be assessed by machine (by the use of a computer program), some sections of the guidelines require real people to determine whether or not a web page is accessible (according to the guidelines). It should be noted that even if something is accessible under one measurement, to some users, this might not be the case.
The issue of compliance is also complicated by the fact that Moodle (along with many other learning management systems) can make use of different blocks, modules or components in a range of different ways. The way that an application is use and configured can significantly influence its accessibility.
Although there is no definitive statement how Moodle adheres to the different WCAG 1.0 levels, but I have discovered a forum posting that relates to a question about the American Section 508 procurement legislation. But will there ever be a statement about WCAG? I decided to dig further by speaking to one of the contributors to the Moodle Accessibility Specification.
Whilst WCAG is great for content, it doesn’t work so well with interactive systems. The Moodle accessibility specification has been created by distilling accessibility principles and ideas from a number of different sources, WCAG as well as an organisation called IMS (see also the IMS Guidelines for Developing Accessible Learning Applications).
Future work?
It was recently announced that the latest version of the WCAG guidelines (version 2.0) will be soon released. One interesting piece of work would be to carry out an assessment of a 'vanilla' (or out of the virtual box) installation of Moodle against these new guidelines.
Strict!
Earlier on I mentioned that I might explore what is meant by the mysterious words XHTML Strict. Whilst browsing the Moodle accessibility pages, I discovered the Moodle tracker task that asked the developers to move to web pages that are 'marked up' in this way.
One part of this tracker jumps out at me, specifically: 'avoid using, within the markup language in which the page is coded, elements and attributes to define the page's presentation characteristics'. In essence, use semantic tagging on web pages as opposed to tagging that relates to the change of the visual characteristics of a display. Rather than using bold tags to indicate a heading, a developer should instead use heading tags. This way, the tags that 'add meaning' to a document can help users who have assistive technology navigate through a page more easily.
A further comment on the subject of semantic tagging is that if a developer needs to add visual formatting to a page, cascading style sheets should be used (CSS). CSS can be used to separate the structure of the content from how it appears on the users screen. A great illustration of what CSS is and what it is capable of can be found within the CSSZengarden.
There is another line within the tracker problem that was interesting: 'for all new sites, use at least version 4.01 of HTML, or preferably version 1.0 of XHTML'. What does this mean, and is there a difference between the two, and why is a difference preferred? Let’s have a look what they are in Wikipedia which contains a paragraph that explains how XHTML relates to HTML.
It seems there are little differences between the two, except that the HTML pages become well-formed XML documents. Not only can then the resulting pages be manipulated by programs that can manipulate XML (and more easily check for different types of conformance – page checking is mentioned in the tracker comments page), but by insisting that they are 'well formed' may prevent the possibility of 'ill-formed' pages confusing assistive technologies, such as screen readers.
The tracker provides more information about how XHTML relates to accessibility. WCAG states that content authors (and you could argue that a page generated by Moodle is content) should 'create documents that validate to published grammars' (checkpoint 3.2). Other useful WCAG checkpoints include guidance not to use deprecated (now obsolete or old) features, and select W3C technologies when they are available, and use the latest versions. In essence, take advantage of new technologies when they are available for use.
Summary
It seems that accessibility, as a subject, has been discussed on the Moodle forums since November 2005. Since this date, a lot of work has been carried out to improve the accessibility of Moodle, some by the Open University. Evidence of this work can be found documented within the Moodle project without too much difficulty. I hope this post has helped to show where (and how) to find information about Moodle accessibility.
Although it can be argued that no platform is totally accessible, strides have been made to make Moodle more suitable for users of assistive technology. Anyone who uses Moodle has to be aware that the accessibility of such a system does not only depend upon the programming code alone, but also how it is used, and what materials it presents to learners.
Acknowledgements are extended to those who I spoke to during preparation of this post. You know who you are!