Tekst źródłowy strony Moodle Accessibility Specification

<p class="note">These are DRAFT specifications that are being authored by a joint [http://www.open.ac.uk Open University] (IET-OCI-VLE) working group. The document specifies improvements to the '''accessibility of the Moodle course management system''' for version 1.7.

Please post comments in the [http://moodle.org/mod/forum/discuss.php?d=48603 RFC - Moodle Accessibility Specification] forum discussion.

(Also, see an earlier document in the forum discussion, [http://moodle.org/mod/forum/discuss.php?d=40484 RFC - Accessibility Proposal].)
</p>

== People ==

Working group members:
* [[User:Cc933|Chetz Colwell]], [http://iet.open.ac.uk/about/index.cfm?id=5087 Accessibility in Educational Media (AEM)], [http://iet.open.ac.uk/ Institute of Educational Technology].
* [[User:MartynCooper|Martyn Cooper]], IET, AEM.
* [[User:Jim Ellis|Jim Ellis]], Learning & Teaching Solutions (LTS) – Staff and Projects.
* Jenny Gray, LTS – Strategic, [http://oci.open.ac.uk/ Open Content Initiative] (OCI).
* [[User:Ndf42|Nick Freear]], LTS – Strategic, Virtual Learning Environment (VLE) project. [mailto:N.D.Freear_at_Open.ac.uk Email N.D.Freear]

Other interested people:
* Stephen Bradley, LTS – Media, OCI.
* Jason Cole, LTS – Strategic, VLE.
* Howard Taylor, [http://www.corous.com/ COROUS], Open University Worldwide Ltd.
* Martin Dougiamas, [http://moodle.com Moodle.com].

== Diary ==

# Initial meeting, Thursday 8 June, afternoon.
# Working meeting, Thursday 15 June, all day.
# Submit to M.Dougiamas, and forums for review, Friday 23 June 2006.

==Moodle Accessibility Specification ==
=== Introduction ===
This accessibility specification has been developed by accessibility experts and Moodle developers at the Open University (OU), UK.  The OU has adopted Moodle as a core component of its VLE and is contributing to the continued Open Source (OS) development of Moodle.  Accessibility is an important for the OU because: it currently has over 9,300 disabled students; it has long standing aspirations to promote widening participation in higher education; and because of its legal obligations.  Further it is important for the whole Moodle community as further discussed under “Rationale” below.

Accessibility is a term that has particular meanings in different contexts; here it refers to design qualities that endeavour to make online learning available to all by ensuring that the way it is implemented does not create unnecessary barriers however the student may interact with their computer.  Virtually anyone, irrespective of any disability, can be enabled to interact effectively with a computer.  Some people with disabilities interact with the computer using methods other than the conventional monitor, keyboard and mouse, some require special tools, usually referred to as “assistive technology”, and some need the way content is presented to them by the computer to be appropriate to their needs (for example in terms of font sizes and/or colour contrast).  

There are well established design principles for accessibility in software design and electronic content. These promote compatibility with assistive technology and ensure that different ways of interacting with the computer can be accommodated.  This specification highlights further development work required in Moodle if these principles are to be considered effectively implemented across its various tools and modules. 

This Accessibility Specification is concerned with meeting the needs of disabled people who may be users of Moodle in whatever role they have, student, teacher, systems administrator, etc. However many accessibility approaches also yield benefits to all users and some help those working in particular circumstances such as working on a small screen PDA or over a low bandwidth link. 

==== Scope ====
The intended scope of this document is to set out an accessibility specification that applies to all elements of Moodle. This follows from the fact that all potential users of Moodle, whether they are students, teachers, administrators or developers, may be people with a disability. Moodle v1.6 had just been released at the time of writing and the specific comments are mainly based on a review of this version. 

The guidance set out under [[#Principles of Accessibility]] applies generically to all elements of Moodle that implement the features concerned and indeed any software development.    Under [[#Current Status Moodle Accessibility]] specific issues are reported where the current version of Moodle is at odds with these principles.  This has been done by a rapid cycle of review of most Moodle elements.   

An initial test of the Open University's instantiation of a Moodle 1.6 development version was undertaken in January and February 2006.  The tests were confined to the Moodle modules and blocks that were then planned for the May 2006 release of OU Moodle course sites:
<blockquote>
* Modules:  Resource page, quiz, forum.

* Blocks:  Course summary, latest news.

: Note, the calendar block and page were not to be used and therefore were not tested.
</blockquote>

These tests were undertaken with IE6, Jaws 7 (screen-reader), ZoomText 8.1 (screen-magnifier), Dragon 7 (voice recognition software), and various browser and operating system settings.

Many of the high priority issues from this evaluation were addressed and then adopted in the Moodle v 1.6 release.  Outstanding issues from this evaluation are reported under [[#Results from Initial OU Jan/Feb 2006 Evaluation]].

The subsequent testing for compiling this specification has been based on Moodle v 1.6 but in various instantiations to enable access to examples of the modules in question.  An installed Moodle Features Demo and a demo OU course (CT505) were mainly used for the testing, plus some features on Moodle.org.  These sources are noted throughout the specification.

The decision was taken to concentrate initially on screen-reader access.  This can be justified in that screen-reader access is usually the most problematic. Further, key issues for screen reader access (e.g. appropriate text labelling of interface elements and focus control) are also issues for voice recognition software and screen-magnifiers.  Therefore all available/relevant blocks and modules have been tested with a screenreader (Jaws 7).  In addition key features that were judged to be potentially problematic have also been tested with voice recognition software (Dragon 8), a screen magnifier (ZoomText 8), IE's 'largest' text size, and Windows display setting 'High Contrast Black #1'. (Note: the tester is not an expert Dragon user and so uses the tool 'out of the box' and relies on Help for techniques.  It is possible that there are 'tricks' for dealing with some of the access issues that have been identified, but these are unknown to the tester.)

===== Priorities =====
The priority of issues is indicated using the WCAG priorities and are marked '''P1, P2, P3'''.  There are some cases in which it is considered that an issue is of higher priority for Moodle than the guidelines state and this is indicated accordingly.  The testing has raised additional issues that are not referred to in the Guidelines which are indicated as having '''High, Medium''' or '''Low''' priority.  Other issues that were picked up but are not strictly accessibility issues are labelled '''Usability'''.

For some issues the ideal solution is not yet known and these are marked as ''needs further consideration'' (or similar).  Ideally various potential solutions need to be built into prototypes and tested, including testing with users.

It has not been possible to do a detailed accessibility evaluation of all current Moodle Modules and Blocks in compiling this specification mainly because good examples of all were not available for testing.  Specifically it was not possible to do a full evaluation of the Quiz Module prior to the release of this specification but further work on this is planned in the near future.  Most Modules and Blocks however have been tested.  Where they have not been tested they are included in the lists under [[#Issues with different Moodle components]] with a note to this effect.  There are many generic issues that apply across many modules and these have been separately listed.  The focus for testing has been modules that generate interface elements that are student facing.

===== The onward process of review and action =====
The exact process of response to this Accessibility Specification is still subject to negotiation.  However broadly it will consist of a period of review (principally via the [http://moodle.org/mod/forum/view.php?id=5752 Moodle Accessibility Forum]), then action on the recommendations followed by evaluation and then iteration as required.  The target is to have all priority 1 and priority 2 issues addressed by September 2006.

==== Rationale for Moodle accessibility ====
There are moral, legal and market reasons why accessibility for disabled users is important for Moodle.  

===== The moral argument =====
In any software product, or content item, if you fail to address issues of accessibility you will exclude or disadvantage significant numbers of people:  

* Disabled people represent about 10-15% of the general population
* At the Open University 5.5% of students declare a disability
* [http://download.microsoft.com/download/0/1/f/01f506eb-2d1e-42a6-bc7b-1f33d25fd40f/ResearchReport.doc  The Wide Range of Abilities and Its Impact on Computer Technology],  a recent Microsoft commissioned market research report, shows: 57% of working age computer users are likely to benefit from accessible technology (where accessible technology is understood as technical responses to promote access for disabled people to computer hardware and software).

So the moral argument is one of inclusion as opposed to discrimination.  Further it is repeatedly demonstrated that good design for disabled people is good design for all.  Considering the needs of disabled students, for example, facilitates reflection on the interactions that support the learning objectives or related tasks and addressing the accessibility agenda promotes usability for all.   

===== The legal argument =====
Many countries are introducing legislation, making it illegal to discriminate against disabled people in education. Examples from 3 jurisdictions are given here. 

The USA led the way with antidiscrimination legislation effecting education with the introduction of [http://www.hhs.gov/ocr/504.html Section 504 of the Rehabilitation Act 1973] and [http://www.ada.gov/ Americans with Disabilities Act (ADA) 1990]. Also of particular relevance is [http://www.section508.gov/index.cfm Section 508 of the Rehabilitation Act 1998].  This requires Federal agencies to make their electronic and information technology accessible to people with disabilities. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. This applies to the public school sector and the state funded universities and colleges.  These agencies must give disabled employees and members of the public, including students, access to information that is comparable to the access available to others.

In the UK the key legislation is the [http://www.opsi.gov.uk/acts/acts1995/1995050.htm Disability Discrimination Act (DDA) 1995] This was amended by the   [http://www.opsi.gov.uk/acts/acts2001/20010010.htm Special Educational Needs and Disability Act (SENDA) 2001] and in April 2005 a new [http://www.opsi.gov.uk/acts/acts2005/20050013.htm Disability Discrimination Act (DDA) 2005].  Now, Part 4 of the DDA specifically applies to the education sector.  This legislates that education providers must not treat a disabled person less favourably for any reason that relates to the person’s disability. Further, the education provider is required to make reasonable adjustments to enable a disabled person to participate in its courses. Access to the online elements of its courses is an important area where, by considering the needs of disabled students, discrimination can be prevented.  An important feature of the Act is that the needs of disabled students need to be anticipated and that it is therefore not sufficient for an educational establishment just to attempt to deal with the needs of a disabled student as they arise.

In Australia, state equal opportunity laws were revised to prohibit discrimination on the grounds of disability in the early 1980s. These laws were harmonised at the federal level by the [http://www.austlii.edu.au/au/legis/cth/consol_act/dda1992264/ Disability Discrimination Act (DDA) 1992]. This Act specifically prohibits discrimination against disabled students. 

The laws in different countries have different scopes and are applied in different ways but all broadly leave any educational institution open to legal challenge if they discriminate against disabled students in their provision of online elements of  courses. Hence in many jurisdictions there is a legal reason for Moodle to address accessibility issues for disabled students.

===== The market argument =====
The market argument follows directly from the moral and legal ones. Globally education institutions are increasingly adopting tools to enable them to deliver components of their teaching and learning online. However many have institutional values that mean they that they wish to do so in a way that is non-discriminatory towards students with disabilities. In most countries educational institutions find themselves working within a legal framework that now enshrines such anti-discriminatory ideals. Thus when an educational institution is considering adopting a technology for the online delivery of course elements the accessibility of these tools should be a key criterion in its decision making. If Moodle is able to demonstrate its commitment to accessibility and, further than that, by having invested in the accessibility of its component elements show that it is able to reduce the overhead for the institution in implementing its online course elements accessibly, it will be well placed in this market place.

==== Organisation of this specification ====

[To be written when final structure of the specification is agreed including whether it is to be a single article or a set of linked articles.]

=== Principles of Accessibility ===

==== The Checklist Issue ====
Many developers express a desire for a set of check points to enable them to work in a way that results in products that are accessible to disabled users.  Such checklists have their place but have been demonstrated over the years not to be effective on their own in promoting accessible design.  The essence of accessible design is for the developer to constantly bear in mind that the not all the users of their developments will interact with the computer environment in the same way that they do.  The purpose of this section of this Accessibility Specification is to give the developers who have to respond to it an overview of the information they need to work in this way.  This is kept deliberately brief but more comprehensive resources are referred to.

==== General Principles of Accessibility ====
A summary of the main accessibility principles that underlay the more detailed points of the various accessibility guidelines and the comments specifically on current Moodle accessibility challenges is presented here. It is recommended that all developers understand these to enable them to effectively take on their responsibilities for accessibility in the design of Web and related software components.

There are various published guidelines that are applicable here that give more detailed information but of particular relevance are:

* [http://www.w3.org/TR/WAI-WEBCONTENT/ W3C Web Content Accessibility Guidelines 1.0 (WCAG 1.0)], 5 May 1999.
* [http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html IMS Guidelines for Developing Accessible Learning Applications], 12 July 2004


[Note - [http://www.w3.org/TR/2006/WD-WCAG20-20060427/ A Last Call Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0)] was published on 27 April 2006. The extended deadline for comment on these was 22 June 2006.  So these are anticipated to supersede WCAG 1.0 soon.]

----
<br/>
'''So in summary the main accessibility principles are:'''
===== Allow for user customisation: =====
User customisation is a key tool in addressing the diversity of needs represented across a full set of users.  Many different disabled people, including those with a visual impairment and dyslexia, find online content and interface elements can be made more readable if they are able to choose particular font styles and sizes and use different background and foreground colours.  Because of the wide diversity in what different people would select as their optimally readable configuration, this is best addressed by allowing them to choose their own settings. This is usually most readily done by enabling the web pages or software to inherit user set parameters from the browser or computer operating system.

===== Provide equivalents for visual and auditory content and interface elements: =====
Text is the most readily accessible form of online content. It can be rendered into synthetic speech by screen readers and configured for different presentation. Text descriptions should be provided for all images, graphics and video content, and text labelling of interface elements should be included.  Text transcriptions of auditory content should be provided.

===== Use different ways of presenting information in an interface: =====
Different people are able to access information from an interface in different ways.  Presenting such information in one way alone will thus probably exclude some people from the effective use of that interface.  Therefore present important information in multiple ways.  For example if the status of a control is indicated by colour, also indicate it by an appropriate text label that can be seen and is accessible to a screen-reader.  This will ensure that it is accessible to those with colour-blindness as well as those who use such assistive technologies.

===== Provide compatibility with assistive technologies: =====
This simple statement hides a multitude of technical issues but, by following set web or software standards, the opportunities for this being adequately addressed are maximised as the assistive technologies are to a large part developed with these same standards in mind. This includes to adhering to standards for web mark-up e.g. mark up headings as headings (and nest correctly), lists as lists and use tables for tabular information. This principle is expanded on in the section  [[#Compatibility with Assistive Technologies]] below.

===== Allow access to all functionality from keyboard alone: =====
Many disabled people are unable or prefer not to use a mouse. This includes blind people and those with some physical disabilities.  By ensuring that software can be fully used without a mouse, the needs of these users are met but also generally more efficient interaction with the software is offered to all users.

===== Provide context and orientation information: =====
It is important to consider the accessibility issues of navigating around the content as well as the content itself. This is an area often neglected.  Support should be provided for efficient navigation by informing the user of where they are, taking into account that some users may be using screen-readers or other assistive technologies. This is another case where thinking about the needs of disabled users often yields benefits for all users by promoting usability generally.
----
<br/>

==== Compatibility with Assistive Technologies ====
There is a range of assistive technologies that are widely employed by people with different disabilities to enable them to effectively interact with a computer environment.  Brief points on the implication of the most common forms of such assistive technology for web and software developers are listed here.   

[Adapted from [http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html IMS Guidelines for Developing Accessible Learning Applications]]

===== Screen-readers =====
Screen-readers are software based tools that enable the user to locate text based information on the computer screen and then vocalize it using speech synthesis software and audio hardware, or they can present it in a refreshable braille display.  Most screen-readers work in close concert with the operating system, relying on the computer's built-in functionality.  Screen-readers are used by all blind computer uses some with other degrees of visual impairment and some people with dyslexia.  They possibly present the most challenging set of issues of all the major assistive technologies for developers of web content or application or other software.

To support screen reading software developers can: 
* Use standard system tools to draw and erase all on-screen text and to display all cursors and pointers. 
* Use system standard on-screen controls whenever possible. 
* Define tools in toolbars, palettes, and menus as separate items. Do not create single graphics containing multiple objects. By keeping tools and other objects separate, the screen reader is better able to identify and name each tool for the user. 
* Embed descriptive text in graphic images in such a way as to make the text known to screen reading software. This addresses the problems that can arise when text is rendered as a graphic image and cannot be read by software. 
* Assign logical names to controls, even if the name is not visible on the screen. Screen readers can access this information and use it to describe the type and function of the control on the screen. 
* Track the system cursor with the mouse, even if the cursor is invisible. This allows the screen reading software to detect the mouse position when customized highlighting or focusing techniques are in use. 
* Use consistent and predictable screen and dialog layouts. 
* Avoid the use of "help" balloons that disappear whenever the hot spot or focus of the mouse changes. Try instead to lock the "help" balloon in place so that the user can move the cursor and continue to read the balloon. 
* Use single column text whenever possible. 
* Provide keyboard equivalents for all tools, menus, and dialog boxes. 
* Ensure that links can be understood out of context, screen-readers can display a list of links to speed up navigation. For example, avoid "more ..." use "more about x".

Since screen readers can only read text (or give names to separately identifiable icons or tools), it is a good idea to: 
* Avoid assigning unlabeled "hot spots" to pictures for use as controls, unless they are duplicated with menu selections. 
* Avoid non-text menu items when possible or at least incorporate visible or invisible text cues to accompany these items. Screen readers can see text even if that text is written to the screen invisibly. 
* Avoid graphic tool bars that are not duplicated. Make any tool bar command available in a menu. 
Finally, documentation and training materials are always more accessible when: 
* Documentation and online help can be understood independent of graphics. Text descriptions should stand on their own. 
* Synchronized audio descriptions are available to play alongside animated graphics or movies.

===== Screen-magnifiers ===== 
Screen-magnifiers are software solutions for users with low-vision. These products allow the user to enlarge the size of images and text displayed on screen. Screen-magnifiers may also permit the user to change the default colours of the display. For example, reversing the colours and blacks of the video signal can make the text more readable for some users.

Compatibility between screen-magnifiers and software can be an issue for developers. Typical screen magnifiers track the cursor or the active region of the screen and will automatically enlarge that portion of the display. Applications that use a custom cursor design may cause the magnifier to enlarge the wrong portion of the screen. Developers can avoid this problem by relying on standard interface practices, particularly those that apply to cursor control and display.  Other compatibility issues include:
* Managing simultaneous events on a screen – the screen magnifier will only display a small portion of the screen at one time.  Hence avoid need to simultaneously monitor two or more events occurring far apart from each other on the screen
* Use the system pointers whenever possible, as well as the system caret or insertion bar, if available. 
* Include a highlight or focus indicator when dragging the system cursor, even at those times when the cursor is invisible. This adjustment will help screen enlargement software using "pan and zoom" features to track the user's movements more accurately. 
* Add support for a "high contrast" setting.

===== Alternative keyboards and mice =====
There is a very wide range of alternative keyboards and mice or other pointing devices available to disabled users.  Most of these do not have any implications for the developer of web application or other because they are used as direct replacements (electronically speaking) for the standard keyboard and mouse. However some people use virtual keyboards.
* Managing simultaneous events on a screen may be a problem for people using virtual keyboards which display a simulation of a keyboard on the screen for selection using a limited input device, for example a foot switch. The issue is similar to that for screen magnifiers above). There is a need to avoid having to  monitor two or more simultaneous events occurring far apart from each other on the screen
* Avoid timed responses or when they cannot be avoided, lengthen the time allowed for a user to respond. Because some alternative keyboard users may be slow to type entries or navigate the screen
* Provide keyboard access to all toolbars, menus, and dialog boxes.

===== Voice recognition software =====
* Generally, web applications and software that allow full access through keyboard commands are well suited for use with voice-recognition software.
* Ensure all windows with text editing functionality are accessible to voice recognition software (currently Moodle Editor for example is not fully accessible).
* Ensure all interface elements have appropriate alt-texts.  
* There are issues to address around how to make the alt-text to a button command or other interface element known to the users when it may not be appropriate to display this text on the interface element  (e.g. Expand/Collapse on Moodle blocks).  However, a workaround is for the Dragon user to say 'click image' and then select from a list that is created by Dragon.  This assumes that the user is aware of this technique.


----

==== Evaluation ====
Evaluation, both by experts and with users, plays an essential role in ensuring the accessibility of any software development.  However well crafted and detailed, guidelines and specifications alone will never be sufficient to guarantee that widespread accessibility is achieved.  In drawing up this specification, accessibility experts at the Open University have tested most of the elements of Moodle with some key examples of assistive technology and applied their expert judgement and knowledge of the published guidelines and the needs and preferences of disabled users to determine where issues exist.  However they would fully advocate that this work should be supplemented by user testing. 
 
There is a planed period of extensive usability and accessibility testing of Moodle with both disabled and non-disabled users at the Open University in the autumn of 2006.  It is hoped many of the issue of accessibility highlighted in this specification will have been addressed in subsequent releases of Moodle before then and thus there will be the opportunity to confirm or otherwise the effectiveness of the responses made to this specification.  Such end-user evaluations will doubtless surface new issues not covered in this specification which will need addressing at a later date.  But then to quote Martin Dougiamas: “Accessibility is a process”.

==== Note on Accessibility in Open Source developments ====
Accessibility is used as a weapon by both sides in the Open Source vs. Propriety Software debate.  The water is very muddy here and it is not the purpose of this brief note to contribute to this debate.  However a few notes on the Pros and Cons of addressing the accessibility agenda in an Open Source context are given.

'''Pros:'''
* When a “customer” detects an accessibility problem in an OS application they can generally affect a fix more readily that they can with propriety software.
* A wide range of accessibility and developer expertise can usually be rapidly and effectively brought to bear on an accessibility issue.

'''Cons:'''
* The inherent attribute of OS development of making software publicly available in early versions so the “community” can contribute to its further development often means that products are released with accessibility poorly addressed. (This can happen with proprietary software too.)
* Key accessibility benefits follow from consistency of interface design and behaviour across an application.  With a more loosely co-ordinated and distributed team of developers contributing to an OS product there is a risk that this consistency is not achieved.   However this is not judged a fundamental challenge in OS developments but one to be addressed in their co-ordination.  Proprietary developments undertaken by large developer teams too can suffer from such inconsistencies.
* Where and OS development results in the rapid release of updated versions of the software, changes in interface design and behaviour can be more problematic for some disabled users as it may take them longer to discover and understand such changes. 


----

=== Current Status Moodle Accessibility ===
==== Results from Initial OU Jan/Feb 2006 Evaluation ====
An initial test of the Open University's instantiation of Moodle a 1.6 development version was undertaken in January and February 2006. The tests were confined to the Moodle modules and blocks that were then planned for the May 2006 release of OU Moodle course sites: 
* Modules: Resource page, quiz, forum. 
* Blocks: Course summary, latest news. 
Note, the calendar block and page were not to be used and therefore were not tested. 
These tests were undertaken with IE6, Jaws 7 (screen-reader), ZoomText 8.1 (screen-magnifier), Dragon 7 (voice recognition software), and various browser and operating system settings. 

A summary of the results from this evaluation are included here.  Many issues raised in this evaluation were addressed prior to the release of Moodle v. 1.6.  So the issue reported here are principally the ones yet to be resolved.

Positive aspects with regard to accessibility in Moodle from this evaluation were:
* Most aspects are keyboard only accessible (exceptions are text editors and automated drop down menu selections).
* Site inherits users’ Windows settings for colour and font size, e.g. ‘Windows High Contrast Large’.
* Mini calendar is marked up with table headers.
* Calendar days of week marked up as table headers.
* Forms appear to be (mostly) marked up correctly.

===== Responses to date =====
A proposal to fix accessibility problems identified in the Jan/Feb 2006 evaluation was posted to the Moodle forums as, [http://moodle.org/mod/forum/discuss.php?d=40484 RFC - Accessibility Proposal]. Following discussion, changes were made by OU developers to code in the Moodle CVS repository on Sourceforge.

With limited resources, most work was done on the core Moodle code and style sheets for the Standard theme. The changes included adding and improving ALT text for significant images; removing tables, improving heading and list mark-up for Moodle side blocks; developing a new 'weekscss' course format which just uses style-sheets for layout, not tables; and improving colour contrast and non-visual cues in the calendar block and page.

===== Outstanding issues =====

====== General/global issues ======

Outstanding issues:
# Headings - check all text that acts as a heading, e.g. ‘general news and announcements’ in news forum and ‘study week x’ on course home pages.  Screenreader users can use headings to navigate around the page. '''P2'''
# Tables are used for layout. Suggest: investigate use of CSS for some if not all layout (it is acknowledged that this is not a perfect science). About 80% complete on main pages seen by students... Outstanding including, Moodle bug tracker 4943 "print_simple_box behaviour changed" Moodle 1.7. '''P2'''
# There are no ‘skip to content’ or ‘skip navigation’ links. These enable screenreader users and keyboard only users to jump over navigation links.  Suggest these links are provided on every page, and are invisible until the user tabs to them. Implemented for OU theme, outstanding for generic Moodle (difficult to guarantee the destination ID). [http://www.webaim.org/techniques/skipnav/ Useful discussion, including the IE focus bug]. '''P3''' (should be higher). 
# The [http://moodle.org/help.php?file=accessibility.html generic accessibility help page] is in Moodle CVS. Outstanding: sitemap; help link still to be provided; the document seems too technical for the ‘average’ student.  Suggest it is re-written without the references to HTML tags, explain how skip links work, and to correct the info about accesskeys which are now provided.  (Good to see request for feedback.) '''P2'''

====== Page header ======

Outstanding issues:
# Language drop down menu does not have a label which means users, particularly screenreader users, will not understand its purpose.  Suggest label such as ‘select preferred language’. '''P2'''
# Suggest the language codes be removed from the list, e.g. ‘en’ because they are not meaningful to most users.  The issue of screenreader access to different languages requires further consideration. '''Usability'''
# Drop down menu is not (easily) keyboard accessible: cannot use arrow keys to scroll through because first option is automatically selected.  (Can use ALT+down arrow to open list, but few students will know this.)  Suggest remove automation and provide a ‘go’ button or similar. '''P2''' (should be higher)  
# ‘»’ in breadcrumb trail is read by screenreader as “greater than greater than” or “double right angle bracket”.  Suggest replace with ‘/’ or ‘:’ or ‘-‘, or with a graphic of an arrow with the alt text ‘/’ or ‘:’ or similar. Fixed, with image (incidental image, no ALT text), and list; "bullet" be vocalised. I’m not sure this is an ideal solution. '''Medium'''

====== Login page ======

Outstanding issues:
* The automatic placing of the cursor in the ‘username’ field is useful for sighted users (including dyslexic, partially sighted, hearing impaired etc) who will see that it is there, but for screenreaders this can be difficult because the screenreader focus does not start at the top of the page and will miss any instructional text such as ‘Login here using your username and password’.  It is difficult to know how to resolve this conflict of needs and so this requires further consideration. '''Medium''' 

====== Edit profile page ======

Outstanding issues:
# The ‘new picture’ field is not marked up correctly so that the label is not read by a screenreader. '''P2'''	
# Suggest users are encouraged to provide a brief description of their image to convey the same message as the image, and include this as ALT text for the image. Alternative, suggest that on the Show/ Edit profile page ALT text is auto-generated; "User image, none supplied" or "User image for [NAME]" as applicable. '''Low''' 
# In some drop down boxes the default item is last in the list when it would be expected to be the first item, so when down arrow it seems that there are no other options.  Suggest default item is first in the list. '''Usability'''  
# The purpose of the ‘description’ field is not clear.  If it is for user to provide a description of themselves, suggest ‘description of me’ or similar. '''Usability'''  
# Ideally the question mark icon should appear before the editor, otherwise a screenreader has to tab through some of the editor controls before getting to the help button. Suggest it is placed between the field label and the start of the editor. '''P3''' (should be higher)  
# Text that appears after an edit field (or other form control) will not be read by a screenreader (due to a limitation in screenreaders).  Suggest all such text (‘for the teacher only’ and ‘max size 2MB’ is moved to the end of the label for the field, e.g. “ID number (for the teacher only)”. '''P2'''	
# Screenreader users are unlikely to continue reading further than the first ‘update profile’ button because they are likely to think this is the end of the page, and will therefore not be aware of the optional items below.  Furthermore the text ‘The following items are optional:’ is not marked up as part of the form and so will not be read by a screenreader (screenreader will move from first ‘update profile’ button to ‘new picture’ field).  Suggest alternative designs are explored so that there is just one ‘update’ button and optional fields are labelled individually as such. '''Usability'''

Further issue
* Dragon does not recognise the 'browse' button, either when say "click browse" or "click button".  This may be because the button does not have it's own label because it is part of the 'file' form control.  Dragon users can access the field by saying "type text" but may not know to do this.  Suggest if possible provide an explicit label for the button.  ''May require further investigation/testing''.

====== Course weekly view ======

Outstanding issues, 'weeks' course format:
# Search button has ‘>’ label, spoken as "greater than".  Suggest change to ‘go’, ‘search’ or similar. Fixed, with resizable image of '>' (may need work), and text hidden from graphical browsers. '''P1'''
# Having left hand and right hand menus may be difficult for screenreaders because they come both before and after the main content of the page.  This requires further consideration as to how to make it useful for sighted and blind users alike. '''P3''' (should be higher)  

====== My courses view ======

Outstanding issues:
# The user’s image and the text link both go to the same destination but are separate links.  Suggest remove the link from the picture, or combine the image and text link in the same link. '''P2'''	
# Suggest mark up list as a list. '''P2'''

====== All courses list ======

Outstanding issues:
# Suggest drop down menu is labelled “choose a course category” rather than just “course categories” so that the control is more meaningful. '''P2'''	
# Suggest mark up as list. '''P2'''
# Enrolment key icon: suggest the label for this is reduced to “course requires enrolment key” or “enrolment key required” rather than “this course requires an enrolment key” to reduce the number of syllables read by a screenreader, particularly is many courses are likely to require this. '''Low'''

----

==== Global Issues from June 2006 OU Evaluation ====
The issues listed in this section and the subsequent section entitled [[#Issues with different Moodle components]] were discovered in the June 2006 evaluation of accessibility issues in Moodle undertaken at the OU specifically to inform this specification.  This testing was undertaken with only Jaws 7 (screen-reader) and Internet Explorer 6 as explained under [[#Scope]].

Note on roles: accessibility issues apply whether it is material only available to students, or other material available to administrators/teachers/course creators.

* do not rely on the title attribute to convey information to screen-readers because this is not read under default screen-reader settings. '''High.'''
* provide 'skip to content' links on all pages that link from the very top of the page to the start of the content of the page. '''P3 (ideally should be P2).'''
* ensure styles allow a visual indication of the browser focus: in IE the indication of the focus is not visible, e.g. on tabbed panes, the breadcrumb trail, etc. '''High.'''

===== Lists =====
Mark up lists of items as HTML lists, e.g. alphabetical list in glossary. '''P2.'''

===== Tabs (tabbed panes) =====
E.g. in glossary and user profile.
* ensure title of tab is marked up as heading, or add a heading in tab. '''P2.'''
* remove link from current tab, e.g. in database when 'view list' tab is selected, remove link from 'view link'. '''Low.'''
* Ensure that tabs wrap when the window is resized so that users do not have to scroll horizontally.  '''Medium'''.

===== Use of Colours =====
* use colours with good contrast between background and foreground. '''P3 (ideally should be P1).'''
* ensure information conveyed with colour also conveyed is alternative way. '''P1'''
* new themes should not break existing fixes regarding colour
* tools for checking colour contrast are available: 
** Colour Contrast Check.  Allows you to specify a foreground and a background colour using sliders and determine if they provide enough contrast. http://www.snook.ca/technical/colour_contrast/colour.html
** Juicy Studio Colour contrast analyser. Online tool which analyses the colours you want to use for text and background (using hexadecimal format) and tells you whether they have sufficient contrast with each other. http://www.juicystudio.com/services/colourcontrast.asp
** Juicy Studio Luminosity Contrast Ratio Analyser. Online tool which analyses the luminosity of colours to help developers ensure they have sufficient contrast. http://juicystudio.com/services/luminositycontrastratio.php
** NILS Colour contrast analyser. Tool which includes colour picker feature to pick the colours from an existing web page and analyse their contrast. http://www.nils.org.au/ais/web/resources/contrast_analyser/index.html

===== Links =====
Ensure all link text is meaningful when read out of context, e.g. 'special' and 'all' in Glossary would be more meaningful as 'non-alphabetic entries' and 'all entries'. '''P2 (perhaps should be P1)'''.

===== Form Elements =====
* remove automation from drop down menus, e.g. glossary 'all categories' as they are not controllable with the keyboard only, and provide a 'go' button or similar to operate the control. '''P2 (ideally should be P1).'''
* 'jump to' menu: replace '<' and '>' with labels such as 'previous section' and 'next section' or similar. '''High.'''
* do not use colour alone for indication of errors - refer to global issues on colour. '''P1.'''
* ensure all forms contain HTML mark-up for labels of controls - do not rely on just providing a text label - ensure labels are explicitly associated with controls ('label' and 'for' tags). '''P2 (ideally should be P1)'''.
* consider the use of 'fielset' and 'legend' tags to group controls together.  There is differing advice about how these tags should be used and so examples need to be implemented and tested: ''requires further investigation''.  '''High'''.
* place information before controls so that screen-reader reads it before reading the control, e.g. on 'add glossary term' form place 'max size' before upload edit field: "attachment (optional, max size xxkb), help button, file input field, browse button". '''High.'''
* remove alt text from radio buttons and checkboxes as they are not necessary and are read by screen-readers as well as the text associated with the control. '''Medium'''.
* Best practice with horizontal radio buttons ''needs to be further investigated''.

===== Images =====
* all images that convey information should have alt text to convey that information (do not rely on <title> for this because it is not read by default by screen-readers). '''P1.'''
* all images that are decorative and do not convey information should have null alt text, i.e. alt="". '''Medium.'''
* help icons should have alt text that indicates the content of the Help link.  "Help with xyz" would be preferable to "Help, xyz" because for screen-readers the comma within the latter causes the screen-reader to pause making "help" and "xyz" sound like separate items. '''High.'''
* in forums users' images have null alt text but Jaws still reads the filename associated with it.  This may be because it is an image link. Perhaps the link could be removed as there is the same link from the person's name. ''This requires further investigation''. '''Medium'''.
* There is a question as to whether users' images should have meaningful alt text that conveys the content of the image, in particular when people use images of e.g. their pet or baby or some other icon.  These images help to build a sense of community and convey something about the person which should perhaps be conveyed to blind users. ''This requires further consideration and discussion.'' '''P1'''.
* where icons are used to indicate the type of resource or the destination of a link this needs to be conveyed to screen-reader users in the link text.  E.g. <pdf icon> <link: interesting article (PDF)>. (It is not necessary to add anything when it is clear from the text link, e.g. "news forum".) '''P1.''' Note it is not sufficient to just add alt text to these icons to convey this information because when screen-readers create a list of links the images will not be included and so the information will not be available in that context.
* it can be useful when image links and text links are used together to the same destination to combine them into the same link as suggested on the [http://trace.wisc.edu/wcag_wiki/index.php?title=Combining_adjacent_image_and_text_links_for_the_same_resource WCAG-wiki], e.g. from wiki: <a href="products.html">  <img src="icon.gif" alt="" />Products page</a>.  This creates one 'clickable' area for mouse users and just one link is read by screen-readers.  Example is list of online users: the image and text links are separate but could be combined. '''Medium.'''

===== Headings ===== 
* ensure all headings are marked-up as HTML headings, and nest them appropriately, e.g. H1, H2, H3 etc. '''P2.'''

===== Scripting =====
All user interfaces and functions created or provided via scripting should be made accessible. '''High'''

===== Layout =====
Use stylesheets for layout instead of tables. '''P2'''.

===== Pop-up windows =====
* pop-up windows can cause difficulties for all users, including those who have pop-ups blocked in their browser, but particularly visually impaired people (both blind and partially sighted): newer screen-readers announce when a new window opens, but older screen-readers do not, and screen magnifier users may not notice that a new window has opened.  WCAG 1.0 says users should be warned in the link text that a new window will open ([http://www.w3.org/TR/WAI-WEBCONTENT/#gl-interim-accessibility checkpoint 10.1, Priority 2]) (e.g. link: "messages: opens new window") but this practice can become cumbersome if it needs to be applied to many links.  It therefore may be preferable in the long term to offer users a global setting for pop-ups to prevent or allow them. ''This requires further consideration''. '''P2'''.
===== Language =====
* changes in language should be marked up appropriately, especially e.g. in language teaching.  This will allow screenreaders to switch languages accordingly and speak with the correct pronunciation. '''P1'''.

===== Tables =====
* ensure all table headers are marked up with 'th'. '''P1'''.
* do not use 'th' just to create bold text in a table if it is not a header (use 'strong' instead). '''Medium'''.
* where possible avoid headers that span more than one column/row. '''Medium'''.

===== Note on Accesskeys =====
WCAG 1.0 recommends providing keyboard shortcuts to important links using the Accesskey tag (Checkpoint 9.5, priority 3), which moves the browser focus to the link so that the user can then select it. A number of implementation problems have been identified, which are summarised in the following articles.  The main problem is that there are so many keys reserved by browsers and assistive technologies (particularly screenreaders) that there are few keys available for use with Accesskey, and these would not be at all intuitive.

* [http://www.wats.ca/show.php?contentid=32 Using Accesskeys - Is it worth it?] 
* [http://www.wats.ca/show.php?contentid=43 Accesskeys and Reserved Keystroke Combinations]

The draft specification for XHTML 2.0 includes a different approach for keyboard shortcuts - see: http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule

It is therefore recommended that Moodle does not adopt Accesskeys until alternative methods are established.

===== Scrolling via voice recognition =====
Moodle pages do not respond to the Dragon command to scroll down.  This command works on other web sites, but it is not clear if something is preventing it in Moodle.  ''This requires further investigation''.

==== Issues with different Moodle components ====

===== Core components =====

====== User account ======
* user (including student) creates an account; logs in.
* user edits their profile.
* refer to global issues on forms and editor.

====== Jump-to menu ======
Tested on Moodle Features.
* refer to global issues on forms
* ensure drop down menu and buttons have HTML labels. '''P2'''
* provide meaningful labels to replace '<' and '>'. '''P2, ideally should be P1'''

====== Language menu ======
* requires admin configuration.
* refer to global issues on forms.
* ensure drop down menu and buttons have HTML labels. '''P2'''.
* changes in language should be marked up appropriately, especially e.g. in language teaching.  This will allow screenreaders to switch languages accordingly and speak with the correct pronunciation. '''P1'''.
* remove language codes, e.g. 'en', 'fa', 'fr' from menu items because not meaningful to users and not read in useful way by screenreaders. '''Medium'''.

====== Help (for both students and course authors) ======
* refer to global issues on images (for 'question mark' logo), and on pop-up windows.
* new 'Moodle Docs for this page' links in page footer (not student-facing).
* mark up headings in help pages as HTML headings. '''P2'''.

====== Error messages in form processing ======
* refer to issues on colour
* provide meaningful heading, e.g. 'error in xyz'. '''P2'''.

====== Site/course administration ======
Not tested as not student facing.
* installation, upgrade, maintenance.
* module, block, filter, language configuration.

====== Skip block links ======
Tested on Moodle Features.
These links are provided because when blocks are collapsed screenreaders still read them even though they are not visible.
* these links need to include the name of the block they are skipping, rather than the block number, e.g. "skip messages block". '''P2'''.

====== Expand/collapse block buttons ======
* See issues on colour.
* These buttons are not visible under Windows High Contrast Black settings.  Need to ensure that these are visible under all settings.  '''High'''.

===== Misc / Library elements =====
====== Editors ======
Tested on early OU Moodle instantiation [[#Vledemo]].

These are the [[#Outstanding issues]] for the ''HTMLArea'' editor (3rd party):
* Editor toolbar is not fully keyboard accessible: the three drop-down menus are in the tab order, but the other buttons are not.  Standard keyboard shortcuts are available (ctrl+b, ctrl+i, ctrl+u etc) but users are not informed of this.  There are not shortcuts for all buttons, e.g. create link, insert image etc. NOTE: the editor can be configured/ disabled on a per-user/ site-wide basis.  '''P1'''
* Dragon can dictate into the editor, and can 'tab' out of it, but it cannot operate the toolbar.
* Jaws announces the editor as “Untitled 1 frame edit”.  Suggest if possible add a meaningful label for this. '''Medium'''  
* The purpose of the links at the bottom of the editor made of the HTML codes is not clear.  However they are within the tab order of the page and would be indicated as links to a screenreader and would not be meaningful.  Suggest these could be hidden from all users to reduce complexity. '''P2'''.
* The drop down menus do not have explicit labels.  Suggest they are labelled ‘font’, ‘font size’ ‘style’ etc.  '''P2'''	
* The default state of the 3rd drop down is blank.  Suggest ‘normal’ is displayed by default. '''Low'''
* Access to the editor for keyboard only users, screenreader users and Dragon users requires further consideration.  The W3C’s [http://www.w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines] may be useful here. '''High'''.

* Accessibility/usability of ''TinyMCE editor'' - UNKNOWN (not integrated for Moodle 1.6). 
* Essential: keyboard and screen-reader accessibility.

====== Main calendar ======
Tested on early OU Moodle instantiation. 

[issues to be copied from report] 
* refer to global issues on colour, meaningful links, headings
* keep table mark-up, and use appropriate table header mark-up.
* note new fixes regarding colour

===== Modules (/mod) =====

====== Blog ======
* no blog available so not tested at this stage.
* generic issues with blogs: 
** screen-reader management of information; 
** need to develop support information for students 
** text-based and so therefore should be technically accessible, as long as headings and meaningful link text used.

====== quiz ====== 
Known issues (prior to June 06 testing):
* refer to generic issues regarding forms, layout and headings.
* ensure all form controls have explicit HTML labels. '''P2, ideally should be P1'''.
* avoid the use of colour on its own to indicate the correct answer, because this information is not available to screenreader users.  Provide the equivalent information in the form of text and/or icons. '''P1'''.
* ensure layout allows appropriate wrapping when feedback is displayed. '''Usability'''.
* 'fill in the gap' questions are difficult for screenreaders when the gap is in the middle of a sentence because in 'forms mode' it may not read beyond the gap.  There is no technical solution to this so screenreader users may need guidance and support on how best to deal with this type of question. '''High'''.
* allow any time limits that are set to be overridden where appropriate (roles issue?). '''High'''.

June 06 testing:

Three types of question interface were tested as this is what was available at the OU: radio buttons, text edit fields and 'fill in the gap'.  Tested on course 'GM001' with Jaws 7.

======= Vertical radio buttons (‘Introduction’ quiz) =======
* Non forms mode: reads fine, but RBs in a 3-column table (only 1 column needed)
* Forms mode: reads fine, but don’t need forms mode to select a RB with space.

======= Horizontal radio buttons (‘Introduction’ quiz) =======
* Non forms mode: reads fine
* Forms mode: reads fine, but don’t need forms mode to select a RB.

======= Edit field (‘Introduction’ quiz) =======
* Non forms mode: reads fine
* Forms mode: need forms mode to enter answer. 
* When tab out of field get straight to next form control (the answer field to the next question) and just reads ‘answer:’ without reading the question.  Therefore need to mark up the whole question with <label> and <for> tags to make sure it is associated with the edit field. '''P2, ideally should be P1'''.

======= Answer page for radio buttons and edit fields ======= 
* Gives correct statement, followed by “correct answer: *xyz* ” followed by “incorrect”.  Suggest this is reduced to “incorrect: the correct answer is: xyz” (without asterisks). '''Usability'''.
* ‘incorrect’ is read almost last – needs to be said first. '''High'''.
* The feedback provided on vertical radio buttons is often squashed into the narrow right hand column.  Suggest allowing this text to use a proportionate space. '''Usability'''.
* There is no structural indication that this text is feedback.  Suggest include a heading or text to indicate this, e.g. “feedback” or similar. '''Medium'''.
* There is no non-visual equivalent to the green highlight on correct answers.  Suggest consider icons such as red crosses and green ticks (with appropriate alt text: ‘incorrect’ and ‘correct’) to indicate wrong and right answers, or some other indication of the correct answers, e.g. an asterisk. '''P1'''.
* There seems no need to include “marks x” if also include “marks for this submission: x/y”.  Suggest replace with “marks for this question: x out of y” or similar (‘submission’ does not seem a meaningful term in this context). '''Usability'''.
* (Note the green highlight used here (#AAFFAA) has sufficient contrast with the black text.)

======= Fill in the gap (‘Doing systems integration’ quiz) =======
* Non forms mode: reads fine – just says ‘edit’ at each field.
* Need forms mode to enter text.  Jaws reads the text since the last edit field with each edit field (and this could be a whole paragraph), but does not read beyond the edit field, so with examples such as “She details a number of <edit field> procedure calls…” the user does not know what the ‘number of’ refers to because ‘procedure calls’ is not read because it is not seen by the screenreader as belonging to that edit field.  As there is no technical solution ''this requires further consideration'' see next section. '''High'''.
* Suggest change ‘submit all and finish’ to ‘submit answers’ or similar. '''P2'''.
* Suggest dialogue box gives instructions for how to save answers if don’t want to submit them now. '''Usability'''.

======= Fill in the gap answer page =======
* The function of the ‘continue’ button is not clear: suggest re-label. '''P2'''.
* Keyboard-only users cannot access feedback because it is only available via mouseovers.  It is possible to move the cursor using ‘MouseKeys’ but this is a laborious process.  In addition Dragon cannot easily reveal the feedback: the only way is to use voice commands to move the mouse pointer, but this is labourious. Need to find a Dragon/keyboard accessible way of providing feedback - ''needs further consideration''. '''High'''.
* There is no non-visual equivalent of the red and green highlights - need to provide an equivalent via text or icon with alt text. '''P1'''.
* Screenreader users cannot access the feedback.  It is possible to operate the mouse cursor with a screenreader but it is not an easy process and involves switching Jaws cursors, which means that when the mouseover window appears, Jaws cannot distinguish between it and the rest of the text on the page, and so reads them together.  It is difficult to suggest an elegant solution to this because there is not a problem with the design: it is a screenreader problem.  One option might be to provide <option> controls on incorrect answers and mark one option as ‘your answer: abc’ and the other option as ‘the correct answer: xyz’.  ''This issue requires development and testing of different prototype solutions.'' '''High'''. 
** ''Update'': Jaws has a function to read mouseovers, but this does not work with the example quiz question tested, and it is not known why.  There is an example that does work at http://www.freedomscientific.com/fs_products/Surfs_Up/MouseOver.htm which might offer guidance.
* According to the colour contrast analyser, there is insufficient contrast between the black text of the answers and the red (#FF0000) and green (#00FF00) backgrounds.  Suggest just place coloured highlight around the edit field, rather than as a background, or use a lighter green such as #80FF80 and red such as #FF8080. '''High'''.
* On subsequent attempts the correct answers that the student has entered should be retained so that they do not have to retype them – '''Usability'''.

====== hotpot ======
Tested on Moodle [[#Features]] course.
* refer to global issues on forms
* remove list mark-up from question as it is not a list item (leave answers in a list). '''Low'''.
* buttons require meaningful labels, such as "previous question" and "next question". '''P2'''.
* "1 / 22" would be more meaningful as "1 of 22" or "1 of 22 questions". '''Low'''.
* place the answer button after the answer text so that it appears as "A. 10 times as much as the force... <answer button>. '''Usability'''.
* label answer buttons as "select answer A", "select answer B" etc. '''P1'''.
* remove frames from hotpot pages.  If frames need to be kept for some reason provide meaningful and useful frame titles, such as "navigation" and "quiz".  '''P1'''. Note: Screen-readers will announce the word "frame" so this does not need to be included in the frame title.
* remove invisible "OK" button: it is not visible but it is announced by Jaws, and does not seem to be necessary in this context. '''Medium'''.
* Dragon cannnot operate the <- and -> buttons, even with "click button" command.  It is assumed that this is because the buttons do not have text labels, but this ''requires further investigation''. '''High'''.
** It is possible to operate the 'show all Qs' button.

====== forum ====== 
Tested on moodle.org open social forum.
* refer to generic issues: images, lists, headings, links, forms, editor. - for all aspects of forums, including new topic and reply.
* suggest change 'next' link to 'next page' to ensure it is fully understood. '''P2.'''
* re-order the 'Everyone can choose to be subscribed' text and the help button so that they are read in a meaningful order. '''Medium'''.
* Change the alt and title of the button from "Help, Everyone can choose to be subscribed" to "help with subscriptions" or similar so that it does not repeat the on-screen text. '''P1'''.
* mark up all message subjects as headings so that screen-readers can easily move from message to message. '''P2'''.
* the nesting of messages is not conveyed non-visually, although how to best do this ''requires further consideration''. '''Medium'''.
* remove the automation from the drop down menu to choose how messages are displayed because it cannot be used with just the keyboard. '''P2, ideally should be P1.'''
* in list of topics, user images are in a separate column, which shares its heading with 'started by' which spans two columns.  Suggest remove the images column and place the images ahead of users' names.  This will reduce the number of columns to be navigated by a screen-reader and avoid having a column without its own header. '''Medium'''.
* within topics (nested and flat) each message is within its own table.  It may be best to place all messages within one table and provide table headers (Subject, sender, date) -  this ''requires further consideration''. '''Medium'''.
* 'add a new discussion topic' is a form submit button, although there is no form, and so does not appear in screen-reader list of links.  Suggest change to a text or button link. '''Low'''.
* 'reply': suggest remove list of links to other messages on same topic from this page as they are not necessary in this context and creates much extra reading for screen-readers, or place the 'reply' section directly after the original message. '''Usability'''.
* provide label for 'display replies...' menu, e.g. 'select layout of messages' or similar. '''P2'''.
* provide label for 'rate' menu, e.g. 'rate this message', and remove the first option 'rate...' from the menu. '''P2'''.

====== exercise ====== 
* not checked - full example not yet available.
* refer to generic issues on forms, links, headings.
* authors need support in using in an accessible way.

====== database ====== 
Tested on [[#CT505]] and LTSECW courses.
* new in Moodle 1.6; can be used for student data entry.
* refer to global issues re tabs, editor, forms, images.
* refer to content authoring guidelines to support course authors in making database accessible
* retain meaningful names in field name entries, i.e. don't replace spaces in names with underscores. '''Medium'''.
* provide alt text for magnifying glass icon. '''P1'''.
* in table of entries mark up table headers, such as 'date found', 'name' etc with <th> tag.  '''P1'''.

====== workshop  ======
Tested on Moodle [[#Features]] course.
* a peer assessment activity module.
* need to support students in authoring accessible content for review by peers.
* refer to issues regarding [[#Editors]], forms, headings.

====== label (adds text, headings) ======
No specific example tested.
* authors need support in using this in an accessible way.

====== choice (a quick poll question) ======
Tested on Moodle Features.
* refer to global issues on forms (particularly labels)
* 'Anonymous choice' and 'update anytime': present results in a table with table headings so that data can be associated with column headings by a screen-reader. '''P1'''.
*'limited number of resources': include 'taken' and 'limit' in the results table so that screen-reader can associate them with the column headings. '''High'''.
* No issues found for Dragon or ZoomText.

====== survey ======
Tested on Moodle Features. 
* screen-readers cannot easily convey the layout of questions with two alternative beginnings, such as those at http://moodle.org/mod/survey/view.php?id=2332.  It may be best to avoid alternative beginnings and repeat each question with its alternative beginnings, and give each separate question a number. '''High'''.
* ensure submit buttons convey their function, e.g. "submit answers" is preferable to "click here to check and continue" which sees to imply that answers will be checked and that there are more questions to come. '''Usability'''.
* explicitly associate radio buttons with the relevant labels, e.g. 'almost never' etc., using <label> and <for> tags. '''P2, ideally should be P1'''.
* ensure all radio buttons have a label to be associated with them: if an 'unanswered' option is required, provide this text as a label. '''P2, ideally should be P1'''.
* Best practice with horizontal radio buttons ''needs to be further investigated''.

====== glossary ====== 
June '06: Empty glossary tested on Moodle Features. July '06: Glossary tested on OU Example of course web site (LTSECW).
* refer to generic issues: lists, headings, tabs, links, images.
* Change 'special' link to 'non alphabetic entries' or similar. '''P2'''.
* Change 'all' link to 'all entries' or similar. '''P2'''.
* provide alt text for printer icon, e.g. "printable version" or similar. '''P1.'''
* remove heading mark-up from printer icon as it is not a heading. '''Low'''.
* the printer icon becomes almost invisible under Windows High contrast black setting.  Suggest making it larger and/or provide a text link combined with it.  '''Medium'''.
* remove link from current 'sort' selection, e.g. when 'by last update' is selected remove the link from this text. '''Medium'''.
* provide alt text for the 'ascending' and 'descending' icons as this information is currently not available to a screen-reader. Combine the text link with the image link so that they are read together by a screen-reader. Note: Do not rely on <title> to convey this information because this is not read by default by screen-readers. '''P1'''.
* label the search edit field and re-order the search controls: place edit field first, followed by 'search full text' checkbox, followed by 'search' button. '''P2 and usability'''.
* There is no explicit label for the 'rate' menu which means Jaws has to guess the text that belongs to it when in forms mode.  Therefore provide a label, eg. "rate this entry". '''P2'''.
* Provide instructions for the 'rate' feature because users, particularly screenreader users, may not realise that they need to operate the button at the bottom of the page to submit their ratings. '''Usability'''.
* When more than one page on entries, change the 'all' link to "all pages" so that link is meaningful.  '''P2'''.
* Avoid opening new windows, e.g. if follow auto-link in glossary entry which opens a new window, and then follow link to its parent glossary, can end up with 3 glossary windows open. '''P2'''.
* In list of glossary entries mark up A, B C etc as headings. '''P2'''.

======= add new entry =======
* the 'browse' button on the upload file control is not read by Jaws in 'forms mode'.  It is not clear why this is and it ''requires further investigation.'' '''High.'''
* change 'revert' button to "cancel entry" or similar. '''P2'''.
* remove alt text from checkboxes because it repeats the text of the control and is therefore repeated by Jaws: alt text is not required for checkboxes, radio buttons etc, but <label> and <for> tags are required. '''P2'''.

======= Browse by category =======
* Provide label for drop down menu, such as 'choose category'. '''P2'''.
* remove automation from drop down menu as it is not controllable with the keyboard only, and provide a 'go' button or similar. Note: this may be an IE problem as it does not seem to occur in Firefox and therefore ''needs further testing''.'''P2, ideally should be P1'''.

====== lams ======
lams server required - developer issue therefore not tested

====== wiki ======
no content available yet therefore cannot be tested.
* generic issues with blogs: 
** screen-reader management of information; 
** need to develop support information for students 
** text-based and so therefore should be technically accessible, as long as headings and meaningful link text used.

====== assignment ======
Tested on Moodle Features. 
* refer to generic issues on forms, editor.
* Upload file: ensure label explicitly associated with upload field. '''P2, ideally should be P1'''.
* Upload file: Dragon does not recognise the 'browse' button, either when say "click browse" or "click button".  This may be because the button does not have it's own label because it is part of the 'file' form control.  Dragon users can access the field by saying "type text" but may not know to do this.  Suggest if possible provide an explicit label for the button.  ''May require further investigation/testing''.
* online text assignment: on re-edit submission page provide a label for field so that screen-reader knows what it is for. '''P2, ideally should be P1'''.

====== scorm======
Developer/author facing tool therefore not tested.

====== resource ======
Developer/author facing tool therefore not tested.
Authors require support in using in an accessible way.

====== chat ======
'open chat event' tested on Moodle features demo.
* the constant refreshing means that screen-readers cannot use this chat feature: it is impossible to type in the edit field because 'forms mode' keeps being switched off.  ''Needs further consideration''.  Auto-refresh = '''P2, ideally should be P1'''.
* suggest change order of text on chat-launch page to read: "an open chat event... this is a chat room with...click here to enter...".  '''Medium'''.
* suggest change 'click here to enter the chat now' to 'enter the chat now'.'''P2'''.
* Dragon cannot dictate words into the edit field - can only dictate letter by letter.  The reason for this is not known and ''needs further investigation''. '''High'''.
* Dragon user has to say "press enter" to send their message because there is no button to operate.  
* It may not be clear to other users that they have to press enter to send a message.  Suggest provide a 'send' button which will make this clear, and would be operable by Dragon.  ''Usability''.
* Dragon cannot select the 'help' button, even when using the "click image" command. The reason for this is not known and ''needs further investigation''. '''High'''.

====== lesson ======
Not tested because can be used in a variety of different ways.  
Authors require support for using in an accessible way.
* Refer to global issues regarding forms and headings.

====== journal ====== 
* no content available and so not tested

===== Blocks =====

====== activity_modules ======
Tested on Features.
'Activities', block on course page is list of text links with icons - see global issues on images/icons.

The pages linked to from the activity block were all checked.  All were found to have the correct markup for tables and headings.  The following pages do not have any accessibility issues: Assignments, Chats, Glossaries, Lessons, Quizzes, SCORMs/AICCs, Surveys, Wikis, Workshops.  

There are some issues with the following pages:

======= Forums page =======
* ensure all columns have a table header, e.g. 'learning forums' table has an unheaded column with the digit '5' in it. '''P1'''.

======= Hot Potatoes Quizzes page =======
* it is not clear why there is a 'show/hide topic' link in this table on the Features demo. '''Usability'''.

======= Resources page =======
* Jaws does not annouce the 'tabledividers' used in this table.  If topic numbers are only used at the beginning of the section of the table it may be best to create separate tables for each topic, and remove the 'topic' column. '''Low'''.

====== admin ======
* On the site homepage this gives access to site administration; on course pages it gives access to course administration.
* Admin/editing-teacher facing generally, and for the OU VLE project.
* Student-facing for the Open University OCI project.

Tested on CT505.
* On course page block is list of text links with icons - see global issues on images/icons.
* Asterisk indicating missing profile description is not part of the 'edit profile' link text and therefore is only read by screenreader when reviewing the page, and is not read when tabbing through links.  It therefore may be missed depending on how the page is being read.  The extent to which this is a problem cannot be predicted and so ''this requires further consideration''.

======= Change password =======
* remove all alt text from form fields because screerneaders read this as well as the onscreen text.  Alt text is not necessary in these situations. '''High'''.
* See also global issues on forms (provision of <label> on all controls). '''P2.'''
* Suggest move 'change password' button to be left-aligned so that it is easy to find with screen magnifier (or at least be centred). '''High'''.
* Page confirming change of password has no accessibility issues.

======= Unenrol from course =======
No accessibility issues.

======= Grades =======
Tested on Moodle Features.
Presented as a horizontal table in which titles of activities often wrap onto several lines.
* Suggest reformat into vertical table so that titles of activities do not have to wrap. '''Usability'''.
* Provide Table Headers such as 'activity', 'maximum grade', 'your grade' with columns beneath. '''P1'''.
* remove links from dashes (indicating no grade yet) and from grade numbers, as these are not meaningful links, they repeat the text links to the activities, and do not seem to be necessary.
* Remove <th> tags from data that is not a table header, e.g. the title of activities and the maximum grade numbers. '''Medium'''.
* Replace 'stats' with 'Statistics' or 'statistics on grades' to convey the meaning. '''P2'''.

====== blog_menu ======
Not yet tested - to be tested with blogs.

====== blog_tags ======
Not yet tested - to be tested with blogs

====== calendar_month (Mini calendar) ======
Tested on early OU Moodle instantiation. 
* [[#Outstanding issues]]. The link ‘January 2006’ does not really indicate that the link goes to a month view. This text also acts as a heading but is not marked up as one. Suggest use [[#Hidden text]]/ link title, "Goto month view". '''P2''' 
* refer to generic issues on links (date link to be meaningful).
* Also refer to main calendar issues.

====== calendar_upcoming (Upcoming events) ====== 
Tested on early OU Moodle instantiation. 
* List of events from calendar, should be marked up as a list. '''P2'''
* Poor colour contrast for ''dimmed text'' for example, "Today (12:00 AM)". '''P3, ideally should be P1'''.
* Refer to main calendar issues.

====== course_list (My courses) ======
Tested on Moodle Features.
* My courses (student view)/Course categories (admin view).
* List of text links marked up OK - no accessibility issues.

====== course_summary ======
* This is an anonymous block (no title).
* Site description on site homepage; course summary on course pages.
* Authors need support in using in an accessible way.

====== glossary_random ======
No example available so not tested.

====== html ======
Authors need support in using in an accessible way.

====== loancalc ======
No example available - not tested.

====== login ======
Tested on [[#Ndf-Moodle]] site.
* Table used for layout; suggest replace with ordered list <code>&lt;ol></code>. '''P2'''.
* General [[#Form Elements]] issues, use <code>&lt;label></code>. '''P2'''.
* Note, the block is only visible when user is ''not'' logged in.

====== messages ======
tested on CT505
* Message block: ensure all links are meaningful, e.g. the number that follows the name of the sender is not meaningful.  '''P2, ideally should be P1'''.
* auto-refresh in various message-related windows causes problems for screen-readers, in particular it turns 'forms mode' off which in turn prevents students from entering text. '''P2, ideally should be P1'''.

======= Contact window =======
* provide alt text for 'add contact', 'block contact' and 'message history' instead of, or as well as titles, because screen-readers read alt text only in their default settings. '''P1'''.

======= Message window =======
* auto-refresh does not seem to be necessary in this window, because user is just reading the current message. '''P2, ideally should be P1'''.
* provide an explicit label for the edit field, e.g. 'reply', or similar. '''P2'''.

======= Send message window =======
* provide an explicit label for the edit field. '''P2'''.

====== news_items ======
Tested on Moodle.org.
* 'more...' links are read by screen-readers as "more dot dot dot", also this link text is not meaningful in its own right, therefore remove the 'more' link and make the subject of the news item the link text. '''P2'''.
* items in block should be marked up as a list to support screen-reader users. '''P2'''.

====== online_users ======
Tested on Moodle Features.
* See generic issues regarding images: icon links and text links should be combined.

====== participants (people) ======
Tested on Moodle.org
* image link to show/hide facilitators should be given a more meaningful label, such as 'show facilitators' and 'hide facilitators'. '''P2'''.
* links to order lists by different headings, and in ascending or descending order, are not conveyed non-visually.  Best practice for this feature ''needs to be considered further.'' '''High'''.
* provide a table heading at the top of the 'user picture' column, e.g. 'picture' or 'user picture' or similar so that screen-readers can identify the content in that column. '''P1'''.

====== quiz_results ======
See quizzes.

====== recent_activity ======
(Was mistakenly under 'activity modules' - see above.)
Tested on Moodle Features. 
* New users - OK, marked up as a list.
* New forum posts - should be marked up as a list. '''P2'''.
* The linked document, 'Full report of recent activity' contains repeating validation errors '''P2''', misformed lists '''P2''', and nested layout tables '''P2'''. 
* See [http://moodle.org/course/view.php?id=5 Using Moodle], [http://moodle.org/course/recent.php?id=5  Full report...].

====== rss_client ======
Tested on CT505.
* A list of links generated from an (external) RSS (XML-based) news feed.
* The quality of the link text is dependent on the quality of the feed.
* Links should open in the same window, or warn the user where they do not. '''P2'''.
* The unordered list should be marked up as such, using &lt;ul>. '''P2'''.

====== search_forums ======
Tested on moodle.org.
* refer to generic issues on forms, headings
* provide explicit label for edit field. '''P2'''.
======= Results page: =======
* to support screen-reader navigation the location/subject of each result could be marked up as a heading so that screen-readers could jump from one to the next easily. '''P2'''.
* the presentation of the location of the message will be difficult for screen-readers to convey but how to do this more easily ''needs further consideration''. '''Medium'''.
* the separators in the location/subject are "->" which is announced by a screen-reader as "dash greater than" or "dash greater", which is not meaningful.  Suggest replacing with a colon or slash. '''Medium'''.
* the highlight of the search term is not available non-visually.  However an immediate solution is not known.  Perhaps it is sufficient that screen-reader users can do a 'find on page' to search for their search term in the results.  This ''needs further consideration''. '''Low'''.

====== section_links ======
* This block can only appear on course pages, not the site homepage.
* List of links to weeks/topics.
* should be marked up as a list. '''P2'''.
* Links "1, 2, 3..." are not very meaningful on own when read by screenreader. Suggest include title of sections.  '''P2'''.

====== site_main_menu ======
Authors need support in using in an accessible way.

====== social_activities ======
No example available so not tested.

===== Authentication modules (/auth) =====

# Note, the user requires ''admin'' privileges to switch between the different authentication methods for testing. 
# Many of the authentication modules do not have a student-facing user-interface – they defer to the  main ''/login'' scripts.

cas
db
email
fc
imap
ldap
manual
nntp
none
pam
pop3
radius
shibboleth

===== Course Format (/course/format) =====
Course formats control the display of an individual course, including the arrangement of Moodle blocks in the left and right columns. All the course formats use a table to lay out the columns, except in the 'weekscss' format. The course is divided into sections which may be time-period or topic based - again a layout table is used, except in 'weekscss'.

====== lams ======
* 2-column table-based layout; uses the LAMS module.
* Not tested.

====== scorm ======
* Not tested; requires SCORM content.

====== social ======
* 3-column table-based layout.
* Contains an embedded forum - see ''forum'' tests.
* Recommendation, should become a table-less layout. '''P2'''.

====== topics ======
* Recommendation, should become a table-less layout. '''P2'''.

====== weeks ======
* Recommendation, should become a table-less layout. '''P2'''.

====== weekscss ======
* A copy of the weeks course format, to demonstrate a layout without tables.
* The CSS is in the Standard theme style sheets. The left and right columns are floated. Each week is a list item.
* To be superseded by ''weeks'', above.

===== Themes (/themes) =====
* standard theme has been most tested and improved.


formal_white
standard
standardlogo
oceanblue
wood
chameleon
metal
standardgreen
orangewhite
cornflower
standardwhite
standardred
standardblue
orangewhitepda

=== Generic Forms in Moodle ===

This section discusses the benefits and possible solutions for implementing generic forms in Moodle.

HTML forms are widely used in Moodle to enable students, and teachers and administrators to interact with the system and each other. The forms are either produced by core Moodle code, Moodle extensions (modules, blocks and so on) or third-party libraries (for example, the HTML-Area editor).

As part of the Moodle Accessibility Specification, generic and specific accessibility problems are being identified for forms throughout Moodle. There are also widely accepted limitations to HTML forms – notably, the requirement for client and server-side scripting (Javascript and PHP, in the case of Moodle), to initialise form data, validate, calculate and handle user input errors. This causes complexity and maintenance issues for large forms.

XForms is a W3C recommendation that will form part of XHTML 2.0 and other XML specifications. It addresses the problems inherent in HTML forms, by separating data, logic and presentation:
# Form data – XML instance data – initial, transitional and final data. A separate XML document.
# Logic – XForms Model – validation, constraints, required values.
# Presentation – XForms User Interface – visible form controls, equivalent elements for each HTML form element, with additions. Can be styled with CSS. 

The logic and presentation components require a host XML document. The XForms Model can be placed in the &lt;head> of a XHTML document, while the User Interface should be in the &lt;body>. The 'scripting' built-in to XForms is not procedural, but declarative in a similar manner to XSL-Transformations.

XForms are not at present supported natively by any widely used Web browser. There are a number of client and server-side implementations. Most client-side solutions require a browser-plugin, the one that does not uses Javascript to transform to HTML [ www.formfaces.com ]. A medium-term solution will require a transformation from XForms to XHTML forms, and at present the only server-side implementations for this are in Java.

It would be a significant and time-consuming project to implement a server-side implementation for all of XForms 1.0 to XHTML in PHP. To be worthwhile, the project should be loosely coupled to Moodle, so that non-Moodle developers can use the software. In the short-term, careful consideration would be required to select the most useful subset of XForms for an initial implementation. Also, this approach is only as useful as the quality of the XHTML that is produced.

An alternative would be – '''TODO''' [S.Marshall's code].

Accessible and usable XHTML forms:
# Appropriate use of <code>&lt;label></code> and 'for' to describe ''every'' form control (for example, the day, month and year select-(drop-down) lists in a date of birth form). Labels (or parts of labels) that are useful to none-visual users, but superfluous to many visual users may be 'hidden' using CSS <code>{ position:absolute; top:-1000px }</code>.
# Appropriate use of <code>&lt;fieldset></code> and <code>&lt;legend></code> to structure, group and summarise form controls.
# Do not use scripting to submit a form, for example using the <code>'onchange'</code> event in a select-(drop-down) list. Or to change the keyboard focus, for example with auto-refresh.
# Use minimal scripting to aid usability, and allow it to be disabled (or provide an alternative) for accessibility.
# Minimal and semantic use of non-form mark-up in forms. So prefer an ordered list <code>&lt;ol></code>, in place of a table for layout.
# A consistent, clear and multi-modal way to indicate required/mandatory fields (so, not just using colour or an un-explained asterisk).
# A consistent, clear and multi-modal way to display error messages (make it clear if the user, or system is at fault).

== Issues for supporting course authors ==
This section has been included to "park" issues that emerged while undertaking the evaluations that do not require technical responses but may need to be included in guidance notes for course authors.
=== usability ===
* automatic month selection? e.g. when select June in one field automatically select June in following field instead of leaving it as Jan?? (but find accessible solution too)
* prevent creation of Moodle 'labels' that are inappropriate, e.g. prevent an H2 if there is not already an H1.  Support authors in using 'label' in an accessible way.
* Where ordered lists are styled to be labelled A, B, C etc the Jaws screen-reader reads the labels as 1, 2, 3 (i.e. it does not recognise the visual styling).

=== authoring accessible material ===
* meaningful labels in database

== Issues for supporting disabled students ==
This section has been included to "park" issues that emerged while undertaking the evaluations that do not require or can not be resolved by technical responses but may need to be included in guidance notes for disabled students.
* Where ordered lists are styled to be labelled A, B, C etc the Jaws screen-reader reads the labels as 1, 2, 3 (i.e. it does not recognise the visual styling).
* Screen-readers are designed to read forms that only contain form controls (edit fields, checkboxes etc) they therefore can fail to read forms that contain links and paragraphs in a meaningful way, and it may miss certain aspects.  Quizzes with 'fill in the gap' in the middle of sentences may be particularly problematic.  The best way for screen-reader users to interact with a page containing a form is to review the page before completing the form - in this way any other content, such as links and paragraphs, will also be read out.

== Resources ==

=== Checklists, Recommendations ===

* OU internal, SQAPI PAT 8.1.1, Resources and guidelines for accessible software. Marion Edwards et al, 17 March 2003.
* BSI/DRC, [http://www.drc-gb.org/default.aspx?page=3364 PAS 78:2006, Guide to good practice in commissioning accessible websites]. British Standards Institute, 2006. (Available from the Disability Rights Commission or the BSI, PDF, 66 pages.)
* [http://www.webaim.org/standards/508/508checklist.pdf WebAIM, Section 508 Web Accessibility Checklist for HTML] (PDF, 4 pages), Paul Bohman, updated 29 March  2001. 
* [http://www.usdoj.gov/crt/508/archive/oldsoftware.html US Department of Justice, Software Accessibility Checklist, Section 508], date unknown (2004).
* [http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html W3C, Checklist... for Web Content Accessibility Guidelines 1.0], 5 May 1999.
* [http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html IMS Guidelines for Developing Accessible Learning Applications], 12 July 2004
* [http://www.bbc.co.uk/guidelines/newmedia/accessibility/ BBC, Accessibility Checklist v0.20], 29 March 2005, Jonathan Hassell. (Relatively short list but with lots of links to more comprehensive BBC guidelines.)
* [http://www-306.ibm.com/able/guidelines/web/accessweb.html IBM, Web accessibility], last updated 06 August 2004 (Similar approach to the BBC).
* [http://www.w3.org/TR/WCAG20/ WCAG 2.0] Working Draft 27 April 2006.
* [http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html WCAG 2.0 Checklist]
* [http://www.w3.org/TR/WCAG20/appendixD.html Comparison of WCAG 1.0 Checkpoints to WCAG 2.0]
* [http://www.w3.org/WAI/intro/atag.php Authoring Tool Accessibility Guidelines (ATAG)]
* [http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/ How People with Disabilities Use the Web], Working-Group Internal Draft, 5 May 2005.


=== Forms Resources ===

* [http://www.alistapart.com/articles/prettyaccessibleforms Prettier Accessible Forms], A List Apart/ Nick Rigby, 20 June 2006.
* [http://www.alistapart.com/articles/sensibleforms Sensible Forms: A Form Usability Checklist], A List Apart/ Brian Crescimanno, 19 December 2005.
* [http://www.w3.org/MarkUp/Forms/ The Next Generation of Web Forms] W3C forms activity.
* [http://www.w3.org/TR/2006/REC-xforms-20060314/ XForms 1.0 Second Edition], W3C Recommendation, 2006.
* [http://xformsinstitute.com/essentials/ XForms Institute presents: O'Reilly XForms Essentials], Micah Dubinko (2003).
* [http://www.ics.uci.edu/~rohit/IEEE-L7-XForms.html Can XForms Transform the Web?] Rohit Khare, 9 March 2000.


=== Sites Tested ===

* <em id="Soc-Forum">Soc-Forum</em>: hosted at Moodle.org, [http://moodle.org/mod/forum/view.php?f=147 Open Social Forum].
* <em id="Features">Features</em>: hosted at Moodle.org, [http://moodle.org/course/view.php?id=34 Features Demo Course].
* <em id="OU-Features">OU-Features</em>: hosted internally at OU (Ndf-Moodle), copy of the 'Features Demo Course'.
* <em id="CT505">CT505</em>: hosted internally at OU (Ndf-Moodle), generic Moodle 1.6 demo/developer site, Topics-format course, demonstration modules including 'database'.
* <em id="Ndf-Moodle">Ndf-Moodle</em>: hosted internally at OU, generic Moodle 1.6 demo/developer site (cvs: MOODLE_16_STABLE), with example blocks and courses.
* <em id="Vledemo">Vledemo</em>: hosted internally at OU, was a Moodle 1.5/1.6-development sandbox in Jan/Feb 2006.

=== See also ===

* http://www.pubbliaccesso.gov.it/normative/Italian_Legislation_on_Accessibility.doc

[[Category:Developer|Moodle Accessibility Specification]]
[[Category:Accessibility]]