What would the appropriate aria roles and behaviors for 2d x/y axis plane input be?

Question

I have a component which presents an x/y axis plane and a nub that users can move around within the plane. Some aspects of accessibility here seem pretty straight forward: the nub should be focusable; keyboard up/down/left/right should move the nub by some interval to increment the x/y values in the appropriate directions. Even with a secondary text input, these behaviors for the widget-proper may be helpful regardless of whether users are employing assistive technology.

But when I began investigating how I should mark this up aria-wise, I wasn’t sure what the appropriate role/roles should be, or what the best way to communicate the available functionality is.

The closest match for a role appeared to be "slider": https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_slider_role

However the slider role as described on MDN seems like it may be specific to single-axis sliders.

Answer 1

A slider is effectively 1D only, so it isn't the appropriate role.

To convaince of this, read the description of slider in ARIA 1.1. http://www.w3.org/TR/wai-aria-1.1/

Nothing in the description mentions that you may use something else than simple numerical values, comparison between values should be unique and total (for 2D points it is not), and it also reads the following:

Elements with the role slider have an implicit aria-orientation value of horizontal

It's horizontal; it may certainly be vertical; but definitely not both at the same time.

By the way, by default, Jaws for example announce more or less this for a slider: "left right slider. Use left and right arrow keys to adjust the value" which is wrong for your case.

IF you were in a discrete plane, I would have suggested grid/row/gridcell. But since you are selecting coordinates in a continuous plane (or almost), your case is special / unconventional, hance there doesn't exist a predefined ARIA recipe you can apply.

IN such a case where there is no really adequate role, tehe best play is probably to not indicate any role at all for your component. An assistive technology will therefore not confuse the user by telling him what your control is not really, nor by giving him wrong indications on how to use it. No indications at all is probably better than wrong ones.

You must of course still use aria-label/aria-labelledby to give your component a label, make it focusable and keyboard usable. You should also ideally compensate the absence of predefined role by giving precise keyboard usage instructions. For this, keep it rahter short in aria-describedby (which might be read each time the control is focused), and if needed / if the control is quite complex, explain it longer somewhere else with plain text.

IF it's really too complex, you are also allowed to give up, as long as you provide an acceptable alternate input mean giving equal possibilities. For a color chooser, enter RGB value or #XXXXXX code would certainly be acceptable and sufficient alternate input means.