MoodleDocs - User contributions [en]

oEmbed proposal

2011-11-02T15:34:03Z

Nfreear: Initial copy from Google Docs.

NOTE: I'm not posting this yet on the Moodle Docs wiki as I'm away 14 Oct-1 November.

Summary: This is a proposal and request for comments for a third-party/ contributed oEmbed filter plugin for Moodle. It would enable authors to easily embed multimedia resources from many web sites, for instance, YouTube, Vimeo, Slideshare, Prezi, LAMS and Google Docs.

IMPORTANT: This a proposal - the code does not yet exist!

[Todo: forum link]

== What is oEmbed? ==

From the Wordpress docs:
oEmbed is "...a protocol for site A (such as your blog) to ask site B (such as YouTube) for the HTML needed to embed content (such as a video) from site B." [http://codex.wordpress.org/Embeds#oEmbed]

Longer explanation:

oEmbed is a [http://oembed.com/ specification] for a service-based approach to embedding external content. An author typically inserts a URL for the provider's web page containing the content, for example, for a YouTube video the author might insert http://youtube.com/watch?v=wZoMbBzqxyc or http://prezi.com/zoidjousoeat/technology-for-the-classroom/ in their Moodle resource. The client plugin (a Moodle filter), takes this URL and makes a request to a web service, for example, http://youtube.com/oembed?format=xml&url=http://youtube.com/watch?v=wZoMbBzqxyc

The web service responds using XML or JSON, and the response contains the embed code. The client replaces the URL in the author's text with the embed code.

== Adoption ==

Many multimedia sites (providers) have an oEmbed service, including YouTube, Flickr, Slideshare...

There are several services to provide oEmbed on behalf of multiple multimedia providers:

* [http://oohembed.com/ Oohembed.com] - 10s of providers
* [http://embed.ly/ Embed.ly] - 100s of providers; jQuery plugin; API key; services.json.
* [http://embed.open.ac.uk/ Embed.open.ac.uk] - The Open University has an experimental oEmbed service, with a jQuery plugin. Currently it supports the OU player (release candidate), YouTube, Prezi, Google Docs spreadsheets/forms and LAMS (Beta). With the OU-embed service we are experimenting with improved mobile support, improved accessibility, HTML5, RDFa, internationalization, and fulfilling niche requirements (eg. embedding LAMS, Scratch etc.). Note, OU-embed ties in with the OULDI project and Cloudworks.

oEmbed is widely adopted on the client side. It is [http://codex.wordpress.org/Embeds#oEmbed native to Wordpress 2.9+], there is a [http://drupal.org/project/oembed Drupal module], and libraries for PHP, Python and other languages. There are also in-browser, Javascript solutions - jquery-oembed, embed.ly's oEmbed plugin, and a version of jquery-oembed for Embed.open.ac.uk).

It is used in sites like Twitter [link],... and [http://cloudworks.ac.uk/.. Cloudworks]

== Advantages ==
There are various advantages to oEmbed:

* An author can avoid manual copy and paste of embed HTML code from the multimedia site. So, it simplifies the task of embedding, and prevents mistakes,
* A web developer need only add support for oEmbed to their site or application once, and take advantage of multimedia embeds from many external sites,
* It can allow un-privileged users (eg. students) to securely embed content,
* For the multimedia providers (like YouTube), it allows them to update their embed code once, while the changes take effect across the Web (when caches are updated). This is particularly relevant at the moment - providers can seamlessly switch from Flash to HTML5 <video>, and from <object> to an <iframe> solution with improved content negotiation (mobiles, HTML5, internationalization).
* A low-cost, lower risk way of experimenting with new multimedia sites and services, including those that are particularly interesting for learning, eg. TimeToast.com (interactive timelines), LAMS etc.

== Dis-advantages ==
I haven't thought of any yet. Feel free to suggest!

== The proposal ==
The proposal is for an oEmbed plugin for Moodle, implemented as a filter in PHP. The plugin would be influenced chiefly by the Wordpress and Drupal solutions.

Considerations/ proposed requirements:

* A Moodle server-side filter solution - so not Javascript,
* (Possibly an interim Javascript solution - using jquery-oembed - would this be useful, or confusing?)
* A plugin for Moodle to consume external resources (it may also be interesting to turn Moodle into an oEmbed provider/server for consumption by other sites, though I don't yet have a specific use-case - not a priority),
* The option of a filter syntax, eg. [embed] http://youtu.be/UniQuEiD [/embed] (Wordpress),
* The option to reveal the filter syntax within the embed. That is, "Click me to see how I was embedded".
* Probably, the option to parse all links - <a href=...</a>,
* oEmbed responses cached in Moodle,
* The ability to add and remove oEmbed providers via PHP configuration (Wordpress), and/or Moodle admin-interface (Drupal module),
* Integration with Moodle roles and permissions,
* Alignment with existing multimedia/ embedding solutions, and Moodle generally,
* Like all Moodle filters (Moodle 2+?), oEmbeds could be enabled on a per-course (per-resource?) basis.
* Security?
* Performance? (caching)
* I propose support for Moodle 2 onwards,
* Support/ compatibility with Embed.ly (including API key, possibly services.json), and Oohembed.com,
* A list of default providers on installation - requires discussion/input,
* Evaluate auto-discovery, versus a white-list approach (security).

I'm writing this proposal to introduce the concept, gauge interest, foster discussion, identify issues/ priorities, and find interested parties and potential collaborators.

I hope to have at least some alpha-level code within 6 months.

NOTE: I propose developing this as a side-project, that is not part of my day job at The Open University (unless someone at the OU says they need it ;).)

[Todo: forum link]

== See also ==

* [groups.google.com/group/oembed/ oEmbed Google Group]
* http://viper007bond.com/wordpress-plugins/other-plugins/enable-oembed-discovery/ (http://v007.me/845) / Alex Mills led the implementation of oEmbed for Wordpress.
* http://viper007bond.com/tag/oembed/
* http://developer.yahoo.com/blogs/ydn/posts/2008/05/oembed_embeddin/ -- Chris Heilmann (@codepo)

* http://freear.org.uk/content/ou-media-player-project
* http://freear.org.uk/content/ou-media-player-project
* http://freear.org.uk/taxonomy/term/54 (oembed)
* http://2010.imoot.org/tag/?tag=maltwiki
* http://slideshare.net/nfreear/malt-wiki-techshare2009

User:Nick Freear

2011-05-14T15:30:24Z

Nfreear: Adding 'Timeline Widget' plugins DB link, etc.

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk/ Freear.org.uk].
* Moodle demo site [http://freear.org.uk/moodle/ Freear.org.uk / moodle]
* My [http://moodle.org/user/view.php?id=93815&course=5 profile on Moodle.org].

Contributed plugins (not written for my day job):

* [http://moodle.org/mod/data/view.php?rid=4143 Calculated Objects question type] contributed plugin - [[Calculated Objects question type| Wiki page]].
** [https://github.com/nfreear/moodle-qtype_calculatedobjects Calculated Objects, on Github]
* [http://moodle.org/mod/data/view.php?rid=4802 Timeline Widget filter] See #CONTRIB-2502.
** [https://github.com/nfreear/moodle-filter_timelinewidget Timeline filter, on Github]
** ([http://bitbucket.org/nfreear/timelinewidget Timeline filter, on Bitbucket])
* [http://moodle.org/mod/data/view.php?rid=4778 SimpleSpeak TTS filter] - speech-synthesis/ text to speech (TTS) - [[User:Nick Freear/SimpleSpeak filter| Wiki page]].
** [https://github.com/nfreear/moodle-filter_simplespeak SimpleSpeak filter on Github]
** ([http://bitbucket.org/nfreear/simplespeak SimpleSpeak filter, on Bitbucket])
* [http://moodle.org/mod/data/view.php?rid=4714 Scratch embed filter] - plugins database.
** [https://github.com/nfreear/moodle-filter_scratchembed Scratch embed on Github]
** ([http://bitbucket.org/nfreear/scratchembed Scratch embod on Bitbucket])
* [https://github.com/nfreear/moodle-filter_interwiki Interwiki links filter] - Github.
* [http://bitbucket.org/nfreear/standard_html5 standard_html5 theme] - Bitbucket.

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle 1.6-1.9.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://mycroft.mozdev.org/search-engines.html?name=Moodle Moodle search plugins, on Mycroft] - 'Moodle code' plugin.

User:Nick Freear

2011-05-07T19:51:10Z

Nfreear: Links

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk/ Freear.org.uk].
* Moodle demo site [http://freear.org.uk/moodle/ Freear.org.uk / moodle]
* My [http://moodle.org/user/view.php?id=93815&course=5 profile on Moodle.org].

Contributed plugins (not written for my day job):

* [http://moodle.org/mod/data/view.php?rid=4143 Calculated Objects question type] contributed plugin - [[Calculated Objects question type| Wiki page]].
* [http://bitbucket.org/nfreear/timelinewidget/src#wiki Timeline Widget filter]. See #CONTRIB-2502.
* [http://moodle.org/mod/data/view.php?rid=4778 SimpleSpeak TTS filter] - speech-synthesis/ text to speech (TTS) - [[User:Nick Freear/SimpleSpeak filter| Wiki page]].
** [https://github.com/nfreear/moodle-filter_simplespeak SimpleSpeak filter on Github]
** ([http://bitbucket.org/nfreear/simplespeak SimpleSpeak filter, on Bitbucket])
* [http://moodle.org/mod/data/view.php?rid=4714 Scratch embed filter] - plugins database.
** [https://github.com/nfreear/moodle-filter_scratchembed Scratch embed on Github]
** ([http://bitbucket.org/nfreear/scratchembed Scratch embod on Bitbucket])
* [https://github.com/nfreear/moodle-filter_interwiki Interwiki links filter] - Github.
* [http://bitbucket.org/nfreear/standard_html5 standard_html5 theme] - Bitbucket.

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle 1.6-1.9.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://mycroft.mozdev.org/search-engines.html?name=Moodle Moodle search plugins, on Mycroft] - 'Moodle code' plugin.

User:Nick Freear

2011-05-07T10:06:10Z

Nfreear: SimpleSpeak links

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk/ Freear.org.uk].
* My Moodle demo site [http://freear.org.uk/moodle/ Freear.org.uk / moodle]

Contributed plugins:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/timelinewidget/src#wiki Timeline Widget filter]. See #CONTRIB-2502.
* [http://moodle.org/mod/data/view.php?rid=4778 SimpleSpeak TTS filter] - speech-synthesis/ text to speech (TTS).
** [https://github.com/nfreear/moodle-filter_simplespeak SimpleSpeak filter on Github]
** ([http://bitbucket.org/nfreear/simplespeak SimpleSpeak filter, on Bitbucket])
* [http://moodle.org/mod/data/view.php?rid=4714 Scratch embed filter] - plugins database.
** [https://github.com/nfreear/moodle-filter_scratchembed Scratch embed on Github]
** ([http://bitbucket.org/nfreear/scratchembed Scratch embod on Bitbucket])
* [https://github.com/nfreear/moodle-filter_interwiki Interwiki links filter] - Github.
* [http://bitbucket.org/nfreear/standard_html5 standard_html5 theme] - Bitbucket.

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].
* [http://mycroft.mozdev.org/search-engines.html?name=Moodle Moodle search plugins, on Mycroft] - 'Moodle code' plugin.

User:Nick Freear

2011-04-22T15:15:37Z

Nfreear: Adding Mycroft link

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk/ Freear.org.uk].
* My Moodle demo site [http://freear.org.uk/moodle/ Freear.org.uk / moodle]

Contributed plugins:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/timelinewidget/src#wiki Timeline Widget filter]. See #CONTRIB-2502.
* [https://github.com/nfreear/moodle-filter_simplespeak SimpleSpeak filter] - speech-synthesis/ text to speech (TTS) - Github.
** ([http://bitbucket.org/nfreear/simplespeak SimpleSpeak filter, on Bitbucket])
* [http://moodle.org/mod/data/view.php?d=13&rid=4714 Scratch embed filter] - plugins database.
** [https://github.com/nfreear/moodle-filter_scratchembed Scratch embed on Github]
** ([http://bitbucket.org/nfreear/scratchembed Scratch embod on Bitbucket])
* [https://github.com/nfreear/moodle-filter_interwiki Interwiki links filter] - Github.
* [http://bitbucket.org/nfreear/standard_html5 standard_html5 theme] - Bitbucket.

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].
* [http://mycroft.mozdev.org/search-engines.html?name=Moodle Moodle search plugins, on Mycroft] - 'Moodle code' plugin.

User:Nick Freear

2011-04-22T15:13:27Z

Nfreear: Adding lots more 'contrib' links

User:Nick Freear

2011-01-02T17:18:33Z

Nfreear:

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Contributed plugins:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/timelinewidget/src#wiki Timeline Widget filter]. See #CONTRIB-2502.
* [http://bitbucket.org/nfreear/simplespeak/src#wiki SimpleSpeak filter] - speech-synthesis/ text to speech (TTS).

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2010-12-12T21:31:53Z

Nfreear: Added 'SimpleSpeak' - reorganised.

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Contributed plugins:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/moodle-timelinewidget/src#wiki Timeline Widget filter]. See #CONTRIB-2502.
* [http://bitbucket.org/nfreear/moodle-simplespeak/src#wiki SimpleSpeak filter] - speech-synthesis/ text to speech (TTS).

Other key contributions/ links:

* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2010-11-29T22:27:25Z

Nfreear:

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Key contributions/links:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/moodle-timelinewidget/src#wiki Timeline Widget] contributed filter plug-in. See #CONTRIB-2502.
* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2010-11-29T22:26:54Z

Nfreear:

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Key contributions/links:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/moodle-timelinewidget/src#wiki| Timeline Widget] contributed filter plug-in. See #CONTRIB-2502.
* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2010-11-29T22:21:16Z

Nfreear: Adding 'Timeline Widget' links

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Key contributions/links:

* [[Calculated Objects question type]] contributed plug-in.
* [http://bitbucket.org/nfreear/moodle-timelinewidget| Timeline Widget] contributed filter plug-in. See [http://tracker.moodle.org/browse/CONTRIB-2502| #CONTRIB-2502].
* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2010-10-10T20:07:58Z

Nfreear:

Accessibility notes

2009-10-06T16:40:34Z

Nfreear: /* Moodle 1.6 */, Moodle forum link

<p class="note">
These notes give an overview of what accessibility work has been done from Moodle 1.6 onwards, what is left to do, and what guidelines, techniques and coding patterns are being used. Initially based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome! [[User:Nick Freear|Nick Freear]]
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Roadmap ==
The issues remaining (todo list), for Moodle 2.0 and beyond.

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - there are[http://www.standards-schmandards.com/2006/wysiwyg-editor-test good open-source contenders] including TinyMCE, [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of the interface, AND the validity and accessibility of the content and markup produced
- see [[#Guidelines|Guidelines]] section.

In the meantime, the current editor can be configured by the system administrator (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: draft status.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, insert link, remove link, insert image, special character (new window), show HTML, search-replace (new window), (language not configurable), (heading/normal not configurable).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, direction left to right, direction right to left, reduce indent, increase indent, text colour, background colour, horizontal rule, insert table, insert emoticon, (spell check, new window), enlarge editor (new window).

== Releases ==
Accessibility issues fixed by Moodle release, with links to the Moodle bug tracker. Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 ===
Released: Beta 2, circa 22 October 2007

Meta-bug, MDL-12298 (14 sub-tasks, 7 dependencies).

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages (3 bugs).
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Moodle 1.6 is the first release to which the Open University contributed development resources. An [http://moodle.org/mod/forum/discuss.php?d=40484 accessibility proposal from Open University] identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), added <h1> to mark-up headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for calendar/event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown; the Open University was not involved with Moodle at this time.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process (similar to the ''waterfall'' programming/design process):
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

(Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).)

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Design patterns ==
This section documents some specific, re-usable coding techniques that improve the accessibility of Moodle. They include server-side (PHP) and client side (XHTML, CSS styles) code samples, and links to specific parts of the [[#Guidelines|Web Content Accessibility Guidelines]].

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' (that is, not spoken by assistive technologies including screen readers) representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

== See also ==
* [[Accessibility]]
* [[Moodle Accessibility Specification|Accessibility Specification, Moodle 1.8]]

{{CategoryDeveloper}}
[[Category:Accessibility]]

User:Nick Freear

2009-07-13T13:45:40Z

Nfreear:

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

* My blog [http://freear.org.uk Freear.org.uk].

Key contributions/links:
* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

User:Nick Freear

2008-07-14T11:54:22Z

Nfreear:

I am a software/web developer at the Open University UK, working in the [http://iet.open.ac.uk Institute of Educational Technology].

Key contributions/links:
* [[Accessibility notes|Accessibility development]] for Moodle.
* [[Groups|Extended groups and groupings]] for Moodle 1.8/1.9.
* [http://moodle.org/user/view.php?id=93815&course=5 My profile on Moodle.org].

Accessibility notes

2008-07-14T11:45:29Z

Nfreear: Re-ordered, new summary, etc.

<p class="note">
These notes give an overview of what accessibility work has been done from Moodle 1.6 onwards, what is left to do, and what guidelines, techniques and coding patterns are being used. Initially based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome! [[User:Nick Freear|Nick Freear]]
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Roadmap ==
The issues remaining (todo list), for Moodle 2.0 and beyond.

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - there are[http://www.standards-schmandards.com/2006/wysiwyg-editor-test good open-source contenders] including TinyMCE, [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of the interface, AND the validity and accessibility of the content and markup produced
- see [[#Guidelines|Guidelines]] section.

In the meantime, the current editor can be configured by the system administrator (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: draft status.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, insert link, remove link, insert image, special character (new window), show HTML, search-replace (new window), (language not configurable), (heading/normal not configurable).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, direction left to right, direction right to left, reduce indent, increase indent, text colour, background colour, horizontal rule, insert table, insert emoticon, (spell check, new window), enlarge editor (new window).

== Releases ==
Accessibility issues fixed by Moodle release, with links to the Moodle bug tracker. Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 ===
Released: Beta 2, circa 22 October 2007

Meta-bug, MDL-12298 (14 sub-tasks, 7 dependencies).

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages (3 bugs).
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Moodle 1.6 is the first release to which the Open University contributed development resources. An accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), added <h1> to mark-up headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for calendar/event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown; the Open University was not involved with Moodle at this time.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process (similar to the ''waterfall'' programming/design process):
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

(Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).)

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Design patterns ==
This section documents some specific, re-usable coding techniques that improve the accessibility of Moodle. They include server-side (PHP) and client side (XHTML, CSS styles) code samples, and links to specific parts of the [[#Guidelines|Web Content Accessibility Guidelines]].

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' (that is, not spoken by assistive technologies including screen readers) representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

== See also ==
* [[Accessibility]]
* [[Moodle Accessibility Specification|Accessibility Specification, Moodle 1.8]]

[[Category:Accessibility]]

Groups

2007-11-27T14:53:56Z

Nfreear: Added 'See also' + Category:Developer

==Improving the Groups design in Moodle 1.9==
Summary of problems:
* Groupings not implemented in modules
* Concept of orphaned groups
* Not integrated into Moodle core
* Potential group sharing problems

==Other proposals==
* [[Groupings OU]]
* [[Groupings and Groups]]

==Change groups/groupings relationship==
At present both groups and groupings are not linked strictly to one course, you could use one group in several courses and groupings at the same time. This loose relationship of groups and groupings adds too much complexity and could be/is a source of bugs in code.

''Solution:'' Each group and grouping would link the course id directly. Groupings would be only limiting the number of usable groups in activities. This allows free sharing of groups in groupings inside course without potential problems. This idea was proposed by Enrique. See attached db schema.

[[Image:groupsdb.png]]

===course===
* groupingid - default grouping used in course (new activities, etc.)

===course_modules===
* groupingid - grouping used in activity
* grouponly - limit access to and visibility of activity based on group membership - if user is not member of at least one group in grouping, the activity is invisible for them; this needs a new shared option in course/moodleform_mod.php

===groupings===
renamed table
* exclusivegroups - hint for UI group distribution tools - non overlapping groups requested
* maxgroupsize - hint for UI group distribution tools - requested number of users in each group

===groupings_groups===
renamed table

===groups===
reverted to pre 1.8 state (with the password exception)

===Benefits===
*fewer tables
*normalized
*simpler SQL
*easier backup/restore implementation
*more compatible with old group implementation in 1.7

==Linked groups==
Maybe in future - it would allow synchronizing of group membership from different courses; the idea is to have linkid in groups table and synchronize the groups membership in group functions for adding/removing of members for groups with the same linkid.

==Group/grouping cloning==
Cloning or duplicating is UI feature only, it helps to prefill new groups/groupings with existing data. In theory it could also copy existing grouping setups from other courses too.

==Other code cleanup==
Current group code does not follow Moodle coding guide, has several unfinished/broken/obsoleted parts, is not integrated into core, etc.
To do:
*integrate setup and upgrade into main lib/db/*.*
*remove columns from groupings table that can be replaced by permissions
*reduce the number of functions, rewrite or fix them, move them into lib/grouplib.php
*rewrite UI in /group/
*implement module and course groupings support, fix all mods to use it (course edit form, mod edit form, etc.)
*fix legacy functions
*documentation

==Needed time==
1 month for implementation and testing.

== See also ==
* [[Groupings and Groups|Enrique Castro group specification]].
* [[Groupings OU|Open University group specification]].

Accessibility notes

2007-11-26T14:09:43Z

Nfreear: /* Editor */, fix white/black lists.

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - there are[http://www.standards-schmandards.com/2006/wysiwyg-editor-test good open-source contenders] including TinyMCE, [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of the interface, AND the validity and accessibility of the content and markup produced
- see [[#Guidelines|Guidelines]] section.

In the meantime, the current editor can be configured by the system administrator (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: draft status.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, insert link, remove link, insert image, special character (new window), show HTML, search-replace (new window), (language not configurable), (heading/normal not configurable).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, direction left to right, direction right to left, reduce indent, increase indent, text colour, background colour, horizontal rule, insert table, insert emoticon, (spell check, new window), enlarge editor (new window).

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

Meta-bug, MDL-12298 (14 sub-tasks, 7 dependencies).

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages (3 bugs).
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown.

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-22T07:42:22Z

Nfreear: /* Moodle 1.9 Beta 2 */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - there are[http://www.standards-schmandards.com/2006/wysiwyg-editor-test good open-source contenders] including TinyMCE, [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of the interface, AND the validity and accessibility of the content and markup produced
- see [[#Guidelines|Guidelines]] section.

In the meantime, the current editor can be configured by the system administrator (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: draft status.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy?, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, link, remove link?, image, character palette, show HTML, R?, (language not configurable).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, ?P, ?P, reduce indent, increase indent, text colour, background colour?, horizontal line, table, emoticon, (spell check?), new window.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

Meta-bug, MDL-12298 (14 sub-tasks, 7 dependencies).

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages (3 bugs).
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown.

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-22T07:36:55Z

Nfreear: /* Editor */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - there are[http://www.standards-schmandards.com/2006/wysiwyg-editor-test good open-source contenders] including TinyMCE, [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of the interface, AND the validity and accessibility of the content and markup produced
- see [[#Guidelines|Guidelines]] section.

In the meantime, the current editor can be configured by the system administrator (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: draft status.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy?, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, link, remove link?, image, character palette, show HTML, R?, (language not configurable).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, ?P, ?P, reduce indent, increase indent, text colour, background colour?, horizontal line, table, emoticon, (spell check?), new window.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages, MDL-7878, MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown.

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-22T07:25:56Z

Nfreear: Use new Moodle tracker filter!

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===

* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss', MDL-9306.
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - TinyMCE is a [http://www.standards-schmandards.com/2006/wysiwyg-editor-test strong open-source contender], [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of use of the interface, and the accessibility of the content and markup produced - see [[#Guidelines]].

In the meantime, the current editor can be configured by system administrators (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: edit.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy?, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, link, remove link?, image, character palette, show HTML, R?, (lang n/a).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, ?P, ?P, reduce indent, increase indent, text colour, background colour?, horizontal line, table, emoticon, (spell check), new window.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: MDL-8627, MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages, MDL-7878, MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug MDL-7396 (45 sub-tasks, 3 dependencies). There was also funding from Italy - see MDL-7860 (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists, MDL-6548: blog tags (inline), messages, news items, section links (inline).
* English help files: MDL-9890, Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, MDL-6548: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

Work done for Moodle 1.5 is unknown.

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-22T07:19:28Z

Nfreear: /* Moodle 1.8 */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - TinyMCE is a [http://www.standards-schmandards.com/2006/wysiwyg-editor-test strong open-source contender], [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of use of the interface, and the accessibility of the content and markup produced - see [[#Guidelines]].

In the meantime, the current editor can be configured by system administrators (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: edit.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy?, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, link, remove link?, image, character palette, show HTML, R?, (lang n/a).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, ?P, ?P, reduce indent, increase indent, text colour, background colour?, horizontal line, table, emoticon, (spell check), new window.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). There was also funding from Italy - see [http://tracker.moodle.org/browse/MDL-7860 MDL-7860] (26 sub-tasks). Here is an (incomplete) summary:

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-22T07:11:30Z

Nfreear: /* Issues remaining */, added Editor

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

=== Editor ===

The rich-text/HTML editor used in Moodle is currently based on HTMLArea. There are many accessibility issues, and we hope it will be replaced soon - TinyMCE is a [http://www.standards-schmandards.com/2006/wysiwyg-editor-test strong open-source contender], [http://themaninblue.com/experiment/widgEditor WidgEditor] would be a very simple starting point, or there are [http://456bereastreet.com/archive/200612/forget_wysiwyg_editors_use_wysiwym_instead what you see is what you mean] (WYSIWYM) editors. We are concerned with the ease of use of use of the interface, and the accessibility of the content and markup produced - see [[#Guidelines]].

In the meantime, the current editor can be configured by system administrators (go to, Site administration - Appearance - HTML editor). Below are lists of the options it would be sensible to enable and disable (starting from the Open University's configuration)
- TODO: edit.

* '''Whitelist''' (untick): Word format filter (tick), format, bold, italic, strikethrough, subscript, superscript, copy?, cut, paste, Word filter, undo, redo, number list, bullet list, anchor, link, remove link?, image, character palette, show HTML, R?, (lang n/a).
* '''Blacklist''' (tick): fontname, font-size, underline, left align, center align, right align, justify, ?P, ?P, reduce indent, increase indent, text colour, background colour?, horizontal line, table, emoticon, (spell check), new window.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-21T17:21:41Z

Nfreear: /* Issues remaining */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list/ roadmap, for Moodle 2.0?

* 'onchange' popup menus: not keyboard accessible.
* Compact forms, example search: consistency, and use an icon label, not hidden label.
* Rich-text editor: fix remaining issues/ replace.
* Rich-text editor: switch off many buttons/menus by default (OU does).
* Old Forms: use QuickForms OR add label markup - pragmatic approach.
* QuickForm fixes: review, complete.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Review USER->screenreader flag use.
* Documentation: detailed release notes, template conformance claims/accessibility statement, help, for different audiences (students, developers, institutions looking to use Moodle)
* ...
* Language packs: fix XHTML, semantics.
* Content: guidelines, limitations?
* Automated testing?

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-20T08:47:55Z

Nfreear: /* Guidelines */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
The [http://w3.org Worldwide Web Consortium] (W3C) and its working groups publishes many relevant recommendations, guidelines and standards. The [http://w3.org/WAI Web Accessibility Initiative] (WAI) is the key part of the W3C concerned with accessibility and usability.

* The [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, are the current recommendations that most apply to Moodle. There are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* The [http://w3.org/TR/WCAG20 Web Content Accessibility Guidelines 2.0] are currently at the W3C Working Draft stage (17 May 2007) - they are expected to become a stable recommendation in 2008. WCAG20 is designed to be more testable and technology agnostic so that it can be applied to the full range of current and future technologies on the Web - XHTML, PDF, Flash and so on. HTML documents and sites that follow WCAG10 will almost certainly comply with WCAG20. (Key principles: perceivable, operable, understandable, robust POUR.)
* The [http://w3.org/TR/aria-roadmap Accessible Rich Internet Applications] draft standards (ARIA roadmap September 2006) are useful to ensure that scripting and asynchronous events (AJAX) work with assistive technologies. They supplement HTML with additional semantics: role, state and properties.
* Moodle and components like the rich-text editor are subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

=== Web Content Accessibility Guidelines 1.0 ===
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.

# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# Clarify natural language usage
# Create tables that transform gracefully.
# Ensure that pages featuring new technologies transform gracefully.
# Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# Use interim solutions.
# Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-02T21:21:10Z

Nfreear: /* Pattern 1: unlist, inline-list */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach echo $X</code> loops (or foreach $output.=$X).
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li>';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-02T13:16:33Z

Nfreear: /* Pattern 2: accesshide */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach</code> loops.
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.sideblock .content .inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li> ';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a [[#Pattern 3: left, right arrows|''silent'' character]]. The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: this is a '''hack''', we prefer visible text - use cautiously (most necessary uses have already been identified), and consult before use.
* Warning: '''NOT''' for links - see [[#Pattern 4: skip link|skip link]] pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Also know as: offscreen/ off-screen hidden text.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://w3.org/TR/WCAG10/#gl-color WCAG10, Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code> (available Moodle 1.9)
<nowiki>// @return string HTML
function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-02T11:46:12Z

Nfreear: /* Pattern 4: skip link */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach</code> loops.
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.sideblock .content .inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li> ';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a ''silent'' character (TODO: link). The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: we prefer visible text - use cautiously (most necessary uses have already been identified, discuss).
* Warning: NOT for links - see 'skip link' pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://www.w3.org/TR/WCAG10/#gl-color WCAG Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code>
<nowiki>function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

=== Pattern 4: skip link ===

* Warnings: we prefer links to be visible.
* Difficulty: medium. <code>:active</code> is a hack for IE 6.
* Problem: keyboard-only users have large numbers of links to contend with in Moodle.
* Context: side blocks, home page and course pages.
* Principle: [http://w3.org/TR/WAI-WEBCONTENT/#gl-facilitate-navigation WCAG1 Guideline 13.6 - Group related links... and, until user agents do so, provide a way to bypass the group].
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution 1, CSS: ('''only''' for comparison)
a.skip { color: white; }
a.skip:focus, a.skip:active { color: black; }

* Solution 2, CSS: <code>theme/standard/styles_layout.css</code> ('''used''' in Moodle 1.9)
a:skip { position: absolute; top: -1000em; }
a.skip:focus, a.skip:active { position: static; }

* Plus, in each case:
.skip-destination, .skip-to { display: block; height: 1px; }

* Examples:

* Also: Weekscss course format, Moodleforms, img-text class .

[[Category:Accessibility]]

Accessibility notes

2007-11-02T11:21:41Z

Nfreear: /* Pattern 3: left, right arrows */, added 'skip link' pattern

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach</code> loops.
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.sideblock .content .inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li> ';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a ''silent'' character (TODO: link). The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: we prefer visible text - use cautiously (most necessary uses have already been identified, discuss).
* Warning: NOT for links - see 'skip link' pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://www.w3.org/TR/WCAG10/#gl-color WCAG Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code>
<nowiki>function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.

== Pattern 4: skip link ==

* Warnings: we prefer links to be visible.
* Difficulty:
* Context:
* Principle:
* Available: Moodle 1.9, October 2007.
* Use count:
* Solution:
* Examples:

* Also: Weekscss course format, Moodleforms .

[[Category:Accessibility]]

Accessibility notes

2007-11-02T11:13:38Z

Nfreear: /* Pattern 2: accesshide */

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach</code> loops.
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.sideblock .content .inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li> ';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting, for example coloured text, or a ''silent'' character (TODO: link). The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

* Warning: we prefer visible text - use cautiously (most necessary uses have already been identified, discuss).
* Warning: NOT for links - see 'skip link' pattern below.
* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Context: provides context for a non-sighted user, where the meaning would otherwise be clear from formatting.
* Principle: [http://www.w3.org/TR/WCAG10/#gl-color WCAG Guideline 2 - don't rely on colour alone].
* Available: Moodle 1.6 March 2006.
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Use count: 29+ !
* Solution, CSS: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Solution, PHP: <code>lib/weblib.php</code>
<nowiki>function get_accesshide($text, $elem='span', $class='', $attrs='')</nowiki>

* Examples, HTML: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.
* Also: Weekscss course format, Moodleforms .

[[Category:Accessibility]]

Accessibility notes

2007-11-01T13:33:31Z

Nfreear: /* Pattern 1: unlist, inline-list */, update from Hackfest slides

<p class="note">These are DRAFT notes on what CSS classes, PHP functions and the so on have been added to Moodle 1.6 onwards to aid accessibility. They can be seen as design patterns, techniques, guidelines, and perhaps best practice(?)

Based on a workshop at [http://moodlemoot.ca Moodlemoot 2007, Canada]
Lots for me to add/edit! Comments welcome!
[[User:Nick Freear|Nick Freear]] 11:38, 28 August 2007 (CDT)
</p>

== Guidelines ==
Most of the relevant guidelines and standards are published by the [http://w3.org Worldwide Web Consortium] (W3C), including the [http://w3.org/WAI Web Accessibility Initiative] (WAI).

* [http://w3.org/TR/WCAG10 Web Content Accessibility Guidelines 1.0] (WCAG10), published May 1999, there are useful documents including [http://w3.org/WAI/intro/wcag10docs.php errata, a checklist, '''techniques''', quick tips and so on].
* WCAG 1.0 contains 14 guidelines (see below), sub-divided into 65 checkpoints numbered 1.1 to 14.3.
* The checkpoints are organised into 3 priority levels, 1 (A) ''must'', 2 (double-A) ''should'', 3 (triple-A) ''may'' - Moodle should aim for level 2 and some of level 3.
* Moodle is subject to other guidelines including the [http://w3.org/TR/ATAG10 Authoring Tool Accessibility Guidelines 1.0], see [http://w3.org/WAI/guid-tech.html this overview].

The WCAG 1.0 Guidelines:
# Provide equivalent alternatives to auditory and visual content.
# Don't rely on color alone (or bold or other styling)
# Use markup and style sheets and do so properly.
# • Clarify natural language usage
# Create tables that transform gracefully.
# • Ensure that pages featuring new technologies transform gracefully.
# • Ensure user control of time-sensitive content changes.
# Ensure direct accessibility of embedded user interfaces.
# Design for device-independence.
# • Use interim solutions.
# • Use W3C technologies and guidelines.
# Provide context and orientation information.
# Provide clear navigation mechanisms.
# • Ensure that documents are clear and simple.

== Fix and test ==

; Formal user testing : The most valuable and time-consuming.
; Informal user feedback : .
; Expert evaluation : .
; Developer evaluation : .

A desirable process:
# Test
# Identify
# Specify/ report
# Discuss/ clarify
# Implement solution
# Re-test
# '''Iterate ...'''

== Issues remaining ==
A todo list, for Moodle 2.0?

* QuickForm fixes: review, complete.
* Old forms: replace remaining with QuickForms.
* Course formats: replace layout tables, as per 'weekscss' [http://tracker.moodle.org/browse/MDL-9306 MDL-9306].
* Layout tables: remove remaining.
* Text editor: fix remaining issues/ replace.
* ...
* Language packs: fix XHTML, semantics.
* Automated testing?
* Documentation.

== Issues fixed ==
Note, some of the headline items here could be added to the release notes.
See also [[Release Notes]] | [[Old releases]] | [[Roadmap]].

=== Moodle 1.9 Beta 2 ===
Released: circa 22 October 2007

* QuickForm fixes: [http://tracker.moodle.org/browse/MDL-8627 MDL-8627], MDL-11134.
* Skip block/ skip to content bug fixes, and extended to site home page, course index, as well as course pages [http://tracker.moodle.org/browse/MDL-7878 MDL-7878], MDL-11675, MDL-11695.
* Side block lists, MDL-6548: TODO.
* English language help files: completed MDL-9890.
* (''Consolidation'')

=== Moodle 1.8 ===
Released: 31st March 2007

Following more expert evaluation, the Open University put together a comprehensive [[Moodle Accessibility Specification|Specification]] listing what needed fixing in parts of core Moodle and modules.
Moodle.com undertook what were judged to be high priority items from this list - see meta-bug [http://tracker.moodle.org/browse/MDL-7396 MDL-7396] (45 sub-tasks, 3 dependencies). Here is a summary...

* Forms: QuickForms adopted for many - consistent rendering: labels, fieldset/legend, tableless.
* XHTML Strict drive.
* Text editor keyboard shortcuts.
* Tabs: replaced table with list.
* ...
* Side block lists [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: blog tags (inline), messages, news items, section links (inline).
* English help files: [http://tracker.moodle.org/browse/MDL-9890 MDL-9890], Help should be well-formed...

=== Moodle 1.7 ===
Released: 7th November 2006

* '''Consolidation'''
* Breadcrumb and left/right-arrow icons fixed: replaced with 'silent' Unicode arrow characters.
* Side block lists, [http://tracker.moodle.org/browse/MDL-6548 MDL-6548]: admin bookmarks, (mnet hosts), rss client.

=== Moodle 1.6 ===
Released: 19th June 2006

Accessibility proposal from Open University identified problems and some solutions. Note, due to time constraints we did not evaluate or modify modules, the content of most side blocks and so on - most changes were to core.

* ALT text: fixed for side-blocks, some themes, and in core.
* Standard theme & other 14 themes: removed layout table(s), <h1> used to markup headings (some to do).
* Breadcrumb trail: marked up as a list, with a heading (hidden by default for visual user), and graphic for breadcrumb separator.
* Side blocks: heading marked up as <h2>, added 'skip block' links (needs review).
* Side blocks: removed nested layout tables, started using list markup (activity modules, admin, course list, participants, main menu, social activities - list render in print_side_block; online users).
* Calendar: fixed data table headers, summary, abbreviations, non-visual indication of 'today', next/previous links.
* Calendar style: improved colour contrast in standard theme for event backgrounds, links, weekend colours.
* Weekscss course format: new format plug-in that does ''not'' use layout tables, based on the 'weeks' course format.

=== Moodle 1.5 ===
Released: 5th June 2005

== Assistive technology ==

Technology to enable those with disabilities to use a computer can be categorised in terms of their ''distance'' from the user.
For example:

* Physical layer: specialist pointing devices, mice, joy-sticks, keyboards.
* Operating system layer: Mac Voiceover, Windows Narrator ...
* System specialisation layer: technology not part of the OS that tries to work with ''all'' software tools.
** Screen magnification.
** Screen readers: JAWS, Window-Eyes, Thunder/WebbIE (speech or braille).
** Speech recognition: Dragon Naturally Speaking ...
* Software tool layer: audio browsers, plug-ins for Web browsers, word processors.
* Application layer: technology integrated in a web site, eg. Browsealoud, style sheet switching/ high-contrast, font size (bad?); ?
* Document layer: tagged PDFs, well-structured semantic PDFs, Word documents, HTML documents.

== What JAWS says ==

[[Wikipedia:Screen reader|Screen readers]] are assistive software that verbalise (via synthesised speech, braille display or both) text displayed on a computer screen from the operating system (Windows and so on) or applications (typically Web browsers, word processors, email software).
JAWS (Job Access With Speech) for Windows is a popular screen reader from [http://freedomscientific.com/ Freedom Scientific]; competitors include Window-Eyes from GW Micro, HAL from Dolphin, and [http://www.screenreader.net Thunder] (free for personal use - please try).

First, to clear up common mis-conceptions:
* Screen readers do NOT request pages directly, they work through a browser, often Internet Explorer.
* They DO try to deal with Javascript and style sheets (with the "screen" media attribute). So 'noscript' elements are not read.
* Screen readers can be configured/scripted for different levels of verbosity, different applications and so on. However, many users concentrate on learning the keyboard shortcuts and don't know or don't have the confidence to change the configuration. Expert evaluation therefore assumes that the default configuration is used.
* In default configuration JAWS does NOT read TITLE attributes. Always use ALT for images.
* Most screen readers have a 'virtual buffer' to allow keyboard shortcuts for headings, lists, forms. This can be a problem for Javascript.
...
[Too much accessibility]

Below are examples of what the JAWS for Windows 7 screen reader verbalises for good and bad markup (HTML).

=== Forms ===

JAWS and other screen readers have a ''forms mode'' to allow the user to input text in forms in a Web browser.

== Accessibility design patterns ==

=== Pattern 1: unlist, inline-list ===

Cascading style sheet (CSS) classes to remove default list-styles from HTML lists.
Class <code>inline-list</code> also makes a list horizontal.

* Warnings: none - please use!
* Difficulty: '''easy''' I hope.
* Context: Moodle contains lots of list - typically look for <code>foreach</code> loops.
* Principle: [http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation WCAG1 Guideline 3.6 - Mark up lists and list items properly].
* Available: ? Moodle 1.8 December 2006 (MDL-6838, nested lists are safe).
* Use count: 5+ (12 including deprecated <code>list</code>).
* Definition, CSS: <code>theme/standard/styles_layout.css</code>
.unlist, .inline-list {
list-style: none;
padding: 0;
margin: 0;
}
.sideblock .content .inline-list li {
display: inline;
}

* Examples, PHP/HTML: <code>blocks/../block_blog_tags.php</code>
<nowiki>$this->content->text .= "<ul class='inline-list'>";
foreach ($etags as $tag) {
$this->content->text .= '<li><a href="'.$link.'" ... >'.$tag->name.'</a></li> ';
}
$this->content->text .= "</ul>";</nowiki>

<nowiki><ul class="inline-list">
<li><a .. class=" s20">Accessibility</a></li>
<li><a .. class=" s10">Test</a></li>
</ul></nowiki>

[Problem, Context, Principle, Solution, Why, Examples]

=== Pattern 2: accesshide ===

CSS class for text to be 'seen' by screen readers but not visual users.

Text classed as <code>accesshide</code> provides context for a non-sighted user, where the context or meaning would only otherwise be clear from formatting ([http://www.w3.org/TR/WCAG10/#gl-color WCAG Guideline 2, don't rely on colour alone]), for example coloured text, or a ''silent'' character (TODO: link). The example below shows how additional text is provided to differentiate ''today'' from the other days in the Moodle calendar - visual differentiation is provided in the ''standard'' theme by a black border, and the <code>accesshide</code> text is duplicated, in this case using Javascript (TODO: modify code! Javascript should use the title attribute.)

Please, use cautiously — most necessary uses have already been identified.

* Difficulty: '''tricky''' — please put the same text in an adjacent/parent <code>title</code> attribute.
* Available: Moodle 1.6 March 2006
* Bugs: 30-May-06, fixed [http://tracker.moodle.org/browse/MDL-5628 MDL-5628] for [[Wikipedia:Internet Explorer|IE 6]] Farsi [[Wikipedia:Right to left|RTL]] language.
* Definition: <code>theme/standard/styles_layout.css</code>
.accesshide {
position: absolute;
top: -1000px;
}

* Use Count: 29 !<br />
* Example: <code>calendar/lib.php</code>
<nowiki>...
<td class="day">26</td>
<td class="day today">
<span class="accesshide">Today Friday, 27 April </span>
<a onmouseover="return overlib(.. 'Today Friday, 27 April')" ..>27</a>
</td>
<td class="weekend day">28</td>
...</nowiki>

=== Pattern 3: left, right arrows ===

PHP variables holding 'silent' representations of right and left arrows (example ► <code>&#x25BA;</code>), to avoid misuse of characters including "greater than" >, "right angle quote" ». The variables are initialised by the function weblib.php: check_theme_arrows, unless they have first been defined in the theme config.php.

* Difficulty: medium. Careful with fonts.<br />
* Available: Moodle 1.7
* Functions in <code>lib/weblib.php</code>
<nowiki>
function check_theme_arrows()
function link_arrow_right($text, $url='', $accesshide=false, $addclass='')
function link_arrow_left($text, $url='', $accesshide=false, $addclass='')
function get_separator()

$THEME->rarrow
$THEME->larrow </nowiki>

* Associated CSS in <code>theme/standard/styles_fonts.css</code>
.arrow, .arrow_button input {
font-family: Arial,Helvetica,Courier,'Arial Unicode MS',sans-serif;
}

* Use count: ?
* Example PHP: weblib.php function print_navigation - breadcrumb trail.
* Also: Weekscss course format, Moodleforms .

[[Category:Accessibility]]

Accessibility notes

2007-10-29T13:57:43Z

Nfreear: /* Moodle 1.9 Beta */, skip links

Accessibility notes

2007-10-12T16:20:45Z

Nfreear: /* What JAWS says */, myths

MoodleMoot 2007 HackFest

2007-10-12T11:48:17Z

Nfreear: /* Accessibility demonstration */, added times (am & pm)

The main part of the [http://moodlemoot.org/ 2007 UK Moodle Moot] is on Wednesday and Thursday 24th and 25th October. The day before, on the Tuesday, there will be a HackFest for developers to meet, talk and write code.

==Practical arrangement==

You need to get [http://maps.google.co.uk/maps?ll=52.025356,-0.710997&spn=0.001005,0.001904&t=k&z=19 right here]. This is the centre of the Open University's Campus:

[http://www3.open.ac.uk/contact/ The Open University]<br />
Walton Hall<br />
Milton Keynes<br />
[http://maps.google.co.uk/?q=mk7+6aa&ie=UTF8&om=1&f=d MK7 6AA]

The area we are meeting in is called the Christodoulou Meeting Rooms. The entry is under an archway, and if you go in and up the stairs you should find us in Meeting Room 15, or the open foyer area just outside it. We will be there from about 10:00am to about 5:30pm, and lunch will be provided.

If you are registered for the MoodleMoot, wireless network sign-in information should be available on arrival.

==Programme for the day==

In keeping with Moodle's open source philosophy, the day will be self-organising. You can turn up and talk to other developers about anything you like. However, within that general free-for-all, we will have a number of pre-announced discussions on particular topics at particular times. We have a number of other rooms available for these break-out sessions, but I don't know the numbers right now.

Please feel free to add your own suggestions below.

Naturally, not all developers will be able to come, so it might be a good idea to start discussing some of these topics in the [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum] now. And if anything significant comes out of the discussions, we should try to record it on the wiki.

===Quiz developments===
{|
|-
| Time: || 2:00 to 3:00
|-
| Room: || ??
|-
| Suggested by: || Tim Hunt
|}
We can discuss some things that have happened recently:
* The implication of [[Plan_to_Improve_Flexibility_of_Question_Category_Sharing_and_Permissions|Jamie's recent changes to the question bank]],
* Improvements to the question type API, especially [[Plans_for_enhancing_import/export_in_questiontype_plugins|Howard's recent changes]],
some things that will probably happen soon:
* The OU's quiz navigation changes, that we hope to put into Moodle 2.0,
* The OU's [[Plans_for_adaptive_mode|changes to adaptive mode]] that we hope to put into Moodle 2.0,
* Tony Gardner-Medwin's plans to introduce certainty-based marking,
known problems with the quiz architecture that no-one is working on right now:
* ... suggestions welcome ...
and anything else you want to raise.

Of course, you can talk to me about the quiz at any time time during the day too, if you have a more specific issue.

===ePortfolios===
{|
|-
| Time: || 2:00 to 3:00
|-
| Room: || ??
|-
| Suggested by: || Thanh Le
|}

===Social Networking tools===
{|
|-
| Time: || 11 - 12
|-
| Room: || ??
|-
| Suggested by: || Jenny Grey
|}

===Offline Moodle (and particularly synchronisation issues)===
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Colin Chambers
|}

===Conditional Activities===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Repository API===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Enrolment 'Groups'===
An overview of 'the problem' how we've solved it in the short term and discussion of hot it can be solved in core.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Dan Poltawski
|}

=== Accessibility demonstration ===
My colleague Chetz Colwell and I would like to give a brief demonstration of assistive technologies to developers, particularly core developers, and discuss future accessibility work on Moodle. We'll hopefully have a screen reader JAWS (Thunder?), screen magnifier, do a keyboard-only demo, and possibly speech recognition.
{|
|-
| Time: || 10:00 to 11:00 (or 15:00 to 16:00)
|-
| Room: || ??
|-
| Suggested by: || Nick Freear
|}

== PGP Keysiging ==

If any developers would like to exchange PGP Keys and expand their web of trust then this could be done during the Developer day.

I think it would be good to follow the [http://www.debian.org/events/keysigning Debian guidlines] for this.--[[User:Dan Poltawski|Dan Poltawski]] 18:03, 10 October 2007 (CDT)

==See also==

* [[Developer conferences]]
* [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum]

MoodleMoot 2007 HackFest

2007-10-11T14:13:03Z

Nfreear: /* Enrolment 'Groups' */, added 'Accessibility demonstration'

The main part of the [http://moodlemoot.org/ 2007 UK Moodle Moot] is on Wednesday and Thursday 24th and 25th October. The day before, on the Tuesday, there will be a HackFest for developers to meet, talk and write code.

==Practical arrangement==

You need to get [http://maps.google.co.uk/maps?ll=52.025356,-0.710997&spn=0.001005,0.001904&t=k&z=19 right here]. This is the centre of the Open University's Campus:

[http://www3.open.ac.uk/contact/ The Open University]<br />
Walton Hall<br />
Milton Keynes<br />
[http://maps.google.co.uk/?q=mk7+6aa&ie=UTF8&om=1&f=d MK7 6AA]

The area we are meeting in is called the Christodoulou Meeting Rooms. The entry is under an archway, and if you go in and up the stairs you should find us in Meeting Room 15, or the open foyer area just outside it. We will be there from about 10:00am to about 5:30pm, and lunch will be provided.

If you are registered for the MoodleMoot, wireless network sign-in information should be available on arrival.

==Programme for the day==

In keeping with Moodle's open source philosophy, the day will be self-organising. You can turn up and talk to other developers about anything you like. However, within that general free-for-all, we will have a number of pre-announced discussions on particular topics at particular times. We have a number of other rooms available for these break-out sessions, but I don't know the numbers right now.

Please feel free to add your own suggestions below.

Naturally, not all developers will be able to come, so it might be a good idea to start discussing some of these topics in the [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum] now. And if anything significant comes out of the discussions, we should try to record it on the wiki.

===Quiz developments===
{|
|-
| Time: || 2:00 to 3:00
|-
| Room: || ??
|-
| Suggested by: || Tim Hunt
|}
We can discuss some things that have happened recently:
* The implication of [[Plan_to_Improve_Flexibility_of_Question_Category_Sharing_and_Permissions|Jamie's recent changes to the question bank]],
* Improvements to the question type API, especially [[Plans_for_enhancing_import/export_in_questiontype_plugins|Howard's recent changes]],
some things that will probably happen soon:
* The OU's quiz navigation changes, that we hope to put into Moodle 2.0,
* The OU's [[Plans_for_adaptive_mode|changes to adaptive mode]] that we hope to put into Moodle 2.0,
* Tony Gardner-Medwin's plans to introduce certainty-based marking,
known problems with the quiz architecture that no-one is working on right now:
* ... suggestions welcome ...
and anything else you want to raise.

Of course, you can talk to me about the quiz at any time time during the day too, if you have a more specific issue.

===ePortfolios===
{|
|-
| Time: || 2:00 to 3:00
|-
| Room: || ??
|-
| Suggested by: || Thanh Le
|}

===Social Networking tools===
{|
|-
| Time: || 11 - 12
|-
| Room: || ??
|-
| Suggested by: || Jenny Grey
|}

===Offline Moodle (and particularly synchronisation issues)===
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Colin Chambers
|}

===Conditional Activities===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Repository API===
The aim is to develop some consensus on how it can work so that a spec can be started.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Martin Dougiamas
|}

===Enrolment 'Groups'===
An overview of 'the problem' how we've solved it in the short term and discussion of hot it can be solved in core.
{|
|-
| Time: || ??
|-
| Room: || ??
|-
| Suggested by: || Dan Poltawski
|}

=== Accessibility demonstration ===
My colleague Chetz Colwell and I would like to give a brief demonstration of assistive technologies to developers, particularly core developers, and discuss future accessibility work on Moodle. We'll hopefully have a screen reader JAWS (Thunder?), screen magnifier, do a keyboard-only demo, and possibly speech recognition.
{|
|-
! Time:
| ??
|-
! Room:
| ??
|-
| Suggested by: || Nick Freear
|}

== PGP Keysiging ==

If any developers would like to exchange PGP Keys and expand their web of trust then this could be done during the Developer day.

I think it would be good to follow the [http://www.debian.org/events/keysigning Debian guidlines] for this.--[[User:Dan Poltawski|Dan Poltawski]] 18:03, 10 October 2007 (CDT)

==See also==

* [[Developer conferences]]
* [http://moodle.org/mod/forum/view.php?id=55 General Developer Forum]

Accessibility notes

2007-09-24T12:42:05Z

Nfreear: /* Guidelines */, add section 'Fix and test'

Accessibility notes

2007-09-23T12:12:07Z

Nfreear: /* Issues remaining */, added section 'Guidelines'

Accessibility notes

2007-09-14T16:57:58Z

Nfreear: /* Issues fixed */, links etc.

Accessibility notes

2007-09-14T16:51:51Z

Nfreear: /* Issues remaining */

Accessibility notes

2007-09-14T16:48:18Z

Nfreear: /* Issues fixed */, lots + added 'Issues remaining' section

Accessibility notes

2007-09-12T12:10:11Z

Nfreear: /* Pattern 2: accesshide */, WCAG10#gl-color link

Accessibility notes

2007-09-05T13:53:01Z

Nfreear: /* What JAWS says */, background

Accessibility notes

2007-09-05T11:49:33Z

Nfreear: /* Pattern 2: accesshide */, 'Wikipedia' links

Accessibility notes

2007-09-05T11:01:54Z

Nfreear: /* Moodle 1.8 */

Accessibility notes

2007-09-05T10:27:52Z

Nfreear: /* Moodle 1.6 */

Accessibility notes

2007-09-04T17:00:57Z

Nfreear: /* Moodle 1.7 */

Accessibility notes

2007-09-04T14:43:50Z

Nfreear: /* Moodle 1.6 */

Accessibility notes

2007-09-04T14:42:10Z

Nfreear: 'Issues fixed' outline: Moodle 1.5, 1.6 and so on

Accessibility notes

2007-08-30T12:50:27Z

Nfreear: /* Assistive technology */, expanding 'layers' idea

Accessibility notes

2007-08-30T12:37:28Z

Nfreear: Added: 'assistive technology', 'what JAWS says'