modernizing aria.js

[pkra]

Besides https://github.com/w3c/aria-common/issues/92 we have https://github.com/w3c/aria/pull/1833/ (which has fallen of the radar) and now https://github.com/w3c/aria/issues/2073 suggesting changes in aria.js

Looking at the code, I wonder if there's interest in modernizing it a bit (and if there are any restrictions or W3C guidelines on this).

[pkra]

@jnurthen following our discussion, I was looking at ariaChild.js and from a rough comparison, they seem nearly identical. While aria.js seems to do extra stuff, I don't think the relevant if-checks would trigger in a child spec. The rest in differences looks like like two files going out of sync.

Does that sounds about right?

(If so then ideally we could refactor aria.js so that its parts are directly re-used in ariaChild.)

[pkra]

A quick search confirms that ariaChild is really only used in dpub-aria, graphics-aria. So mostly we'd worry about dpub aria.

[pkra]

Another point from the discussion with @jnurthen: re skipindex. A quick search only finds aria.js being used in the aria spec.

The performance benefit of ?fast seems to be ~1s (of 3.5s). I'd suggest to throw it out.

[pkra]

Some thoughts about testability. As James had said, running respec locally is probably the right direction.

Here's what I've got so far

• get a copy of index.html from the aria repo
  • but replace common/ paths to relative paths
• run it through respec - $ npx respec --src index.html --out out.html ("RESPEC RUN")
• grab a copy of the real spec - $ wget https://w3c.github.io/aria/ ("TRUE SPEC")
• diff!

Now the diff has some expected differences

• respec version no
• relative path to css
• only true spec has revision hash (as meta tag and json data)
• different dates in json metadata
• different publications dates (respec run will be current date)
• only true spec has github contributors
• respec run has two warnings about terms not actually referenced (-> file issue on aria)
• only true spec has wg-active and funders (no idea why respec run can't pick up on the files even with changed paths)

So diffing these seems at least initially a feasible step for testing changes to aria.js

Next steps:

• mess around with aria.js to see what happens
• think about testing roleInfo.js

[pkra]

As suggested by James the other day, it should be sufficient to diff a local respec run before & after aria.js changes.

It looks like there will always be differences in the aria-wg-active.html includes -- they fail and seem to get a changing ID in the data-include-id attribute.

[pkra]

It looks like there will always be differences in the aria-wg-active.html includes -- they fail and seem to get a changing ID in the data-include-id attribute.

Oh, and for funders.html as well, of course.

[pkra]

As a way to explore what's going on, I've tried to extract/condense the pieces that generate roleInfo.js. I eventually ran into a roadblock. I couldn't figure out how some props are generated. I think it comes down to roletype's special treatment.

Since this didn't work out, I think I'll try for a naive refactoring next.