Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: HEAD
- OS Version: Mac OS 12.6.3
Steps to Reproduce:
- Launch vscode web server
- Open main editor view
- Ctrl-f / cmd-f to open Find / Replace dialog
Results:
Find / replace dialog does not programmatically identify itself as a dialog and has the aria role generic.
The component does follow many aspects of dialog behavior, for instance:
- focus moves to component when opened
- is dismissible via esc key and has a close button
- is a logical grouping of other controls or information
It does not trap focus within the component and is therefore non-modal. There is not yet an established pattern for non-modal dialogs (w3c/aria-practices#102) but they do have common usage, such as toasts, snackbars, side panels, etc.
The following pattern would provide programmatic grouping for controls within the dialog and make their intent more clearly associated. Close button should be moved out of find-part as it should be directly associated with the dialog and not part of the find input form group.
<div class="find-widget" role="dialog" aria-label="Find / Replace">
...
<button>Close</button>
</div>
Previously, screen reader output (NVDA) for close, when shift-tabbing into the dialog from the status bar for instance:
main landmark, Close (escape), button
A screen reader user cannot directly tell from the control itself what this button closes.
With dialog role and label, as the last element in the dialog:
main landmark, Find / Escape, dialog, Close (escape), button
In this case close is identified as belonging to the dialog, where it was previously unclear what the function of the button was.
Does this issue occur when all extensions are disabled?: Yes
Steps to Reproduce:
Results:
Find / replace dialog does not programmatically identify itself as a dialog and has the aria role
generic.The component does follow many aspects of dialog behavior, for instance:
It does not trap focus within the component and is therefore non-modal. There is not yet an established pattern for non-modal dialogs (w3c/aria-practices#102) but they do have common usage, such as toasts, snackbars, side panels, etc.
The following pattern would provide programmatic grouping for controls within the dialog and make their intent more clearly associated. Close button should be moved out of
find-partas it should be directly associated with the dialog and not part of the find input form group.Previously, screen reader output (NVDA) for close, when shift-tabbing into the dialog from the status bar for instance:
A screen reader user cannot directly tell from the control itself what this button closes.
With dialog role and label, as the last element in the dialog:
In this case close is identified as belonging to the dialog, where it was previously unclear what the function of the button was.