feat(react): new component FileUpload

[oddvernes]

resolves #1236

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1392825

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Preview deployments for this pull request:

storybook - 27. Mar 2026 - 09:55

www - 27. Mar 2026 - 10:01

[oddvernes]

One issue I have encountered: because all the components are in one common @layer, placing FileUpload inside a Field causes .ds-field to overwrite styles on .ds-file-upload (being a label) due to usage of stronger selectors (:is()). For now I have solved this by repeating the class twice .ds-file-upload.ds-file-upload {} to get same specificity (0.2.0) and then it wins by being later in the css order.

[Febakke]

Tested with VoiceOver.

Label in field gives weird behavior. Image is showing reading order of elements.

Image from screen reader:

Text inside works fine:

We need to discuss:

• Should we support label outside of dropzone? If so, how do we create a robust screen reader experience?
• We need to think about the "slipp filer her" text. This is something we might want to hide from screen readers. How do we support this and flexible texts 🤔

[eirikbacker]

Pushed some updates now:

• Screen reader tested 👍
• Moved from label to description for all text
• Question: should readonly really be same visually as hover?
• Question: should :hover really change button styling too? (this makes it harder for end user to change to ie. primary button)
• Question: should FileUpload.Button be renamed to FileUpload.Trigger or FileUpload.CTA or something, as Button sets expectations of a HTML <button> but we are rendering a <span>? ☺️
• Question: there is a lot of aria-hidden="true" on the description texts in the stories - are we sure we want to hide this text from screen readers? I see why it might feel redundant, but in the same time - we should strive to have the same information accessible for everyone

[Febakke]

@eirikbacker Thanks for excelent feedback as always! ❤️

• Question: should readonly really be same visually as hover?

Good point. I made some changes so we align more with Nav Aksels design on this. Not solid border and a grey background. We need to decide if we want it to follow data-color or not. I might be leaning on always using the neutral scale as it follows how we solve or other read-only components.

Here is an example if we would follow data-color with a blue color.

• Question: should :hover really change button styling too? (this makes it harder for end user to change to ie. primary button)

This is not important to me. We have a pretty "heavy" hover state with both background and changes to border. Having the button be static I think is okay.

• Question: there is a lot of aria-hidden="true" on the description texts in the stories - are we sure we want to hide this text from screen readers? I see why it might feel redundant, but in the same time - we should strive to have the same information accessible for everyone

Im guessing you are referring to hiding the "Slipp filer her" text. We based this on some user tests that the american design system had done on screen reader users. But we do not have any first hand data on this. If you think its better to make all text available, thats fine by me. One reason why I dont push back on this is meant to be changed by our consumers. So lets say they remove the "label" and add the text. "Drop you application here or choose file" then important information would be hidden from screen readers if aria-hidden="true" is standard. Might be safer to just let all text be available.