Tags for forms

[wfree-aph]

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?

[GeorgeKerscher]

Hi,

This means saving the file would need to be in scope. Then there are the logistics of transmiting the file somewhere, not to mention security.

[mattgarrish]

Security and privacy issues. Without a button or other means of the user authorizing the reading system to save data, it suggests that the reading system automatically saves whatever is entered. Users may not want that, especially on a shared device. Then there's the issue of clearing the data.

It's also potentially expensive for the reading system to be constantly monitoring for changes to save them, not to mention reloading the last state when a document is opened again. If the document is opened straight off the web, there are also going to be issues with storing data when the document itself isn't local.

It's a big problem to solve for the MVP. Not tackling it now doesn't add any obstacles to punting it down the road, though, as the elements will always be there later.

[jrbowden]

Hi, Can we link this issue to #77