File inputs are pretty ugly, and can be confusing to naive users (e.g., “Should I type what I want in that box?”).  Quirksmode describes a nicer solution that mail.aol.com (Compose) happens to use:
http://www.quirksmode.org/dom/inputfile.html

But if one cares about Big-A accessibility, such a solution won’t work for users with normal vision who are limited to the keyboard (no mice), such as those with carpal tunnel syndrome.  The reason it won’t work is that such users rely on tab order, and tabbing into an invisible file input consumes 2 tabs before one sees any visible result — the user won’t know they are on top of the Browse button.

One might suggest putting the nonfunctional button in the tab order, and when it receives focus, call click() on the nonvisible file input. But in my experiments, click() did not trigger a FileOpen dialog.

One might also suggest faking focus on the nonfunctional button by drawing a rectangle around it when the nonvisible file input receives focus.  But remember that file inputs consume 2 tabs — it might make sense to draw the rectangle on the second tab, when focus is on the Browse button, but what about the first tab?  Even if there are separate events from the file input from the tabs, which seems doubtful, what would one display for the first tab?

A decent compromise is to get rid of the nonfunctional button and make the file input visible.  But like the mail.aol.com use, hide the inputs once they are used and show a checkbox with the filename instead, with focus moved to this checkbox (so blind users will be aware of the result of their file selection).