AccessibleNode Polyfill

[G0dwin]

I know it's very early days yet but I'm wondering if anyone has begun or is interested in beginning work on a polyfil.

[robdodson]

I started to play around with the idea but put it on pause to work on other things.

One thing that really tripped me up is the fact that AOM does not reflect to ARIA, per spec design. After a lot of debate I think we agree that this is probably a good thing. However, for any polyfill to work and actually change an element's semantics, AOM would reflect to ARIA. I'm pretty concerned that if the polyfill catches on folks will begin to expect that behavior...

[G0dwin]

Thanks @robdodson, I think that's a valid concern, also consider me a little ignorant , I haven't done any polyfill work personally.

Do we know of a polyfill that may have had to tackle the same issue? It would be great to be able to see what they did and how much of an impact it had.

I'm having a difficult time coming up with a scenario that would result in a negative impact on the end-user. If we can come up with one that might help to drive a solution. Right now the best story I can come up with is that, if the dev gets used to seeing the aria- attribute added to their widget, they may get confused when their browser begins to support AOM and start submitting bug reports. I'm not seeing that as a good enough reason not to make the AOM available to browsers before official adoption.

[caridy]

I'm pretty concerned that if the polyfill catches on folks will begin to expect that behavior...

The concern is not only CSS and query selectors (which I think it is what @robdodson is referencing above), but also possible mutations on the host, in which case we will have to patch setAttribute/getAttribute/removeAttribute to avoid users to mutation when the accessible node is in the driving seat.

Right now the best story I can come up with is that, if the dev gets used to seeing the aria- attribute added to their widget, they may get confused when their browser begins to support AOM and start submitting bug reports.

It is not that they might get confused, but we might break them if the polyfill is not good enough. Same that I mentioned above:

• css rules based on attributes applied by the polyfill will not longer work after AOM kicks in. (not very common to see css rules using aria-* or role, but still a concern)
• business logic that search for elements via query selectors relying on aria-* or role applied by the polyfill will blow up. (again, not a super big issue, and very unlikely that they use something that they haven't set)
• interaction with setAttribute/getAttribute/removeAttribute, will produce different outcome when AOM is in control (attempting to setting role attribute will be overrule by polyfill, which will skip such mutations in favor of the internal role definition in the accesible node, but will be successfully apply when AOM is implemented), again, not super worry about this one either, but it is something to highlight as a polyfill limitation.

[G0dwin]

The concern is not only CSS and query selectors (which I think it is what @robdodson is referencing above), but also possible mutations on the host, in which case we will have to patch setAttribute/getAttribute/removeAttribute to avoid users to mutation when the accessible node is in the driving seat.

Ah, not sure why that didn't occur to me earlier. Here's what I'm thinking would mitigate the most risk:

1. Document this clearly in the readme
2. Evangelize on Stackoverflow and anywhere else we see people asking questions like: Are there reasons not to use ARIA states and roles as selectors in CSS?
3. Make sure the Polyfill comes out after implementation in Chrome and Firefox

I think #3 would probably have the biggest impact and depending on who's implementing it I wouldn't be surprised if the timeline reached this far out if not longer. Of course we can't assume that all devs will have an up-to-date browser but it should greatly reduce the risk.