MoodleDocs - User contributions [en]

Running acceptance test

2020-06-08T09:00:18Z

Bawjaws: Add non-selenium instructions.

== Short version ==

...or how I got it to work on Ubuntu and some of the problems encountered.

You need a bunch of browsers and terminal windows open to do this.

==== 1. Background ====

# I am using the desktop version of Ubuntu 17.04 so there are no issues about running this software in headless mode. Running in headless mode was not tested.
# Moodle is version 3.3 and is a fully installed and working version using the 'standard' Ubuntu LAMP stack.

==== 2. Set up Selenium ====
First, you should have a look at [[Acceptance_testing/Browsers/Working_combinations_of_OS%2BBrowser%2Bselenium#Working_combinations_of_OS.2BBrowser.2Bselenium|working combinations of OS+Browser+selenium]].

# Download the Selenium Standalone Server from [http://www.seleniumhq.org/download/ http://www.seleniumhq.org/download/]. It's a single JAR file, put it anywhere handy.
# Download the Chrome driver from [https://sites.google.com/a/chromium.org/chromedriver/ https://sites.google.com/a/chromium.org/chromedriver/]. Ensure you have the right version of the Chrome driver - see [[#Trouble_shooting| Trouble shooting]]. (Firefox is currently problematic. See [[Actual_Selenium_with_old_Firefox_47.0.1]] if you need to try to make it work.)
# Unzip the driver (it's a single file) and copy to /usr/local/bin (should work anywhere on the path)
# If not installed already, '<tt>sudo apt install default-jre</tt>'
# Start Selenium - '<tt>java -jar /path/to/your/selenium/server/selenium-server-standalone-N.NN.N.jar -port 4444</tt>'
# check it works, access 'localhost:4444/wd/hub/' in your browser and check you can create a new Chrome session.

If running headless or the above doesn't work ("Selenium server is not running" when running the behat tests). Try the following
# Run '<tt>Xvfb -ac :99 -screen 0 1280x1024x16 &</tt>'
# Then immediately, '<tt>export DISPLAY=:99</tt>'
# The run the Selenium command as above

==== 3. Set up Moodle ====

# Create a new 'dataroot' area for files especially for behat adjusting permissions accordingly.
# If not there already, add Section 11 from config-dist.php to your config.php file and review the settings.
# $CFG->behat_wwwroot needs to point to your Moodle site yet be different from the 'normal' wwwroot (e.g. if you used localhost for wwwroot use 127.0.0.1 for the behat_wwwroot). Whatever you choose, make sure it works.
# $CFG->behat_dataroot should point to the directory you created above
# $CFG->behat_prefix should be fine.
# Set up $CFG->behat_profiles to select Chrome as the browser...

$CFG->behat_profiles = [
'default' => [
'browser' => 'chrome',
'extensions' => [
'Behat\MinkExtension' => [
'selenium2' => [
'browser' => 'chrome',
]
]
]
]
];

==== 4. Configure Behat for Moodle ====

# Run '<tt>php admin/tool/behat/cli/init.php</tt>' (from the root of your Moodle install). This installs all the required software and creates the test version of Moodle.

==== 5. Run Behat tests ====

# Run '<tt>vendor/bin/behat</tt>'. If you don't want to run all the tests add '<tt>--tags="@something"</tt>' where the @something refers to the tags at the top of most feature files. Use comma-separated list like '<tt>@some_thing,@some_thing_else</tt>' to run tests from multiple areas. See upstream documentation on Gherkin filters for advanced syntax and more complex examples.
# After some initial setup dots should start to go by. It's a while before Selenium is first accessed. On the Linux desktop a new Chrome window appears and the testing process 'remote control' starts (hopefully!)

== Prerequisite ==
Before initializing acceptance test environment for running behat, you should ensure:
# [[Acceptance_testing#Requirements Meet min. system requirements for running tests]]
# [[Acceptance_testing#Installation Have set min. config variable in config.php for behat]]
# [[Acceptance_testing#Installation Downloaded composer dependencies]]

== Overview ==
Acceptance tests (also known as behat), use [http://www.seleniumhq.org/download/ Selenium server] and can be run as:
# '''Single run:''' In single run, only one behat run is executed. So all features are executed in this single run.
# '''Parallel runs:''' (Since Moodle 3.0) Parallel runs allow dev's to execute multiple behat runs together. This was introduced to get acceptance tests results faster. To achieve this:
#* Features are divided between multiple behat runs
#* Symlinks behatrun{x} (x being the run process number), are created pointing to moodle directory, so site for run 1 is accessible via https://localhost/moodle/behatrun1
#* Process number is included as suffix to $CFG->behat_prefix.
#* Process number is suffixed to $CFG->behat_dataroot.

== Step 1: Initialise acceptance test environment ==
Before running acceptance tests, environment needs to be initialised for acceptance testing.

=== Single run ===
For initialising acceptance tests for single run, above command is sufficient.
<code>
php admin/tool/behat/cli/init.php
</code>

=== Parallel runs ===
For initialising acceptance tests for parallel runs, you can use one of the following options
# '''-j=<number> or --parallel=<number>''' (required) Number of parallel behat run to initialise
# '''-m=<number> or --maxruns=<number>''' (optional) Max parallel site which should be initialised at one time. If your system is slow, then you can initialise sites in chucks.
# '''--fromrun=<number>''' (optional) Initialise site to run specified run from. Used for running acceptance tests on different vms
# '''--torun=<number>''' (optional) Initialise site to run specified run till. Used for running acceptance tests on different vms
# '''-o or --optimize-runs''' (optional) This option will split features with specified tags in all parallel runs, so they are executed first when parallel run gets executed.
# '''-a=<name> or --add-core-features-to-theme=<name>''' (optional) Since Moodle 3.2. Use this option to add all core features to specified themes (comma separated list of themes)
<code>
// Below command will initialise moodle to run 2 parallel tests.
php admin/tool/behat/cli/init.php --parallel=2
</code>

== Step 2: Running acceptance test environment ==
=== Single run ===
Run either of the following commands. For more options '''vendor/bin/behat --help''' or http://docs.behat.org/guides/6.cli.html
<code>
vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behatrun/behat/behat.yml
</code>

You almost always want to limit the number of tests that are run. To run all the tests in one plugin:

<code>
vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behatrun/behat/behat.yml --tags mod_myplugin
</code>

To run all the tests in one .feature file:

<code>
vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behatrun/behat/behat.yml /path/to/moodle/mod/myplugin/tests/behat/testsomething.feature
</code>

To run a single scenario:

<code>
vendor/bin/behat --config /path/to/your/CFG_behat_dataroot/behatrun/behat/behat.yml /path/to/moodle/mod/myplugin/tests/behat/testsomething.feature:40
</code>

Here, '40' is the line-number of the feature file where the Scenario starts.

=== Parallel runs ===
For running parallel runs, use following command

php admin/tool/behat/cli/run.php

Following optional options are available for custom run:
# '''--feature''' Only execute specified feature file (Absolute path of feature file).
# '''--suite''' Features for specified theme will be executed.
# '''--replace''' Replace args string with run process number, useful for output and reruns.
# '''--fromrun''' Execute run starting from (Used for parallel runs on different vms)
# '''--torun''' Execute run till (Used for parallel runs on different vms)
# Behat options can be passed for filtering features/scenarios:
#* In case you don't want to run Javascript tests, use the Behat tags option to skip them, '''--tags="~@javascript"'''
#* In case you want to run specific scenario, use the Behat name option to run it, '''--name="Filter user accounts by role and cohort"'''
#* In case you want to run specific feature file, use the Behat feature option to run it, '''--feature="/PATH/TO/MOODLE/admin/tests/behat/filter_users.feature"'''

Example: Initialise and run Behat tests for a custom plugin under a custom theme:

php admin/tool/behat/cli/init.php --parallel=3 --add-core-features-to-theme="mytheme"
php admin/tool/behat/cli/run.php --tags="@tool_myplugin" --suite="mytheme"

=== Common options for running tests ===
==== Tests filters ====
With the '''--tags''' or the '''-name''' Behat options you can filter which tests are going to run or which ones are going to be skipped. There are a few tags that you might be interested in:
* '''@javascript''': All the tests that runs in a browser using Javascript; they require Selenium to be running, otherwise an exception will be thrown.
* '''@_file_upload''': All the tests that involves file uploading or any OS feature that is not 100% part of the browser. They should only be executed when Selenium is running in the same machine where the tests are running.
* '''@_alert''': All the tests that involves Javascript dialogs (alerts, confirms...) are using a feature that is OS-dependant and out of the browser scope, so they should be tag appropriately as not all browsers manage them properly.
* '''@_switch_window''': All the tests that are using the '''I switch to "NAME" window''' step should be tagged as not all browsers manage them properly.
* '''@_switch_iframe''': All the tests that are using the '''I switch to "NAME" iframe''' steps should be tagged as it is an advanced feature and some browsers may have problems dealing with them
* '''@_cross_browser''': All the tests that should run against multiple combinations of browsers + OS in a regular basis. The features that are sensitive to different combinations of OS and browsers should be tagges as @_cross_browser.
* '''@componentname''': Moodle features uses the [https://docs.moodle.org/dev/Frankenstyle Frankenstyle] component name to tag the features according to the Moodle subsystem they belong to.

==== Output formats ====
Since Moodle 3.1 option for output is:
<code>
--format=pretty --out=/path/to/pretty.txt --format=moodle_progress --out=std
</code>
Before Moodle 3.1 option for output was:
<code>
--format='moodle_progress,pretty' --out=',/path/to/pretty.txt'
</code>
Following output formats are supported:
# '''progress''': Prints one character per step.
# '''pretty''': Prints the feature as is.
# '''junit''': Outputs the failures in JUnit compatible files.
# '''moodle_progress''': Prints Moodle branch information and dots for each step.
# '''moodle_list''': List all scenarios.
# '''moodle_stepcount''': List all features with total steps in each feature file. Used for parallel run.
# '''moodle_screenshot''': (since Moodle 3.1) Take screenshot and core dump of each step. With following options you can dump either or both.
## --format-settings '{"formats": "image"}'**: will dump image only
## --format-settings '{"formats": "html"}'**: will dump html only.
## --format-settings '{"formats": "html,image"}'**: will dump both.
## --format-settings '{"formats": "html", "dir_permissions": "0777"}'**
If you want to see the failures immediately (rather than waiting ~3 hours for all the tests to finish) then either use the -v option to output a bit more information, or change the output format using --format. Format 'pretty' ('''-f pretty''') is sufficient for most cases, as it outputs each step outcomes in the command line making easier to see the progress.

== Advance usage ==
=== Rerun failed scenarios ===
With slow systems or parallel run you might see some random failures, to rerun only failed scenarios (to eliminate random failures), use --rerun option
# '''Single run:''' --run="absolute_path_to_empty_file" (Behat will record failed scenarios in this file, and when run again only failed scenarios will be run)
# '''Parallel run:''' --rerun="absolute_path_to_empty_file_{runprocess}.txt --replace="{runprocess}" ({runprocess} will be replaced with the process number for recording fails in the specific run process).
'''Since Moodle 3.1 --rerun option don't accept any value, as it is handled internally by behat'''

=== Running behat with specified theme (Since Moodle 3.2) ===
You can run behat with any theme installed. To execute behat with specified theme use '''--suite={THEME_NAME}''' option, while running behat. By default the features in theme behat folder will be executed for the suite. But if you want to run all core features with the specific theme then initialise acceptance test with --add-core-features-to-theme={THEME_NAME}, e.g.

<code>
php admin/tool/behat/cli/init.php --add-core-features-to-theme=clean
vendor/bin/behat --suite=clean --tags="@enrol_foobar"

</code>

That is a core theme but it will work with custom theme. No = or quotes needed around the theme name.

Make sure that <tt>$CFG->theme</tt> is '''not set''' in your config.php.

==== Override behat core context for theme suite ====
To override behat step definitions so as to run behat with specified theme, you should create a contexts within '''/theme/{MYTHEME}/tests/behat/''' with prefix behat_theme_{MYTHEME}_ and suffixed with the context being overridden. For example, if you want to override behat_mod_forum context, then you should create a class /theme/{MYTHEME}/tests/behat/mod_forum/behat_theme_{MYTHEME}_behat_mod_forum.php

==== Blacklist behat context or features to run in theme suite ====
To blacklist contexts/ features to be executed by theme suite you should create a /theme/{MYTHEME}/tests/behat/blacklist.json file with following format. Following will not use step_definitions from behat_grade and behat_navigation while running theme suite. Also, scenarios in auth/tests/behat/login.feature and grade/tests/behat/grade_hidden_items.feature won't be executed with theme suite.
<code>
{
"contexts": [
"behat_grade",
"behat_navigation",
],
"features": [
"auth/tests/behat/login.feature",
"grade/tests/behat/grade_hidden_items.feature",
]
}
</code>
==== Override core behat selectors ====
To override behat selectors in specific theme, you should create a class behat_theme_{MYTHEME}_behat_selectors in /theme/{MYTHEME}/tests/behat/behat_theme_{MYTHEME}_behat_selectors.php extending behat_selectors.

=== Use php built in web server ===
You can use php built-in-web server for executing behat runs. To do so:
# Open a command line interface and '''cd /to/your/moodle/dirroot'''
# '''php -S localhost:8000''' (This is the test site URL that moodle uses by default, if you want to use another one you can override it in config.php with $CFG->behat_wwwroot attribute; more info in https://docs.moodle.org/dev/Acceptance_testing#Advanced_usage or config-dist.php)
# Update $CFG->behat_wwwroot = localhost:8000; in config.php

=== Define custom options for parallel runs ===
You can set following custom config options for parallel runs via $CFG->behat_parallel_run. It's an array of options where 1st array is for 1st run and so on.
<code>
array (
'dbtype' => 'mysqli',
'dblibrary' => 'native',
'dbhost' => 'localhost',
'dbname' => 'moodletest',
'dbuser' => 'moodle',
'dbpass' => 'moodle',
'behat_prefix' => 'mdl_',
'wd_host' => 'http://127.0.0.1:4444/wd/hub',
'behat_wwwroot' => 'http://127.0.0.1/moodle',
'behat_dataroot' => '/home/example/bht_moodledata'
)
</code>

To set different selenium servers for parallel runs, you can use following. NOTE: Running parallel (headless) runs on different selenium servers avoid random focus failures.
<code>
$CFG->behat_parallel_run = array (
array ('wd_host' => 'http://127.0.0.1:4444/wd/hub'),
array ('wd_host' => 'http://127.0.0.1:4445/wd/hub'),
array ('wd_host' => 'http://127.0.0.1:4446/wd/hub'),
);
</code>

=== Write new tests and behat methods ===

If you want to write tests for your own integration, you can do so by creating new tests with format .feature. Follow instructions in [[Writing_acceptance_tests|this page]] to write new tests.

It is also possible to add new steps the moodle behat integration. In order to do so, you will have to create a new .php class with the prefix '''behat_'''. Copy the format from '''lib\behat\behat_base.php''', but set your class to extend the behat_base class instead of the MinkExtension. You can define new behat steps by declaring functions with the appropriate heading.

You will not be able to use these steps and features right away. Check [[Running_acceptance_test#New_step_definitions_or_features_are_not_executed|this section]] for instructions on how to update the behat integration.

For further information on how to create new steps definitions, check [[Acceptance testing/Custom acceptance steps]].

=== Running acceptance tests with different browser ===

If you follow the steps above, Behat will run with Chrome.

You can get it to run with other browsers. The basic idea is to expand the $CFG->behat_profiles array in config.php to list more browsers.

<code>
$CFG->behat_profiles = array(
'chrome' => array(
'browser' => 'chrome',
'tags' => '@javascript',
)
);
</code>

[[Acceptance_testing/Browsers|More info about alternative browsers]]

=== Start multiple selenium servers ===
From command line Start selenium servers at different ports (say 4444, 4445, 4446 for 3 parallel runs)
<code>
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4444 &
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4445 &
java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port 4446
</code>

Alternative way of running three Selenium servers in parallel:

$ printf %d\\n {4444..4446} | xargs -n 1 -P 3 java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar -port

=== Run tests directly in Chrome, with no Selenium ===

Historically, the tests would talk to a Selenium server, which would then tell the target browser what to do. More and more, the browsers themselves contain such a server and you can talk to them directly, which is faster and easier. Work was done to get this working with Chrome in MDL-58948, but it still needs some further setup to get it working, which is detailed in the bug ticket, and which I'll copy below:

Replace your current behat config with the abve, the api_url is where you'll talk directly to your Chrome browser.
<code>
$CFG->behat_config = [
'default' => [
'extensions' => [
'DMore\ChromeExtension\Behat\ServiceContainer\ChromeExtension' => [],
'Behat\MinkExtension' => [
'browser_name' => 'chrome',
'base_url' => $CFG->behat_wwwroot,
'goutte' => null,
'selenium2' => null,
'sessions' => [
'javascript' => [
'chrome' => [
'api_url' => 'http://localhost:9222'
]
]
]
]
]
],
];
</code>

Use composer to install two more required libraries:
<code>
composer require --dev dmore/behat-chrome-extension
composer require --dev dmore/chrome-mink-driver
</code>

If you try to run the tests it will tell you that Chrome isn't running, in a second tab run the following to start Chrome (or chromium-browser on Ubuntu)

<code>chrome --disable-gpu --headless --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222</code>

This is running headless so you won't see any windows pop up as the tests run, though it runs in the other mode too.

Behat should now run as before, but faster.

=== Using Docker to start selenium server ===
==== What is Docker ====
Docker is a app container, it's a kind of virtual machine, but only for one app, service, so you can download
a docker image and run a selenium server without worry in how to configure selenium in your machine, one for chrome, others for firefox, you either don't need to install the browsers in your machine
To install docker follow this link; https://docs.docker.com/engine/installation/

==== Selenium docker images ====
There is many docker images available, for many browser, the complete list is in https://hub.docker.com/u/selenium/
for moodle you can use standalone version.
You can download specific selenium version too, for example, for firefox, moodle recommend selenium 2.53.1, see: [https://docs.moodle.org/dev/Acceptance_testing/Browsers/Working_combinations_of_OS%2BBrowser%2Bselenium What version do I need?]

so the command will be:
<code>
docker run -d -p4444:4444 selenium/standalone-firefox:2.53.1-beryllium
</code>
to see all available version click in tags. For firefox you can find at: https://hub.docker.com/r/selenium/standalone-firefox/tags/

==== Change config.php file ====
In config.php file you must change the $CFG->behat_wwwroot= to your network card (NIC) ip address, you can't use
localhost , 127.0.0.1, ... or selenium docker server will fail

=== Increasing timeouts ===

You may see errors such as:

<code>
Javascript code and/or AJAX requests are not ready after 10 seconds.
There is a Javascript error or the code is extremely slow.
</code>

Sometimes this indicates a genuine problem with the code, but if you are using a slow computer, it could just mean that the browser was not yet ready. You may find that the test works if you run it again. If you get this error frequently, it might be useful to increase the timeout.

It is possible to increase this timeout by adding a line in your config.php. (Requires Moodle versions 3.5 (from 3.5.6), 3.6 (from 3.6.4), or 3.7+.)

<code>
$CFG->behat_increasetimeout = 2;
</code>

This will increase all the timeouts by a factor of 2; if that isn't sufficient, you could use 3.

Increasing timeouts will make tests run a bit slower (because there are points where Behat waits up to a timeout to make sure something doesn't happen) so don't do this unless you need to.

== NOTE ==
# Start the Selenium server (in case you want to run tests that involves Javascript)
#* (See http://www.installationpage.com/selenium/how-to-run-selenium-headless-firefox-in-ubuntu/ for running 'headless' Firefox and xvfm in a server environment)
#* Open another command line interface and '''java -jar /path/to/your/selenium/server/selenium-server-standalone-2.NN.N.jar'''

=== Disable acceptance test environment ===
if you want to prevent access to test environment
<code>
php admin/tool/behat/cli/util.php --disable
</code>
'''Note that if you have the HTTP_PROXY environment variable set, which you may have had to do to run composer, then you also need to set NO_PROXY=localhost.'''

== Trouble shooting ==

=== New step definitions or features are not executed ===
If you are adding new tests or steps definitions update the tests list
<code>
php admin/tool/behat/cli/util.php --enable
</code>
''' For parallel runs, all options for initialising parallel runs are valid '''

=== Tests are failing ===

If you followed all the steps and you receive an unknown weird error probably your browser version is not compatible with the Selenium version you are running. Please refer Working combinations to ensure you have correct [[Acceptance_testing/Browsers#Working_combinations_of_OS.2BBrowser.2Bselenium]] of them to run acceptance test.

=== The tests are failing, and the error message is completely useless ===

For example, it just says "Error writing to database" with no stack trace.

Add -vv command-line option to get very verbose output.

=== Errors during setup (before test are launched) ===
Typical errors are:
* Behat requirement not satisfied: http://127.0.0.1/m/stable_master is not available, ensure you specified correct url and that the server is set up and started.
* Behat is configured but not enabled on this test site.

In order to fix those errors please check that: the behat_dataroot has correct write permissions and that the $CFG->behat* variables are placed before the lib/setup.php include:
require_once(__DIR__ . '/lib/setup.php');

=== Selenium server is not running ===
==== Chrome specific ====

If you are using chrome, you need to ensure that the driver matches the version of the installed chrome browser – which may change on OS updates/upgrades. Moodle or Selenium will not give the appropriate message – see [https://tracker.moodle.org/browse/MDL-67659/ MDL-67659]. One solution is the one suggested in the issue and use Andrew Nicols’ [https://github.com/andrewnicols/chromedriver-wrapper/ Chromedriver Wrapper] which will ensure you have the appropriate driver before running the tests.

== External links ==
* Vagrant profile with Moodle and Behat preconfigured: https://github.com/mackensen/moodle-hat
* Docker containers for Moodle Developers and Behat: https://github.com/moodlehq/moodle-docker
* Docker environment with Behat preconfigured : https://github.com/tobiga/docker_moodle_environment

== See also ==
* [[Acceptance testing for the mobile app]]

[[Category:Quality Assurance]][[Category:Behat]]

Grunt

2016-10-07T09:03:56Z

Bawjaws:

{{Moodle 2.9}}

Grunt is a command line tool used to prepare our javascript and less-generated css for production usage. After making any change to javascript or less files in Moodle, you must run grunt to lint, minify and package the javascript/css properly so that it can be served by Moodle.

== Install grunt ==
The Javascript modules (AMD and YUI) and less css in Moodle must be processed by some build tools before they will be visible to your web browser. We use "[http://gruntjs.com/ grunt]" as a build tool to wrap our different processes. Grunt is a build tool written in Javascript that runs in the "[http://nodejs.org/ nodejs]" environment. This means you first have to install nodejs - and it's package manager "[https://www.npmjs.com/ npm]". The details of how to install those packages will vary by operating system, but on Linux it's likely to be:
apt-get install nodejs npm
See also: [http://askubuntu.com/questions/594656/how-to-install-the-latest-versions-of-nodejs-and-npm-for-ubuntu-14-04-lts/711976 how to install the latest version of nodejs and npm for ubuntu 14.04]

There are downloadable packages for other operating systems here: http://nodejs.org/download/.

Once this is done, you can run the command:
npm install
from the top of the Moodle directory to install all of the required tools.

You also need to install the grunt-cli package globally in order to have a "grunt" command in your path. To do this run:
npm install -g grunt-cli

== Running grunt ==
Typical commands:

grunt amd # Short-cut for grunt jshit uglify, rebuild all AMD modules.
grunt shifter # Run shifter
grunt js # Short-cut for grunt amd shifter

grunt css # Run less
grunt # Try to do the right thing:
# * If you are in a folder called amd, do grunt amd
# * If you are in a folder called yui/src/something, do grunt shifter
# * Otherwise build everything (grunt css js).

grunt watch # Watch for changes and re-run grunt tasks depending on what file changes

On Linux/Mac it will build everything in the current folder and below. On Windows, you need to specify the path on the command line like <tt>--root=admin/tool/templatelibrary</tt>.

== Using Grunt in additional plugins ==

You may want to use Grunt for performing tasks in your custom Moodle plugins. For building AMD and YUI modules in your plugin, the standard configuration Gruntfile.js located in the Moodle root should work well. For building CSS files from LESS templates, you will have to set up a separate Grunt installation in the root of your plugin.

If you do not have it yet, create the package.json file in the root of your plugin:

{
"name": "moodle-plugintype_pluginname"
}

Install grunt, grunt less and grunt watch modules. Note that you should put the folder node_modules into your plugin's .gitignore file, too.

$ cd /path/to/your/plugin/root
$ npm install --save-dev grunt grunt-contrib-less grunt-contrib-watch grunt-load-gruntfile

Create a Gruntfile.js in the root of your plugin and configure the task for building CSS files from LESS:

<code javascript>
"use strict";

module.exports = function (grunt) {

// We need to include the core Moodle grunt file too, otherwise we can't run tasks like "amd".
require("grunt-load-gruntfile")(grunt);
grunt.loadGruntfile("../../Gruntfile.js");

// Load all grunt tasks.
grunt.loadNpmTasks("grunt-contrib-less");
grunt.loadNpmTasks("grunt-contrib-watch");
grunt.loadNpmTasks("grunt-contrib-clean");

grunt.initConfig({
watch: {
// If any .less file changes in directory "less" then run the "less" task.
files: "less/*.less",
tasks: ["less"]
},
less: {
// Production config is also available.
development: {
options: {
// Specifies directories to scan for @import directives when parsing.
// Default value is the directory of the source, which is probably what you want.
paths: ["less/"],
compress: true
},
files: {
"styles.css": "less/styles.less"
}
},
}
});
// The default task (running "grunt" in console).
grunt.registerTask("default", ["less"]);
};
</code>

Now running "grunt" or "grunt less" in your plugin root folder will compile the file less/styles.less and saves it as styles.css. Running "grunt watch" will watch the less/*.less files and if some is changed, it will immediately rebuild the CSS file.

If you are working on a custom theme, you may have multiple less/*.less files that you want to compile to their style/*.css counterparts. You can either define an explicit list all such file pairs, or let that list be created for you by making use of [http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically expand:true feature] of gruntfile.js:

<code javascript>
// This dynamically creates the list of files to be processed.
files: [
{
expand: true,
cwd: "less/",
src: "*.less",
dest: "style/",
ext: ".css"
}
]
</code>

== See also ==
* [[YUI/Shifter]]
* [[Javascript Modules]]
* [[LESS]]

[[Category:AJAX]]
[[Category:Javascript]]

Grunt

2016-10-06T17:01:36Z

Bawjaws: /* Using Grunt in additional plugins */

{{Moodle 2.9}}

Grunt is a command line tool used to prepare our javascript and less-generated css for production usage. After making any change to javascript or less files in Moodle, you must run grunt to lint, minify and package the javascript/css properly so that it can be served by Moodle.

== Install grunt ==
The Javascript modules (AMD and YUI) and less css in Moodle must be processed by some build tools before they will be visible to your web browser. We use "[http://gruntjs.com/ grunt]" as a build tool to wrap our different processes. Grunt is a build tool written in Javascript that runs in the "[http://nodejs.org/ nodejs]" environment. This means you first have to install nodejs - and it's package manager "[https://www.npmjs.com/ npm]". The details of how to install those packages will vary by operating system, but on Linux it's likely to be:
apt-get install nodejs npm
See also: [http://askubuntu.com/questions/594656/how-to-install-the-latest-versions-of-nodejs-and-npm-for-ubuntu-14-04-lts/711976 how to install the latest version of nodejs and npm for ubuntu 14.04]

There are downloadable packages for other operating systems here: http://nodejs.org/download/.

Once this is done, you can run the command:
npm install
from the top of the Moodle directory to install all of the required tools.

You also need to install the grunt-cli package globally in order to have a "grunt" command in your path. To do this run:
npm install -g grunt-cli

== Running grunt ==
Typical commands:

grunt amd # Short-cut for grunt jshit uglify, rebuild all AMD modules.
grunt shifter # Run shifter
grunt js # Short-cut for grunt amd shifter

grunt css # Run less
grunt # Try to do the right thing:
# * If you are in a folder called amd, do grunt amd
# * If you are in a folder called yui/src/something, do grunt shifter
# * Otherwise build everything (grunt css js).

grunt watch # Watch for changes and re-run grunt tasks depending on what file changes

On Linux/Mac it will build everything in the current folder and below. On Windows, you need to specify the path on the command line like <tt>--root=admin/tool/templatelibrary</tt>.

== Using Grunt in additional plugins ==

You may want to use Grunt for performing tasks in your custom Moodle plugins. For building AMD and YUI modules in your plugin, the standard configuration Gruntfile.js located in the Moodle root should work well. For building CSS files from LESS templates, you will have to set up a separate Grunt installation in the root of your plugin.

If you do not have it yet, create the package.json file in the root of your plugin:

{
"name": "moodle-plugintype_pluginname"
}

Install grunt, grunt less and grunt watch modules. Note that you should put the folder node_modules into your plugin's .gitignore file, too.

$ cd /path/to/your/plugin/root
$ npm install --save-dev grunt grunt-contrib-less grunt-contrib-watch

Create a Gruntfile.js in the root of your plugin and configure the task for building CSS files from LESS:

<code javascript>
"use strict";

module.exports = function (grunt) {

// We need to include the core Moodle grunt file too, otherwise we can't run tasks like "amd".
require("grunt-load-gruntfile")(grunt);
grunt.loadGruntfile("../../Gruntfile.js");

// Load all grunt tasks.
grunt.loadNpmTasks("grunt-contrib-less");
grunt.loadNpmTasks("grunt-contrib-watch");
grunt.loadNpmTasks("grunt-contrib-clean");

grunt.initConfig({
watch: {
// If any .less file changes in directory "less" then run the "less" task.
files: "less/*.less",
tasks: ["less"]
},
less: {
// Production config is also available.
development: {
options: {
// Specifies directories to scan for @import directives when parsing.
// Default value is the directory of the source, which is probably what you want.
paths: ["less/"],
compress: true
},
files: {
"styles.css": "less/styles.less"
}
},
}
});
// The default task (running "grunt" in console).
grunt.registerTask("default", ["less"]);
};
</code>

Now running "grunt" or "grunt less" in your plugin root folder will compile the file less/styles.less and saves it as styles.css. Running "grunt watch" will watch the less/*.less files and if some is changed, it will immediately rebuild the CSS file.

If you are working on a custom theme, you may have multiple less/*.less files that you want to compile to their style/*.css counterparts. You can either define an explicit list all such file pairs, or let that list be created for you by making use of [http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically expand:true feature] of gruntfile.js:

<code javascript>
// This dynamically creates the list of files to be processed.
files: [
{
expand: true,
cwd: "less/",
src: "*.less",
dest: "style/",
ext: ".css"
}
]
</code>

== See also ==
* [[YUI/Shifter]]
* [[Javascript Modules]]
* [[LESS]]

[[Category:AJAX]]
[[Category:Javascript]]

Collaborate

2015-08-31T16:15:12Z

Bawjaws: Initial placeholder text for installing, configuration.

A module for integration with Blackboard Collaborate.

== How to Install the Collaborate Module ==

Before you can install Collaborate, you must download the zip file.

# Go to http://behind.blackboard.com.
# Sign in with your Behind the Blackboard account. Note: If you have a pre-existing account in our Bb Support Portal, use your email address to sign in. If you are a new client, we have setup access for your email address that we have on file.
# Once logged in, select Collaborate from the What’s New for… drop-down list.
# In the Self Service panel click Downloads.
# Select your Collaborate product.
# Select the appropriate integration component file for your CMS type and Blackboard Collaborate product to download.
# Select the appropriate installation guide for your integration under Related Documentation.

== How to Configure the Collaborate Module ==

# From the Moodle Admin Menu Select : Site Administration > Plugins > Activity Modules > Collaborate
# Use the information provided to you to complete the configuration

Collaborate

2015-08-31T16:04:05Z

Bawjaws: Initial page creation, for linking from readme

A module for integration with Blackboard Collaborate.

HTML5 player

2015-03-19T12:18:35Z

Bawjaws: /* Comparison Matrix */

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* [http://mediaelementjs.com/ MediaElement.js]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! [[#MediaElement.js|MediaElement.js]]
! No Player
|-
! Accessible Player:
| colspan="5"|
|-
!
* Keyboard control
| Yes
| Yes (http://accessibility.oit.ncsu.edu/blog/2013/05/09/accessible-video-js-player-available-on-global-accessibility-awareness-day/) This was instructed by Greg Krause, one of the key accessibility advisors for Moodle.
| Yes (configurable)
| Yes
| Yes
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes
| Yes (see http://caniuse.com/webvtt)
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="5"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| Yes
| Yes
|-
!
* RTL support
| Yes
| No
| No
| Unknown (CSS, so I guess so...)
| Yes
|-
! Mobile platforms:
| colspan="5"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
| Yes
|-
! Streaming protocols:
| colspan="5"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| Yes
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| HLS
| via Media Source Extension
|-
! Audio player
| No
| Yes
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
| style="border-bottom: 2px solid;" | Yes
| style="border-bottom: 2px solid;" | No
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| MIT
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| Flash and Silverlight (for .wmv support) fallback, used to provide the HTML5 video/audio elements.
| The Video tag can contain fallback content (e.g. Flash object) for browsers that don't support it at all (http://camendesign.com/code/video_for_everybody), but not based on codec support.
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== MediaElement.js ===

'''Pros:'''
* Flash fall-forward - uses Flash/Silverlight to provide the HTML5 MediaElement API.
* Consistent HTML/CSS Player
* No logo on screen.

'''Cons:'''
* ...

'''Technical notes (lessons learned from the prototypes)'''

* ...

'''Missing features'''

* ...

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

=== HTML5 browser native ===

'''Pros:'''
* Simple
* Standard on mobile

'''Cons:'''
* IE8 has no support

'''Technical notes'''
*

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=mediaelementjs MediaElement.js] version 2.6.14
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=native Native browser support].

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-18T21:40:20Z

Bawjaws: /* Sample Pages */

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="4"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes (see http://caniuse.com/webvtt)
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="4"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="4"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="4"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
| style="border-bottom: 2px solid;" | No
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| The Video tag can contain fallback content (e.g. Flash object) for browsers that don't support it at all (http://camendesign.com/code/video_for_everybody), but not based on codec support.
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

=== HTML5 browser native ===

'''Pros:'''
* Simple

'''Cons:'''
* IE8 has no support

'''Technical notes'''
*

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=native Native browser support].

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-18T09:19:01Z

Bawjaws: /* Sample Pages */ add Native HTML link

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="4"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes (see http://caniuse.com/webvtt)
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="4"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="4"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="4"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
| style="border-bottom: 2px solid;" | No
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| The Video tag can contain fallback content (e.g. Flash object) for browsers that don't support it at all (http://camendesign.com/code/video_for_everybody), but not based on codec support.
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

=== HTML5 browser native ===

'''Pros:'''
* Simple

'''Cons:'''
* IE8 has no support

'''Technical notes'''
*

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=native] Native in your browser.

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-18T09:17:21Z

Bawjaws: /* Comparison Matrix */ add link to http://caniuse.com/webvtt

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="4"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes (see http://caniuse.com/webvtt)
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="4"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="4"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="4"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
| style="border-bottom: 2px solid;" | No
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| The Video tag can contain fallback content (e.g. Flash object) for browsers that don't support it at all (http://camendesign.com/code/video_for_everybody), but not based on codec support.
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

=== HTML5 browser native ===

'''Pros:'''
* Simple

'''Cons:'''
* IE8 has no support

'''Technical notes'''
*

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-17T14:53:47Z

Bawjaws: /* Comparison Matrix */

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="3"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="3"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="3"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="3"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| VideoForEverybody can allow you to use any Flash player as fallback.
|
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

=== HTML5 browser native ===

'''Pros:'''
* Simple

'''Cons:'''
* IE8 has no support

'''Technical notes'''
*

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-17T14:38:45Z

Bawjaws: /* Comparison Matrix */

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="3"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="3"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="3"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="3"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| VideoForEverybody can allow you to use any Flash player as fallback.
|
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

HTML5 player

2014-04-17T14:35:53Z

Bawjaws: /* Candidates */ HTML native player

{{Work in progress}}
{{Infobox Project
|name = HTML5 Player with flash fallback
|state = In Development
|tracker = https://tracker.moodle.org/browse/MDL-38158
|discussion = https://moodle.org/mod/forum/discuss.php?d=222753#p1110024
|assignee = [https://tracker.moodle.org/secure/ViewProfile.jspa?name=kabalin Ruslan Kabalin]
}}
{{Moodle 2.x}}

== Project goals ==

The purpose of this document is to choose HTML5 player with flash fallback for integration in Moodle and plan its implementation.

The aim of this change is to reach a consistent look of the player among different platforms and browsers, as well as making sure that player starts using flash if html5 is not supported by browser for the given format. Another aim is to improve accessibility and usability, enhance customisation.

== Considerations ==

* Usability of the player - is it easy to use it and intuitively understand how to use controls?
* Accessibility of the player - possibility of keyboard navigation, subtitles, support?
* Appearance of the player - can its interface be modified, themes support, RTL?
* Consistency among browsers - does player look the same?
* Audio support - can player handle HTML5 <audio> tag?
* Mobile platforms support - does player also work on iOS and Android?
* Streaming media support (including adaptive-bitrate delivery) - can player handle RTMP, Apple HLS, Adobe HDS, Microsoft HSS?
* Plugins support - can we use or develop community plugins easily?
* Embedding support - so users could post media content outside Moodle, if permitted.
* Maintainability of the links between the player and Moodle - how much work will we need to do every time we upgrade?

== Candidates ==

* [http://flowplayer.org/ Flowplayer HTML5]
* [http://www.videojs.com/ Video.JS]
* [http://www.projekktor.com/ Projekktor]
* ?Are there other alternatives?

== Comparison Matrix ==

{| class="nicetable"
|-
!
! [[#Flowplayer_HTML5|Flowplayer HTML5]]
! [[#Video.JS|Video.JS]]
! [[#Projekktor|Projekktor]]
! No Player
|-
! Accessible Player:
| colspan="4"|
|-
!
* Keyboard control
| Yes
| No
| Yes (configurable)
| unknown
|-
!
* Subtitles support
| Yes
| Yes
| Yes (via plugin)
| Yes
|-
!
* Touch interface
| Yes
| Yes
| Yes
| Yes
|-
! Appearance:
| colspan="4"|
|-
!
* Skins
| Yes (via CSS)
| Yes (via CSS)
| Yes (via CSS)
| No
|-
!
* CSS customisation
| Yes
| Yes
| Yes
| unknown
|-
!
* RTL support
| Yes
| No
| No
| Unknown
|-
! Mobile platforms:
| colspan="4"|
|-
!
* iOS
| Yes
| No
| Yes
| Yes
|-
!
* Android
| Yes
| No
| Yes
| Yes
|-
! Streaming protocols:
| colspan="4"|
|-
!
* RTMP
| Yes
| Yes
| Yes (via playlist)
| No
|-
!
* Adaptive HTTP
| HLS
| HLS (via plugin)
| HLS (via playlist)
| Only in Chrome so far (Media Source Extension)
|-
! Audio player
| No
| Yes
| Yes
| Yes
|-
! style="border-bottom: 2px solid;" | Embedding support
| style="border-bottom: 2px solid;" | Yes (configurable)
| style="border-bottom: 2px solid;" | Yes (via addThis plugin)
| style="border-bottom: 2px solid;" | Yes (via plugin)
|-
! License
| GPL v3 (with additional terms)
| Apache 2
| GPL v3
| no extra code needed
|-
! JS library
| jQuery
| -
| jQuery
| none required
|-
! Plugins infrastructure
| No
| Yes
| Yes
| No
|-
! Flash fallback player
| Flowplayer Flash
| video-js flash
| StobeMediaPlayback (but can be jarisplayer or some other).
| VideoForEverybody can allow you to use any Flash player as fallback.
|
|-
! API
| Yes (plus window.flowplayer object)
| Yes
| Yes
| Yes
|-
|}

=== Flowplayer HTML5 ===

'''Pros:'''
* Good looking player, resembles existing flash flowplayer in Moodle (with "functional" skin)
* Extensive customisation (via CSS3 skins and configuration object)
* Streaming support (RTMP, HLS)
* Good accessibility features
* Configurable embedding functionality
* Existing flash flowplayer can be configured for fallback (the appearance of player will not be affected).

'''Cons:'''
* Require jQuery for functioning
* Flowplayer logo remains on screen

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using wrapper around <video>.
* width and height attributes in video tag are ignored, player size is configured via wrapper size only.
* RTMP server connection is configured via data-rtmp attribute in wrapper or player init config parameter, actual path the file specified in src attribute of source item.
* <source type="video/flash"... dummy MIME type to force using plash player for whatever content.

'''Missing features'''
* Plugins infrastructure
* No audio support

=== Video.JS ===

'''Pros:'''
* No logo on screen.
* Extensive API.
* No extra JS library needed.
* Many plugins.

'''Cons:'''
* Poor documentation
* RTMP requires non-standard MIME.
* Android and iOS override Video.JS with own player, when not overridden, content is not playing.
* No RTL.
* HLS support via plugin (many files to include, external contributor see https://github.com/videojs/videojs-contrib-hls).

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* RTMP server connection and path specified as single URI in src attribute of source item, '&' character is used as server connection and path divider.

'''Missing features'''
* Embedded HLS support.

=== Projekktor ===

'''Pros:'''
* No logo on screen.
* Well documented API.
* Media RSS support.
* Possibility to choose flash player for fallback (included by default are StrobeMediaPlayback and Jarisplayer, both Open Source).
* Platform preference order selection (e.g. browser, ios, android, flash, native).

'''Cons:'''
* Uses flash where it is not supposed to (e.g. mp4 in Chrome).
* Issues on ios and android (suggests to download file when play button is pressed).
* RTMP only work if defined via playlist rather than in <source> tags.
* Subtitles plugin is not free.

'''Technical notes (lessons learned from the prototypes)'''
* Player initialisation is done using <video> tag directly (no wrapper needed).
* Make sure <video> tag has class attribute with 'projekktor' value (even if you initialise it by ID of the element), player will not work properly otherwise.

'''Missing features'''

== Cross-browser support ==

=== Method ===
Compatibility checks were done manually by accessing the sample page using different browsers and platforms. Sample page contained the list of identical player instances, initialised for each <video> definition with a <source> of particular format: mp4, webm, ogg, flv. Streaming support was checked by setting up a <video> container with two sources of the same video, one was HLS (Apple HTTP Live Streaming) stream for browsers and platforms that support html5 video streaming, another one was RTMP which is played using flash engine and supposed to be used in case if HLS is not supported.

=== Sample Pages ===

* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=flowplayer Flowplayer HTML5] version 5.4.6.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=videojs Video.JS] version 4.4.1.
* [https://dev.mle.lancs.ac.uk/videotest/players.php?player=projekktor Projekktor] version 1.3.09.

=== Source ===

Source of testing page is hosted on [https://github.com/kabalin/test-html5-players/blob/master/players.php github]. The actual source of the html page can be viewed in browser.

=== Discussion ===

The players comparison that has been carried out demonstrated that "least hassle" player is Flowplayer. Despite some drawbacks listed in [[#Flowplayer_HTML5|corresponding section above]], it is clearly a winner as it works as expected and according to documentation for all browsers and platforms I had chance to test it. This is the only player that supports RTL layout, display platform incompatibility message prior to attempt to play, and was simple to configure (no undocumented tricks that I had to figure out to make it work). Both VideoJS and Projekktor do now perform properly in all cases. Among those two, I personally prefer Projekktor more for its extensive API, plugins infrastructure and configuration flexibility. However problems on mobile platforms and flash fallback inconsistency make them unreliable at this stage.

=== Compatibility results ===

The table was populated using Flowplayer as others do not perform good enough with some formats and platforms, e.g. VideoJS allow mobile platform player to override itself, Projekktor does not always use HTML5 where browser clearly can handle it (supported in native mode and Flowplayer).

{| class="nicetable"
|-
! Browser
! mp4
! webm
! ogg
! flv
! RTMP/HLS*
|-
! Windows 7
| colspan="5"|
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
!
* Firefox 27.0.1
| html5
| html5
| html5
| flash
| flash
|-
!
* Opera 12.16
| flash
| html5
| -
| flash
| flash
|-
!
* Safari 5.1.7
| flash
| -
| -
| flash
| flash
|-
!
* Internet Explorer 11.0.9600.x
| html5
| -
| -
| flash
| flash
|-
! Linux (Debian Wheezy)
| colspan="5"|
|-
!
* Chrome 33.0.1750.115
| html5
| html5
| html5
| flash
| flash
|-
! OSX 10.9
| colspan="5"|
|-
!
* Safari 7.0 (9537.71)
| html5
| -
| -
| flash
| html5
|-
!
* Chrome 33.0.1750.117
| html5
| html5
| html5
| flash
| flash
|-
! Android 4.2.2 phone (CyanogenMod, no flash)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| -
| html5
|-
! Android 4.2.2 tablet (GalaxyTab2, flash app 11.1.115.36)
| colspan="5"|
|-
!
* Chrome 32.0.1700.99
| html5
| html5
| -
| -
| -
|-
!
* Browser 4.2.2 (com.android.browser)
| html5
| html5
| -
| flash
| html5
|-
!
* Opera 19.0.1340.x
| html5
| html5
| -
| -
| -
|-
! iPhone 4S (6.1.3)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
! iPad 4 (7.0.6)
| colspan="5"|
|-
!
* Safari
| html5
| -
| -
| -
| html5
|-
|}
* For HLS/RTMP, html5 in the table means HLS has been used, flash means player fell back and used RTMP.

== Sub Tasks ==

In initial stage FlowPlayer HTML5 (or any other) will handle all existing HTML5 Video extensions as per core_media_player_html5video class, plus m3u8 (HLS). It will also be possible optionally to make flash files handled by HTML5 Video player as well (possibility of using existing flash FlowPlayer for flv files will remain).

== Mock-Ups/Prototypes ==

See [[#Sample_Pages|Sample pages]] section.

== Workaround ==

As intermediate solution, if you require player consistency throughout all browsers and platforms, you may consider using JW Player filter: https://github.com/lucisgit/moodle-filter_jwplayer Notice, that JW Player is not free for commercial use.

== Related Tracker Issues ==
* MDL-38158

== Useful links ==
* http://praegnanz.de/html5video/
* http://html5video.org/wiki/HTML5_Video_Player_Comparison
* http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Choosing-a-Video-Player-Features-and-Specs-for-the-Top-Five-94188.aspx

[[Category:Project]]

Common unit test problems

2013-11-29T12:28:31Z

Bawjaws:

== General Issues ==

=== Unit tests are taking more than 10 mins to run ===
This problem is under investigation. We are hoping to find the soluton. On a typical system all tests complete in under 6 mins.--[[User:Dan Poltawski|Dan Poltawski]] 12:43, 15 May 2012 (WST)

You maybe find much better performance on psql as a workaround for now if not doing DB dependent tests.

If using linux on an EXT4 file system, disabling barriers by adding barrier=0 to the end of the options in /etc/fstab for the drive should offer HUGE speed improvements. Note that this is very dangerous for system stability and in the event of a power failure can cause permanent and irrecoverable data loss.

=== Segfaults on Oracle ===

When I was running tests on oracle I was getting phpunit sefaulting.. --[[User:Dan Poltawski|Dan Poltawski]] 00:29, 16 May 2012 (WST)

'''Solution''' Set statement_cache_size in php.ini: <code>oci8.statement_cache_size = 0</code>

== Specific failures ==

=== dml_testcase::test_unique_index_collation_trouble===

<code>Unique index is accent insensitive, this may cause problems for non-ascii languages. This is usually caused by accent insensitive default collation.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== dml_testcase::test_sql_binary_equal ===

<code>SQL operator "=" is expected to be case sensitive Failed asserting that 1 matches expected 2.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== grading_manager_testcase::test_tokenize===

<code>A test using UTF-8 characters has failed. Consider updating PHP and PHP's PCRE or INTL extensions (MDL-30494) Failed asserting that false is true.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== moodlesimplepie_testcase::test_getfeed ===

<code>Failed to load the sample RSS file. Please check your proxy settings in Moodle. %s</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings.

=== moodlesimplepie_testcase::test_redirect ===

<code>Failed asserting that 'cURL Error: Operation timed out after 2000 milliseconds with 0 bytes received' is null.</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings

=== collatorlib_testcase::test_asort_objects_by_method ===

<code>Collation aware sorting not supported, PHP extension "intl" is not available.</code>

'''Solution''' Install php intl extension.

Note that, on Windows, this extension does not seem to be included in the installer, but you can get it by downloading the zip, and copying the right DLLs across. If you Google, there are more detailed instructions on Stack Exchange.

=== moodlelib_testcase::test_fix_utf8 ===

<code>Failed asserting that false is identical to 'aaabbb'.</code>

'''Solution''' This problem indicates buggy iconv. See [http://tracker.moodle.org/browse/MDL-33007] for discussion. So this is a real problem, to be fixed in a future integration cycle

=== filestoragelib_testcase::test_get_file_preview ===

<code>Failed asserting that false is an instance of class "stored_file".</code>

'''Solution''' Unfortunately, the php GD extension is a requirement for this test (see MDL-36447).

Go to your Moodle directory and type <code>php admin/tool/phpunit/cli/util.php --drop</code>, then reinitialise PHPunit and run the test again.

=== MSSQL failures with core_course_externallib_testcase===

On the MSSQL database driver, some problems occur with core_course_externallib_testcase, for example:

core_course_externallib_testcase::test_duplicate_course

unserialize(): Error at offset 24191 of 24192 bytes

'''Solution''' Ensure that the correct configuration is set in freedts.conf (from https://docs.moodle.org/26/en/FreeTDS), e.g.

<pre>text size = 20971520
client charset = UTF8</pre>

=== PHP Warning: include_once(PHPUnit/Extensions/Database/Autoload.php): failed to open stream ===

This occurs on Mac installs from experience. The reason this occurs is because DBUnit was not installed during the PHPUnit installation via PEAR.

'''Solution''' In terminal type: <code>sudo pear install -f phpunit/DbUnit</code>

=== !!! Error reading from database !!!!! Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. ===

If running unit tests under FreeTDS, remember that without a valid FREETDS environment variable, PHP won't be able to find the freetds.conf file and will default to version 5.0 which has poor support for unicode collations.

'''Solution''' Ensure a FREETDS environment variable is set prior to running the automated tests, which points to a valid path that contains a freetds.conf file. Also ensure the tds version element is set to a recent enough version (8.0)

Note: Another potential solution may be to set TDSVER (http://freetds.schemamania.org/userguide/freetdsconf.htm)

[[Category:Unit testing]]

Common unit test problems

2013-11-29T12:27:01Z

Bawjaws:

== General Issues ==

=== Unit tests are taking more than 10 mins to run ===
This problem is under investigation. We are hoping to find the soluton. On a typical system all tests complete in under 6 mins.--[[User:Dan Poltawski|Dan Poltawski]] 12:43, 15 May 2012 (WST)

You maybe find much better performance on psql as a workaround for now if not doing DB dependent tests.

If using linux on an EXT4 file system, disabling barriers by adding barrier=0 to the end of the options in /etc/fstab for the drive should offer HUGE speed improvements. Note that this is very dangerous for system stability and in the event of a power failure can cause permanent and irrecoverable data loss.

=== Segfaults on Oracle ===

When I was running tests on oracle I was getting phpunit sefaulting.. --[[User:Dan Poltawski|Dan Poltawski]] 00:29, 16 May 2012 (WST)

'''Solution''' Set statement_cache_size in php.ini: <code>oci8.statement_cache_size = 0</code>

== Specific failures ==

=== dml_testcase::test_unique_index_collation_trouble===

<code>Unique index is accent insensitive, this may cause problems for non-ascii languages. This is usually caused by accent insensitive default collation.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== dml_testcase::test_sql_binary_equal ===

<code>SQL operator "=" is expected to be case sensitive Failed asserting that 1 matches expected 2.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== grading_manager_testcase::test_tokenize===

<code>A test using UTF-8 characters has failed. Consider updating PHP and PHP's PCRE or INTL extensions (MDL-30494) Failed asserting that false is true.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== moodlesimplepie_testcase::test_getfeed ===

<code>Failed to load the sample RSS file. Please check your proxy settings in Moodle. %s</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings.

=== moodlesimplepie_testcase::test_redirect ===

<code>Failed asserting that 'cURL Error: Operation timed out after 2000 milliseconds with 0 bytes received' is null.</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings

=== collatorlib_testcase::test_asort_objects_by_method ===

<code>Collation aware sorting not supported, PHP extension "intl" is not available.</code>

'''Solution''' Install php intl extension.

Note that, on Windows, this extension does not seem to be included in the installer, but you can get it by downloading the zip, and copying the right DLLs across. If you Google, there are more detailed instructions on Stack Exchange.

=== moodlelib_testcase::test_fix_utf8 ===

<code>Failed asserting that false is identical to 'aaabbb'.</code>

'''Solution''' This problem indicates buggy iconv. See [http://tracker.moodle.org/browse/MDL-33007] for discussion. So this is a real problem, to be fixed in a future integration cycle

=== filestoragelib_testcase::test_get_file_preview ===

<code>Failed asserting that false is an instance of class "stored_file".</code>

'''Solution''' Unfortunately, the php GD extension is a requirement for this test (see MDL-36447).

Go to your Moodle directory and type <code>php admin/tool/phpunit/cli/util.php --drop</code>, then reinitialise PHPunit and run the test again.

=== MSSQL failures with core_course_externallib_testcase===

On the MSSQL database driver, some problems occur with core_course_externallib_testcase, for example:

core_course_externallib_testcase::test_duplicate_course

unserialize(): Error at offset 24191 of 24192 bytes

'''Solution''' Ensure that the correct configuration is set in freedts.conf (from https://docs.moodle.org/26/en/FreeTDS), e.g.

<code>text size = 20971520</code>
<code>client charset = UTF8</code>

=== PHP Warning: include_once(PHPUnit/Extensions/Database/Autoload.php): failed to open stream ===

This occurs on Mac installs from experience. The reason this occurs is because DBUnit was not installed during the PHPUnit installation via PEAR.

'''Solution''' In terminal type: <code>sudo pear install -f phpunit/DbUnit</code>

=== !!! Error reading from database !!!!! Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. ===

If running unit tests under FreeTDS, remember that without a valid FREETDS environment variable, PHP won't be able to find the freetds.conf file and will default to version 5.0 which has poor support for unicode collations.

'''Solution''' Ensure a FREETDS environment variable is set prior to running the automated tests, which points to a valid path that contains a freetds.conf file. Also ensure the tds version element is set to a recent enough version (8.0)

Note: Another potential solution may be to set TDSVER (http://freetds.schemamania.org/userguide/freetdsconf.htm)

[[Category:Unit testing]]

Common unit test problems

2013-11-29T12:17:38Z

Bawjaws: General formatting and tidy up

== General Issues ==

=== Unit tests are taking more than 10 mins to run ===
This problem is under investigation. We are hoping to find the soluton. On a typical system all tests complete in under 6 mins.--[[User:Dan Poltawski|Dan Poltawski]] 12:43, 15 May 2012 (WST)

You maybe find much better performance on psql as a workaround for now if not doing DB dependent tests.

If using linux on an EXT4 file system, disabling barriers by adding barrier=0 to the end of the options in /etc/fstab for the drive should offer HUGE speed improvements. Note that this is very dangerous for system stability and in the event of a power failure can cause permanent and irrecoverable data loss.

=== Segfaults on Oracle ===

When I was running tests on oracle I was getting phpunit sefaulting.. --[[User:Dan Poltawski|Dan Poltawski]] 00:29, 16 May 2012 (WST)

'''Solution''' Set statement_cache_size in php.ini: <code>oci8.statement_cache_size = 0</code>

== Specific failures ==

=== dml_testcase::test_unique_index_collation_trouble===

<code>Unique index is accent insensitive, this may cause problems for non-ascii languages. This is usually caused by accent insensitive default collation.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== dml_testcase::test_sql_binary_equal ===

<code>SQL operator "=" is expected to be case sensitive Failed asserting that 1 matches expected 2.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== grading_manager_testcase::test_tokenize===

<code>A test using UTF-8 characters has failed. Consider updating PHP and PHP's PCRE or INTL extensions (MDL-30494) Failed asserting that false is true.</code>

'''Solution''' This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== moodlesimplepie_testcase::test_getfeed ===

<code>Failed to load the sample RSS file. Please check your proxy settings in Moodle. %s</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings.

=== moodlesimplepie_testcase::test_redirect ===

<code>Failed asserting that 'cURL Error: Operation timed out after 2000 milliseconds with 0 bytes received' is null.</code>

'''Solution''' Your moodle needs network connectivity, please check proxy settings

=== collatorlib_testcase::test_asort_objects_by_method ===

<code>Collation aware sorting not supported, PHP extension "intl" is not available.</code>

'''Solution''' Install php intl extension.

Note that, on Windows, this extension does not seem to be included in the installer, but you can get it by downloading the zip, and copying the right DLLs across. If you Google, there are more detailed instructions on Stack Exchange.

=== moodlelib_testcase::test_fix_utf8 ===

<code>Failed asserting that false is identical to 'aaabbb'.</code>

'''Solution''' This problem indicates buggy iconv. See [http://tracker.moodle.org/browse/MDL-33007] for discussion. So this is a real problem, to be fixed in a future integration cycle

=== filestoragelib_testcase::test_get_file_preview ===

<code>Failed asserting that false is an instance of class "stored_file".</code>

'''Solution''' Unfortunately, the php GD extension is a requirement for this test (see MDL-36447).

Go to your Moodle directory and type <code>php admin/tool/phpunit/cli/util.php --drop</code>, then reinitialise PHPunit and run the test again.

=== MSSQL failures with core_course_externallib_testcase===

On the MSSQL database driver, some problems occur with core_course_externallib_testcase, for example:

core_course_externallib_testcase::test_duplicate_course

unserialize(): Error at offset 24191 of 24192 bytes

'''Solution''' Ensure that the correct configuration is set in freedts.conf (from https://docs.moodle.org/26/en/FreeTDS), e.g.

<code>text size = 20971520</code>
</code>client charset = UTF8</code>

=== PHP Warning: include_once(PHPUnit/Extensions/Database/Autoload.php): failed to open stream ===

This occurs on Mac installs from experience. The reason this occurs is because DBUnit was not installed during the PHPUnit installation via PEAR.

'''Solution''' In terminal type: <code>sudo pear install -f phpunit/DbUnit</code>

=== !!! Error reading from database !!!!! Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. ===

If running unit tests under FreeTDS, remember that without a valid FREETDS environment variable, PHP won't be able to find the freetds.conf file and will default to version 5.0 which has poor support for unicode collations.

'''Solution''' Ensure a FREETDS environment variable is set prior to running the automated tests, which points to a valid path that contains a freetds.conf file. Also ensure the tds version element is set to a recent enough version (8.0)

Note: Another potential solution may be to set TDSVER (http://freetds.schemamania.org/userguide/freetdsconf.htm)

[[Category:Unit testing]]

Common unit test problems

2013-11-29T12:04:16Z

Bawjaws: /* Solution */

=== Unit tests are taking more than 10 mins to run ===
This problem is under investigation. We are hoping to find the soluton. On a typical system all tests complete in under 6 mins.--[[User:Dan Poltawski|Dan Poltawski]] 12:43, 15 May 2012 (WST)

You maybe find much better performance on psql as a workaround for now if not doing DB dependent tests.

If using linux on an EXT4 file system, disabling barriers by adding barrier=0 to the end of the options in /etc/fstab for the drive should offer HUGE speed improvements. Note that this is very dangerous for system stability and in the event of a power failure can cause permanent and irrecoverable data loss.

=== dml_testcase::test_unique_index_collation_trouble===
"Unique index is accent insensitive, this may cause problems for non-ascii languages. This is usually caused by accent insensitive default collation."
==== Solution ====
This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== dml_testcase::test_sql_binary_equal ===
"SQL operator "=" is expected to be case sensitive Failed asserting that 1 matches expected 2."
==== Solution ====
This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== moodlesimplepie_testcase::test_getfeed ===
"Failed to load the sample RSS file. Please check your proxy settings in Moodle. %s"
==== Solution ====
Your moodle needs network connectivity, please check proxy settings.

=== moodlesimplepie_testcase::test_redirect ===
Failed asserting that 'cURL Error: Operation timed out after 2000 milliseconds with 0 bytes received' is null.
==== Solution ====
Your moodle needs network connectivity, please check proxy settings

=== collatorlib_testcase::test_asort_objects_by_method ===
Collation aware sorting not supported, PHP extension "intl" is not available.
==== Solution ====
Install php intl extension.

Note that, on Windows, this extension does not seem to be included in the installer, but you can get it by downloading the zip, and copying the right DLLs across. If you Google, there are more detailed instructions on Stack Exchange.

=== grading_manager_testcase::test_tokenize===
A test using UTF-8 characters has failed. Consider updating PHP and PHP's PCRE or INTL extensions (MDL-30494) Failed asserting that false is true.
==== Solution ====
Your Database is incorrectly configured. You probably are running MySQL and need to switch to utf8_bin collation.

=== moodlelib_testcase::test_fix_utf8 ===
Failed asserting that false is identical to 'aaabbb'.
==== Solution ====
This problem indicates buggy iconv. See [http://tracker.moodle.org/browse/MDL-33007] for discussion. So this is a real problem, to be fixed in a future integration cycle

=== Segfaults on Oracle ===
When I was running tests on oracle I was getting phpunit sefaulting.. --[[User:Dan Poltawski|Dan Poltawski]] 00:29, 16 May 2012 (WST)
==== Solution ====
Set statement_cache_size in php.ini:
oci8.statement_cache_size = 0

=== filestoragelib_testcase::test_get_file_preview ===
Failed asserting that false is an instance of class "stored_file".
==== Solution ====
Unfortunately, the php GD extension is a requirement for this test (see MDL-36447).

Go to your Moodle directory and type 'php admin/tool/phpunit/cli/util.php --drop', then reinitialise PHPunit and run the test again.

=== MSSQL failures with core_course_externallib_testcase===

On the MSSQL database driver, some problems occur with core_course_externallib_testcase, for example:
core_course_externallib_testcase::test_duplicate_course
unserialize(): Error at offset 24191 of 24192 bytes
==== Solution ====

Ensure that the correct configuration is set in freedts.conf (from https://docs.moodle.org/26/en/FreeTDS), e.g.

text size = 20971520
client charset = UTF8

=== PHP Warning: include_once(PHPUnit/Extensions/Database/Autoload.php): failed to open stream ===
This occurs on Mac installs from experience. The reason this occurs is because DBUnit was not installed during the PHPUnit installation via PEAR.
==== Solution ====
In terminal type: sudo pear install -f phpunit/DbUnit

=== !!! Error reading from database !!!!! Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. ===
If running unit tests under FreeTDS, remember that without a valid FREETDS environment variable, PHP won't be able to find the freetds.conf file and will default to version 5.0 which has poor support for unicode collations.
==== Solution ====
Ensure a FREETDS environment variable is set prior to running the automated tests, which points to a valid path that contains a freetds.conf file. Also ensure the tds version element is set to a recent enough version (8.0)
Note: Another potential solution may be to set TDSVER (http://freetds.schemamania.org/userguide/freetdsconf.htm)
[[Category:Unit testing]]

Common unit test problems

2013-11-29T12:03:41Z

Bawjaws: /* Solution */

=== Unit tests are taking more than 10 mins to run ===
This problem is under investigation. We are hoping to find the soluton. On a typical system all tests complete in under 6 mins.--[[User:Dan Poltawski|Dan Poltawski]] 12:43, 15 May 2012 (WST)

You maybe find much better performance on psql as a workaround for now if not doing DB dependent tests.

If using linux on an EXT4 file system, disabling barriers by adding barrier=0 to the end of the options in /etc/fstab for the drive should offer HUGE speed improvements. Note that this is very dangerous for system stability and in the event of a power failure can cause permanent and irrecoverable data loss.

=== dml_testcase::test_unique_index_collation_trouble===
"Unique index is accent insensitive, this may cause problems for non-ascii languages. This is usually caused by accent insensitive default collation."
==== Solution ====
This is expected to fail if you are running MySQL. These tests should pass if you use the <code>utf8_bin</code> collation on your database for unit tests, but we recommend <code>utf8_unicode_ci</code> for actual live Moodle sites. Work is being done to resolve this issue, read more about the [[Database collation issue]] for further info.

=== dml_testcase::test_sql_binary_equal ===
"SQL operator "=" is expected to be case sensitive Failed asserting that 1 matches expected 2."
==== Solution ====
Your Database is incorrectly configured. You probably are running MySQL and need to switch to utf8_bin collation.

=== moodlesimplepie_testcase::test_getfeed ===
"Failed to load the sample RSS file. Please check your proxy settings in Moodle. %s"
==== Solution ====
Your moodle needs network connectivity, please check proxy settings.

=== moodlesimplepie_testcase::test_redirect ===
Failed asserting that 'cURL Error: Operation timed out after 2000 milliseconds with 0 bytes received' is null.
==== Solution ====
Your moodle needs network connectivity, please check proxy settings

=== collatorlib_testcase::test_asort_objects_by_method ===
Collation aware sorting not supported, PHP extension "intl" is not available.
==== Solution ====
Install php intl extension.

Note that, on Windows, this extension does not seem to be included in the installer, but you can get it by downloading the zip, and copying the right DLLs across. If you Google, there are more detailed instructions on Stack Exchange.

=== grading_manager_testcase::test_tokenize===
A test using UTF-8 characters has failed. Consider updating PHP and PHP's PCRE or INTL extensions (MDL-30494) Failed asserting that false is true.
==== Solution ====
Your Database is incorrectly configured. You probably are running MySQL and need to switch to utf8_bin collation.

=== moodlelib_testcase::test_fix_utf8 ===
Failed asserting that false is identical to 'aaabbb'.
==== Solution ====
This problem indicates buggy iconv. See [http://tracker.moodle.org/browse/MDL-33007] for discussion. So this is a real problem, to be fixed in a future integration cycle

=== Segfaults on Oracle ===
When I was running tests on oracle I was getting phpunit sefaulting.. --[[User:Dan Poltawski|Dan Poltawski]] 00:29, 16 May 2012 (WST)
==== Solution ====
Set statement_cache_size in php.ini:
oci8.statement_cache_size = 0

=== filestoragelib_testcase::test_get_file_preview ===
Failed asserting that false is an instance of class "stored_file".
==== Solution ====
Unfortunately, the php GD extension is a requirement for this test (see MDL-36447).

Go to your Moodle directory and type 'php admin/tool/phpunit/cli/util.php --drop', then reinitialise PHPunit and run the test again.

=== MSSQL failures with core_course_externallib_testcase===

On the MSSQL database driver, some problems occur with core_course_externallib_testcase, for example:
core_course_externallib_testcase::test_duplicate_course
unserialize(): Error at offset 24191 of 24192 bytes
==== Solution ====

Ensure that the correct configuration is set in freedts.conf (from https://docs.moodle.org/26/en/FreeTDS), e.g.

text size = 20971520
client charset = UTF8

=== PHP Warning: include_once(PHPUnit/Extensions/Database/Autoload.php): failed to open stream ===
This occurs on Mac installs from experience. The reason this occurs is because DBUnit was not installed during the PHPUnit installation via PEAR.
==== Solution ====
In terminal type: sudo pear install -f phpunit/DbUnit

=== !!! Error reading from database !!!!! Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. ===
If running unit tests under FreeTDS, remember that without a valid FREETDS environment variable, PHP won't be able to find the freetds.conf file and will default to version 5.0 which has poor support for unicode collations.
==== Solution ====
Ensure a FREETDS environment variable is set prior to running the automated tests, which points to a valid path that contains a freetds.conf file. Also ensure the tds version element is set to a recent enough version (8.0)
Note: Another potential solution may be to set TDSVER (http://freetds.schemamania.org/userguide/freetdsconf.htm)
[[Category:Unit testing]]

CSS Coding Style

2013-11-18T11:50:16Z

Bawjaws: link to issue to make these official

{{Work in progress}}

The Moodle CSS coding style (a Work in Progress, see MDLSITE-1796 for the effort to make it official)

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

or

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

or

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T15:40:00Z

Bawjaws: minor improvment to the Table of Contents, removing repitition of headers

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

or

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

or

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T15:38:49Z

Bawjaws: Undo revision 42792 by Bawjaws (talk)

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

***Correct***

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T15:35:13Z

Bawjaws: /* Block Style */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

'''''Correct'''''

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

'''''Incorrect'''''

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T15:33:21Z

Bawjaws: /* Correct */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

***Correct***

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T15:32:56Z

Bawjaws: /* Correct */ testing hiding some headings from TOC

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

==== Correct ====

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T10:10:22Z

Bawjaws: /* Properties and Values */ rewrote the colon space rule to be more explicit.

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties and values should be seperated by a colon and a single space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, always provide a hex fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use <code>!important</code>, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

Talk:CSS Coding Style

2013-10-30T10:07:08Z

Bawjaws: Some reasoning for my recent changes

== Removed "unless it is the last rule in the list of CSS mark-up." ==

https://docs.moodle.org/dev/index.php?title=CSS_coding_style&diff=42786&oldid=42785

I don't think this made any sense. Possibly someone was getting colons and semi-colons mixed up? You always need the colon, and while you **can** leave the semi-colon off the last one, and it's a common minification technique, that's something the CSS minifier should take care of automatically (note to myself, should really check the Moodle minifier does this, but I think it does). Otherwise it introduces noise into the diffs since you need to change two lines if you add or remove the line at the end and gives the person writing the CSS a weird, subtle manual rule to be aware of. (In PHP we recommend the opposite and add a comma at the end of arrays even though it's not necessary.)

== Leave one line between blocks ==

https://docs.moodle.org/dev/index.php?title=CSS_coding_style&diff=42785&oldid=42784

Changed this from recommending no empty line between CSS blocks, except for signalling sections to a standard one line between all blocks. The old rule is hard to enforce or check automatically since the tool won't know about what is and isn't a section.

I also checked the Wordpress CSS guides that this was based on and they (at least currently) say "Add two blank lines between sections and one blank line between blocks in a section." which seems a bit more reasonable (I think one line is fairly standard) but still suffers from not being able to run a formatter or linter over the file without losing info. If people want to have section breaks they should use comments, which are covered later in the doc.

== A few questions ==

A few questions about these style guidelines, as they seem a bit outdated:
# Do we need to restrict color settings to only HEX? This probably made sense when there was only HEX & RGB, but we now have really cool stuff like HSLA which is supported in all the browsers we support except IE8. It's also very easy to provide fallback to HEX:
<code>

.selector {
background-color: #hex;
background-color: hsla(170, 50%, 45%, 1);
}

</code>
# For many properties, browser prefixes are no longer needed for our supported browsers. Shouldn't we be recommending that browser prefixes be added for supported browsers which need them, only? (Also, to make sure there is a background-color fallback for things like gradients?)
# What about !important being a bad thing? If you can't override existing rules without !important, that indicates that existing selectors are too aggressive (usually using IDs rather than classes and elements).
# How about we recommend OOCSS and where you can't use it request classes added to Moodle's markup so you can?

CSS Coding Style

2013-10-30T09:56:11Z

Bawjaws: /* Properties and Values */ don't use !important full stop. also minor formatting

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: <code>#fff</code> instead of <code>#ffffff</code> or <code>#c06</code> instead of <code>#cc0066</code>).
* For color codes, if you use HSLA or RGBA, provide a hex fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use <code>!important</code>. If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T09:53:49Z

Bawjaws: /* Properties and Values */ remove "unless it is the last rule in the list of CSS mark-up." see talk page for rationale

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T09:52:01Z

Bawjaws: /* Block Style */ leave one line between blocks, see talk page for rationale

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Leave one line between blocks.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-10-30T09:50:33Z

Bawjaws: /* Naming Conventions */ style exemplar filename as monospace

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named <code>styles.css</code>.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

Bootstrap

2013-04-24T14:15:00Z

Bawjaws: /* Overview */

{{Themes}}
== Overview ==

Bootstrap (http://getbootstrap.com) is a "sleek, intuitive, and powerful front-end framework for faster and easier web development". Moodle now has some themes that build upon the best practices, documentation, tools and resources that it provides.

If you're new to Bootstrap we'd suggest starting by reading through the documentation. Not only is it well written and informative, it uses Bootstrap itself and so is a live demonstration too.

http://getbootstrap/getting-started.html

A common complaint about Bootstrap is that all Bootstrap-built sites look the same, since people like the defaults so much they just don't bother to change them. It is however not designed to be a final look, just a platform to build on. Some examples of what can be done can be found at http://builtwithbootstrap.com/ and http://expo.getbootstrap.com

== Features ==

=== Responsive design ===

A key feature of Bootstrap is responsive design. This means that the look of the page changes based on the width of your screen and allows you to alter the presentation so that iPhones, iPads, Netbooks & Desktops get subtly (or radically) different views of the same page.

http://getbootstrap.com/scaffolding.html#responsive

=== Less ===

Bootstrap's stylesheets are written in a variant of CSS called LESS. It is possible to use Bootstrap without LESS as they provide the compiled output as CSS too, but for integration with existing Moodle HTML it is (at least currently) necessary for Moodle Bootstrap's core styles to be compiled after any changes. See the [[LESS]] page for more on this.

=== Glyphicons ===

Bootstrap provides an set of icons called Glyphicons. These are not used for the core Moodle icons as there aren't enough suitable icons to cover Moodle's needs. But they are available for use in content by applying simple CSS classes via the HTML editor. (Note in the next version of Bootstrap this "icon sprite" is replaced with an icon font. It is hoped that Moodle can merge it's SVG icons into this font and all icons will be applied in the same manner)

http://getbootstrap.com/base-css.html#icons

=== Grids ===

Bootstrap uses CSS grids where previously web developers would have used floats (or before that tables). A key feature of grids is that they can "collapse" at smaller widths and so items that would be in a row will appear as a single column on smaller devices like iPhones.

http://getbootstrap.com/scaffolding.html#fluidGridSystem

=== Layouts ===

The core Bootstrap theme uses a "Fluid Grid System". (Note that in the next version of Bootstrap, there is only one grid system and it is fluid, though it is no longer called that since it is the only grid system.)

http://twitter.github.io/bootstrap/scaffolding.html#fluidGridSystem

LESS

2013-04-12T14:15:09Z

Bawjaws: /* The bootstrap theme */

== Overview ==

LESS ([http://lesscss.org lesscss.org]) extends CSS with dynamic behavior such as variables, mixins, operations and functions. It's an advanced way of writing CSS that we use in some themes within Moodle.

Browsers don't interpret it themselves, however, so LESS files need to be converted into normal CSS before use.

Recess is one tool used to compile and compress LESS into CSS under *nix based systems. There are [https://github.com/cloudhead/less.js/wiki/GUI-compilers-that-use-LESS.js many others tools for LESS].

== The bootstrap theme ==

Moodle's [[Bootstrap]] base theme has rules written using LESS.

The main LESS file is '''theme/bootstrap/less/moodle.less''', with additional files in '''theme/bootstrap/less/moodle/''' imported by the main file.

After compiling the LESS files, CSS ends up in '''theme/bootstrap/style/generated.css'''. This file should not be edited manually.

== Compilers ==

=== Recess ===
==== Installing Recess under Ubuntu ====
The following commands should be run to install Recess

<pre>
sudo apt-get install npm node
npm install recess -g
</pre>

<code>npm</code> stands for Node Package Manager, and is the equivalent of apt-get for node.js packages.

==== Installing Recess on Mac OS X ====
1. Install the basic node packages from the web site: [http://nodejs.org http://nodejs.org] (or use your favourite package manager to install <code>node</code> and <code>npm</code>).

2. On the command line, install recess like this:
<pre>
npm install recess -g
</pre>

==== Using Recess ====

After editing the LESS files, compile your CSS as follows:

<pre>
cd theme/boostrap/less/
recess --compile --compress moodle.less > ../style/generated.css
</pre>

This will compile and compress the moodle.less file (and all the LESS and CSS files it imports) into a single file, generated.css, and store it in the style folder of the bootstrap theme.

NOTE: if you are getting empty generated.css files, this is being caused by a parsing error in your LESS code. A bug in <code>recess</code> currently prevents it giving you helpful error messages in many cases. You will need to examine what you have altered or written to make sure it is complete and the syntax is correct. The <code>lessc</code> compiler is what is used by <code>recess</code> to do the actual compiling and will have been installed automatically along with it. If you call it directly as <code>lessc moodle.less</code> it should give you a helpful error message that points you to where the problem is.

=== WinLess ===
Download [http://winless.org/ WinLess] and install it.

==== Using WinLess ====
1. Click the '''Add folder''' button.

2. Select '''theme\bootstrap\less\''' as the folder to add.

3. Deselect all the LESS files by ticking, then unticking the tick box up in the column header.

4. Select '''moodle.less''' from the list by ticking the checkbox beside it.

5. Right click on the '''moodle.less''' row and click '''Select output file'''.

6. Browse to '''theme\bootstrap\style\''' and select generated.css as the output file.

7. Click the '''Compile''' button.

8. Swap to the '''Compiler''' tab to check the result of the process.

[[Category:Developer tools]]

Bootstrap

2013-04-12T09:02:01Z

Bawjaws: Make a start

== Overview ==

Bootstrap (http://getbootstrap.com) is a "sleek, intuitive, and powerful front-end framework for faster and easier web development". Moodle now has some themes that build upon the best practices, documentation, tools and resources that it provides.

If you're new to Bootstrap we'd suggest starting by reading through the documentation. Not only is it well written and informative, it uses Bootstrap itself and so is a live demonstration too.

http://getbootstrap/getting-started.html

A common complaint about Bootstrap is that all Bootstrap-built sites look the same, since people like the defaults so much they just don't bother to change them. It is however not designed to be a final look, just a platform to build on. Some examples of what can be done can be found at http://builtwithbootstrap.com/

== Features ==

=== Responsive design ===

A key feature of Bootstrap is responsive design. This means that the look of the page changes based on the width of your screen and allows you to alter the presentation so that iPhones, iPads, Netbooks & Desktops get subtly (or radically) different views of the same page.

http://getbootstrap.com/scaffolding.html#responsive

=== Less ===

Bootstrap's stylesheets are written in a variant of CSS called LESS. It is possible to use Bootstrap without LESS as they provide the compiled output as CSS too, but for integration with existing Moodle HTML it is (at least currently) necessary for Moodle Bootstrap's core styles to be compiled after any changes. See the [[LESS]] page for more on this.

=== Glyphicons ===

Bootstrap provides an set of icons called Glyphicons. These are not used for the core Moodle icons as there aren't enough suitable icons to cover Moodle's needs. But they are available for use in content by applying simple CSS classes via the HTML editor. (Note in the next version of Bootstrap this "icon sprite" is replaced with an icon font. It is hoped that Moodle can merge it's SVG icons into this font and all icons will be applied in the same manner)

http://getbootstrap.com/base-css.html#icons

=== Grids ===

Bootstrap uses CSS grids where previously web developers would have used floats (or before that tables). A key feature of grids is that they can "collapse" at smaller widths and so items that would be in a row will appear as a single column on smaller devices like iPhones.

http://getbootstrap.com/scaffolding.html#fluidGridSystem

=== Layouts ===

The core Bootstrap theme uses a "Fluid Grid System". (Note that in the next version of Bootstrap, there is only one grid system and it is fluid, though it is no longer called that since it is the only grid system.)

http://twitter.github.io/bootstrap/scaffolding.html#fluidGridSystem

LESS

2013-04-12T08:30:01Z

Bawjaws: /* Installing Recess under Ubuntu */

== Overview ==

LESS ([http://lesscss.org lesscss.org]) extends CSS with dynamic behavior such as variables, mixins, operations and functions. It's an advanced way of writing CSS that we use in some themes within Moodle.

Browsers don't interpret it themselves, however, so LESS files need to be converted into normal CSS before use.

Recess is one tool used to compile and compress LESS into CSS under *nix based systems. There are [https://github.com/cloudhead/less.js/wiki/GUI-compilers-that-use-LESS.js many others tools for LESS].

== The bootstrap theme ==

Moodle's bootstrap base theme has rules written using LESS.

The main LESS file is '''theme/bootstrap/less/moodle.less''', with additional files in '''theme/bootstrap/less/moodle/''' imported by the main file.

After compiling the LESS files, CSS ends up in '''theme/bootstrap/style/generated.css'''. This file should not be edited manually.

== Compilers ==

=== Recess ===
==== Installing Recess under Ubuntu ====
The following commands should be run to install Recess

<pre>
sudo apt-get install npm node
npm install recess -g
</pre>

<code>npm</code> stands for Node Package Manager, and is the equivalent of apt-get for node.js packages.

==== Installing Recess on Mac OS X ====
1. Install the basic node packages from the web site: [http://nodejs.org http://nodejs.org] (or use your favourite package manager to install <code>node</code> and <code>npm</code>).

2. On the command line, install recess like this:
<pre>
npm install recess -g
</pre>

==== Using Recess ====

After editing the LESS files, compile your CSS as follows:

<pre>
cd theme/boostrap/less/
recess --compile --compress moodle.less > ../style/generated.css
</pre>

This will compile and compress the moodle.less file (and all the LESS and CSS files it imports) into a single file, generated.css, and store it in the style folder of the bootstrap theme.

NOTE: if you are getting empty generated.css files, this is being caused by a parsing error in your LESS code. A bug in <code>recess</code> currently prevents it giving you helpful error messages in many cases. You will need to examine what you have altered or written to make sure it is complete and the syntax is correct. The <code>lessc</code> compiler is what is used by <code>recess</code> to do the actual compiling and will have been installed automatically along with it. If you call it directly as <code>lessc moodle.less</code> it should give you a helpful error message that points you to where the problem is.

=== WinLess ===
Download [http://winless.org/ WinLess] and install it.

==== Using WinLess ====
1. Click the '''Add folder''' button.

2. Select '''theme\bootstrap\less\''' as the folder to add.

3. Deselect all the LESS files by ticking, then unticking the tick box up in the column header.

4. Select '''moodle.less''' from the list by ticking the checkbox beside it.

5. Right click on the '''moodle.less''' row and click '''Select output file'''.

6. Browse to '''theme\bootstrap\style\''' and select generated.css as the output file.

7. Click the '''Compile''' button.

8. Swap to the '''Compiler''' tab to check the result of the process.

[[Category:Developer tools]]

LESS

2013-04-12T08:27:59Z

Bawjaws: /* Using Recess */

== Overview ==

LESS ([http://lesscss.org lesscss.org]) extends CSS with dynamic behavior such as variables, mixins, operations and functions. It's an advanced way of writing CSS that we use in some themes within Moodle.

Browsers don't interpret it themselves, however, so LESS files need to be converted into normal CSS before use.

Recess is one tool used to compile and compress LESS into CSS under *nix based systems. There are [https://github.com/cloudhead/less.js/wiki/GUI-compilers-that-use-LESS.js many others tools for LESS].

== The bootstrap theme ==

Moodle's bootstrap base theme has rules written using LESS.

The main LESS file is '''theme/bootstrap/less/moodle.less''', with additional files in '''theme/bootstrap/less/moodle/''' imported by the main file.

After compiling the LESS files, CSS ends up in '''theme/bootstrap/style/generated.css'''. This file should not be edited manually.

== Compilers ==

=== Recess ===
==== Installing Recess under Ubuntu ====
The following commands should be run to install Recess

<pre>
sudo apt-get install npm node
npm install recess -g
</pre>

==== Installing Recess on Mac OS X ====
1. Install the basic node packages from the web site: [http://nodejs.org http://nodejs.org] (or use your favourite package manager to install <code>node</code> and <code>npm</code>).

2. On the command line, install recess like this:
<pre>
npm install recess -g
</pre>

==== Using Recess ====

After editing the LESS files, compile your CSS as follows:

<pre>
cd theme/boostrap/less/
recess --compile --compress moodle.less > ../style/generated.css
</pre>

This will compile and compress the moodle.less file (and all the LESS and CSS files it imports) into a single file, generated.css, and store it in the style folder of the bootstrap theme.

NOTE: if you are getting empty generated.css files, this is being caused by a parsing error in your LESS code. A bug in <code>recess</code> currently prevents it giving you helpful error messages in many cases. You will need to examine what you have altered or written to make sure it is complete and the syntax is correct. The <code>lessc</code> compiler is what is used by <code>recess</code> to do the actual compiling and will have been installed automatically along with it. If you call it directly as <code>lessc moodle.less</code> it should give you a helpful error message that points you to where the problem is.

=== WinLess ===
Download [http://winless.org/ WinLess] and install it.

==== Using WinLess ====
1. Click the '''Add folder''' button.

2. Select '''theme\bootstrap\less\''' as the folder to add.

3. Deselect all the LESS files by ticking, then unticking the tick box up in the column header.

4. Select '''moodle.less''' from the list by ticking the checkbox beside it.

5. Right click on the '''moodle.less''' row and click '''Select output file'''.

6. Browse to '''theme\bootstrap\style\''' and select generated.css as the output file.

7. Click the '''Compile''' button.

8. Swap to the '''Compiler''' tab to check the result of the process.

[[Category:Developer tools]]

LESS

2013-04-12T08:25:13Z

Bawjaws: /* Installing Recess on Mac OS X */

== Overview ==

LESS ([http://lesscss.org lesscss.org]) extends CSS with dynamic behavior such as variables, mixins, operations and functions. It's an advanced way of writing CSS that we use in some themes within Moodle.

Browsers don't interpret it themselves, however, so LESS files need to be converted into normal CSS before use.

Recess is one tool used to compile and compress LESS into CSS under *nix based systems. There are [https://github.com/cloudhead/less.js/wiki/GUI-compilers-that-use-LESS.js many others tools for LESS].

== The bootstrap theme ==

Moodle's bootstrap base theme has rules written using LESS.

The main LESS file is '''theme/bootstrap/less/moodle.less''', with additional files in '''theme/bootstrap/less/moodle/''' imported by the main file.

After compiling the LESS files, CSS ends up in '''theme/bootstrap/style/generated.css'''. This file should not be edited manually.

== Compilers ==

=== Recess ===
==== Installing Recess under Ubuntu ====
The following commands should be run to install Recess

<pre>
sudo apt-get install npm node
npm install recess -g
</pre>

==== Installing Recess on Mac OS X ====
1. Install the basic node packages from the web site: [http://nodejs.org http://nodejs.org] (or use your favourite package manager to install <code>node</code> and <code>npm</code>).

2. On the command line, install recess like this:
<pre>
npm install recess -g
</pre>

==== Using Recess ====

After editing the LESS files, compile your CSS as follows:

<pre>
cd theme/boostrap/less/
recess --compile --compress moodle.less > ../style/generated.css
</pre>

This will compile and compress the moodle.less file (and all the LESS and CSS files it imports) into a single file, generated.css, and store it in the style folder of the bootstrap theme.

NOTE: if you are getting empty generated.css files, this is being caused by a parsing error in your LESS code. You will need to examine what you have altered or written to make sure it is complete and the syntax is correct.

=== WinLess ===
Download [http://winless.org/ WinLess] and install it.

==== Using WinLess ====
1. Click the '''Add folder''' button.

2. Select '''theme\bootstrap\less\''' as the folder to add.

3. Deselect all the LESS files by ticking, then unticking the tick box up in the column header.

4. Select '''moodle.less''' from the list by ticking the checkbox beside it.

5. Right click on the '''moodle.less''' row and click '''Select output file'''.

6. Browse to '''theme\bootstrap\style\''' and select generated.css as the output file.

7. Click the '''Compile''' button.

8. Swap to the '''Compiler''' tab to check the result of the process.

[[Category:Developer tools]]

Plan to improve ability to delegate administer tasks to course category level

2007-07-19T09:20:16Z

Bawjaws: Development:Plan to improve ability to delegate administer tasks to course category level moved to Development:Plan to improve ability to delegate administrator tasks to course category level: typo

#redirect [[Plan to improve ability to delegate administrator tasks to course category level]]

Plan to improve ability to delegate administrator tasks to course category level

2007-07-19T09:20:16Z

==Motivation==

In a large organisation it is likely that course categories will repesent (in some sense) departments. It would be useful to be able to, effectively, have administrators assigned at the category context and to expect them to have rights to create/delete/edit subcategories and create/delete/edit courses. Some parts of this work, but a lack of underlying original functionality make this inconsistent and incomplete. Roles was mostly a wrapper around existing functionality, so the concept of being able to administer all the courses within a particular role didn't exist but now it becomes possible (and desirable) to assign the administrator role in the Category context.

The main problem area is in the course and category editing screen. This is split across two scripts - course/index.php and course/category.php. The former displays the entire tree and allows new categories to be added and existing ones to be moved, deleted and edited. The latter shows the contents of categories (and subcategories) but allows no editing. It does, however, allow new courses to be added. In an ideal world this would have been a single script providing editing ability within any category level but this would now require a substantial rewrite.

This plan is to make a few small changes to provide a better level of functionality without major changes, rewrites, or refactoring.

==Partial Workaround==

Creating a new role with a single capability allowed - moodle/category:update - and assigning the user to this at the site level gives them access the category and course editing screen (or it should). They will *also* be assigned to the administrator (or equivalent) role in the appropriate category context.

This gives them access to the course/index.php screen enabling them to manipulate categories. The roles system (mostly) controls the rights appropriately to the category editing functions.

==Issues==

Some of these were clearly bugs anyway and have been fixed, but they are noted for completeness.

===Courses item in Administration not tied to capability===

''This has been fixed''

Giving somebody the capability moodle/category:update did not give the option in the Administration menu. This has been fixed.

===No capability for moving categories===

Creating and deleting categories are both covered by capabilities and this is correctly reflected in the course/index.php code. However, the ability to move categories is only controlled by the moodle/category:update capability - the same one that gives you access to the page at all. There is no finer grain control available.

'''Proposal:''' Add a new capability '''moodle/category:move''' along with apropriate code in course/index.php to enforce it.

===No ability to add subcategories directly===

You can only add a new category at the top level even though you can assign the create permission at the category context.

'''Proposal:''' Factor out the code for this out of course/index.php into course/lib.php (functions exist for display already) and add aditionaly to course/category.php with appropriate permissions checking.

'''Caveat"''' This isn't ideal as the course/category.php script does not allow further manipulation of the category; you would have to return to the course/index.php page. However, it's much better than nothing and is an order of magnitude easier to do than a complete rewrite of the two scripts to combine them (which would be the ideal solution)

==Scope==

I don't think there's anything too complex or critical in here and would like to get this into 1.8.3.

==See Also==

The following tracker reports are related:
* [http://tracker.moodle.org/browse/MDL-10049 MDL-10049]
* [http://tracker.moodle.org/browse/MDL-10496 MDL-10496]
* [http://tracker.moodle.org/browse/MDL-10093 MDL-10093]
* [http://tracker.moodle.org/browse/MDL-10031 MDL-10031]
* [http://tracker.moodle.org/browse/MDL-10029 MDL-10029]

Discussion
* [http://moodle.org/mod/forum/discuss.php?d=76226 http://moodle.org/mod/forum/discuss.php?d=76226]

Talk:Moodle Accessibility Specification

2006-09-19T17:26:38Z

Bawjaws: extra square bracket

Was going to add this link:

* [http://www.websemantics.co.uk/tutorials/accessible_forms/ Accessible Forms: Guidelines, examples and accessible JavaScript tricks] Mike Foskett, 9th August 2006

but noticed the [[Moodle Accessibility Specification]] page is protected, so I'll just note it here. Recommend it highly, seems based on a great deal of knowledge and practical experience and has some very good advice on usability, accessiblity and legality (UK) of web forms, written in a very clear manner. --[[User:David Scotson|David Scotson]] 08:29, 6 September 2006 (CDT)

Talk:Moodle Accessibility Specification

2006-09-19T17:26:22Z

Bawjaws: minor clarification

Was going to add this link:

* [http://www.websemantics.co.uk/tutorials/accessible_forms/ Accessible Forms: Guidelines, examples and accessible JavaScript tricks] Mike Foskett, 9th August 2006]

but noticed the [[Moodle Accessibility Specification]] page is protected, so I'll just note it here. Recommend it highly, seems based on a great deal of knowledge and practical experience and has some very good advice on usability, accessiblity and legality (UK) of web forms, written in a very clear manner. --[[User:David Scotson|David Scotson]] 08:29, 6 September 2006 (CDT)

Talk:Moodle Accessibility Specification

2006-09-06T13:29:11Z

Bawjaws:

Was going to add this link:

* [http://www.websemantics.co.uk/tutorials/accessible_forms/ Accessible Forms: Guidelines, examples and accessible JavaScript tricks] Mike Foskett, 9th August 2006]

but noticed page is protected. Recommend it highly, seems based on a great deal of knowledge and practical experience and has some very good advice on usability, accessiblity and legality (UK) of web forms, written in a very clear manner. --[[User:David Scotson|David Scotson]] 08:29, 6 September 2006 (CDT)

Moodle Accessibility Specification

2006-09-06T13:26:00Z

Bawjaws: whoop, didn't realise this page was protected, reverting my own edit

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].)


== 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.]

----
 
'''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.
----
 

==== 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><ol></code>. '''P2'''.
* General [[#Form Elements]] issues, use <code><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 <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 <head> of a XHTML document, while the User Interface should be in the <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><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><fieldset></code> and <code><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><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 ===

* Soc-Forum: hosted at Moodle.org, [http://moodle.org/mod/forum/view.php?f=147 Open Social Forum].
* Features: hosted at Moodle.org, [http://moodle.org/course/view.php?id=34 Features Demo Course].
* OU-Features: hosted internally at OU (Ndf-Moodle), copy of the 'Features Demo Course'.
* CT505: hosted internally at OU (Ndf-Moodle), generic Moodle 1.6 demo/developer site, Topics-format course, demonstration modules including 'database'.
* Ndf-Moodle: hosted internally at OU, generic Moodle 1.6 demo/developer site (cvs: MOODLE_16_STABLE), with example blocks and courses.
* Vledemo: 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:Accessibility]]

Moodle Accessibility Specification

2006-09-06T13:24:39Z

Bawjaws: adding really nice writeup of usability, accessibility and legal (UK) implications of form design

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].)


== 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.]

----
 
'''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.
----
 

==== 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><ol></code>. '''P2'''.
* General [[#Form Elements]] issues, use <code><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 <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 <head> of a XHTML document, while the User Interface should be in the <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><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><fieldset></code> and <code><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><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.
* [http://www.websemantics.co.uk/tutorials/accessible_forms/ Accessible Forms: Guidelines, examples and accessible JavaScript tricks] Mike Foskett, 9th August 2006]

=== 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 ===

* Soc-Forum: hosted at Moodle.org, [http://moodle.org/mod/forum/view.php?f=147 Open Social Forum].
* Features: hosted at Moodle.org, [http://moodle.org/course/view.php?id=34 Features Demo Course].
* OU-Features: hosted internally at OU (Ndf-Moodle), copy of the 'Features Demo Course'.
* CT505: hosted internally at OU (Ndf-Moodle), generic Moodle 1.6 demo/developer site, Topics-format course, demonstration modules including 'database'.
* Ndf-Moodle: hosted internally at OU, generic Moodle 1.6 demo/developer site (cvs: MOODLE_16_STABLE), with example blocks and courses.
* Vledemo: 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:Accessibility]]

Progressive enhancement

2006-07-30T10:33:32Z

Bawjaws:

'''Progressive enhancement''' is a new spin on the popular web design concept of ''graceful degredation''. While the latter focuses on the visual presentation of a web page for the mainstream audience, progressive enhancement prioritises delivering the content and functionality to everyone. By ensuring that it works for every user regardless of technology platform and then adding any non-essential functionality that requires certain capabilities in the browser (or its user) onto that baseline it ensures [[Usability|usability]] and [[accessibility]].

== Progressive enhancement and Moodle ==

=== YUI ===
Moodle has adopted the [[Yahoo! user interface library]] as a platform to build [[AJAX]] and [[DHTML]] enhancements with. Yahoo! have adopted progressive enhancement as one of their key design goals for the library.

=== Hijax ===

Many of most popular AJAX applications were written from scratch with that goal in mind. While that may have saved them time and effort, it also makes it very easy to not support progressive enhancement. Coding for the mainstream audience first may make it very difficult to add support for everyone later. Moodle on the other hand was designed and built in a pre-AJAX age and so already has that infrastructure. [[Hijax]] is the name given to the technique of adding AJAX without removing or replacing the fall-back for less capable browsers.

== See also ==

* [[Javascript]]
* [[AJAX]]
* [[Hijax]]

* [http://hesketh.com/publications/inclusive_web_design_for_the_future/ ''Inclusive Web Design For the Future with Progressive Enhancement'' presentation]
* [http://adactio.com/journal/959 ''Progressive enhancement with Ajax'' blog post]
* [http://hesketh.com/publications/progressive_enhancement_paving_way_for_future.html ''Progressive Enhancement: Paving the Way for Future Web Design'' article]

[[Category:Javascript]]
[[Category:AJAX]]
[[Category:Accessibility]]

User talk:David Scotson

2006-07-18T11:10:06Z

Bawjaws: /* Moodle Docs stats */

==User group pages==

Hi David, I hope it's ok to combine the contents of the user group pages you created, in order to focus on the documentation of standard Moodle features. --[[User:Helen Foster|Helen Foster]] 21:48, 21 February 2006 (WST)

Hello Helen. I'm confused as to whether you're asking permission or forgiveness. I thought at first you'd already combined the pages, but they still seem in place. I suppose the third option is that your asking me to make the change myself.

I had thought about asking whether MoodleDocs was intended for only for 'documentation' in the strict sense, but it appeared that the Wiki was already being used to collate and present a variety of other Moodle-related info, and that made a great deal of sense to me. Similarly to the list of big adopters I thought that one of the first steps for people new to Moodle would be to find out who's using it locally/nationally, people who would theoretically 'sell' Moodle with their success stories etc.

I kind of hoped that I'd finish writing this response and be less confused as to what you were asking, but I'm not. My best guess is that my use of several pages linked by Categories is 'polluting' the namespace for the core documentation content. If so, do you want me to collate the info onto a single page for the time being?

If so no problem, let me know and I'll get to it tomorrow afternoon. It may (hopefully) grow beyond one page later (I still have another 8 JISC user groups to add, and that's just one organisation in one country) but we can cross that bridge when we come to it. --[[User:David Scotson|David Scotson]] 04:12, 22 February 2006 (WST)

:Hi David, apologies for not explaining things clearly. I was confused by the number of redirects and category pages you had created and wondered whether this was intentional or not. Please start by collating the information onto a single page. Thanks! :-) --[[User:Helen Foster|Helen Foster]] 07:41, 22 February 2006 (WST)

I'll do that, but there is a method to my madness which I will explain:

redirects: the purpose of my adding the redirects is so that people get taken to the right page even if there are several equally valid titles, e.g. SMUG, Scottish Moodle User Group, Scottish Moodle User*s* Group. If people type these exact terms in the search box and click 'go' (as opposed to 'search') and the redirects are set up they all get taken to the same page automatically. If the redirects don't exist then you get taken to a page that says "there is no exact match etc." and displays the search results for the entered term. Usually one of the first few entries is going to be relevant, but it's just a little less smooth. (Note the same system applies if people enter these terms at the end of URLs).

categories: these are my favourite feature of MediaWiki, the Wikipedia has literally [http://en.wikipedia.org/wiki/Special:Allpages/Category:A thousands of them] which very rarely get in your way unless you are actually navigating the a subset of the hierarchy that interests you. My general feeling is the more the merrier, and criss-crossing categories would add a lot of value. We should therefore expect and plan for many Categories to be added. They also have a role to play in my next point.

wiki philosophy: I'd always read that what you leave out of a wiki is as important as what you add. Since part of the point of using a wiki is to invite community participation, it's sometimes recommended to leave things half done, to encourage people to jump in and finish it off. This applies to stub pages, links that don't go anywhere, and to a certain extent not worrying about the quality of your English (particularly if it's not your first language) as all these things present opportunities for others to join in, while on the other hand editing or adding to a tight core of well written documentation may seem intimidating as a first step to someone with only a little time or information to offer. Categories are important pointers in this direction as seeing a list of UK user groups would surely prompt others to add their own countries, at some point you begin to feel left out if your country isn't listed. And the same occurs within each country as each User Group doesn't want to be left out. I thought that because people feel a sense of ownership of their user groups they would therefore feel comfortable writing the pages about them. Also because of the kind of people that are involved in them, I thought they would be ideal first steps for the kind of people who should be editing MoodleDocs. Once they've got that first page under their belt then further participation should be easy. --[[User:David Scotson|David Scotson]] 18:56, 22 February 2006 (WST)

:Hi David, thanks for your explanation - much appreciated :-) --[[User:Helen Foster|Helen Foster]] 01:05, 23 February 2006 (WST)

==Marking pages for deletion==

I've moved the info into a single page called [[list of user groups]] but I'm confused about how to mark the old pages for deletion --[[User:David Scotson|David Scotson]] 19:15, 22 February 2006 (WST)

:I see you've noticed that [[:Template:Delete|Template:Delete]] is yet to be created ;-) --[[User:Helen Foster|Helen Foster]] 01:05, 23 February 2006 (WST)

==Thank you==

Hi Dave, just wanted to say how interesting your user page is - a big thank you for your contributions to Moodle Docs :-) --[[User:Helen Foster|Helen Foster]] 19:27, 28 April 2006 (WST)

==Moodle Docs stats==

Re. [[Special:Statistics|Statistics]] for registered users, I recall Eloy mentioning a bug resulting in the stats not updating properly ;-) I don't know if it's been fixed yet. --[[User:Helen Foster|Helen Foster]] 19:31, 28 April 2006 (WST)

:Update: I've used Eloy's work-around for updating registered users. --[[User:Helen Foster|Helen Foster]] 18:30, 18 July 2006 (WST)

:: Great stuff, I wasn't sure whether the integration with Moodle.org was throwing the number out. 3.5K registered users is pretty good going --[[User:David Scotson|David Scotson]] 19:10, 18 July 2006 (WST)

==Module page names==

Just thinking that it seems a good plan to rename module pages to ''Whatever'' module (e.g. Wiki module) in the same way that block pages have been renamed ''Whatever'' block. Thanks for your suggestion :-) --[[User:Helen Foster|Helen Foster]] 19:17, 8 May 2006 (WST)

User:David Scotson

2006-07-16T17:03:53Z

Bawjaws: /* stats */

An E-learning Technologist / software developer working for the [http://www.gla.ac.uk University of Glasgow] as part of the newly formed Learning and Teaching Centre.

[http://moodle.org/user/view.php?id=3152&course=5 My profile at Moodle.org]

== Me and MoodleDocs ==

I gave a talk about Moodle recently to some of our IT support teams, one of the main points of which was was a great project MoodleDocs was (or at that time 'was going to be'), and how it could be a 'killer app' for Moodle i.e. so good that people use Moodle rather than alternatives simply because the documentation is so good. It's certainly the case that when we evaluated Moodle, the strong community support was a key deciding factor (it's a fruitless chicken and egg question whether the quality of Moodle attracted the strong community or the strong community contributed to the quality of Moodle, obviously they re-inforce each other). Having a commited, passionate community building documentation in a wiki just seemed like such a great idea, especially as I was aware of how much great info was 'hidden' within the postings of the Using Moodle forums, and the shared urge to teach/share that drives much of that. As I'm one of those people who loves to say 'I told you so!' when things turn out as I predict them to and, more importantly, because I think lack of good documentation is one of the areas holding back widespread adoption of e-learning/Moodle, I thought I'd get involved.

I'm particularly interested in:

* the social/community aspects of the project (including it's role as a community of practice)
* how the documentation caters to different audiences (dev/admin/teacher/student) while at the same time supporting/encouraging people to move between (or at least understand) different roles
* effective use of hypertext/web/wiki medium (meaning both collaborative text writing and using hyperlinks to break up and interwingle content)
* the interaction between the project websites, forums, databases, and this wiki

== Things I've learned, realised or had brought home to me through contributing to this Wiki ==

=== prose versus lists ===

Short version: lists win every time. They:
* allow others to easily interject, add to or edit your contributions, without having to untangle your text. Even editing your own text as you add things can turn into a scene reminiscent of Monty Python: "NOBODY expects the Spanish Inquisition! Our chief weapon is surprise...surprise and fear...fear and surprise.... Our two weapons are fear and surprise...and ruthless efficiency.... Our *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope.... Our *four*...no... *Amongst* our weapons.... Amongst our weaponry...are such elements as fear, surprise.... I'll come in again."
* make following step-by-step lists easy, aiding readability and scan-ability
* act as an open invite for other others to contribute (I think at least part of this is to do with depersonalisation, which sounds bad, but in a collaborative wiki text is necessary for effective copy-editing for clarity, length etc.)
* can be easily scannable indexes, into various documentation sub-topics.

=== singular versus plural ===

* MediaWiki seems to have a slight technical preference for singular names of articles. You can use <nowiki>[[Module]]s and
[[Quiz]]zes when you need to use a plural in a sentence instead of [[Modules|Module]] and [[Quizzes|Quiz]] if the page is pluralised</nowiki>
* Categories, when used as lists, make more sense (to me at least) as plurals, but means possibly having two similar very terms e.g. if themes is a list of Moodle Themes, then what do you use for Theme related content? ''Themeing''?

=== stats ===

The [[Special:Statistics|stats]] page linked off the frontpage is very cool, particularly the number of registered users. I'd love it if these could be graphed over time.

The [http://www.alexa.com/data/details/traffic_details?&compare_sites=&y=t&q=&size=medium&range=6m&url=http://moodle.org/ Alexa] (recently bought by Amazon) stats are also interesting, showing 14% of traffic to moodle.org going to the docs.moodle subdomain. Again graphing this over time would be interesting I might make manual notes myself for a rough tally. Current standings are:

* moodle.org ~ 70%
* docs.moodle.org ~ 14%
* download.moodle.org ~ 7%
* demo.moodle.com ~ 4%
* moodle.com ~ 3%
* Other websites ~ 2%

== Mediawiki supports RSS and Atom ==

The RSS and Atom feeds are a good way to keep up with what's going on, though they don't seem very discoverable and the Atom feed, which I would generally prefer doesn't seem to display as nicely and the RSS one, at least on Safari.

* [https://docs.moodle.org/en/index.php?title=Special:Recentchanges&feed=rss RSS feed of recent changes]
* [https://docs.moodle.org/en/index.php?title=Special:Recentchanges&feed=atom Atom feed of recent changes]

[http://meta.wikimedia.org/wiki/Syndication_feeds more info, and a list of other available feeds e.g new pages]

== To-do list ==

A list of things for me to think/do something about in MoodleDocs:

* highlighted article category (like Wikipedia)
* list of standards that Moodle supports
* more info on ways to contribute
* Jargon page
* fix the database so searches for three-letter words work
* ...

== Docs topics for Uk MoodleMoot 06 ==

* Search stuff
** how to recompile MySQL to fix searching for 3 letter words
** adding OpenSearch to Mediawiki
** Google Sitemaps
* usage statistics
** why 3,605 registered users in [[Special:Listusers]] but 1,060 registered users in [[Special:Statistics]]?
** How many non-registered users does the 2% increase in share of moodle.org visitors (from 14-16% in last few months according to [http://www.alexa.com/data/details/traffic_details?q=&url=moodle.org]) represent in actual no. of people?
** How popular are our [[Special:Popularpages]] and how meaningful are those numbers (tangent: long tail graph for pages?)
** How do we measure success? Are our users finding what they are looking for? Are we helping people to help themselves?
* Misc
** redirect docs.moodle.org/Stuff to docs.moodle.org/en/Stuff?
** personally thank contributors

User:David Scotson

2006-07-16T16:50:01Z

Bawjaws: stuff for MoodleMoot

An E-learning Technologist / software developer working for the [http://www.gla.ac.uk University of Glasgow] as part of the newly formed Learning and Teaching Centre.

[http://moodle.org/user/view.php?id=3152&course=5 My profile at Moodle.org]

== Me and MoodleDocs ==

I gave a talk about Moodle recently to some of our IT support teams, one of the main points of which was was a great project MoodleDocs was (or at that time 'was going to be'), and how it could be a 'killer app' for Moodle i.e. so good that people use Moodle rather than alternatives simply because the documentation is so good. It's certainly the case that when we evaluated Moodle, the strong community support was a key deciding factor (it's a fruitless chicken and egg question whether the quality of Moodle attracted the strong community or the strong community contributed to the quality of Moodle, obviously they re-inforce each other). Having a commited, passionate community building documentation in a wiki just seemed like such a great idea, especially as I was aware of how much great info was 'hidden' within the postings of the Using Moodle forums, and the shared urge to teach/share that drives much of that. As I'm one of those people who loves to say 'I told you so!' when things turn out as I predict them to and, more importantly, because I think lack of good documentation is one of the areas holding back widespread adoption of e-learning/Moodle, I thought I'd get involved.

I'm particularly interested in:

* the social/community aspects of the project (including it's role as a community of practice)
* how the documentation caters to different audiences (dev/admin/teacher/student) while at the same time supporting/encouraging people to move between (or at least understand) different roles
* effective use of hypertext/web/wiki medium (meaning both collaborative text writing and using hyperlinks to break up and interwingle content)
* the interaction between the project websites, forums, databases, and this wiki

== Things I've learned, realised or had brought home to me through contributing to this Wiki ==

=== prose versus lists ===

Short version: lists win every time. They:
* allow others to easily interject, add to or edit your contributions, without having to untangle your text. Even editing your own text as you add things can turn into a scene reminiscent of Monty Python: "NOBODY expects the Spanish Inquisition! Our chief weapon is surprise...surprise and fear...fear and surprise.... Our two weapons are fear and surprise...and ruthless efficiency.... Our *three* weapons are fear, surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope.... Our *four*...no... *Amongst* our weapons.... Amongst our weaponry...are such elements as fear, surprise.... I'll come in again."
* make following step-by-step lists easy, aiding readability and scan-ability
* act as an open invite for other others to contribute (I think at least part of this is to do with depersonalisation, which sounds bad, but in a collaborative wiki text is necessary for effective copy-editing for clarity, length etc.)
* can be easily scannable indexes, into various documentation sub-topics.

=== singular versus plural ===

* MediaWiki seems to have a slight technical preference for singular names of articles. You can use <nowiki>[[Module]]s and
[[Quiz]]zes when you need to use a plural in a sentence instead of [[Modules|Module]] and [[Quizzes|Quiz]] if the page is pluralised</nowiki>
* Categories, when used as lists, make more sense (to me at least) as plurals, but means possibly having two similar very terms e.g. if themes is a list of Moodle Themes, then what do you use for Theme related content? ''Themeing''?

=== stats ===

The [[Special:Statistics|stats]] page linked off the frontpage is very cool, particularly the number of registered users. I'd love it if these could be graphed over time.

The [http://www.alexa.com/data/details/traffic_details?&compare_sites=&y=t&q=&size=medium&range=6m&url=http://moodle.org/ Alexa] (recently bought by Amazon) stats are also interesting, showing 14% of traffic to moodle.org going to the docs.moodle subdomain. Again graphing this over time would be interesting I might make manual notes myself for a rough tally. Current standings are:

* moodle.org ~ 70%
* docs.moodle.org ~ 14%
* download.moodle.org ~ 7%
* demo.moodle.com ~ 4%
* moodle.com ~ 3%
* Other websites ~ 2%

== To-do list ==

A list of things for me to think/do something about in MoodleDocs:

* highlighted article category (like Wikipedia)
* list of standards that Moodle supports
* more info on ways to contribute
* Jargon page
* fix the database so searches for three-letter words work
* ...

== Docs topics for Uk MoodleMoot 06 ==

* Search stuff
** how to recompile MySQL to fix searching for 3 letter words
** adding OpenSearch to Mediawiki
** Google Sitemaps
* usage statistics
** why 3,605 registered users in [[Special:Listusers]] but 1,060 registered users in [[Special:Statistics]]?
** How many non-registered users does the 2% increase in share of moodle.org visitors (from 14-16% in last few months according to [http://www.alexa.com/data/details/traffic_details?q=&url=moodle.org]) represent in actual no. of people?
** How popular are our [[Special:Popularpages]] and how meaningful are those numbers (tangent: long tail graph for pages?)
** How do we measure success? Are our users finding what they are looking for? Are we helping people to help themselves?
* Misc
** redirect docs.moodle.org/Stuff to docs.moodle.org/en/Stuff?
** personally thank contributors

UK MoodleMoot 06 hackfest

2006-07-12T17:35:18Z

Bawjaws: /* Performance profiling */

Monday 24th July, 2006

''Welcommen zum Hackfest'' (OK - I've been watching too much WorldCup on TV).

The first MoodleMoot hackfest is nearly upon us... and we don't have an agenda!

This is an open source agenda for the hackfest. We'll have a day before the Moot to geek out on some code, maybe develop a feature or two, fix some bugs and generally make our favorite learning system a happier place. But I leave it up to you to tell me exactly what we should do. We have four or five rooms with internet connections, a few projectors, and I'll try to get pizza.

Let's start by brainstorming some ideas here for a few days. If someone posts something you're interested in, put your name under it as a vote. The top votes become our central organizing ideas. For example

==1 Bug fixing==

Let's spend a few hours and hunt down as many outstanding bugs in 1.6 as possible. Bounties for most bugs killed, trickiest bug killed, and most unusual bug killed.

''I'm Interested:''
# Jason Cole
# skodak
# martin langhoff (auth & enrolment specifically).
# Martin Dougiamas
# Juliette White (arriving late though!)
# Dan Stowell

(iarenaza) I won't be there, but here are a couple of bugs for Martin L., related to auth: #4648 and #5373. Very easy to fix :-)

==2 What next for the quiz module?==

If any other quizzy people are there, we should have a talk about where we see the quiz module going.

I/the OU have the following priorities:

# Make question type plugins really plug-in-able. At the moment there are some limitations:
#* All the lang strings are still in lang/en_utf8/quiz.php.
#* qtype plugins cannot easily feed CSS and Javascript into the page.
#* pluggable qtypes and pluggable inport/export filters don't play nicely together.
# Write some new question types.
# Make some improvements to existing question types.
# Get RQP working again, so our in-house question engine can talk to Moodle.

I'm not going to be there, but I think it would be helpful if you were to discuss ways in which the teacher's usage of the quiz module could be made more efficient, more in terms of grading than in creating quizzes (as there have already been a lot of improvements in that respect in 1.6). I've submitted a lot of bug reports about this already but personally efficiency would be more of a priority to me than new question types.--[[User:N Hansen|N Hansen]] 08:27, 12 July 2006 (WST)

''I'm Interested:''
# Tim Hunt
# Jamie Pratt

==Performance profiling==

Pick a (memory|database) hog and put it on a diet.

''I'm interested''

# martin langhoff
# dave scotson (particularly the TinyMCE performance issues mentioned recently by Martin D)

(iarenaza) Once again, I won't be there, but here's an unfixed bug in 1.6.x and HEAD (was fixed in 1.5.x, but not applied to HEAD at the moment): bug #4591

==Hacking on the OLPC Board==

MartinL will be bringing the OLPC board (if it is booting, and customs allows!) for people to have a play with it. If we have any Mozilla/XUL experts in the house, he will want to explore building a limited cached Moodle UI with it for offline work.

'''Note:''' We will need some spare parts & hardware to get the board going. I will bring a power supply, but a VGA monitor, USB mouse + keyboard, USB ext disk, USB hub, and open wifi (no ethernet on the board) will be needed.

''JC: We'll make sure you have the appropriate stuff. I need a USB disk anyway.''

''I'm interested:''

# martin langhoff
# Jason Cole

==How to save/retrieve a complete section from stock?==
Now the sections become more and more accepted as the tasksets for a week, our teachers wish to have topic oriented stores (courses for the moment) as section stores and want to copy one/more sections form that task store to a clean course..

''(In the end we wish that students can select sections from the store to compose their own courses, until the teacher freezes their choice set and the learning game can begin.)''

''I'm interested:''
# Ger Tielemans (I arrive a little later, so start with the bugs first, please :))
# Jan Kater (same arrival=same message as Ger T.)

==How to reveale files outside a course without using datadir for course 1?==
Can someone explain the right setup and use of the exception array:
- we want to show a student (after login) only his own file from that store
- we want to show a teacher/tutor only the files from the students in his course(s)

''I'm interested:''
# Ger Tielemans
# Jan Kater

==How to repair the last bug in the old bookmark option ?==
We changed William's bookmark in a student only note-taking tool and (thanks Chardelle!) almost repaired the complete bookmark for 1.6. (and it can be accessed from My Page)
Bug: Only when the user tries to sort the heder in the overview, the text of the headers disappear.
Code clean-up: how to remove obsolete code and make the bookmark pages secure?
(Wish for new code: categories are privat, so allow a student to delete a self created category)

''I'm interested:''
Ger Tielemans

==How to insert a HTML-editor in old code block and make it secure ?==
To make the set of student note-taking tools complete, I found old code to have a global private notebook.
(I group this with bookmarks in the calender, so the student has: 1. privat time-related-notes in the calendar, 2. a button for the overview of the privat page-related-notes under the calendar and 3. a global privat notebook for other scribbles..)
On this moment this piece of code has a flat text editor, would be nice to have HTML or even the new (Ajax?) miniWiki?)

With the new "View as student button" check like if isstudent() {..show..} offers teachers and admins empty - only for real student - spots (so an error)

''I'm interested:''
# Ger Tielemans
# Jan Kater

== Improve the way we integrate Rubrics in Moodle, like... ==
http://docs.subjectivemetrics.com/User/cam/rubistar/rs_overview.html

maybe with some flavors of...

http://ipeer.apsc.ubc.ca/ipeer_site/

==Add your suggestion here ...==

Go on, you know you want to.

==See also==
* [http://moodlemoot.org/ http://moodlemoot.org/]

Unit test API

2006-06-19T14:54:28Z

Bawjaws: /* More about unit testing in general */ small typo plus category

The purpose of unit testing is to test the individual parts of the program (functions, and methods of classes) to make sure that each individually does the right thing. Once unit testing has given you the confidence that each part works, then you should use other forms of testing to ensure that the different parts work together properly.

The unit testing framework is based on the [http://www.lastcraft.com/simple_test.php SimpleTest] framework. It was incorporated into Moodle by Nick Freear and Tim Hunt from [http://www.open.ac.uk/ The Open University].

== Running the unit tests in Moodle ==

=== Running the basic tests ===

# Log in with an admin account.
# Go to the admin screen.
# Near the bottom of the menu, there is a link to run the unit tests.
# Wait for the tests to run.

=== Options for running the tests ===

At the bottom of the tests page there is form that lets you adjust the options used when running the tests.

==== Show passes as well as fails ====

Normally, only details of the tests that have failed are printed. Turning on this options shows details of all the passes too.

==== Show the search for test files ====

The tests to run are found automatically be searching the codebase for files whose names match '''test*.php''' in directories called '''simpletest'''. Turning on this option will print a list of the folders searched and the test files found. This is sometimes useful for debugging.

This option is particularly useful when one of your test files gives a syntax error. When this happens, you sometimes just get a blank page with no error message. Turning on the show search option lets you see which test file it was that gave the error. If necessary, you can enable this option manually by adding "showsearch=1" to the end of the URL.

==== Run a thorough test (may be slow) ====

If you turn on this option, then as well as looking for files called '''test*.php''', the search also looks for files called '''slowtest*.php'''.

To be useful, the full test run should find most bugs, but not take too long to complete. So if you have very, very detailed tests of an area of the code, it may be better to select a subset for everday testing, and only use the more detailed tests when a bug is reported, or you are doing new development in that area of the code.

This option is most useful when combined with the next option.

==== Only run tests in ====

Normally, tests from all parts of the codebase are run. However, when you are just doing development of one part of the code, that is a waste of time. You can type the name of a folder (for example '''mod/quiz''') or a particular test file (for example '''lib/simpletest/testdatalib.php''') and then only those tests will be run.

[[Image:RunOnlyTheseTests.png|right]] Instead of typing a path into this box, there is an easier way. Whenever a pass or fail is displayed, the name of the test file is printed. Each section of the path name is a link to run only the tests in that folder or file.

== Writing new tests ==

As an example, suppose we wanted to start writing tests for the functions in the file 'question/editlib.php'.

=== Were to put the tests ===

If you have read the first half of this page and were paying attention, you can probably work out that you should create a folder called '''question/testeditlib''', and in there, create a file called something like '''testeditlib.php'''.

The skeleton of this file should look like:

<pre><?php
/**
* Unit tests for (some of) question/editlib.php.
*
* @copyright © 2006 The Open University
* @author T.J.Hunt@open.ac.uk
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
* @package question
*/

/** */
require_once(dirname(__FILE__) . '/../../config.php');

global $CFG;
require_once($CFG->libdir . '/simpletestlib.php'); // Include the test libraries
require_once($CFG->dirroot . '/question/editlib.php'); // Include the code to test

/** This class contains the test cases for the functions in editlib.php. */
class question_editlib_test extends UnitTestCase {
function test_get_default_question_category() {
// Do the test here/
}
}
?></pre>

That is, you have a class called something_test, and in that class you have lots of methods called test_something. Normally, you have one test method for each function you want to test, and you may as well called the test method '''test_name_of_function_being_tested'''.

=== Inside a test function ===

TODO

=== Test data ===

TODO

=== Further information ===

The simpletest documentation is at: http://simpletest.sourceforge.net/.

== Changes to your existing code to make it work with unit testing ==

TODO

== More about unit testing in general ==

The best book I know about unit testing is '''Pragmatic Unit Testing in Java with JUnit'' by Andrew Hunt and David Thomas. I know, this book is not called Pragmatic Unit Testing in PHP with SimpleTest. However, it is an excellent book - short, to the point, and very practical. Most of what it says is not specific to Java and JUnit and it is obvious how to apply it in our testing setup.

User talk:Helen Foster

2006-05-27T09:40:26Z

Bawjaws: /* Moodle Docs Wiki accidentally switched to Portuguese? */

== More hierarchy ==

Hi Helen, I think this wiki is very useful and I would like to thank you for the work you are putting into it. I like your navigation boxes on the module pages. I have a suggestion for extending these: I think it would be nice to have an extra link that allows one to go higher up in the hierarcy to [[Teacher_documentation]]. What do you think? --[[User:Delius|Delius]] 17:48, 26 January 2006 (WST)

:Hi Gustav, thanks for your kind words. Your contributions to the documentation are most welcome. Please feel free to edit [[Template:Quizzes]] or any other template page. You may also wish to consider further use of category pages e.g. [[:Category:Teacher]] for navigation. -- [[User:Helen|Helen]] 18:26, 26 January 2006 (WST)

== Do you monitor all talk pages? ==

Helen, I have posted another question for you on [[Talk:mod/quiz/index]]. Do you get alerted to anything I put on any talk page or should I post on this page if I want you to see it? --[[User:Delius|Delius]] 18:01, 26 January 2006 (WST)

:Hi Gustav, please note that I often check [[Special:Recentchanges|Recent changes]] or the rss feed. --[[User:Helen|Helen]] 18:26, 26 January 2006 (WST)

::Yes, the [[Special:Recentchanges|Recent changes]] page is very useful. You can tell that I have never used a wiki intensively before. Thanks for your tips. --[[User:Gustav|Gustav]] 18:35, 26 January 2006 (WST)

:::Hey, let's discover the wiki way together! :-) --[[User:Helen|Helen]] 00:24, 27 January 2006 (WST)

==Moodle profile==

Helen- I think you should link to your moodle profile like Martin does (assuming you have one, which I assume <grin>). -- D.I. 29Jan06
Wow, you're fast.. .or I'm confused. --D.I. 29Jan06

:Hi D.I. thanks for your suggestion, which [[User:UrsHunkler|someone else]] seem to be following up! ;-) --[[User:Helen|Helen]] 05:00, 30 January 2006 (WST)

== German moodle docs possible? ==

Hello Helen,

thank you very much for these nice and structured doc pages.
When do you plan to launch a german part of the docs.moodle.org pages?
I ask these question because i can translate some of the english doc pages to german.

Greetings Christoph

:Hi Christoph, thanks for your kind offer of translation. Please email ''docs AT moodle DOT org'' so I may get in touch with you easily when the German Moodle documentation is launched. --[[User:Helen|Helen]] 05:17, 30 January 2006 (WST)

== German User Docs ==

Thanks a lot, Helen, for all your work.
I would also like to help with the German version.

Ulrike

:Hi Ulrike, thanks for your kind offer too. MoodleDocs in other languages will happen soon, for sure! --[[User:Helen|Helen]] 08:30, 31 January 2006 (WST)

== Documentation for different versions ==

Helen

Is there a mechanism for specifying which version of Moodle a particular document refers to? If, for instance, a feature is only available in version 1.6, how would a 1.5.3 user know they couldn't follow these instructions?

Equally, if something is done differently in two versions, how would we stop an edit war breaking out between 1.5.3 and 1.6 users?

I appreciate this probably isn't an issue just yet, but it's possible it may become one in later versions.

Cheers,

[[User:CHRISF|CHRISF]] 19:20, 1 February 2006 (WST)

:Hi ChrisF, thanks for highlighting the issue of differences in Moodle versions. Perhaps a Moodle 1.6 template, inserted using the code <code><nowiki>{{Moodle 1.6}}</nowiki></code>, may be used to show features specific to Moodle 1.6. What do you think? --[[User:Helen|Helen]] 04:22, 4 February 2006 (WST)

::Good idea. I think that would clear it up nicely. [[User:CHRISF|CHRISF]] 18:08, 7 February 2006 (WST)

==Hungarian Moodle Docs==

Hello Helen,
I may be knocking at the wrong door.
Could you please create a folder for me to start Moodle documentation in Hungarian please?
Thanks a lot.
Karoly

(Karoly Fabricz, kfabricz AT vnet DOT hu)

:Hi Karoly, thanks for your kind offer. Please read the information on [[MoodleDocs:Starting MoodleDocs|starting Moodle Docs in another language]]. I'll be in touch soon. --[[User:Helen Foster|Helen Foster]] 17:09, 15 March 2006 (WST)

== Belarusian Docs is possible? ==

Dear Helen,

I would like to manage Moodle documentation on Belarusian. Could you create a folder for me to start Moodle documentation in Belarusian, please? Аlphabetic acronym of Belarusian language is be.

Sincerely,
Maryia Davidouskaia
(maryia at iatp dot by)

:Hi Maryia, thanks for your kind offer. As I said to Karoly, please read the information on [[MoodleDocs:Starting MoodleDocs|starting Moodle Docs in another language]], and remember that the more people that are involved in creating the documentation, the better it will be. I'll be in touch soon. --[[User:Helen Foster|Helen Foster]] 17:09, 15 March 2006 (WST)

Ok, You are a STAR!

== Template styles ==
Hi Helen! I noticed that you reverted my edits on [[Template:Book]] and [[Template:Assignments]]. You were right -- I didn't realise that the [[MoodleDocs:Styling|style]] doesn't match [[MoodleDocs:Style guide|moodle.org style]]. However, the current template doesn't look right either. It should float to the right instead of occupying a substantial part of the upper screen (for eg. on [[Calculated question developer docs]] page) -- this wil provide easier navigation. Also, the tempalate should be colorful and/or bordered -- this looks more attractive and the reader can understand that it is not a part of the article. May be we can have orange or similar colored templates (such as [[Template:Large Installations]] and [[Template:excerpted from Jason Cole]]) that match with moodle.org style? Is there any official style documentation? Is there a moodle.org style guide which describes styles for templates -- I couldn't find one? [[User:Utkarshraj Atmaram|Utkarshraj Atmaram]] 17:40, 30 March 2006 (WST)

:Hi Utkarshraj, thanks for your contributions to Moodle Docs. As you've found, [[MoodleDocs:Style guide]] and [[MoodleDocs:Styling]] contain all the Moodle Docs styling documentation to-date. Please add your comments about template styling to [[MoodleDocs talk:Styling]]. --[[User:Helen Foster|Helen Foster]] 17:26, 31 March 2006 (WST)

::Thank you! I've started the discussion at [[MoodleDocs talk:Styling]]. [[User:Utkarshraj Atmaram|Utkarshraj Atmaram]] 19:14, 31 March 2006 (WST)

:::LoL, I just realized that the problem is not with the templates, but with themes. Templates just look find with the MoodleDocs theme, but when I am logged in, I use MonoBook theme -- it doesn't display them as right-aligned (at Wikipedia, we explicity make the templates right-aligned). Sorry for wasting your time! [[User:Utkarshraj Atmaram|Utkarshraj Atmaram]] 14:44, 18 April 2006 (WST)

== Slovak Moodle Documentation ==

Hi, Helen. We would like to start work on translation on Moodle Slovak (sk) documentation. Please, do you think is it possible? Thank you.

Sincerely, Juraj Chlebec
havran@gmail.com

:Hi Juraj, thanks for your offer. Please note that, for non iso-8859-1 languages we need to wait for moodle.org to be converted to UTF-8 (since Moodle Docs authenticates against moodle.org) before setting things up. I'll be in contact when this is done. --[[User:Helen Foster|Helen Foster]] 22:05, 10 April 2006 (WST)

== Polish Moodle Documentation ==

Hello, Helen. I saw Your comments to Juraj's post, so just want to let you know that we are ready to start polish translation. Hope the situation will change soon.

== Removing erroneous pages ==

How can unsuitable pages be removed? I just found [[RHLANGUAGE]] which is not documentation-quality...
Maybe you could do it (please) Helen? Not sure.

Best, Dan
--[[User:Dan Stowell|Dan Stowell]] 04:24, 4 May 2006 (WST)

:Thanks Dan, for future reference please add the deletion template, <code><nowiki>{{Deletion}}</nowiki></code>, to any unsuitable page you find. --[[User:Helen Foster|Helen Foster]] 04:45, 5 May 2006 (WST)

== Request for help (check) ==

Hi, Sun, could you check this page: https://docs.moodle.org/en/Release_Notes
all the info written both in 1.6 and 1.5.4 relative to the Authorize plugin? Ethem Evlice requested me to do so, but you know, I'm not the best English checker in the world! ;-) [[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 17:35, 11 May 2006 (WST)

:NP Sol, I've done as requested :-) --[[User:Helen Foster|Helen Foster]] 19:51, 15 May 2006 (WST)

== Moodle Doc Is Great ==

You have done a great job and inspired me to use Media Wiki!

:Thanks Martin, though it's everyone's contributions that make Moodle Docs a great resource! --[[User:Helen Foster|Helen Foster]] 06:36, 24 May 2006 (WST)

== Moodle Docs Wiki accidentally switched to Portuguese? ==

Hi Helen, all of the built in Mediawiki content is appearing in Portuguese for me, both before and after I log in. Perhaps an admin setting that's been accidentally changed? --[[User:David Scotson|David Scotson]] 17:36, 27 Maio 2006 (WST)

:To clarify, only some of the Mediawiki content is in Portuguese. If I go to to the user preferences and choose Portuguese it changes even more text. Changing back to English only returns some text to English. However, choosing French changes all Mediawiki text to French. From this I'm guessing that someone may have overwritten some of the english language files on the server with Portuguese ones. --[[User:David Scotson|David Scotson]] 17:40, 27 Maio 2006 (WST)

User talk:Helen Foster

2006-05-27T09:36:01Z

Bawjaws: /* Moodle Docs Wiki accidentally switched to Portuguese? */