WCAG2ICT Project: Add from WCAG 2.2 - 2.5.7 Dragging Movements

[maryjom]

• Add 2.5.7 Dragging Movements section (from WCAG 2.2)
• Add in any interpretation of the defined term "dragging movement", if needed.
• Add in the Understanding 2.5.7 Dragging Movements Intent and Benefits sections
• Consider and write up whether there are any notes needed for application of this SC to non-web technologies
• Address other open issue on this topic and, if needed, make necessary changes to content

[maryjom]

dragging movement

an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer until an up event

NOTE: Examples of draggable elements include list items, text elements, and images.

Seems that there will be no interpretation needed for this definition, which would apply as written.

[patrickhlauke]

dropping this here, but: the one aspect of 2.5.7 that will cause/is already causing confusion is the

functionality is determined by the user agent

and

Note: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

part. For web content, there's a nice clean(ish) distinction between dragging gestures that are used to operate the browser (like scrolling) and ones that are implemented on the content itself (e.g. a custom-built scroller using JavaScript). the distinction is a bit academic at times, but generally the idea is that if it's a dragging gesture to operate the browser, then it's the browser/OS that needs to provide a solution, so not a content author's responsibility. whereas something like a custom scroller is under the control of the author, so they are on the hook.

this distinction falls away when we come to things like native applications, where there is no user agent. all of a sudden, in theory anyway, any interaction like scrolling is pretty much "custom". for WCAG when it comes to web content, the WG was able to sidestep this particular discussion, but native apps will have to grapple with it.

[patrickhlauke]

See for instance this (split, unfortunately) thread on mastodon https://mas.to/@deanbirkett/110643436599576759

[maryjom]

@patrickhlauke In WCAG2ICT, "user agent" is defined as follows:

user agent (as used in WCAG2ICT)
any software that retrieves and presents documents for users

So from a document perspective, there is a user agent that is used to render the document. The document itself doesn't provide the scroll bars/scrolling capabilities. The user agent does.

[patrickhlauke]

I'm not worried from a "document" perspective. Worried from a "native application" perspective (e.g. an iOS/Android app)

[GreggVan]

@maryjom Not sure how to do the PR request but the text is pasted here and also attached as a word doc

This applies directly as written and as described in Intent from Understanding Success Criterion 2.5.7 (also provided below), replacing "user agent" with "user agent or platform software" and replacing “Web content” with “non-web documents or software”.
With these substitutions, it would read:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the [user agent or platform software] and not modified by the author.
NOTE
This requirement applies to [non-web documents or software] that interprets pointer actions (i.e. this does not apply to actions that are required to operate the [user agent, platform software] or assistive technology).

Intent
The intent of this Success Criterion is to ensure functionality that uses a dragging movement has another single pointer mode of operation without the need for the dexterity required to drag elements.
Some people cannot perform dragging movements in a precise manner. Others use a specialized or adapted input device, such as a trackball, head pointer, eye-gaze system, or speech-controlled mouse emulator, which may make dragging cumbersome and error-prone.
When an interface implements functionality that uses dragging movements, users perform four discrete actions:

1. tap or click to establish a starting point, then
2. press and hold that contact while...
3. performing a repositioning of the pointer, before...
4. releasing the pointer at the end point.
   Not all users can accurately press and hold that contact while also repositioning the pointer. An alternative method must be provided so that users with mobility impairments who use a pointer (mouse, pen, or touch contact) can use the functionality.
   This requirement is separate from keyboard accessibility because people using a touch screen device may not use a physical keyboard. Keyboard specific interactions such as tabbing or arrow keys may not be possible when encountering a drag and drop control. Note, however, that providing a text input can be an acceptable single-pointer alternative to dragging. For example, an input beside a slider could allow any user to enter a precise value for the slider. In such a situation, the on-screen keyboard that appears for touch users offers a single-pointer means of entering an alphanumeric value.
   This criterion does not apply to scrolling enabled by the user-agent. Scrolling a page is not in scope, nor is using a technique such as CSS overflow to make a section of content scrollable.
   2-5-7.docx

[maryjom]

Set up a survey for 2.5.7 Dragging Movements due 1 November. Created the draft in markdown using PR #245.

[maryjom]

As of the 9 November meeting, the TF made a resolution to incorporate the 2.5.7 content and as-is and also made a resolution to incorporate 'dragging movements' term to the "Applies to all Tech" section.

[maryjom]

Dragging movements has been approved by the AG WG in the review that ended 12 December. As a result of their review we adjusted the notes. This work is done.