Add what ARIA module / version a feature is part of
WilcoFiers opened this issue · 6 comments
I was wondering if it would be possible to indicate what version of ARIA a role/prop is supported in. For instance, aria-grabbed and aria-dropeffect are deprecated in ARIA 1.1. Also there are of course things that got introduced in ARIA 1.1 that aren't part of 1.0. It'd be helpful if that information was available in aria-query.
This may also help make this project more future proof. Right now neither the graphics module nor the DPUB module seem to be included, which is something that would be a nice addition.
@WilcoFiers , Oh, yes, that would be good so folks can target the API level they want to support. I'm open to the change!
@WilcoFiers what about just chasing the editor drafts instead of baking in version targeting?
As far as I know most implementors track editor drafts instead of recommendations or working drafts (e.g. JSDOM (source)).
Might be a good idea to get this in before the next (major?) release.
@WilcoFiers & @eps1lon, what do you think about simply chasing the spec, rather than accounting for different versions. AT developers don't account for different spec versions. And all Author work should be conducted against the most recent spec recommendations. No one is building a website and targeting ARIA 1.1 on purpose. They should be targeting ARIA 1.2 and if new updates to this module create downstream errors in linters, well, those should be corrected and not tolerated.
@WilcoFiers & @eps1lon, what do you think about simply chasing the spec, rather than accounting for different versions.
Isn't that tracking the latest editor's draft as I suggested? What do you mean specifically ba "chasing the spec"? How would that look like?
The editor's draft is based on the master branch and is at:
w3c.github.io/ariaI can't tell what branch your rawGitHack URL is referencing, but I wouldn't use it.
The editor's draft is really a draft, and there will be plenty that lands there that does not make it into the spec. We have a stable branch that is closer to a useful latest version. Before cherry-picking a feature into the stable branch from master, we make sure it is implementable. That means we have two browser implementations, browser tests in the ARIA test suite, and supporting guidance in the editor's draft of authoring practices. No one should be using any ARIA feature in any product that doesn't at least meet these requirements. Even then, it can be a bit of a gamble, depending on the feature.
I recommend chasing the stable branch:
w3c/aria@stableHere's that branch in rawGitHack:
raw.githack.com/w3c/aria/stable/index.html
BTW, at this time, as we are approaching CR for 1.2, the stable branch is not getting updated with 1.3 features. Some of those 1.3 features are reasonably stable with 1 browser implementation and strong support voiced from other browsers. So, there could be an argument for following the master branch on github.io. I guess the decision depends on who this project is supporting. I would default to tracking the stable branch and provide a way to query the master branch for those who understand that is what they really want.