![\"An](\"https:\/\/github.blog\/wp-content\/uploads\/2024\/07\/image3.png?resize=1024%2C545\")
<\/div>\nBased on our findings, here are some of the challenges we faced and how we solved them:<\/p>\n
Challenge: Screen readers use arrow keys to navigate through content<\/span><\/a><\/h2>\nOne of the very first challenges we faced involved setting up an interaction model for moving an item through keyboard navigation. We chose to use arrow keys as we wanted keyboard operation to feel natural for a visual keyboard user. However, this choice posed a problem for users who relied on screen readers to navigate throughout a webpage.<\/p>\n
To note<\/strong>: Arrow keys are commonly used by screen readers to help users navigate through content, like reading text or navigating between cells in a table. Consequently, when we tested drag-and-drop with screen reader users, the users were unable to use the arrow keys to move the item as intended. The arrow keys ignored drag-and-drop actions and performed typical screen reader navigation instead.<\/p>\nIn order to override these key bindings we used role='application'<\/code>.<\/p>\nTake note<\/strong>: I cannot talk about using role='application'<\/code> without also providing a warning. role='application'<\/code> should almost never be used. It is important to use role='application'<\/code> sparingly and to scope it to the smallest possible element. The role='application'<\/code> attribute alters how a screen reader operates, making it treat the element and its contents as a single application.<\/a><\/td>\nConsidering the mentioned caution, we applied the role to the drag-and-drop trigger to restrict the scope of the DOM impacted by role='application'<\/code>. Additionally, we exclusively added role='application'<\/code> to the DOM when a user activates drag-and-drop. We remove role='application'<\/code> when the user completes or cancels out of drag-and-drop. By employing role='application'<\/code>, we are able to override or reassign the screen reader’s arrow commands to correspond with our drag-and-drop commands.<\/p>\nRemember, even if implemented thoughtfully, it’s crucial to rely on feedback from daily screen reader users to ensure you have implemented role='application'<\/code> correctly. Their feedback and experience should be the determining factor in assessing whether or not using role='application'<\/code> is truly accessible and necessary.<\/p>\nChallenge: NVDA simulates mouse events when a user presses Enter or Space<\/span><\/a><\/h2>\nAnother challenge we faced was determining whether a mouse or keyboard event was triggered when an NVDA screen reader<\/a> user activated drag-and-drop.<\/p>\nWhen a user uses a mouse to drag-and-drop items, the expectation is that releasing the mouse button (triggering an onMouseUp<\/code> event) will finalize the drag-and-drop operation. Whereas, when operating drag-and-drop via the keyboard, Enter or Escape is used to finalize the drag-and-drop operation.<\/p>\nTo note<\/strong>: When a user activates a button with the Enter or Space key while using NVDA, the screen reader simulates an onMouseDown<\/code> and onMouseUp<\/code> event rather than an onKeyDown<\/code> event.<\/p>\nBecause most NVDA users rely on keyboard operations to operate drag-and-drop instead of a mouse, we had to find a way to make sure our code ignored the onMouseUp<\/code> event triggered by an NVDA Enter or Space key press.<\/p>\nWe accomplished this by using two HTML elements to separate keyboard and mouse functionality:
\n 1. A Primer Icon button<\/a> to handle keyboard interactions.
\n 2. An invisible overlay to capture mouse interactions.<\/p>\n![\"A](\"https:\/\/github.blog\/wp-content\/uploads\/2024\/07\/image2.png?resize=1024%2C750\")
<\/div>\nChallenge: Announcing movements in rapid succession<\/span><\/a><\/h2>\nOnce we had our keyboard operations working, our next big obstacle was announcing movements to users<\/a>, in particular announcing rapid movements of a selected item.<\/p>\nTo prepare for external user testing we tested our announcements ourselves with screen readers. Because we are not native screen reader users, we moved items slowly throughout the page and the announcements sounded great. However, users typically move items rapidly to complete tasks quickly, so our screen reader testing did not reflect how users would actually interact with our feature.<\/p>\n
To note<\/strong>: It was not until user testing that we discovered that when a user moved an item in rapid succession the aria-live<\/code> announcements would lag or sometimes announce movements that were no longer relevant. This would disorient users, leading to confusion about the item’s current position.<\/p>\nTo solve this problem, we added a small debounce to our move announcements. We tested various debounce speeds with users and landed on 100ms to ensure that we did not slow down a user’s ability to interact with drag-and-drop. Additionally, we used aria-live='assertive'<\/code> to ensure that stale positional announcements are interrupted by the new positional announcement.<\/p>\nexport const debounceAnnouncement = debounce((announcement: string) => {\n announce(announcement, {assertive: true})\n}, 100)\n<\/code><\/pre>\nTake note<\/strong>: aria-live='assertive'<\/code> is reserved for time-sensitive or critical notifications. aria-live='assertive'<\/code> interrupts any ongoing announcements the screen reader is making and can be disruptive for users. Use aria-live='assertive'<\/code> sparingly and test with screen reader users to ensure your feature implores it correctly.<\/p>\nChallenge: First-time user experience of a new pattern<\/span><\/a><\/h2>\nTo note<\/strong>: During user testing we discovered that some of our users found it difficult to operate drag-and-drop with a keyboard. Oftentimes, drag-and-drop is not keyboard accessible or screen reader accessible. As a result, users with disabilities might not have had the opportunity to use drag-and-drop before, making the operations unfamiliar to them.<\/p>\nThis problem was particularly challenging to solve because we wanted to make sure our instruction set was easy to find but not a constant distraction for users who frequently use the drag-and-drop functionality.<\/p>\n
To address this, we added a dialog with a set of instructions that would open when a user activated drag-and-drop via the keyboard. This dialog has a \u201cdon\u2019t show this again\u201d checkbox preference for users who feel like they have a good grasp on the interaction and no longer want a reminder.<\/p>\n
![\"A](\"https:\/\/github.blog\/wp-content\/uploads\/2024\/07\/image1.png?resize=1024%2C579\")
<\/div>\nChallenge: Moving items with voice control in a scrollable container<\/span><\/a><\/h2>\nOne of the final big challenges we faced was operating drag-and-drop using voice control assistive technology. We found that using voice control<\/a> to drag-and-drop items in a non-scrollable list was straightforward, but when the list became scrollable it was nearly impossible to move an item from the top of the list to the bottom.<\/p>\nTo note<\/strong>: Voice control displays an overlay of numbers next to interactive items on the screen when requested. These numbers are references to items a user can interact with. For example, if a user says, \u201cClick item 5\u201d and item 5 is a button on a web page the assistive technology will then click the button. These number references dynamically update as the user scrolls through the webpage. Because references are updated as a user scrolls, scrolling the page while dragging an item via a numerical reference will cause the item to be dropped.<\/p>\nWe found it critical to support two modes of operation in order to ensure that voice control users are able to sort items in a list. The first mode of operation, traditional drag-and-drop, has been discussed previously. The second mode is a move dialog.<\/p>\n
The move dialog is a form that allows users to move items in a list without having to use traditional drag-and-drop:<\/p>\n
![\"A](\"https:\/\/github.blog\/wp-content\/uploads\/2024\/07\/image4.png?resize=998%2C792\")
<\/div>\nThe form includes two input fields: action and position.
\nThe action field specifies the movement or direction of the operation, for example, \u201cmove item before\u201d or \u201cmove item after.\u201d And the position specifies the location of where the item should be moved.<\/p>\n
Below the input fields we show a preview of where an item will be moved based on the input values. This preview is announced using aria-live<\/code> and provides a way for users to preview their movements before finalizing them.<\/p>\nDuring our testing we found that the move dialog was the preferred mode of operation for several of our users who do not use voice control assistive technology. Our users felt more confident when using the move dialog to move items and we were delighted to find that our accessibility feature provided unexpected benefits to a wide range of users.<\/p>\n
In Summary, creating an accessible drag-and-drop pattern is challenging and it is important to leverage feedback and consider a diverse range of user needs. If you are working to create an accessible drag-and-drop, we hope our journey helps you understand the nuances and pitfalls of this complex pattern.<\/p>\n
A big thanks to my colleagues, Alexis Lucio<\/a>, Matt Pence<\/a>, Hussam Ghazzi<\/a>, and Aarya BC<\/a>, for their hard work in making drag-and-drop more accessible. Your dedication and expertise have been invaluable. I am excited about the progress we made and what we will achieve in the future!<\/p>\n
In order to override these key bindings we used Take note<\/strong>: I cannot talk about using Considering the mentioned caution, we applied the role to the drag-and-drop trigger to restrict the scope of the DOM impacted by Remember, even if implemented thoughtfully, it’s crucial to rely on feedback from daily screen reader users to ensure you have implemented Another challenge we faced was determining whether a mouse or keyboard event was triggered when an NVDA screen reader<\/a> user activated drag-and-drop.<\/p>\n When a user uses a mouse to drag-and-drop items, the expectation is that releasing the mouse button (triggering an To note<\/strong>: When a user activates a button with the Enter or Space key while using NVDA, the screen reader simulates an Because most NVDA users rely on keyboard operations to operate drag-and-drop instead of a mouse, we had to find a way to make sure our code ignored the We accomplished this by using two HTML elements to separate keyboard and mouse functionality: Once we had our keyboard operations working, our next big obstacle was announcing movements to users<\/a>, in particular announcing rapid movements of a selected item.<\/p>\n To prepare for external user testing we tested our announcements ourselves with screen readers. Because we are not native screen reader users, we moved items slowly throughout the page and the announcements sounded great. However, users typically move items rapidly to complete tasks quickly, so our screen reader testing did not reflect how users would actually interact with our feature.<\/p>\n To note<\/strong>: It was not until user testing that we discovered that when a user moved an item in rapid succession the To solve this problem, we added a small debounce to our move announcements. We tested various debounce speeds with users and landed on 100ms to ensure that we did not slow down a user’s ability to interact with drag-and-drop. Additionally, we used Take note<\/strong>: To note<\/strong>: During user testing we discovered that some of our users found it difficult to operate drag-and-drop with a keyboard. Oftentimes, drag-and-drop is not keyboard accessible or screen reader accessible. As a result, users with disabilities might not have had the opportunity to use drag-and-drop before, making the operations unfamiliar to them.<\/p>\n This problem was particularly challenging to solve because we wanted to make sure our instruction set was easy to find but not a constant distraction for users who frequently use the drag-and-drop functionality.<\/p>\n To address this, we added a dialog with a set of instructions that would open when a user activated drag-and-drop via the keyboard. This dialog has a \u201cdon\u2019t show this again\u201d checkbox preference for users who feel like they have a good grasp on the interaction and no longer want a reminder.<\/p>\n One of the final big challenges we faced was operating drag-and-drop using voice control assistive technology. We found that using voice control<\/a> to drag-and-drop items in a non-scrollable list was straightforward, but when the list became scrollable it was nearly impossible to move an item from the top of the list to the bottom.<\/p>\n To note<\/strong>: Voice control displays an overlay of numbers next to interactive items on the screen when requested. These numbers are references to items a user can interact with. For example, if a user says, \u201cClick item 5\u201d and item 5 is a button on a web page the assistive technology will then click the button. These number references dynamically update as the user scrolls through the webpage. Because references are updated as a user scrolls, scrolling the page while dragging an item via a numerical reference will cause the item to be dropped.<\/p>\n We found it critical to support two modes of operation in order to ensure that voice control users are able to sort items in a list. The first mode of operation, traditional drag-and-drop, has been discussed previously. The second mode is a move dialog.<\/p>\n The move dialog is a form that allows users to move items in a list without having to use traditional drag-and-drop:<\/p>\n The form includes two input fields: action and position. Below the input fields we show a preview of where an item will be moved based on the input values. This preview is announced using During our testing we found that the move dialog was the preferred mode of operation for several of our users who do not use voice control assistive technology. Our users felt more confident when using the move dialog to move items and we were delighted to find that our accessibility feature provided unexpected benefits to a wide range of users.<\/p>\n In Summary, creating an accessible drag-and-drop pattern is challenging and it is important to leverage feedback and consider a diverse range of user needs. If you are working to create an accessible drag-and-drop, we hope our journey helps you understand the nuances and pitfalls of this complex pattern.<\/p>\n A big thanks to my colleagues, Alexis Lucio<\/a>, Matt Pence<\/a>, Hussam Ghazzi<\/a>, and Aarya BC<\/a>, for their hard work in making drag-and-drop more accessible. Your dedication and expertise have been invaluable. I am excited about the progress we made and what we will achieve in the future!<\/p>\nrole='application'<\/code>.<\/p>\nrole='application'<\/code> without also providing a warning. role='application'<\/code> should almost never be used. It is important to use role='application'<\/code> sparingly and to scope it to the smallest possible element. The role='application'<\/code> attribute alters how a screen reader operates, making it treat the element and its contents as a single application.<\/a><\/td>\nrole='application'<\/code>. Additionally, we exclusively added role='application'<\/code> to the DOM when a user activates drag-and-drop. We remove role='application'<\/code> when the user completes or cancels out of drag-and-drop. By employing role='application'<\/code>, we are able to override or reassign the screen reader’s arrow commands to correspond with our drag-and-drop commands.<\/p>\nrole='application'<\/code> correctly. Their feedback and experience should be the determining factor in assessing whether or not using role='application'<\/code> is truly accessible and necessary.<\/p>\nChallenge: NVDA simulates mouse events when a user presses Enter or Space<\/span><\/a><\/h2>\n
onMouseUp<\/code> event) will finalize the drag-and-drop operation. Whereas, when operating drag-and-drop via the keyboard, Enter or Escape is used to finalize the drag-and-drop operation.<\/p>\nonMouseDown<\/code> and onMouseUp<\/code> event rather than an onKeyDown<\/code> event.<\/p>\nonMouseUp<\/code> event triggered by an NVDA Enter or Space key press.<\/p>\n
\n 1. A Primer Icon button<\/a> to handle keyboard interactions.
\n 2. An invisible overlay to capture mouse interactions.<\/p>\n<\/div>\nChallenge: Announcing movements in rapid succession<\/span><\/a><\/h2>\n
aria-live<\/code> announcements would lag or sometimes announce movements that were no longer relevant. This would disorient users, leading to confusion about the item’s current position.<\/p>\naria-live='assertive'<\/code> to ensure that stale positional announcements are interrupted by the new positional announcement.<\/p>\nexport const debounceAnnouncement = debounce((announcement: string) => {\n announce(announcement, {assertive: true})\n}, 100)\n<\/code><\/pre>\naria-live='assertive'<\/code> is reserved for time-sensitive or critical notifications. aria-live='assertive'<\/code> interrupts any ongoing announcements the screen reader is making and can be disruptive for users. Use aria-live='assertive'<\/code> sparingly and test with screen reader users to ensure your feature implores it correctly.<\/p>\nChallenge: First-time user experience of a new pattern<\/span><\/a><\/h2>\n
<\/div>\nChallenge: Moving items with voice control in a scrollable container<\/span><\/a><\/h2>\n
<\/div>\n
\nThe action field specifies the movement or direction of the operation, for example, \u201cmove item before\u201d or \u201cmove item after.\u201d And the position specifies the location of where the item should be moved.<\/p>\naria-live<\/code> and provides a way for users to preview their movements before finalizing them.<\/p>\n