Neckbeard dev seeks answers to form accessibility brief: conditional input zones on ∞ rows
irl last edited by
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).
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.
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:
From an accessibility perspective, just make sure the tabbing sequence makes sense and that all elements have an https://www.w3.org/TR/accname-1.1/#dfn-accessible-name (usually via a
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 ( https://www.w3.org/TR/WCAG21/#on-input )