When making custom Shiny inputs, this class is properly automatically added to the outer container alongside the input id at the time the HTML-generating Shiny input function is called. This is as intended.
However, I am finding that if such a widget contains any input tags deeper within its HTML hierarchy (i.e., custom checkboxes), and that input tag has an id attribute, the presence of the id attribute on the input tag appears to cause Shiny to also automatically append class='shiny-bound-input' in every case.
I do not know if this is unintended or by design, but it is problematic for designing for accessibility. I need the ability to create input tags that are part of custom Shiny inputs and that must have unique id attributes for accessibility reasons, but which are not reactive (not sure if that's the right word to use in this context).
Is it possible to prevent this in Shiny itself? Am I doing something wrong to cause this? As far as I can tell, any custom widget that has an input such as
<input type="checkbox" id="inputid-option1" ...
will cause Shiny to force the class="shiny-bound-input" to appear.
Is my only option going to be to use an ad hoc JS solution to listen to widgets and remove shiny-bound-input wherever I need to? If so, can someone recommend the least bad way to do that?
I came here first because the Shiny behavior described doesn't strike me as a bug, but by design- just one with unanticipated consequences. It's also not really a feature request.
But it is fairly technical, and I do need to find a solution to it. Thanks
I can't really make sense of your requirements I'm afraid. You want to have named inputs that don't behave as inputs ? Can you give an example of an input that you would not want to be bound, and the why of that?
When this is rendered in the browser by shiny, it appends shiny-bound-input to the class attribute of the container, at the top level where the ID is. The individual <input> tags inside the container for each checkbox are not appended with such a class. This is because they are not supposed to be individually reactive inputs (For example, if you use bookmarking, the state of every single checkbox option will not clutter your bookmark URL.).
The problem is I have to make custom inputs like these that meet better web accessibility standards and are more friendly to screen reading devices etc. I need to provide unique id attributes to <input> tags. But it seems like doing so triggers shiny to say "I've found an input tag that has an id attribute; therefore add this class to make it reactive". This leads to something like a checkbox group with five options having the shiny-bound-input class appended to it in six places causing other problems.
I can try to post a more reproducible example later, but it will have to include a JS binding. But to the best that I can tell, this occurs as soon as I give my tags IDs. WIthout IDs, the issue does not occur.
Hi thanks for your explanation. I'm sure I agree with you that this is an accessibility issue not yet fully addressed in shiny. They would probably appreciate an issue raised on their github.
I expect this is only a tangential concern for you, but there is a shiny functionality to exclude id's from being bookmarked.
I imagine you are having to compose your own shiny objects so as to incorporate the label for name style syntax, and ID in the subcomponents ?
is that what you meant by ?
Including the IDs causes every option to be bound as a Shiny input.
Thanks for your feedback, I will post something on github then since that sounds appropriate.
Yes, the bookmark exclude is handy for normal inputs but does not adequately address this issue, and with enough inputs and options would be very frustrating to use even just for the bookmarking case.