Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Aria Guidelines: Difference between revisions

From MoodleDocs
Line 45: Line 45:


== Changing div/span content ==
== Changing div/span content ==
=== Summary ===


=== Accessibility Goals ===
=== Accessibility Goals ===

Revision as of 05:08, 2 August 2013

This is a collection of best practice techniques for use of aria attributes and related features to enable access from assistive technologies in Moodle (e.g. screenreaders, zoom text, keyboard navigation).

As developers are fixing bugs or designing new interactions for keyboard access, please add to this list of examples.


Drag and drop

Summary

Unless care is taken, this interaction is not possible for users not using a mouse or touch interface (this could be a screen reader, or someone may have a motor impairment). Note: providing a non-javascript alternative for this interaction is not sufficient to make this accessible (javascript enabled != can use a mouse).

Accessibility Goals

Provide a keyboard equivalent for this interaction.

References

http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#dragdrop http://www.w3.org/TR/2008/WD-wai-aria-20080204/#dragdrop

How this applies to Moodle

Keyboard navigation for drag and drop has been built into the Moodle yui module moodle-core-dragdrop (once MDL-36002 is integrated). If you are implementing drag and drop in Moodle - use it - don't roll your own. Second - if you are using drag and drop in Moodle - you must use obvious "grab handles" which is a standard element used to initiate the drag and drop. Get a grab handle with M.core.dragdrop.get_drag_handle() (which will return a Y.Node with an image of a grab handle and event listeners already setup).

The way this works with M.core.dragdrop is that pressing enter on the drag handle will open list of valid drop targets for the drag with all the correct aria attributes.

Related tracker issues

MDL-36002


Opening a dialogue/popup

Summary

Opening a dialog involves many aria tasks. You need to take care about:

  • dialog focus: if the dialog gets the focus, and in most case it should have the focus, then the user needs to be alerted.
  • dialog label: alert the user what the dialog is about.
  • triggering button: alert the user that the button will open a dialog.
  • triggering link: alert the user that the link will open a dialog.

Accessibility Goals

Alert the user that a link will open a dialog. Alert the user that a dialog is opened.

References

dialog focus

dialog label

triggering button

triggering link

Related tracker issues

Changing div/span content

Accessibility Goals

Alert the user that a specific region changed.

References

aria-live http://www.w3.org/TR/wai-aria/states_and_properties#aria-live https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Live_Regions

Collapsing/Expanding

Accessibility Goals

You need to alert the user of a collapsing/expanding changes.

References

aria-expanded http://www.w3.org/TR/wai-aria/states_and_properties#aria-expanded
aria-controls http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls

Related tracker issues

MDL-36011