Add move/resize functionality to relevant patterns
from https://www.w3.org/Bugs/Public/show_bug.cgi?id=29326
For those patterns which need Move/resize need a new pattern which can be referenced
The following patterns may need this
- Dialog
- Dialog (non-modal)
- Column Headers
- Date Picker
- Media Player?
Provide a single mouse click/tap way to resize a TextArea
- Single click on TextArea's resize handle - nothing happens.
- There no way to re-size the area with a mouse single click/tap to met 2.5.7 Dragging Movement
The APG needs to show a/some design patterns implementing compliance with 2.5.7, such as one of the following alternatives to consider:
- Keyboard Control: this alternative DOES NOT MEET 2.5.7, but is required for 2.1.1 Keyboard. So a keyboard alternative is also required but not sufficient.
- Context Menu: Implement a context menu for the text-area that includes options for resizing (e.g., "increase height," "decrease width").
- Input Fields: Provide numeric input fields (width and height) next to the text-area where users can enter desired dimensions directly.
- Buttons: Include dedicated "plus" and "minus" buttons to incrementally adjust the text-area's width or height.
While the resizing functionality of a default HTML native text-area can be convenient for many users, it's not inherently accessible for everyone. Implementing an alternative resizing method alongside the default dragging behavior is necessary to ensure compliance with WCAG 2.5.7.
Auto-resize: this is a partial solution to automatically increase the height when typing input but will not automatically show scroll-bars. it simply automatically increases the area to match and not show scroll-bars. So how will the user reduce the text-area without dragging? In my opinion a critical reason the design wants resizable text-area input is to allow the user (not the dev) to decide the best size and when to show or remove scroll-bars.
Auto-scroll-bars: this is similar partial solution to not automatically increase the height when typing input but to automatically show scroll-bars. The area size does not increase the area to match and automatically shows scroll-bars. So how will the user resize the text-area to remove scroll-bars without dragging? In my opinion a critical reason the design wants resizable text-area input is to allow the user (not the dev) to decide the best size and when to show or remove scroll-bars.
Fix native element
Another way to resolve the issue with the native HTML text-area component/element is to open an issue and fix it there, not as an AIRA alternative pattern here.
Agreed, the HTML native textarea element seems not to be accessible when resizing. Interested in the outcome of this.