Usability issues

[Tobias Bengfort]

I am the author of aria-api, a library to provide programmatic access to ARIA-related information from JavaScript. For example, my library allows you to call something like aria.querySelectorAll(element, 'landmark'). In order to implement this, I need access to a lot of the information that is available from this project. However, I chose not to use aria-query for now.

I would like to explain why I decided that way and maybe start a discussion on how aria-query could become more useful for developers in general. I understand that a lot of these points will be highly subjective, but still they may be interesting feedback for you.

• I personally dislike complicated build setups, so I do not use ES6 in many of my projects yet. Is it possible to include a ES5 build in the npm package?
• I do not do valdation in my project, so I do not need requiredProps and the like. Using aria-query would increase the bundle file size for no reason. As far as I understand, tree shaking would not help much either. Is it possible to provide different builds for different use cases?
• I need to be able to get the (implicit) role of an HTML element. The concept of "related concepts" seems not to be sufficient to get the implicit role. Is it possible to include information required to get the implicit role of an HTML element?
• I need to know whether an HTML element has a specific role. Note that roles are hierarchical, so an element can have more than one role. The information for that is available, but the datastructures do not make it particularily easy to get to it. Is it possible to provide simple access to all super-roles, e.g. superClassRecursive?

[Alex Abenoja]

• Looking at the latest release, the only es6 feature not compiled down to es5 is Map. Should be a fairly easy update, unless there is something else in the release that I missed. The flip side is whether or not such support is desirable. According to the browser support chart on MDN only IE has issues with Map. An argument could be made to switch to babel-preset-env and target both node and IE11 and be done with it.
• Why complicate the release process when everything is right there in the release package? require('aria-query/path/to/desired/file') is still viable. Tree shaking just simply makes it so we can write more concise code without having to write noisy require paths. Need only aria.dom? require('aria-query/lib/domMap'). While part of me would like to see a tree shaking friendly version of the release such support is way down my list when users of this package are through the lint plugin.

For the last two bullet points, maybe it might be better to submit a couple of PRs to add that support. To answer both your questions in those points it is possible, and I think submitting your own PRs that add that support will give the other collaborators and project owners a better understanding of what you need and how to incorporate it while giving your own opinions on the implementation a little more weight.

[Tobias Bengfort]

Sorry for my late reply.

I thought about your comments and tried to replace my custom code by aria-query again. It kinda works, but the size of my library triples (after compression, x7 before compression). I think this is just not a good tradeof.

A possible solution would be to convert all role definitions to JSON and include a build script that generates a JS library from that. In that build script you could select which fields you wanted to include. Converting the underlying data to JSON would have the side effect of making it useable from non-javascript code.

I would actually be up for helping with that change. But I guess this is just not what this project is about. There is nothing wrong with that, it just means that this project is not what I need.

Thanks for taking the time to answer my questions!

[Alex Abenoja]

Sounds like a tooling issue, IMO. Here's a simple example of tree shaking with rollup. Looking at the entry.js and bundle.js we remove the extra "fat" that is causing the bloated bundle sizes. Looking at your project it should be easy to utilize rollup with your existing browserify setup using rollupify. This would certainly be better than constantly trying to maintain a fork of aria-query. Although I still question how you ended up with a large bundle size pointed directly to the files you need. It sounds more like you were still importing the entirety of aria-query.

[Tobias Bengfort]

I do not information on all roles, so just importing ariaPropsMap is not an option. My point is that I do not need all information on all roles.