Hidden file inputs [Was: Revert Request]

On Tue, Jan 31, 2012 at 10:29 PM, Charles Pritchard <chuck@jumis.com> wrote:
> While I disagree with this method, I want to point out one little irking
> unresolved issue.
> <input type="file" hidden> is becoming a real thing.
>
> I don't think it's a big issue, but since a11y peoples are on this thread, I
> do want to point it out.
> This is how I'd handle it, in my current code.
>
> <button onclick="file.click()" role="file button">Add files</button>
> <input type="file" id="file" hidden />

Providing custom file inputs by delegating clicks to a hidden file
input is a tricky business, since UAs try to prevent activation of
hidden file inputs for security reasons. When they do prevent it,
"click" fails silently which makes it impossible to test for this
behavior. Getting "click" to trigger a file dialog to open therefore
depends on circumventing the UA's hidden control detection, which
means there's a high risk that code that works today will break
tomorrow when UA detection mechanisms improve.

I suppose you could argue that UAs should at least throw a security
exception when click() is called on a hidden file input as per:

"When support for a feature is disabled (e.g. as an emergency measure
to mitigate a security problem, or to aid in development, or for
performance reasons), user agents must act as if they had no support
for the feature whatsoever, and as if the feature was not mentioned in
this specification. For example, if a particular feature is accessed
via an attribute in a Web IDL interface, the attribute itself would be
omitted from the objects that implement that interface — leaving the
attribute on the object but making it return null or throw an
exception is insufficient."

   http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements

But building a good UI when such exceptions occur would be tricky. I
suppose you could throw up a modal dialog and ask the user to click a
normal file input, but that would be clunky.

I'm not sure how we can give authors powerful skinning abilities for
such controls while still allowing UAs to ensure that file dialogs
only open as a result of deliberate user action.

As an aside, what's the advantage of including role="file button" in
your markup example? Only one role would ever be used; only "button"
is defined, and that semantic is represented by the element anyway.
Possible negative effects of using the "file" token include:

   1. Byte wastage.

   2. Causing the control to be misinterpreted according to some
future definition such as "represents a file".

   3. Constraining ARIA-Next to define the "file" role to mean "button
that causes a file dialog to open" rather than whatever the spec
editors think best at the time.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 31 January 2012 23:22:31 UTC