Tekst źródłowy strony Broken/Accessibility notes

<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 [[Development: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 &lt;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 &lt;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''' &mdash; 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>&amp;#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]]
* [[Development:Moodle Accessibility Specification|Accessibility Specification, Moodle 1.8]]


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