Accessibility

Websites built with accessibility in mind are flexible in meeting different user needs, preferences and situations. Though these methods can increase usability for everyone who uses the Web they are often legally required to be implemented in a specific effort to prevent discrimination against people with disabilities.

Starting points

These are some readable introductions to accessibility that cover; what accessibility is, why it is important, as well as practical advice.

• Web Accessibility Initiative's Introduction to Web Accessibility
• Mark Pilgrim's Dive into Accessibility
• Joe Clark's Building Accessible Websites book

Moodle-related accessibility coding guidelines

Use CSS, but still use headings, strong and emphasis

It is generally a good idea to separate a document's content HTML from how it is presented using CSS. There are some tags that affect a document's presentation but also contribute to the structure and meaning of the content. These tags should remain in HTML. This includes heading tags <h1>, <h2>, <h3>..., which are used to form the document's hierarchical structure, and <strong> and <em> tags, which are used to add meaning to sections of text.

Avoid using background images for important information

Users of non-visual browsers cannot see images. They can read the alt tags of normal images, but background images are not presented like normal images.

Image alt and title attributes

• An alt attribute is required (even if empty) on all images.
• If a link is wrapping an <img>, the <img> does not need a title attribute if the link has one.
• The alt for an image and the title for its surrounding link should usually differ. An image alt attribute provides a text equivalent to an image, whereas a title attribute adds supplementary information about the purpose or action associated with an image link. Simply repeating the same text in alt and title attributes adds little and can be annoying for screen reader users.

Links and buttons should be selectable and easily click-able

• An image used as an icon for a user to click should be large enough so that the user can click on it easily.
• Users should be able to navigate to all links and buttons using the keyboard.
• Generally we should avoid having two buttons/links that achieve the same action in the same area. This can be annoying and confusing for users of screen readers.

Support dynamic interaction with ARIA attributes

Events triggered by AJAX and JavaScript can be less obvious to users of non-visual browsers. ARIA attributes can assist users of such browsers to follow a dynamic change.

Use labels with inputs

Context can easily be lost without a visual presentation. Labels are needed on all input input elements (except button) to describe their purpose in a form. Labels should be unique on a page. Repeated elements should have a unique label that identifies the element within its context.

Use appropriate page titles

A page title is a starting point for a screen reader. Page titles should be unique and should make sense for the page. Avoid generic page titles.

All pages should be navigable using just a keyboard

It should be possible navigate to all points on a page just using a keyboard. Important events triggered by a mouse event should be able to be triggered when the item receives focus through keyboard navigation.

Web standards, guidelines and legislation

International

• Web Accessibility Initiative
  • Web Content Accessibility Guidelines (WCAG)
  • Web Content Accessibility Guidelines 2.0 (draft)
    • An article on the problems with WCAG2 from A List Apart

USA

• Section 508

UK

• SENDA - Special Educational Needs and Disability Act/Bill
• Disability Discrimination Act 1995

Germany

• Barrierefreie Informationstechnik-Verordnung - BITV

Tools

Firefox extensions

• Firefox Accessibility Extension by the Illinois Center for Information Technology and Web Accessibility (iCITA)
• Web developer extension for Firefox
• Blank Your Monitor and Easy Reading Extension for Firefox
• plugin for Firebug
• contrast plugin for Firefox

Accessibility validation tools

• W3C validation (for HTML in Moodle, CSS and RSS)
• Web accessibility evaluation tool
• Cynthia Says accessibility checker

Screen readers

• Fangs – the screen reader emulator for Firefox
• NVDA NonVisual Desktop Access - open source screen reader for Windows

See also this long list of accessibility tools.

Resources

• Web Standards.org's Accessibility Task Force Manifesto
• Accessibility articles from A List Apart
• Mark Pilgrim's Won’t somebody please think of the gerbils?

Dive Into Accessibility by Mark Pilgrim

• Joe Clark's writings on accessibility

Building Accessible Websites by Joe Clark (online version)

• Wikipedia article on Web Accessibility
• Validity and Accessibility
• Videos showing as student accessing another Learning Management System via Screen Reader software

See also

• Semantic HTML
• Accessibility forum on Moodle.org
• Using Moodle New Accessibility Themes forum discussion
• See en:Usability FAQ for the related concept of usability.
• en:Moodle Accessibility Specification
• http://moodle.org/mod/forum/discuss.php?d=127807#p559951
• The Introduction to Moodle Programming provides some extensive information and discussion on accessibility.
• EASY: Interface Between The Virtual Environment Moodle Learning and People with Visual Impairments
• BBC blog post on how their Web 2.0 homepage was made accessible
• BBC Accessibility Help
• Accessibility Compliance in Moodle 1.8
• Compliance with Italian Legislation on Accessibility