Last week I posted about why the accept attribute on file inputs is bad UX.
The accept attribute lets you specify which file types an input will accept. For example, if users need to upload a receipt, you can do this:
<input type="file" accept="image/jpeg,image/png,application/pdf">
That means users can only select those file types. All other files are disabled:
This sounds good because it stops users from picking an invalid type before they submit - which would then cause an error.
But as I said in the post, this is bad UX because:
- The disabled files are greyed out making them hard to read
- Some users will not notice the subtle greyed out styling - so will try clicking the invalid files anyway
For them, this makes the interface feel broken and confusing.
But someone called Russell replied to me in disagreement:
Disabling non-eligible options is good UX, recommended by WCAG (Web Content Accessibility Guidelines).
Users may have to go through the upload flow several times and not understand why it’s not working.
You’re also breaking Jakob’s Law — disabling files when uploading is something users are familiar with.
Ignoring it forces them to adjust their approach, increasing friction and cognitive load.
The problem is that the accept attribute causes the exact problem we’re both trying to solve.
Specifically, that users won’t understand why the interface isn’t working.
And this isn’t theoretical.
I’ve seen this repeatedly in user research.
Russell did also say that we should tell users the accepted types in hint text:
This way users know what to do before they open the file dialog.
Totally agree.
But you can’t rely on every user reading hint text. Research repeatedly shows that many users don’t spot or read it.
And when this happens users end up rage clicking because they don’t understand why the computer isn’t responding.
That’s bad.
Even if the user does read the hint text, there’s no guarantee they’ll remember what it says - perhaps they:
- are stressed and in a rush
- get interrupted by a phone call
- have cognitive impairments or memory issues
So the accept attribute is not a layer of protection.
It’s the cause of the problem.
If instead we ditch the accept attribute and show an error, users get feedback that helps them fix the problem, right there and then like this:
If that’s not enough to convince you - and it should be - there are three more issues with the accept attribute:
- It only handles file type, not file size
- You can bypass it by dragging and dropping files instead
- Some browsers don’t support it - for example, Firefox on Android
So not only is it fragile, you still have to handle errors anyway.
I asked Russell to cite where WCAG recommends the accept attribute. He sent me advisory guidance relating to criterion 3.3.2:
Choose a design that reduces the chance that the user will make a mistake. This includes: […] Using an interface where only valid input can be selected […]
To be clear:
This is not success criteria. It’s advisory guidance.
But this guidance almost definitely comes from Jakob Nielsen’s 5th usability heuristic about error prevention.
The heuristic is fine, but designers constantly misinterpret it as approval to hide errors from users.
As if it’s better to hide an error and pretend one doesn’t exist, than it is to show the error and let users fix it.
In short:
Error hiding is not error prevention.
Which is why the accept attribute is so bad.
If you’d like to know all the different, legitimate, user-friendly ways to properly prevent errors - instead of hiding them, you might like my course, Form Design Mastery: