E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Geethavani.Shamanna
Date: Fri, Oct 07 2022 4:15AM
Subject: Aria live region
No previous message | Next message →

Hello all,

I am currently testing a search page where aria live region is implemented. On entering a search term and activating the Search button, the page reloads and my screen reader starts reading text from the top of the page, instead of announcing the number of search results. The number of search results as well as the time taken to search are displayed on the page, but this is not announced by the screen reader.

Can this be resolved by using the status role and by setting aria-atomic attribute to false? How can we ensure that the screen reader announces only the updated status message?

Many thanks.
Geetha

From: Steve Green
Date: Fri, Oct 07 2022 4:30AM
Subject: Re: Aria live region
← Previous message | Next message →

You should not be using a live region if the page reloads. Your screen reader is doing what it's designed to do when a new page loads, and there's nothing you can do to stop it. Indeed, you shouldn't do anything to stop it.

Steve Green
Managing Director
Test Partners Ltd

From: Mark Magennis
Date: Fri, Oct 07 2022 4:54AM
Subject: Re: Aria live region
← Previous message | Next message →

Hi Geethavani,

In a situation like this, some screen reader users prefer focus to be set to the start of the search results list because you can almost guarantee that's where they want to start reading. Specifically, for focus to go to the statement of the number of results, e.g. "showing 1,832 results for xxx. When focus is set to this text, the screen reader will read it automatically (the JAWS bug preventing this is fixed) and there will be no need for a live region to announce the results statement.

I said "some screen reader users prefer", but how many is "some" is open to debate and not all screen reader users or accessibility practitioners would agree with this approach. Some would prefer, as Steve says, for the screen reader to be left to do what it naturally does. My interactions with screen reader users makes me inclined towards the "move focus" approach, but I know Steve also has a lot of insight into what users want and need, having done a lot of user testing with real users.

Also note, if there is no actual page load (e.g. you have a single page application) then you are going to have to place focus somewhere anyway. This could be top of page, results statement, or anywhere else you think is appropriate.

Mark

From: Geethavani.Shamanna
Date: Fri, Oct 07 2022 5:38AM
Subject: Re: Aria live region
← Previous message | Next message →

Hi Mark,

Many thanks for your response.

When the search results are updated, the message 'Your search yielded 15 results' is displayed on the screen. This message is not automatically read out by the screen reader. Rather than moving focus to this message, is it not better practice to get the screen reader to read out this status message (SC 4.1.3)?

Geetha

From: David Farough
Date: Fri, Oct 07 2022 6:37AM
Subject: Re: Aria live region
← Previous message | Next message →

An alternative idea might be to include a skip to results at top of page. This way the user can choose whether or not to go there.
Incidentally does the search edit field automatically get focus after page load?
If so, then the skip link doesn't make sense.

From: Steve Green
Date: Fri, Oct 07 2022 6:43AM
Subject: Re: Aria live region
← Previous message | Next message →

It is not a status message. The first part of the WCAG definition of a status message says that a status message is a "change in content that is not a change of context". A change of context occurs when the page loads, so the text cannot be a status message. SC 4.1.3 therefore does not apply.

https://www.w3.org/WAI/WCAG21/Understanding/status-messages#dfn-status-message

Steve

From: Geethavani.Shamanna
Date: Fri, Oct 07 2022 7:12AM
Subject: Re: Aria live region
← Previous message | Next message →

That is very interesting, thanks Steve.

So in this instance, if we need to make screen reader users aware of the number of search results displayed on the page without them having to scroll down to view the message, would the best option be to move the focus to that message?

Geetha

From: Steve Green
Date: Fri, Oct 07 2022 7:23AM
Subject: Re: Aria live region
← Previous message | Next message →

I would question whether you need to make screen reader users aware of the number of search results. It is not the normal or expected behaviour on any website I can think of, except when the results are updated without a page reload, in which case the text is a status message and must meet SC 4.1.3.

Unless there is evidence to the contrary, I always advise that you don't change standard behaviours that users expect. By "evidence", I mean user research, not just something that a product owner dreamed up. Alternatively, build prototypes of both versions and conduct user testing so see which performs best.

Steve

From: Mark Magennis
Date: Fri, Oct 07 2022 9:12AM
Subject: Re: Aria live region
← Previous message | Next message →

The point of moving focus to this message is:

1. It will cause the screen reader to read it.
2. It presumably comes immediately before the search results listing which is where the user almost certainly wants to be. In fact, it may be the heading of the results listing.

From: Steve Green
Date: Fri, Oct 07 2022 9:21AM
Subject: Re: Aria live region
← Previous message | Next message →

When the page loads, screen readers will typically announce the number of headings and links, then start reading the page in "Say All" mode until the user stops it. If you move the focus while this is happening, it's anyone's guess what the screen reader will do. The expected behaviour under such circumstances is not defined anywhere and it may not even be the same each time.

Steve

From: Alan Zaitchik
Date: Fri, Oct 07 2022 9:26AM
Subject: Re: Aria live region
← Previous message | Next message →

Geetha,
Maybe I missed something, but if, as you say, the number of results and processing time are displayed on the results page, and if the screen reader is, as you say, reading out the entire results page on load, why would it not read out the number of results and processing time as well, in exactly the correct order as the visual presentation, if you do nothing at all to change the default SR behavior? If the placement of the message concerning number of results is inconvenient for SR users (maybe at the bottom?) then it probably is inconvenient for visual users— can't you just move it up on the page for all users?
A

From: glen walker
Date: Fri, Oct 07 2022 1:03PM
Subject: Re: Aria live region
← Previous message | No next message

Alan, I suspect the search results *are* read as part of the "say all" mode
but it would be buried by all the other elements that are read and could be
easily missed. Even if the search results are near the top of the page, if
you have a lengthy main menu or header information, there could be a lot of
stuff read before it gets to the search results.

On Fri, Oct 7, 2022 at 9:26 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = > wrote:

>
> Maybe I missed something, but if, as you say, the number of results and
> processing time are displayed on the results page, and if the screen reader
> is, as you say, reading out the entire results page on load, why would it
> not read out the number of results and processing time as well, in exactly
> the correct order as the visual presentation, if you do nothing at all to
> change the default SR behavior? If the placement of the message concerning
> number of results is inconvenient for SR users (maybe at the bottom?) then
> it probably is inconvenient for visual users— can't you just move it up on
> the page for all users?
>
>