E-mail List Archives
Thread: Page loading announcement to screen reader user
Number of posts in this thread: 6 (In chronological order)
From: Sudheer Babu
Date: Tue, Sep 26 2023 4:50AM
Subject: Page loading announcement to screen reader user
No previous message | Next message →
Hello All,
We have a use case where the page reloads on a submission and takes time to
load the page.
When the browser is still taking time to load, is there a way we can
communicate the status to the screen reader users.
We tried updating the page title when the page is loading and used
aria-live regions and role alerts, but JAWS/NVDA is not picking up anything
related to that.
Do we have any working examples that we can refer to and compare the
behaviours of?
Also, on the other hand I feel that screen readers should automatically
pick up the status of the browser loading and communicate that to the user.
I see VoiceOver announces as web busy when the page is still loading but
not JAWS/NVDA.
Thanks in advance!
Sudheer
From: Patrick H. Lauke
Date: Tue, Sep 26 2023 5:23AM
Subject: Re: Page loading announcement to screen reader user
← Previous message | Next message →
On 26/09/2023 11:50, Sudheer Babu wrote:
> We tried updating the page title when the page is loading and used
> aria-live regions and role alerts, but JAWS/NVDA is not picking up anything
> related to that.
How are you using the live region/role? Note that if you're essentially
serving the already populated container with aria-live="..." and
role="alert" (i.e. the container already has the message in it in the
markup sent by the server), SRs won't recognise it as a live region
change and not explicitly announce it. live regions need to first be
"primed" (e.g. the browser/SR need to first see the region one time),
and then any *subsequent* changes in content inside that region will be
announced (i.e. you need to push the actual announcement dynamically via
JS into that container, so that the browser/AT then notice a
mutation/change, which then triggers the announcement).
P
--
Patrick H. Lauke
https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Tue, Sep 26 2023 7:15AM
Subject: Re: Page loading announcement to screen reader user
← Previous message | Next message →
Your best bet is probably to put focus on an image element with the
word "loading..." untl the page is fully loaded.
You can put aria-busy="true" on the <body> element of the page until
it is done loading, then remove it.
That will make the page impossible to explore by a screen reader user
until it is done loading.
On 9/26/23, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 26/09/2023 11:50, Sudheer Babu wrote:
>
>> We tried updating the page title when the page is loading and used
>> aria-live regions and role alerts, but JAWS/NVDA is not picking up
>> anything
>> related to that.
>
> How are you using the live region/role? Note that if you're essentially
> serving the already populated container with aria-live="..." and
> role="alert" (i.e. the container already has the message in it in the
> markup sent by the server), SRs won't recognise it as a live region
> change and not explicitly announce it. live regions need to first be
> "primed" (e.g. the browser/SR need to first see the region one time),
> and then any *subsequent* changes in content inside that region will be
> announced (i.e. you need to push the actual announcement dynamically via
> JS into that container, so that the browser/AT then notice a
> mutation/change, which then triggers the announcement).
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
>
>
> > > > >
--
Work hard. Have fun. Make history.
From: Jeremy Echols
Date: Tue, Sep 26 2023 7:40AM
Subject: Re: Page loading announcement to screen reader user
← Previous message | Next message →
If you're creating a single-page app, the information below is irrelevant and you should ignore me :)
But if you're talking about a traditional website, where the entire page is being requested from the server, there may not be any techniques that will get what you want here. If the form submission takes a long time to process, there may not be a title or body until after that occurs.
In a case like this, it is probably good to have some messaging on the form to let everybody know that the form submission can take some time. You could also have an intermediate page with a very minimal "processing your submission" message. This approach takes some server-side work that will depend on your approach and the backend technology in use, but it gives everybody a nice page that lets them know the form processor is slow, but it is working.
From: Sudheer Babu
Date: Tue, Sep 26 2023 7:57AM
Subject: Re: Page loading announcement to screen reader user
← Previous message | Next message →
Thanks for all the responses! I really appreciate it.
@Echols - thanks for pointing that out, it indeed is a traditional website.
I forgot to mention that in my original email.
We will look into that option you mentioned.
Thanks!
On Tue, Sep 26, 2023 at 7:10 PM Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> If you're creating a single-page app, the information below is irrelevant
> and you should ignore me :)
>
> But if you're talking about a traditional website, where the entire page
> is being requested from the server, there may not be any techniques that
> will get what you want here. If the form submission takes a long time to
> process, there may not be a title or body until after that occurs.
>
> In a case like this, it is probably good to have some messaging on the
> form to let everybody know that the form submission can take some time. You
> could also have an intermediate page with a very minimal "processing your
> submission" message. This approach takes some server-side work that will
> depend on your approach and the backend technology in use, but it gives
> everybody a nice page that lets them know the form processor is slow, but
> it is working.
>
>
From: Ben Moxey
Date: Tue, Sep 26 2023 4:16PM
Subject: Re: Page loading announcement to screen reader user
← Previous message | No next message
This is a multi-part message in MIME format.
------_=_NextPart_37975029-5237-4327-b426-7061b7d07e1f
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Sudheer
The default behaviour for Windows screen readers is that they simply don't =
speak any page content until it's finished loading. Once a user learns thei=
r screen reader and knows to wait, this is effective and there's no need to=
add loading prompts.
Interestingly, Microsoft Edge introduced a loading prompt using UI Automati=
on some years back and many screen reader users find it unnecessary and som=
ewhat patronising. In fact, JAWS introduced the ability to turn these annou=
ncements off, based on user feedback.
All the best.
Ben
=E2=80=8BBen Moxey
Access and Technology Advisor
P 1800 436 364
=20
|
=20
T=20
+61 2 4063 3019
=20
=20
Suite 2, 265 Wharf Road, Newcastle NSW 2300=20
|=20
=20
=20
=20
=E2=80=94
We acknowledge Aboriginal and Torres Strait Islander Peoples as the First P=
eoples and the Traditional Owners and Custodians of the lands and
=E2=80=8B=E2=80=8Bwaters on which we live and work. We pay our respects to =
their Elders, Knowledge Holders and Leaders, past, present and emerging and=
extend
=E2=80=8B=E2=80=8Bthat respect to all Aboriginal and Torres Strait Islander=
Peoples.
=E2=80=94
This e-mail is for the use of the intended recipient(s) only. If you have r=
eceived this e-mail in error, please notify the sender immediately and then
delete it. If you are not the intended recipient, you must not use, disclos=
e or distribute this e-mail without the author=E2=80=99s permission. We hav=
e taken
precautions to minimise the risk of transmitting software viruses, but we =
advise you to carry out your own virus checks on any attachment to this=20
e-mail. We cannot accept liability for any loss or damage caused by softwar=
e viruses.
=20
Guide Dogs Privacy Policy
=20