At what point during initial page loading do WCAG success criteria apply?

[TestPartners]

In a separate discussion, it was asserted that if there is an author-created visual indication of page loading progress, this constitutes a status message that must be dynamically announced. I have two concerns:

1. Given that the DOM has not been fully built during this time, is it reasonable for WCAG success criteria to apply? If so, when do they start to apply, given that dozens or even hundreds of files may need to be downloaded and many scripts may need to run?
2. Is it even possible to achieve conformance at all times before the DOM has been fully built, given that the author cannot fully predict the order in which files will load and scripts will run.

Note that this question does not relate to single page applications or updating content. It's about a page loading from scratch.

[patrickhlauke]

it was asserted that if there is an author-created visual indication of page loading progress, this constitutes a status message that must be dynamically announced

you clearly didn't read what i wrote...or rather, you missed out the nuance of it

Note that this question does not relate to single page applications or updating content

if a page completes loading to the point where a progress indicator is shown, and it shows the progress being updated (rather than being a generic spinner) ... the initial page load has completed, and scripting/etc is making ajax-y type calls for further content to then update the page, replacing the progress indicator with actual content.

[patrickhlauke]

To my mind, a loading progress indicator that shows less than 100% means that the page is not ready for consumption or interaction

but by having a progress indicator itself, you are communicating to a sighted user that something is happening. why would you not think that same indication should also be communicated to, say, a screen reader user, or somebody with low vision, or ...

if the spinner is only showing an indefinite state (just an animation that spins and spins, doesn't actually refer to specific progress), then that spinner image needs to at least have a text alternative, so an SR user can find that and be made aware that "oh, that page is still loading stuff".

if the progress indicator is actually showing visually what the progress is (e.g. a bar that is slowly filling), then that information also needs to be conveyed to, say, an SR user.

(also, in both cases those spinners/indicators need to have sufficient non-text contrast etc)

not quite sure what's so controversial/difficult to understand here.

[patrickhlauke]

incidentally, i swear this discussion made the rounds years ago already on one of the wcag mailing lists...

[TestPartners]

I agree that it would be good to convey the state of a progress indicator programmatically prior to completion of page loading, but I am sceptical that it can be done reliably in a DOM that is still under construction. And the testability notes still apply. I expect that many automated testing tools won't evaluate the code prior to the load event firing.

[patrickhlauke]

if the progress indicator is being dynamically updated (via scripting) already to show actual progress, the DOM has completed loading (DOMContentLoaded has fired), and the script that updates the progress indicator has completed loading and is actively executing (and ajaxy calls are being made to load extra stuff to swap into the page), so the DOM is not "still under construction" by the browser, but by the author's own scripting...

[yatil]

Yeah, I don’t understand this discussion either. You are responsible once you decide to generate web content. A custom loading indicator is a form of web content; you create web content that says, “Something else is loading”. If the browser loads the page on its terms, then WCAG applies when the web content is loaded, not before.