WebAIM - Web Accessibility In Mind

E-mail List Archives

What does "life-cycle" mean in the ARIA 1.2 specification?

for

From: Steve Green
Date: Aug 23, 2021 6:45PM

This question starts with a rather obscure reference in the ARIA specification, but it turns out to have a much more general implication. Sorry this is a bit long, but your thoughts would be very welcome.

We are testing a website that uses JavaScript to add some ARIA attributes to an element during page loading. These attributes are not present in the initial source code.

The final state of the DOM is ok, but an automated tool (and the HTML Nu Validator) are complaining that the initial state of the DOM is invalid (which indeed it is, if that matters).

The ARIA spec at https://www.w3.org/TR/wai-aria-1.2/#usage makes a statement about page life-cycle that appears to be relevant:

"Authors need to associate elements in the document to a WAI-ARIA role and the appropriate states and properties (aria-* attributes) during its life-cycle, unless the elements already have the appropriate implicit WAI-ARIA semantics for states and properties"

This seems to be saying that the ARIA role, states and properties can change, but they must be valid at all times during the life-cycle. The problem is that the specification doesn't define "life-cycle", in particular when it starts.

The automated tool and the HTML validator are assuming the life-cycle starts when the initial source code is loaded into the DOM.

An alternative interpretation is that the life-cycle starts when the DOM has finished rendering. No one expects the DOM to be in a meaningful state before that, not least because you have very little control over the order in which the DOM is modified. I don't believe that the HTML, CSS and JavaScript specifications require any level of validity while the DOM is rendering, so I don't understand why the ARIA should - it seems pretty pointless if all the surrounding code is incomplete or invalid.

If the life-cycle starts when the initial source code is loaded into the DOM, then we need to validate both the initial source code and the final rendered DOM. As it happens, we have always done this during our manual testing. However, I am guessing that automated tools only test it once, in which case they will potentially fail to report issues they are perfectly capable of finding. Worse still, you would need to run your own tests to find out when your tool of choice is doing the test.

Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
<EMAIL REMOVED>
www.testpartners.co.uk
 
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2