aria-practices
aktenkoffer
| aria-practices | aktenkoffer | |
|---|---|---|
| 4 | 2 | |
| 1,160 | 2 | |
| 1.0% | - | |
| 8.0 | 0.0 | |
| about 11 hours ago | about 1 year ago | |
| HTML | Ruby | |
| GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
aria-practices
-
Here are the 10 projects I am contributing to over the next 6 months. Share yours
W3C Aria Practices
-
React Arborist – A full-featured tree component for React
I should apologize off-the-bat for not digging in too deeply, but how does this handle keyboard and screenreader accessibility?
W3C has some in-depth list of expected keyboard interactions, though I'm not sure how complete they are:
https://w3c.github.io/aria-practices/#TreeView
https://w3c.github.io/aria-practices/examples/treeview/treev...
I ask because I've tried to implement a [TreeGrid](https://w3c.github.io/aria-practices/#treegrid) myself before and... it's a lot of work. I'd love an accessible, keyboard-friendly React tree :).
-
Custom JavaScript controls can't capture the nuance of form fields (2021)
Yep I totally agree with this.
There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).
I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?
-
4 takeaways from axe-con 2021
The ARIA practices GitHub is a good resource to see where certain patterns fall short.
aktenkoffer
- What Are Your Most Used Self Hosted Applications?
-
Custom JavaScript controls can't capture the nuance of form fields (2021)
I was wondering about this, too.
> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient.
For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I created a custom select that allows for filtering/searching of contacts when choosing sender/recipient for a given document. I don't use browser's select because:
1. There's a lot of contacts one has, and the list will become very long, a usecase for which select seems not to be the best fit, i.e. I don't want to load all the options always.