A11y enhancements for SelectField.

[willnationsdev]

A few type hints, but mostly A11y attributes for the combobox, listbox, and options, along with their various pressed/expanded/selected/disabled states.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
svelte-ux	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 4, 2023 8:49am

[what-the-diff]

PR Summary

• Expansion of SelectField Component
  The SelectField.svelte component has been augmented with a variety of new variables and functions. This includes prevValue, prevSelected, and updateSelected, which help keep better track of the selected state. The new onBlur, onKeyPress, and onClick functions allow for more interactive user experience. The new TextField component improves the overall structure. Finally, the addition of role, aria-expanded, aria-selected, and aria-disabled attributes improves accessibility for users with disabilities.

• Update to TextField Component
  The TextField.svelte component has been enhanced by adding a role prop to make the component more accessible to users with certain disabilities.

[techniq]

Another great PR, thanks @willnationsdev. A11y is another area I know the library needs a lot of TLC. I've contemplated using Melt UI to help with this, although I'd like to wait for it to be more stable with breaking changes (~v1). I've done a lot of work with keyboard accessibility, so I'm not sure how much it would provide compared to just fixing the issues directly (adding role, aria-, tabindex, etc)

I really appreciate all the PRs!

[techniq]

@willnationsdev Are you on the Discord? I have a contributors channel where it might be nice to talk/plan upcoming changes.

[techniq]

@willnationsdev Sorry I forgot to mention, but could you also submit changesets npm run changeset and fill out the few prompts when you send in PRs. I need to setup the changeset-bot to help with this.

This is used to generate the CHANGELOG.md and shown on the website. Thanks!

[willnationsdev]

@techniq Not familiar with the tool. Is that something I should do once for each PR, before it is submitted? And what's the protocol now that I've already merged feature branches without doing so? Just run it once and describe the changes from all merged branches in one go as its own PR?

[techniq]

@willnationsdev Preferable it should be ran for each PR (to both explain the change, and indicate the semver change). The tool is used by the a lot of big projects, including svelte itself.

Quick summary:

• run npm run changeset and pick the semver version (patch, minor, or major)

Pre 1.0, I've been using patch for non-breaking changes or minor features, and minor for breaking changes and bigger features. Post v1, we'll follow standard semantic versioning. For these cases, I think patch would suffice (no anticipated breaking changes).

• Running that command ultimately just creates markdown file in the .changeset directly of the project with a generated name (name doesn't matter). Here is an example of one generated (that hasn't been released yet)

• Once we're ready to cut a release, I will run npm run version which takes all those changes sets, and

  • Determines the correct version to increment based on the changes (if we have 3 patches and 1 minor, it will bump the minor version, for example)
  • Updates the version in package.json
  • Transfers all the .changeset/* markdown files to CHANGELOG.md (and deletes them)

• Lastly, I'll deploy using npm run publish to send to NPM and create a git tag.

I'm planning to make npm run version and npm run publish aa Github action at some point

Let me know if that is helpful. I wrote it in a bit of a rush :)