[aria] Request: Provide the ARIA “Characteristics” data as JSON or in some other machine-readable form

[sideshowbarker]

If the ARIA WG were to provide the data from the per-role Characteristics tables in the ARIA spec in JSON or in some other machine-readable form, it could be generally useful.

As a concrete example, https://github.com/LadybirdBrowser/ladybird/blob/master/Libraries/LibWeb/ARIA/AriaRoles.json is JSON file that we maintain in the code for the Ladybird browser engine. And it’s essentially just a machine-readable representation of what’s in the spec.

For Ladybird, we use that to enable a feature for web developers in our browser devtools. When a web developer is using our devtools to inspect a particular element, that feature enables them to see — at point of use — which ARIA states and properties are allowed on that element (based on that element’s assigned or computed ARIA role), whether its Name From calculation is based on, etc.

That feature seems pretty useful and helpful, so it’s imaginable that other browser project might want to implement a similar feature in their devtools — in which case they’d also need to have the data in some machine-readable format.

And if/when that ever might happen, then we’d have a situation in which either N different browser projects were each maintaining their own data for it, or else at the Ladybird project, we’d be maintaining our thing, and other browser project would be grabbing it and using it.

Neither of those seems ideal. It’d instead seem better if the ARIA WG itself could provide the data upstream in some machine-readable form that all browser projects (and other apps/tools that could find use for it) could grab and use — and that’d be canonical and authoritative because we all could have the confidence it was coming from the ARIA WG itself, and being reviewed and maintained by the WG itself.

For that https://github.com/LadybirdBrowser/ladybird/blob/master/Libraries/LibWeb/ARIA/AriaRoles.json might merit consideration by the WG as at least a starting point.

As someone who’s currently been working on the related stuff in Ladybird, I can say I think we’d have no problem with the WG adopting that and then making any changes y’all want to the (implicit) schema for that (adding additional fields, changing existing ones, whatever).

Regardless, I can say that I would happily rewrite the related Ladybird code to change it to consuming the data in whatever form the WG would end up providing it in upstream.

[pkra]

While it is out of date and only covers ARIA itself, could https://github.com/w3c/aria/blob/main/common/script/roleInfo.js be helpful?

The editors group has already been discussing a better solution to keep that file updated (related to #2408); while child specs depend on this file, I don't see why it couldn't be tweaked for more uses case (e.g., the pen I built for #1222 way back when).

[sideshowbarker]

While it is out of date and only covers ARIA itself, could main/common/script/roleInfo.js be helpful?

Thanks that does look like it’s the kind of thing I had in mind.

The editors group has already been discussing a better solution to keep that file updated (related to #2408); while child specs depend on this file, I don't see why it couldn't be tweaked for more uses case (e.g., the pen I built for #1222 way back when).

Yeah, it does seem imaginable that you could end up with something that’s useful both for the editors’ own purposes in maintaining the spec, while also being repurposable for use cases like Ladybird’s