E-mail List Archives

Search E-mail List Archives for

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

From: Sumit Patel
Date: Sun, Jun 25 2023 1:44PM
Subject: Alert on search results update
No previous message | Next message →

Hai all,

I have a search field in my website. Here, as I am typing any
character , the results will updating . As I type each character , the
results will be changing. We don't have any search button to perform
the search. Just type the keywords, below results would be loading .
But, I guess it would be difficult for screen reader user to
understand the same as there is neither any alert to inform them that
results have been loaded below nor any instruction is given to pre
indicate the user that results would be loading as they type character
.

What would be the right way to fix this ?

I feel , if we give any instant alert , it would be oververboes as the
results would be changing as they type each characters. I thought
giving any offscreen instruction and associating it with the field
using aria-describedby would help screen reader users . , for example
: resulkts gets updated below as you type anything here

Please suggest me is it the right approach or do we have anything better ?

Regards,
Sumit.

From: glen walker
Date: Sun, Jun 25 2023 2:33PM
Subject: Re: Alert on search results update
← Previous message | Next message →

This is mostly a UX question, although the part about having instructions
to let the user know that results will be updated immediately could satisfy
WCAG 3.2.2. Keep in mind that those instructions could be beneficial to
many users, not just screen reader users, so consider having them visible
rather than offscreen.

Having an aria-live region to announce the result changes could become
quite verbose, as you noted, although if you use a "polite" region and you
update the text in rapid succession, often times the earlier updates get
tossed and you only hear the last one, but I suspect that varies by
platform and screen reader.

From: Yeti
Date: Sun, Jun 25 2023 10:27PM
Subject: Re: Alert on search results update
← Previous message | Next message →

Hello Sumit and All,

The worst solution is when the screen reader doesn't say anything!
For this reason too much talking is only the second worst solution.

Nevertheless, you could do the following:

Similar to input fields, where the number of entered or remaining characters is displayed, a delayed output can be the solution.

Implement an element that shows the number of results when there are many results and the results themselves or the first result when there are few results.

With a call

var DelayedLiveRegion = new LiveregionHandler("DelayedLiveRegion", 500);

you may initialize an object of the JS LiveregionHandler class attached below, which then takes care of such a delayed output. And this is equally delayed for sighted and blind people.
A delay of 250 to 500 milliseconds should be a good compromise.

Anytime, your Results change, You may call

DelayedLiveRegion.Say(newElementcontent);

Blind users are not more stupid than sighted users, their intelligence often just gets less information to work with.

By the way: It's not uncommon for blind users to hit enter when they think they've reached their goal. Much like how sighted users instinctively click with the mouse on something that looks interesting.

Implementing the search field in a way that the first search result is focused when you press Enter should therefore be considered.

Ad Astra

Yeti

/* *** Begin Liveregion/Autotext
This class transforms the passed element into an area whose content is automatically output via the BLP when it changes.
Time-delayed outputs can also be made, which are useful, for example, for the number of characters that have already been entered.
Parameters of constrruktor:
- aOutputElementID:
Unique identifier of the element to be used for the output. Elements such as P, DIV or SPAN are suitable.
Passing an invalid identifier causes the constructor to fail.
The assignment to OutputElement.innerText only takes place when required.
- aDelayMS:
Waiting time in milliseconds that should elapse between setting the value and updating the content / speaking the same through the BLP.
The handoff is fault-tolerant; If in doubt, 0 (no delay) is assumed.
Parameters of the Say method
- aText:
Text to be output.
The repeated consecutive output of the same text is suppressed by the object.
*/
class LiveregionHandler {
constructor(aOutputElementID, aDelayMS) {
this.OutputElement = document.getElementById(aOutputElementID);
this.OutputElement.ariaLive = 'polite';
this.OldText = "";
this.NewText = "";
this.DelayMS = 0;
if (Number.isInteger(aDelayMS))
this.DelayMS = aDelayMS;
if (this.DelayMS < 0)
this.DelayMS = 0;
this.Ticker = 0;
}
Say(aText) {
this.NewText = aText;
if (this.NewText == this.OldText)
return;
if (this.DelayMS < 1) {
this._SayNow();
return;
}
this.SayTime = this.DelayMS + new Date().getTime();
if (0 == this.Ticker)
this.Ticker = setInterval(this._SayLater, 100, this);
}
_SayNow() {
this.OutputElement.innerText = this.NewText;
this.OldText = this.NewText;
}
_SayLater(aLiveregion) {
if (new Date().getTime() < aLiveregion.SayTime)
return;
clearInterval(aLiveregion.Ticker);
aLiveregion.Ticker = 0;
aLiveregion._SayNow();
}
}
/* *** End Liveregion/Autotext */ /* *** Begin Liveregion/Autotext
This class transforms the passed element into an area whose content is automatically output via the BLP when it changes.
Time-delayed outputs can also be made, which are useful, for example, for the number of characters that have already been entered.
Parameters of constrruktor:
- aOutputElementID:
Unique identifier of the element to be used for the output. Elements such as P, DIV or SPAN are suitable.
Passing an invalid identifier causes the constructor to fail.
The assignment to OutputElement.innerText only takes place when required.
- aDelayMS:
Waiting time in milliseconds that should elapse between setting the value and updating the content / speaking the same through the BLP.
The handoff is fault-tolerant; If in doubt, 0 (no delay) is assumed.
Parameters of the Say method
- aText:
Text to be output.
The repeated consecutive output of the same text is suppressed by the object.
*/
class LiveregionHandler {
constructor(aOutputElementID, aDelayMS) {
this.OutputElement = document.getElementById(aOutputElementID);
this.OutputElement.ariaLive = 'polite';
this.OldText = "";
this.NewText = "";
this.DelayMS = 0;
if (Number.isInteger(aDelayMS))
this.DelayMS = aDelayMS;
if (this.DelayMS < 0)
this.DelayMS = 0;
this.Ticker = 0;
}
Say(aText) {
this.NewText = aText;
if (this.NewText == this.OldText)
return;
if (this.DelayMS < 1) {
this._SayNow();
return;
}
this.SayTime = this.DelayMS + new Date().getTime();
if (0 == this.Ticker)
this.Ticker = setInterval(this._SayLater, 100, this);
}
_SayNow() {
this.OutputElement.innerText = this.NewText;
this.OldText = this.NewText;
}
_SayLater(aLiveregion) {
if (new Date().getTime() < aLiveregion.SayTime)
return;
clearInterval(aLiveregion.Ticker);
aLiveregion.Ticker = 0;
aLiveregion._SayNow();
}
}
/* *** End Liveregion/Autotext */ /* *** Begin Liveregion/Autotext
This class transforms the passed element into an area whose content is automatically output via the BLP when it changes.
Time-delayed outputs can also be made, which are useful, for example, for the number of characters that have already been entered.
Parameters of constrruktor:
- aOutputElementID:
Unique identifier of the element to be used for the output. Elements such as P, DIV or SPAN are suitable.
Passing an invalid identifier causes the constructor to fail.
The assignment to OutputElement.innerText only takes place when required.
- aDelayMS:
Waiting time in milliseconds that should elapse between setting the value and updating the content / speaking the same through the BLP.
The handoff is fault-tolerant; If in doubt, 0 (no delay) is assumed.
Parameters of the Say method
- aText:
Text to be output.
The repeated consecutive output of the same text is suppressed by the object.
*/
class LiveregionHandler {
constructor(aOutputElementID, aDelayMS) {
this.OutputElement = document.getElementById(aOutputElementID);
this.OutputElement.ariaLive = 'polite';
this.OldText = "";
this.NewText = "";
this.DelayMS = 0;
if (Number.isInteger(aDelayMS))
this.DelayMS = aDelayMS;
if (this.DelayMS < 0)
this.DelayMS = 0;
this.Ticker = 0;
}
Say(aText) {
this.NewText = aText;
if (this.NewText == this.OldText)
return;
if (this.DelayMS < 1) {
this._SayNow();
return;
}
this.SayTime = this.DelayMS + new Date().getTime();
if (0 == this.Ticker)
this.Ticker = setInterval(this._SayLater, 100, this);
}
_SayNow() {
this.OutputElement.innerText = this.NewText;
this.OldText = this.NewText;
}
_SayLater(aLiveregion) {
if (new Date().getTime() < aLiveregion.SayTime)
return;
clearInterval(aLiveregion.Ticker);
aLiveregion.Ticker = 0;
aLiveregion._SayNow();
}
}
/* *** End Liveregion/Autotext */

From: tim.harshbarger
Date: Mon, Jun 26 2023 5:37AM
Subject: Re: Alert on search results update
← Previous message | No next message

This is just my own opinion about this, but hopefully it might help at least a little bit.

"Is the screen reader speaking too much information" very often tends to be a usability question rather than just an accessibility question. if you are uncertain how to proceed in making this accessible, I suggest setting aside any usability questions and just ffocusing on the accessibility questions alone. You can address the usability questions later.

One thing I will try to do is list out what might be the fundamental or basic information that is conveyed visually. What I am trying to figure out is what information is essential fto allow someone to interact with this widget successfully.

here are some of the things I find on my list.

* When the user starts typing, the widget visually conveys that typing will display results.
* The visual appearance of the list gives the user some general idea of how many results there might be--maybe not the exact number but whether there is none, 3, or more than 10 or 20.
* The user has some idea of how to select the results or to make progress with the widget in getting a desired result.

For me, that means some of the basic accessibility questions I need to answer are.

* How will the screen reader user know typing in the field displays results?
* How will the screen reader user know what keyboard interactions to use to select a result.
* How wil the screen reader get a general idea of how many results there currently are. particularly whether there are no results, a single result, or a lot of results.
* How will the screen reader know that using this widget successfully requires selecting on one of these options and they won't have another way to complete this step.

If you are not sure if this is everything or maybe even includes things that are unnecessary, ask yourself the question "If this information were visually missing from the interface, would it negatively impact visual users?"

After this, I would look at what HTML and ARIA features might help answer the question. I would also look at any additional accessibility techniques.

One additional technique I might use in this situation if I ended up using aria-live regions is to delay the speaking of messages. This is a technique I prefer to use if messages are being generated in response to keyboard entry.

The idea is that you use setTimeout to schedule the message to be spoken slightly later. However, if the user continues to press keys that alter what information is being provided, I then clear the timeout for that old message so it is never spoken. The advantage of this technique which is based on debouncing means that the user isn't flooded with messages. I typically set the timeout for less than a second--I try to just make it long enough so that the pause likely indicates the user has stopped typing for the moment so they can figure out what to do next but not so long that they move on without hearing the message.

After you answer the key accessibility questions, you can then go back and try to answer any usability questions. The benefit of doing this is that any answers to usability questions will be a bit easier to answer because you know what the accessibility requirements are.

Additionally when you get into answering usability questions, keep in mind that one of the best ways to answer these questions is with user testing. Some times you do have to rely on expert opinions which is ok, but just realize that as expert as the opinions are they are opinions.

Again there is nothing wrong with relying on expert opinions--especially if user testing is not possible. However, also realize that even those of us who are experts learn new things constantly whenever we get to participate in user testing.

Thanks!
Tim