Tags for forms

One proposal for the eBraille file type is interactive materials. This behavior is not currently available while using a digital braille file and can only be accomplished via hardcopy braille or some other means, like a print file, web page, app, etc.

HTML has methods for forms that can be used to collect user input. The main way this is done is using the \ element. Within the \ element, various kinds of \ elements can be used. Here are the different ways that \ can be used:

- \ Displays a single-line text input field
- \ Displays a radio button (for selecting one of many choices)
- \ Displays a checkbox (for selecting zero or more of many choices)
- \ Displays a submit button (for submitting the form)
- \ Displays a clickable button

I don't think we need "submit" or "button" since that's not how the file type will work but I included them here so we can discuss them.

I'm thinking we would limit ourselves to "text", "radio", and "checkbox". We could then use CSS to handle aspects like how much space to reserve for a text field, for example.

What are the challenges of allowing these kinds of interactive materials within the spec? One is the burden it places on reading systems. How will they handle it? One option is that reading systems that lack editing options and static braille preparation software both represent the interactive aspects of the file using braille, so displaying the equivalent amount of space that would be allotted by the text box, the boxes that would be necessary for checkboxes, etc. If we provide enough information, I think that the file can remain a specific size (hopefully making it so the file doesn't need to be resized as the user inputs text) and that should benefit both dynamic and static hardware and reading systems regardless of their ability to also edit.

What other issues do we need to consider? Is there a better method than the one proposed? Are they appropriate in the MVP?