aria-practices
standards-support
| aria-practices | standards-support | |
|---|---|---|
| 4 | 1 | |
| 1,161 | 105 | |
| 1.1% | 1.0% | |
| 8.0 | 7.4 | |
| 1 day ago | about 1 month ago | |
| HTML | HTML | |
| GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
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.
standards-support
-
Jaws Screen Reader is not able read Text Area Html Mark up in LW
As I said, this is intended behavior. See for instance this issueon Github. Any workarounds are likely to just cause more trouble down the line, so I would not worry too much about this.
What are some alternatives?
react-arborist - The complete tree view component for React
ingo-steinke.de - www.ingo-steinke.com is a portfolio website about web developer Ingo Steinke. The site is built using HTML, CSS, JavaScript, and 11ty (eleventy). English version: www.ingo-steinke.com
react-table-library - :bento: React Table Library
itext-pdfhtml-java - pdfHTML is an iText add-on for Java that allows you to easily convert HTML and CSS into standards compliant PDFs that are accessible, searchable and usable for indexing.
bootstrap-select - :rocket: The jQuery plugin that brings select elements into the 21st century with intuitive multiselection, searching, and much more.
monaco-tree - Curiosity hacks with Monaco Editor's tree component
aktenkoffer - 💼 Personal document management made easy.
axe-core - Accessibility engine for automated Web UI testing