0

Forgive me for having a bit of difficulty articulating the UI and design goals that I've been handed, but I need to appeal to the hive mind to find out best practice re usability and accessibility for the following scenario.

Basically we have a series of numerical inputs where in each row users can either input a 'basic' master value in column 1, or, a series of component values in the remaining 5 columns.

Each row is a sector, and the number of rows can vary dynamically based on user choice from 1 to 50+.

My initial sketches are starting to feel a bit like a spreadsheet, and become a bit overwhelming with many rows.

The target platforms include desktop and tablet, so tap target size is a concern, as is accessible keyboard use, which will benefit both the differently abled and power users.

I'm specifically interested in:

  • What best practices and guideline the community may be aware of that might apply to this use case (my google fu is failing me)

  • Any examples of prior-art that achieve similar aims, even if they approach things differently (also, happy for any feedback or criticism on my current direction).

A more compact approach that would rely on visual queues and aria descriptions

In the above 'compact' sketch, the interaction would rely heavily on careful use tab index and arrow key interaction. The javascript behaviour could become quite complex as we would need to govern aria roles changes etc. I can also imagine a lot of user prompts "are you sure you want to clear column 1 values?"

Example using vertical toggle to enable disable input zones

This second example adds a vertical toggle which could enable/disable the two input zones in the row. This will persevere tab index order, and leans more heavily on the browser to govern functionality. I think its major drawback is the addition of another control in a strange(ish) context. The toggle may also be a hinderance when trying to quickly input values in many rows.

Thanks in advance for your thoughts and time.

Improve this question
3
  • Without knowing use cases -- would using Tabs be simpler? Can Tab A contain all items that need to have Primary info, and Tab B show all items that need a collection of components? Does the user need to see everything in one co-mingled view or could they handle two collections?
    – Izquierdo
    Mar 10, 2022 at 21:17
  • It looks like an either/or situation so having tabs would not be conducive to that. One user might want to enter all primary info and another user might want to enter all component info. A third user might want a combination so switching back and forth between tabs would be annoying. But it was a good thought given the lack of use cases.
    – slugolicious
    Mar 10, 2022 at 22:25
  • In fact the original design handed to us, did just that with a tab separating all of the first column and the second tab holding all of the remaining columns. But this approach hid the context of the two options making it difficult to tell that the decision was applicable to each row. Adding a tabbed interface for each individual row was rejected as unwieldily. It did make it obvious that it was a per row decision, but again the context became confusing IMHO.
    – orionrush
    Mar 11, 2022 at 7:38

1 Answer 1

Reset to default
2

Another option, although this isn't conducive to compact rows, is to emphasize the either/or nature of "primary" vs "components" by using a radio group and having the input fields be hidden for the radio button that's not selected.

Roughly something like this:

Primary selected

enter image description here

Components selected:

enter image description here

From an accessibility perspective, just make sure the tabbing sequence makes sense and that all elements have an accessible name (usually via a <label> or aria-label).

You wouldn't have to prompt to clear the values when switching between radio buttons because you'd know which option they choose (by the value of the radio group). This has the nice benefit that the user could change their mind and switch to the other radio button and their values would still be there (until they submit).

Dynamically hiding/unhiding the input fields is not an accessibility issue as long as the user knows it will happen (WCAG 3.2.2)

Improve this answer
1
  • Thank you for your thoughts @slugolicious, and ref links for accessible names and WCAG!
    – orionrush
    Mar 17, 2022 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.