Dropdown that takes instant action on a web app - is this an accessibility or usability issue?

Question

Dropdowns that take action on websites were frowned upon years ago in that users of screenreaders didn't necessarily want to activate an item in a dropdown as they navigated through the dropdown to read all the different options. A "Go" button was recommended to actually activate the chosen selection. Is this still an issue for screen readers?

Today it seems that dropdowns in websites & web apps that set values instantly are a bit more common (though inline edit may be more usable, as the user has take an explicit action, e.g. hitting "enter" or clicking outside the field to save it). However, I'm not sure how common dropdowns that set values but also take action in are.

In our system (which will be used almost exclusively on a desktop), it is hypothesized that orders in this table will be processed one by one. Changing the value in the row-level dropdown would move the order into the next "Status" and do some back-end processing of it. Though it is an expert system, it seems to me to be somewhat unconventional to have the dropdown take instant action on the item in that row. Depending on the filter being used, the row may disappear from the list. We could potentially add an "Are you sure you want to change the status?" dialog, but we want to make it as efficient as possible for our users who will generally make lots of quick changes.

Is there a better way?

I did design a version of this that does batch processing, but this was declined as an option while I was away, I was told because the managers of this team don't want to support batch processing.

Answer 1

Batch processing would be preferable but as that was not accepted you are left with updating on dropdown change.

I also think your users would prefer batch processing (i.e. could change all "In Progress" to "Approve" in one click, this would be a good feature) so perhaps raise that with your managers as an added usability benefit for everyone.

As this is an expert system (by which I am assuming you mean a company back-end system not a public facing one without training) you can get away with certain behaviours as long as you indicate what action will occur.

The simplest way to achieve this would be with a combination of explanations of behaviour. (so add a 'help' button that opens a dialog explaining what each action would do, what behaviour the user should expect and where focus will change to if an item is deleted.)

Couple that with an aria-live="assertive" section to instantly feedback results of actions (and errors, don't forget meaningful, human friendly errors so that WHEN (not if) an action fails the user knows about it) and you will have an accessible experience.

So for example, for your delete scenario where an item gets removed I would have an aria-live="assertive" region announce something along the lines of "Order 7421 deleted" and at the same time focus the record above it so that it announces "order date for order 74563", I am assuming that all other accessibility issues have been accounted for so that this kind of announcement is present as you navigate through the table, if not then you could also announce this using youraria-live` region ("Order 7421 deleted, order 74563 selected").

Additionally if a user changes the status there could be a use case to announce this change, but you would have to try that with a screen reader (as the screen reader will announce that you have selected an item normally, depends on how you are updating things on the record though).

The one thing that you must do is ensure that actions are only taken on enter (or space depending on the input type) and do not occur just because you navigate to an option and then leave the input field.

This would be your biggest accessibility problem and is something I see more often than I care to admit. (so for clarity if I move down to the fourth option and then press tab for example, do not update the record state!)

The main thing to avoid is navigation on a drop-down change, if the site changes page due to a drop-down action then this is where you MUST implement a "go" button. I am assuming from the way you phrased your question that actions are AJAX and not delivered via a page refresh.