I am working on a React eCommerce website. The designs given to me show a flow for checking someone's credit for approval. When the user hits the "Submit Application" button, it takes them to a page that says "Reviewing Application" with a progress bar that takes about 12 seconds to load. When the bar is complete, the text says, "You're Approved" or "Sorry, you are not approved".
The designs then show that the Approved screen stays for a few seconds and then they are redirected to the checkout page. My question is, does this break any accessibility rules? It feels wrong to have a user click a button and then all these actions happen and if they are not paying attention, they could miss it telling them that they are approved.
The client is very keen on having a good accessibility score and wants to make sure that they don't break any rules. If this isn't allowed, can you please add a link to where it is stated more specifically? All I keep getting when Googleing this are examples of how to build a progress bar. TIA!
There two WCAG checkpoints at play here.
The first is dynamic content added to the page. "Reviewing application..." and then "you're approved (or not)". That falls under WCAG 4.1.3 Status Messages. Just make sure the "reviewing application" indicates that the process is running. I'm guessing you have some kind of animation during the 12 seconds or so that it takes to approve or disapprove? You could potentially use aria-busy="true" during the 12 seconds then set it to false when done.
Alternatively, you can use an aria-live region and then update the contents of that region to say "reviewing application..." and then maybe update it every 5 seconds or so to say "still reviewing...". You'll probably need aria-atomic="true" if you update the region with the same text ("still reviewing...") multiple times, otherwise the live region won't think anything changed.
The second checkpoint is WCAG 2.2.1 Timing Adjustable because you are redirecting the user on your own timing, and like you said, they might miss the approval status. Or they might not have had time to read the approval page.
There are 6 ways to fix 2.2.1 as noted in the guideline itself. "Extend" is the most common and you typically see this in "log off" situations where you're about to be logged off due to inactivity but are given a chance to extend your session. The same would be applied to your redirect. You can show the user the approval or denial message and then have a "you will be redirected to the checkout page in XX seconds" message with an option to extend the time limit.
Personally, I think the redirection should be avoided altogether. Just tell the user they've been approved or denied and then have a call to action button (CTA) and let the user navigate to the checkout screen on their own time. Then you avoid the 2.2.1 issue.