Need a "4-way" picker to allow picking or moving an object within a 2D space

[jnurthen]

In order to support color pickers (and possibly other things) we really need a way to indicate a "4-way" slider. This needs to support x-min, x-max, y-min, y-max, x-value, y-value as well as "valuetext".

[AmeliaBR]

I'm very much supportive of this. It's something I've been frustrated with, and just hadn't gotten around to writing it down.

2D selectors for mouse/pointer users are so easy to implement with JavaScript, on any block element, that there has never been much demand for a dedicated HTML element. And with a little extra work, you can make it keyboard accessible, too, for basic arrow keys and maybe modifiers. But as James points out, there's no easy or standard way to communicate the purpose of the field, it's available ranges, and it's current 2D value. You could add 2 separate range inputs along the axes for screen readers, but that makes it a lot less convenient to select a value (tabbing back and forth between inputs), and means the screen-reader accessible representation is not well integrated with the pointer-accessible version.

[sinabahram]

Question: couldn't this all be achieved by using/abusing grid?

I'm responding to this issue because I assume #1363 may be closed as a duplicate of this one.

[jnurthen]

@sinabahram I'm not sure I see how to use grid for this. Can you explain?

[sinabahram]

Grid is a control that already assumes 4-way cardinal movement, and that assumption is shared by the user, so I assumed up/down can indicate your brightness values, for example, and left/right can control your shade/color choices. Each grid cell, when landed upon, would then speak out the color being shown on screen in a sensible way. You still get cardinality/ordinality information on a row/column basis, and in fact the automatic filtering by AT when moving within a row or column could be useful in the proposed use case . Additionally, you're automatically put into focus/forms mode with Windows screen readers, so that part is also nicely handled too. Maybe I've missed a restriction of grid that would prevent making a color picker out of it?

[jnurthen]

hmmm - a single cell grid using aria-rowcount, aria-rowindex, aria-colcount and aria-colindex? We would certainly want to virtualize such a control though as creating all of the cells in the a11y tree would be far too costly.

<div role="grid" aria-rowcount="256">
  <div role="row" aria-rowindex="125">
     <div role="gridcell" aria-colcount="256" aria-colindex="12"></gridcell>
  </row>
</grid>

Its certainly an interesting direction.

[sinabahram]

Yes, exactly. I do think it may be worth identifying the significant performance hits on the grid sans virtualization. I think some paging may be necessary, but given modern cache lines, a few hundred cells at a time should really fly. It probably doesn't right now (I've never been blown away by grid performance) but that may be worth pushing on with the right entities?

[jnurthen]

We certainly can't go for no virtualization. We're envisioning using this type of thing to allow users to move objects around a potentially huge canvas. It may be possible to use a very small virtualized grid, but to be honest every extra cell could be a big performance issue here. @ckundo - anything to add?

[ckundo]

We need to have per pixel level control for a canvas with a full viewport on a potentially high resolution display, so I don't think drawing a grid cell for each pixel makes sense for performance, unless I'm misunderstanding.. for example we'd like to track relative and absolute position of a DOM object in a full screen canvas, eg 510 out of 1800px.

[sinabahram]

If it is per-pixel level control, then wouldn't doing a raw intercept of arrow keys with custom sonification/verbalization be the way to go? I'm obviously not usually a fan of self-voicing interfaces, but if you are wanting each pixel to be individually addressed, it seems like presumable other requirements in related tasks will eventually be selection or quick-skimming or jumping around, possibly by non-cardinal directions e.g. diagonally (stair-stepping == bad). If you don't go that way, I strongly recommend you allow for controllable discretization, though I'm partial to such an approach (almost wrote a Ph.D. on user-controllable reduction of complexity using this technique). The reason for that is so that you can take advantage of working memory to telescope the user into where they wish to be via switching between large movements into fine-level movements e.g. move into the quadrant where you wish to have something be (quadrant is arbitrary, just use a nXm config that makes sense for your domain) and then within that smaller area facilitate fine-grain control. Research on targeting, albeit for mouse pointers, showed promising results via that technique.

I think a slider would end up being super-limited for what I now understand is continuous motion in 2-D, possibly 3-D. Note, you get some really nice multimodal/multisensory mapping opportunities with the approach of grose/fine-grain movement because you can then use speech, haptics, and sonification independently or in combinations of two for primary/confirmatory signals to facilitate faster/more accurate placement. Not sure if you're multilayering or single layering, but collision detection would be worth a discussion with such a control so as not to force that to be a separate lookup during positioning tasks by an eyes-free user. I bring it up here because it implies additional event-driven speech anyways.

I fear I've strayed way off topic with the above, though. Sorry :). Happy to discuss offline, though, as this is a space I am deeply passionate about. Noted why a grid won't work, though.

[jnurthen]

Made title more generic to support #1363 use case

[carmacleod]

In case it's helpful, this type of thing is called a D-pad out in the real world.
So dpad might be a good role name, if you decide to go there, because it brings some affordance of what it does, and it's a shorter and more understandable string than fourwaypicker or multidirectionalslider or similar.

Edit: Never mind. NVDA reads dpad correctly (D pad), but JAWS says something like "duh pad" which would be really confusing. Interestingly, both screen readers say fourwaypicker and multidirectionalslider perfectly...

[danlevy1]

+1 on this for a Color Picker.

[benni-e]

+1 on this for street view map person movement and placement, if there isn't something more appropriate