This post covers creating accessible Drag and Drop functionality; including various ARIA and non-ARIA techniques that ensure automatic accessibility for screen reader and keyboard only users. Specifically, keyboard and mouse events must be cross-referenced to ensure equal functionality for all user types, and accessible feedback must be provided to convey the role, state and action of draggable objects to Assistive Technology users.
There are two ways to implement drag and drop functionality while ensuring accessibility for screen reader and keyboard only users; these being ARIA and standard HTML.
The most important thing to be aware of in both cases is that foolproof scripting using JavaScript must be used to ensure that all draggable objects are accessible from the keyboard. ARIA will not do this automatically by itself.
In the Accessible Drag and Drop demo at
http://whatsock.com/modules/css_drag_drop_module/demo.htm, standard XHTML and JavaScript is used to dynamically convert a list of images into draggable objects. At the same time, a visually hidden link is added for screen reader and keyboard only users that will initiate the drag process; when the dynamically displayed Drop link is then activated, the Drop event is fired for that object.
The value of this approach is that it allows programmers to modify the keywords “Drag”, “Dragging”, and “Drop” to fit the visual metaphor of whatever application the drag and drop functionality is applied to. E.G. “Cut”, “Moving”, “Paste”, etc.
In contrast, the use of ARIA-Grabbed and ARIA-Dropeffect will only convey “Draggable”, “Grabbed”, and a subset of drop effects such as “Droppable”, “Movable”, and so on, which may or may not fit the desired functionality of the application.
It is critical to keep in mind that the addition of ARIA will not automatically enable accessible functionality within an application, but will instead convey only the intended behavior of that functionality. For instance, adding the ARIA attribute role=”button” to a Span tag will cause screen readers to announce the element as a button, however this Span tag will not be keyboard accessible, nor will it be actionable. Foolproof scripting must be used to ensure proper functionality in all such cases.
In the Sortable Listbox demo at
http://whatsock.com/modules/aria_sortable_listbox_module/demo.htm, the ARIA attributes ARIA-Grabbed and ARIA-Dropeffect are used to convey when a listbox item has been grabbed and where it can be dropped. This functionality is automatically configured when the “Sort” button is activated.
The implementation for the sortable listbox is slightly different from the previous Drag and Drop demo, in which sighted mouse users cannot hold the left mouse button down on an item to drag it to another, but rather, mouse users can simply click the item to be grabbed, then click another item to drop it. For the purpose of ARIA-Grabbed and ARIA-Dropeffect, this functionality is irrelevant, since these attributes only convey the behaviors “Draggable”, “Grabbed”, and “Droppable” to screen reader users.
Screen reader users can press the Spacebar to grab a list item, then arrow to another, then press Spacebar again to drop it in that location. When nothing is grabbed, the attribute ARIA-Grabbed is set to “false”; when grabbed, ARIA-Grabbed is set to “true”. At the same time, when an item is grabbed, ARIA-Dropeffect is set to “move” on all available drop targets.
Here too, the use of foolproof scripting is critical to ensure proper keyboard functionality, while the addition of ARIA significantly enhances the user experience for screen reader users.
The post Accessible Drag and Drop – Why Foolproof Scripting Is Critical When Using ARIA appeared first on SSB BART Group.