- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 31 Jan 2012 15:43:43 -0800
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Laura Carlson <laura.lee.carlson@gmail.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On 1/31/12 3:21 PM, Benjamin Hawkes-Lewis wrote: > 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, This ship has already sailed. As I understand it, Mozilla introduced it, WebKit is fixing bugs related to it. It's a lot better than the previous situation of using: style="opacity: 0". Security is handled by the typical manner: restricting execution to the current gesture. That is, you can only send that click during a user gesture. > 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. It's five bytes. > 2. Causing the control to be misinterpreted according to some > future definition such as "represents a file". > Could certainly be a problem. There's no telling what's in store in the future. But since I have access to update my application in the future, I'm not too worried. > 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. That's the same issue as #2. I'm not constraining ARIA next at all, as I'm not putting "file" in a spec, I'm just sticking it in my current markup. I don't believe "file" as a reference to the file system will become an ARIA role. I don't believe "folder" will either. -Charles
Received on Tuesday, 31 January 2012 23:44:08 UTC