[Question 🙋🏻‍♀️] Do you have opinions of non-chart shadcn/ui elements?

[sarajw]

Hi Ashlee!

I just read your quick-ish accessibility review and clearly the shadcn charts are not good for charts. Yet, at least.

I'm curious whether the rest of the UI library is similarly questionable, or not bad, actually?

Thank you!

[ashleemboyer]

Hi @sarajw! I appreciate you giving it a read and for your patience while waiting for me to reply!

I've not reviewed every component and it's been a while since I've reviewed most.

My shorter answer is to evaluate one component at a time as you need them. My longer answer would make a great blog post because there's a bit of nuance. But overall I usually avoid UI libraries largely because they're built directly from the WAI ARIA Authoring Practices Guide (APG) and end up over-engineered with too much ARIA and custom keyboard/focus navigation. Native <button> and <a> elements go much further than people think!

I'll have to add this topic to my writing list. :)

[sarajw]

Thank you so much! That's an interesting insight though - is the WAI APG somewhat overengineered, then? 🤔

[ashleemboyer]

No problem @sarajw!

To answer your follow-up:

I'd say it depends on a person's intention behind using the APG. If copy-pasting almost wholesale to create UI components, many are over-engineered on the code side. On the design pattern side, many of the complex patterns aren't needed that often. Take Menu, MenuBar, and MenuButton for example. If I were to draw a Venn diagram with two circles, where one circle represents "over-engineered code" and the other represents "over-engineered UI," these often fall in the center where the circles intersect. From a UI perspective, semantically for the most part, these widgets should only be used when used in an area of a page that behaves like a desktop application. (Think: the menus in your browser window.)

From a code perspective, there is SO MUCH to implement. Listening to keystrokes, manually focusing menu items or other menus, trapping focus in flyouts, tabindex, ARIA states, ARIA properties, labels, styling. Using button and link HTML elements removes the need for a lot of those things. It's far easier to make the same visual thing out of button and link elements, and then assistive tech interactions become simplified too. Announcements are less verbose, and screen reader users, for example, don't have to guess how to interact with the elements because their default interactions include TAB, SHIFT+TAB, ENTER, SPACE, etc. So long as the roles aren't overwritten, assistive tech users are likely to try those keys first before others like arrows.

That was a bit long winded! Does that all make sense? Happy to elaborate or clarify!

[sarajw]

No that's great, thank you! And I agree.

At work we have several things that need rebuilding to become accessible and it's basically the lack of styleable select elements that leads to most of it. Dropdowns with images and subtext inside them, a custom select type thing which I managed to make behave mostly like a normal select (like the roving tabindex and arrow navigation - didn't add the home/end and typing in of list items) - and it's sometimes hard to decide at what level it's "good enough" - honestly stylable selects when they finally come will save so much mess!