[WCAG 2.2 Draft Feedback] Success Criterion 2.5.7 Dragging Movements (Level AA) #2705
Comments
|
Proposed working group answer: |
detlevhfischer
added
2.5.7. Dragging Movements
2.5.7 Dragging Movements
Survey - Ready for
and removed
2.5.7. Dragging Movements
labels
|
Regarding keyboard accessibility, the logic given comes across as "it doesn't count because we say so". I think if the Understanding documentation can frame this instead in terms of user needs and the reason why, for users, keyboard equivalents can't work for any device accessing the web, that would clarify things enough to cover that concern.
The Understanding Dragging Movements documentation does not point to any research or evidence. If research and evidence exists to back this guidance up across everything on the web, then linking to that in the documentation should cover this concern. |
|
@slauriat In answer to a request sent to several organisations of people with motor impairment I got email feedback from just one (Pfennigparade) where several users with motor impairment came together to discuss this and told us that they think the SC is useful and dragging is a pain for them. It seems this is not really suitable as reference to be linked to from the Understanding doc though. Would it help / make a difference if they publish a statement that can be linked to? I can ask them if they can. I have repeatedly asked (implored?) WG members to reach out to relevant oganisations and/or to provide pointers to research to put this on a better footing. It seems nothing has turned up so far. This could indicate that there really isn't sufficient research, or even mean the user need is not so pronounced. So this could in turn mean that we drop the SC (if that is still an option). To my knowledge, the WG decided to go forward with it. I am easy both ways - I just wanted to get the ball moving by proposing a WG answer to this issue. |
Absolutely! Full research would help the most in terms of backing up the specific guidance, but statements from representative organizations would still help in terms of offering at least something by way of evidence of impact to users.
Very much appreciated! I just checked in on the ones @dshoukry filed for Google, saw your drafted responses, and wanted to clarify a couple of things for the Working Group's discussions about your drafted response. |
@slauriat — could you point to places in Understanding (or elsewhere) of this being the logic given? In my experience, it is not uncommon for PWD who use trackballs or other adaptive pointing devices to be frustrated by a drag-and-drop UI, and being told to use the keyboard instead is not sufficiently responsive to their need. Sometimes the impairment is fine motor function. Sometimes the impairment is cognitive. It is common tor most any visually-oriented / mouse-oriented user to resent being told they need to use a keyboard, but the limitation being only for PWD seems like an obvious gap that a11y standards might address. There is also the category of end-users whose only access to a computer is, for example, an electronic head pointer. Their default UI is point-and-click only, perhaps with an on-screen keyboard. A subset of these users cannot point-and-drag and use a "dwell select" or maybe use their AT to switch modes (e.g., right-click, left-click-lock). The webpage directly supporting point-click (only) would be easier. Some people who use some of these pointer-only interfaces are not cognitively able to manage different mouse modes, so they only can use point-single-click UI. There is no need for clinical trials or other hard research to know that 2.5.7 Dragging Movements closes an accessibility gap. |
|
Here an example of the sort of product I have in mind: Origin Instruments HeadMouse Nano When looking for that, I learned that OS X provides a way to Move the pointer using head pointer on Mac Both of those provide mouse-pointer only. The user will need some way to click, but apps where the user can avoid the need for click-and-drag will be easier to use. The option to use the mouse, and not a mouse-controlled-keyboard, is important. Another example is a large format trackball with ability switch input: AbleNet BIGTrack2 Someone for whom that specialized trackball is a good input modality probably has motor difficulties with switches such that click-and-hold-and-move-the-mouse-pointer is much harder than just point-and-click. For that person, using the keyboard input modality required to meet 2.1.1 is not a good option. Again, 2.5.7 addresses a real-world accessibility issue not covered by 2.1 or 2.0. |
|
I don't personally doubt the user needs, the understanding documentation just doesn't make the user needs clear and it should before inclusion into WCAG.
Detlev's drafted response, and this bit from the understanding documentation essentially says that because other things in WCAG cover keyboard interactions, meeting those keyboard interactions doesn't automatically meet this new SC.
Keyboards work in tapping keys. The user needs you described in this github comment seems like great examples to include in the understanding documentation, with links to research or evidence of some kind (statements from representative groups like Detlev mentioned, documented flows of interaction modalities in relation to keyboards, whatever works) as to how on screen keyboards, scripting of the AT, etc. doesn't make for an acceptable mechanism and, as such, keyboard accessibility doesn't help for these user needs. Hope that helps! Also happy to talk through these suggestions in more detail with the group. |
|
Thanks @slauriat as I think this is good constructive criticism for improving both Understanding and @detlevhfischer Proposed working group answer. |
I've attempted to do that in #2828. I've focused on the introduction area at the top. The "relationship to other requirements" leads on from that, and is focused on interpretation of the SCs rather than the direct user-need.
The understanding documents are supposed to be how-to guides, they don't include the background research. The group and interested stakeholders should be satisfied that it exists and is appropriate, but it would be inconsistent (and very long) to include in the understanding documents. We can document those elsewhere, such as the WG Wiki. |
|
Approved working group answer (from Detlev's and others above):
The SC does not require a pointing device, but if dragging is enabled then, by definition, the content is supporting a pointing device. It is possible for web content to meet 2.1.1 and fail 2.5.7. Some interfaces support drag & drop with a pointer and support selection and movement with the keyboard. They may not support selection and movement by single-taps. Google drive is a good example, where you can select an item and go through the process of moving it by tapping on the context menu and "move to", without using the keyboard or dragging. PR #2828 attempts to make this aspect clearer in the understanding document.
2.5.7 is concerned with providing alternatives for single pointer activation for pointer users with motor impairments, both for touch input users and mouse users. That part of the document is saying that it should be evaluated separately from keyboard accessibility. The first line of the intent is intended to convey that aspect.
This has not impacted the implementations we've looked at. For example, trello uses a standard drop-down: That type of dialogue uses a standard drop-down so would pass target size, and it should scroll if needed. Another option is to provide a text input (which should reliably trigger an onscreen keyboard). That could be a simple number, or the more advanced version in Google drive. The Working Group believes that there is sufficient evidence of user needs to include the new SC. It is logical based on how the interactions using specialised pointers work, and feedback from users at Pfennigparade. |
|
hmmm
Looks like the Understanding document function has changed - or I am misreading the comment below
Originally — the HOW TO was the techniques document
The UNDERSTANDING document was why, what it means, and how we came to this form.
So research results would be in the Understanding WCAG - showing how we came to the wording, numbers, etc.
gregg
…------------------------------
Gregg Vanderheiden
***@***.***
I don't personally doubt the user needs, the understanding documentation just doesn't make the user needs clear and it should before inclusion into WCAG.
I've attempted to do that in #2828 <#2828>. I've focused on the introduction area at the top. The "relationship to other requirements" leads on from that, and is focused on interpretation of the SCs rather than accessibility requirements.
The user needs you described in this github comment seems like great examples to include in the understanding documentation, with links to research or evidence of some kind (statements from representative groups like Detlev mentioned
The understanding documents are supposed to be how-to guides, they don't include the background research. The group and interested stakeholders should be satisfied that it exists and is appropriate, but it would be inconsistent (and very long) to include in the understanding documents. We can document those elsewhere, such as the WG Wiki.
—
Reply to this email directly, view it on GitHub <#2705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXVDHHCTQEET2JFPNWLWL4MUZANCNFSM6AAAAAAQ5DB7XI>.
You are receiving this because you are subscribed to this thread.
|
|
+1
This is very good and should be in the understanding document as an example (with company names removed)
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Dec 6, 2022, at 3:44 AM, Alastair Campbell ***@***.***> wrote:
Proposed working group answer (from Detlev's and others above):
The standard is missing an exception for a keyboard interface, as it requires a pointing device. If the dragging motion is not essential for operation, then keyboard users should also be able to perform the action.
The SC does not require a pointing device, but if dragging is enabled then, by definition, the content is supporting a pointing device.
It is possible for web content to meet 2.1.1 and fail 2.5.7. Some interfaces support drag & drop with a pointer and support selection and movement with the keyboard. They may not support selection and movement by single-taps.
Google drive is a good example, where you can select an item and go through the process of moving it by tapping on the context menu and "move to", without using the keyboard or dragging.
What is the reasoning behind this [relationship to 2.1.1]? Mobile could be a reason for this, but that depends on the platform and should not impose all mobile requirements on all desktop content.
2.5.7 is concerned with providing alternatives for single pointer activation for pointer users with motor impairments, both for touch input users and mouse users. That part of the document is saying that it should be evaluated separately from keyboard accessibility. The first line of the intent is intended to convey that aspect.
Reordering items in a list would require a bit of a large set of buttons per item, especially together with the Target Size (Minimum) SC.
This has not impacted the implementations we've looked at. For example, trello uses a standard drop-down:
<https://user-images.githubusercontent.com/216630/205899279-0aac4d9f-f9af-4f65-934d-e50ed3752802.png>
That type of dialogue uses a standard drop-down so would pass target size, and it should scroll if needed. Another options are to provide a text input (which should reliably trigger an onscreen keyboard). That could be a simple number, or the more advanced version in Google drive.
The Working Group believes that there is sufficient evidence of user needs to include the new SC. It is logical based on how the interactions using specialised pointers work, and feedback from users at Pfennigparade <https://www.pfennigparade.de/>.
—
Reply to this email directly, view it on GitHub <#2705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQB7CKO4HXKUGKOFNLWL4RLLANCNFSM6AAAAAAQ5DB7XI>.
You are receiving this because you are subscribed to this thread.
|
That isn't what I can see in the 2.0 docs, they don't include the research into why the requirement exists. Even in the links of the resources section, things like colour contrast, non-text content, keyboard don't include research into why those are issues. I had assumed that was because the understanding docs were aiming to summarise what people needed to know in order to understand and implement the SC (expanded by the techniques), rather than how the requirement was created in the first place. |
|
I agree that Understanding does not include research into why those are issues. I agree that how the requirement was created in the first place is not useful. On the other hand, we sometimes do go into the weeds. For example, from color contrast, rationale for the ratios chosen. |
|
On Dec 6, 2022, at 10:18 AM, Alastair Campbell ***@***.***> wrote:
That isn't what I can see in the 2.0 docs, they don't include the research into why the requirement exists. Even in the links of the resources section, things like colour contrast <https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#resources>, non-text content <https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html#resources>, keyboard <https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html> don't include research into why those are issues.
The "Why they are issues" is at the top of each Understanding WCAG 2.0 item - as well as the benefits from doing it
The research bit has to do with the research as to why they are worded as they are.
When we first created Understanding WCAG - its purpose was to understanding the SC - and understand what the WG was thinking when it created the SC
- to help people understand the language which sometimes seem technical
- to help those who are applying them understand the need — why they are being asked to do this
- to help answer questions about where the numbers came from that are in the SC
Thus it was mean to help with
- understanding what it means
- understanding what needs it was meant to address
- understanding the benefits
- understanding how it came to be worded that way - and where numbers came from.
- (also to know if there were tools to help in testing some of the harder to test ones like FLASH and CONTAST.)
For example Understanding WCAG 2.0 CONTRAST <https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html> has all of these items.
The Reseach links to the research both on the need and the basis for the numbers is included
as well as a whole section on "Rationale for the Ratios Chosen" is included.
Other things like "the need for text alternatives" are at the top of those items along with who benefits (another way at getting at needs)
They do not have research for values since there is no value per se for including alternatives or not.
So we include Reseach information in the Understanding WCAG docs when we have it and relied on it. (But not when we don’t or didnt)
Does that help?
Gregg
… On Dec 6, 2022, at 10:18 AM, Alastair Campbell ***@***.***> wrote:
So research results would be in the Understanding WCAG - showing how we came to the wording, numbers, etc. gregg
That isn't what I can see in the 2.0 docs, they don't include the research into why the requirement exists. Even in the links of the resources section, things like colour contrast <https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#resources>, non-text content <https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html#resources>, keyboard <https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html> don't include research into why those are issues.
I had assumed that was because the understanding docs were aiming to summarise what people needed to know in order to understand and implement the SC (expanded by the techniques), rather than how the requirement was created in the first place.
—
Reply to this email directly, view it on GitHub <#2705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXWY7APEFESHLUBAND3WL57PTANCNFSM6AAAAAAQ5DB7XI>.
You are receiving this because you commented.
|
|
This is going on quite a tangent, but I'll note that colour contrast is the only one that goes "into the weeds" like that, the exception that proves the rule? For dragging, it follows from people needing alternative pointer inputs and not having (easy) access to keyboard equivalents. Also people with motor impairments struggling with accuracy on touch screens. I think this would be in the category of "They do not have research for values since there is no value per se for including alternatives or not.". Where dragging is required, it triggers problems. |
|
This is going on quite a tangent, but I'll note that colour contrast is the only one that goes "into the weeds" like that, the exception that proves the rule?
Well - I think calling it "into the weeds" is pejorative. - but I don’t think this is the only one with rationale. Most are not of the quatantative type - so there is no reason to go into how it was derived. But when we do - we should leave documentation as to where we got it from — how we came up with that number.
ÆI think this would be in the category of "They do not have research for values since there is no value per se for including alternatives or not.". Where dragging is required, it triggers problems.
I agree.
The purpose of the Understanding document is to help people understand. For most of them - it is not necessary to go into such detail - or to show were it was derived from. For example (as you highlighted) we did not need to do a bunch of research to determine that pictures needed alt text.
But for contrast - there was lots of discussion and many opinions about how much was enough and people asked for what the research said. So a research effort was carried out to find and bring to the group the information for them to make a decision. Then it was decided to include that so others could follow the trail. Ditto for FLASH where there is much more information than for many others - though there it got even tougher since almost all standards were based on an algorithm that was proprietary — so the group focused only on the most salient (and didnt for example try to tackle pattern triggers for seizures).
… On Dec 6, 2022, at 3:39 PM, Alastair Campbell ***@***.***> wrote:
This is going on quite a tangent, but I'll note that colour contrast is the only one that goes "into the weeds" like that, the exception that proves the rule?
For dragging, it follows from people needing alternative pointer inputs and not having (easy) access to keyboard equivalents. Also people with motor impairments struggling with accuracy on touch screens.
I think this would be in the category of "They do not have research for values since there is no value per se for including alternatives or not.". Where dragging is required, it triggers problems.
—
Reply to this email directly, view it on GitHub <#2705 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRAXF73FXCCA6HUV6LWL7FB7ANCNFSM6AAAAAAQ5DB7XI>.
You are receiving this because you commented.
|
|
Note to self from call 1/31 – keyboard alternative/emulation provided by platform (and thus which is easy to rely upon) is acceptable. |
“Success Criterion 2.5.7 Dragging Movements (Level AA): 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 and not modified by the author.”
Recommendation:
We kindly request that the group remove this SC until research is completed for all affected input modalities. We couldn’t find reasoning documented as to why "Success Criteria 2.1.1 Keyboard and 2.1.3 Keyboard (No Exception) require dragging features to be keyboard accessible. However, achieving keyboard equivalence for a dragging operation does not automatically meet this Success Criterion" from the Understanding documentation. We believe more considerations are needed for various platforms, and that there shouldn’t be an imposition of all mobile requirements on all desktop content. For example, responsive design techniques offer ways of adapting UIs to different screen sizes and mobile/desktop environments. Even with desktop environments that offer full touch screen input, they generally include ways of triggering keyboard shortcuts. There are also concerns about implications around interaction patterns for reordering list items and a large set of buttons per item, especially together with Target Size (Minimum).
This seems like an especially important area to have research, a diverse set of use cases, evidence of user impact, and a specific set of content structures to keep the SC beneficial, appropriately scoped, and attainable.
Please find detailed specifics covered in our Sep22 2.5.7 Dragging Movements (AA) Google Doc
The text was updated successfully, but these errors were encountered: