Address accessibility gaps in Shoelace

[shoelace-style]

Address accessibility gaps in Shoelace

[claviska]

I figured as much. I'm open to including a small JS snippet in shoelace.js if it makes the button accessible. Just let me know how you think it should work and I'll be happy to work on it.

[claviska]

Thanks for the PRs. And absolutely, let's discuss this!

[claviska]

Per #41, I reworked most components and made sure to address accessibility with buttons, switches, tabs, etc.

Focus states for buttons are similar to BS4-beta's approach:

I also updated switches to have a consistent focus state:

Badges:

Tabs too:

I'm working on the docs now, and then I'll push a release and update the website. Until then, you can view these changes in master.

One component that still needs to be addressed is the file button. The markup looks like this:

<label class="button">
  Select File
  <input type="file">
</label>

Not sure if the same trick you used for switches will work for this. I couldn't get the focus state working on the label. Any ideas?

[scottaohara]

yeh the file button was something i was trying to figure out how to bring up, because of the issue with the lack of focus state, but in addition to that, there is no visual indicator of when a file has been slated for upload, at all.

There really is no good CSS only solution for customizing file upload buttons.

I've done work on doing style uploads with JS/CSS in the past though...I'll try to see if I can't dig that back up.

[scottaohara]

i'll try to find some time to get you that demo / any specs that may need to be added, asap

[claviska]

I believe all the accessibility issues outlined are now resolved. File buttons were the last ones, and have been fixed in 0f8e1ec. The structure was changed and the markup is a bit more verbose, but it's a fair tradeoff for making them accessible.

Examples: https://shoelace.style/docs/file-buttons.html

[scottaohara]

Hey @claviska sorry I haven't had time to jump on this, but saw the issue closed so wanted to check in.

Per the file buttons, is the examples page you provided up to date?

I know I didn't outline it before, but here are some of the issues pertaining to the current file upload button style:

1. There's still no visible keyboard focus of the 'buttons' (though they can be accessed by keyboard). (file inputs work differently than things like checkboxes, where you can use sibling selectors to style an element on focus of the checkbox. To achieve focus styling in the past, I've needed to rely on JavaScript to add/remove a focus class)
2. With normal file upload inputs, the file name of a chosen file will be displayed. With the styled buttons, there is no text area or other indication that a file has been slotted for upload with it.

Again, apologies I haven't been able to dig up an appropriate example that I've previously done for these. Hope the above 2 points are helpful though.

[claviska]

I need to handle cache busting better. Make sure you refresh to get the latest styles. They work the same as buttons when focused:

With normal file upload inputs, the file name of a chosen file will be displayed. With the styled buttons, there is no text area or other indication that a file has been slotted for upload with it.

File buttons !== file inputs. As noted in the docs:

File buttons are much easier to style, but come with the caveat that the name and number of files selected will not be automatically shown to the user. This aspect of a file button’s UX can be handled effectively with JavaScript, but this is left as an exercise for the user.

File buttons are becoming more and more common, particularly in single page apps and apps that upload files via XHR.

Ways to handle this type of feedback vary a lot these days. Some apps upload automatically on change and only show a loader (no need for filenames since the user knows what they just selected). Others show a preview (for images) or an icon with the filename. Others use a queue.

With FileReader, we can do tons of things we never could before, and there's no way a library can properly handle all those edge cases. That's why I think it's best to leave that up to the user.

[scottaohara]

Hey @claviska thanks for the reply.

It seems that the issue is FireFox specific, as I can verify that I see the focus state in Safari, Chrome and IE/Edge. But in Firefox on PC and Mac, there are no focus states.

And yes, I did see the note in the documentation about these being 'file buttons' but outside of styling, there is nothing semantically different about how they are announced to users than normal file inputs, because under the hood that's what they are. But per your documentation, you do make it clear that it's up to the user to finish the job, so I will leave it at that.

Thanks!

[claviska]

Ah, Firefox. Don't think we can do anything about that though :(

https://stackoverflow.com/questions/20095105/input-type-file-focus-adjacent-selector-in-css