WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Combobox: what should the Esc key do?

for

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

From: Lynn Holdsworth
Date: Tue, Apr 10 2018 7:50AM
Subject: Combobox: what should the Esc key do?
No previous message | Next message →

Hi all,

I'm creating a combobox widget, and wonder what's the most appropriate
behaviour for the Esc key when using a screenreader?

On its own, when the Esc key is pressed the textbox is left with the
value the user typed into it, and the listbox that dropped down below
it disappears.

When using JAWS or NVDA, the screenreader grabs the Esc key and
interprets it as an instruction to leave forms mode. Pressing Esc a
second time triggers the combobox's standard behaviour. I don't feel
that this is intuitive for the user.

Would it be better if this could work the other way round: pressing
Esc the first time hides the dropdown list, and a second press takes
the screenreader out of forms mode? I think I could achieve this by
adding an application role to the wrapping div and then removing it
once the Esc key has been pressed.

I'd really appreciate your thoughts on this.

Cheers, Lynn

From: Birkir R. Gunnarsson
Date: Tue, Apr 10 2018 8:08AM
Subject: Re: Combobox: what should the Esc key do?
← Previous message | Next message →

Lynn

Weird, I thought the screen reader did not intercept the escape key in
forms/application mode if the page does something with it. A screen
reader should be in forms mode when user navigates inside an input
field or in an element with role="combobox" or "listbox".
Now that you mention it, I think this is an NVDA bug. I don't thin
jaws exhibits this behavior.
Well, easy to find out.




On 4/10/18, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> I'm creating a combobox widget, and wonder what's the most appropriate
> behaviour for the Esc key when using a screenreader?
>
> On its own, when the Esc key is pressed the textbox is left with the
> value the user typed into it, and the listbox that dropped down below
> it disappears.
>
> When using JAWS or NVDA, the screenreader grabs the Esc key and
> interprets it as an instruction to leave forms mode. Pressing Esc a
> second time triggers the combobox's standard behaviour. I don't feel
> that this is intuitive for the user.
>
> Would it be better if this could work the other way round: pressing
> Esc the first time hides the dropdown list, and a second press takes
> the screenreader out of forms mode? I think I could achieve this by
> adding an application role to the wrapping div and then removing it
> once the Esc key has been pressed.
>
> I'd really appreciate your thoughts on this.
>
> Cheers, Lynn
> > > > >


--
Work hard. Have fun. Make history.

From: mhysnm1964@gmail.com
Date: Tue, Apr 10 2018 10:59PM
Subject: Re: Combobox: what should the Esc key do?
← Previous message | Next message →

Jaws, passes the escape key through. AS it closes the dropdown after being pressed. Need to check NVDA as I cannot recall how it behaves.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, 11 April 2018 12:09 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Combobox: what should the Esc key do?

Lynn

Weird, I thought the screen reader did not intercept the escape key in forms/application mode if the page does something with it. A screen reader should be in forms mode when user navigates inside an input field or in an element with role="combobox" or "listbox".
Now that you mention it, I think this is an NVDA bug. I don't thin jaws exhibits this behavior.
Well, easy to find out.




On 4/10/18, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> I'm creating a combobox widget, and wonder what's the most appropriate
> behaviour for the Esc key when using a screenreader?
>
> On its own, when the Esc key is pressed the textbox is left with the
> value the user typed into it, and the listbox that dropped down below
> it disappears.
>
> When using JAWS or NVDA, the screenreader grabs the Esc key and
> interprets it as an instruction to leave forms mode. Pressing Esc a
> second time triggers the combobox's standard behaviour. I don't feel
> that this is intuitive for the user.
>
> Would it be better if this could work the other way round: pressing
> Esc the first time hides the dropdown list, and a second press takes
> the screenreader out of forms mode? I think I could achieve this by
> adding an application role to the wrapping div and then removing it
> once the Esc key has been pressed.
>
> I'd really appreciate your thoughts on this.
>
> Cheers, Lynn
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

From: Isabel Holdsworth
Date: Fri, Apr 13 2018 2:49AM
Subject: Re: Combobox: what should the Esc key do?
← Previous message | Next message →

Sure enough the Esc key works as expected in native HTML5 comboboxes,
but it doesn't seem to work in composite ARIA-enabled widgets. I
wonder if there's some way to force the ESC key to be passed to the
browser first before it's grabbed by the AT? I can build a hack where
the container has a role of "application" until the Esc key is
pressed, but in that scenario JAWS says "application" a lot when the
user interacts with the widget.

I'd much rather use a native implementation, but it's just not
possible to get enough info from it to let users know how many results
are available as they type. Very frustrating.

On 11/04/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Jaws, passes the escape key through. AS it closes the dropdown after being
> pressed. Need to check NVDA as I cannot recall how it behaves.
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Wednesday, 11 April 2018 12:09 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Combobox: what should the Esc key do?
>
> Lynn
>
> Weird, I thought the screen reader did not intercept the escape key in
> forms/application mode if the page does something with it. A screen reader
> should be in forms mode when user navigates inside an input field or in an
> element with role="combobox" or "listbox".
> Now that you mention it, I think this is an NVDA bug. I don't thin jaws
> exhibits this behavior.
> Well, easy to find out.
>
>
>
>
> On 4/10/18, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi all,
>>
>> I'm creating a combobox widget, and wonder what's the most appropriate
>> behaviour for the Esc key when using a screenreader?
>>
>> On its own, when the Esc key is pressed the textbox is left with the
>> value the user typed into it, and the listbox that dropped down below
>> it disappears.
>>
>> When using JAWS or NVDA, the screenreader grabs the Esc key and
>> interprets it as an instruction to leave forms mode. Pressing Esc a
>> second time triggers the combobox's standard behaviour. I don't feel
>> that this is intuitive for the user.
>>
>> Would it be better if this could work the other way round: pressing
>> Esc the first time hides the dropdown list, and a second press takes
>> the screenreader out of forms mode? I think I could achieve this by
>> adding an application role to the wrapping div and then removing it
>> once the Esc key has been pressed.
>>
>> I'd really appreciate your thoughts on this.
>>
>> Cheers, Lynn
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
> > > > >

From: Tim Harshbarger
Date: Fri, Apr 13 2018 7:01AM
Subject: Re: [EXTERNAL]Combobox: what should the Esc key do?
← Previous message | Next message →

Depending on what you are trying to do, you might think about using an aria live region to convey information to screen reader users.

For example, if the person is typing information into a textfield and results that match that text are being put in the combobox, you could use an aria live region to tell them how many options are now displayed inside the box.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Isabel Holdsworth
Sent: Friday, April 13, 2018 3:49 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] Combobox: what should the Esc key do?

Sure enough the Esc key works as expected in native HTML5 comboboxes,
but it doesn't seem to work in composite ARIA-enabled widgets. I
wonder if there's some way to force the ESC key to be passed to the
browser first before it's grabbed by the AT? I can build a hack where
the container has a role of "application" until the Esc key is
pressed, but in that scenario JAWS says "application" a lot when the
user interacts with the widget.

I'd much rather use a native implementation, but it's just not
possible to get enough info from it to let users know how many results
are available as they type. Very frustrating.

On 11/04/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Jaws, passes the escape key through. AS it closes the dropdown after being
> pressed. Need to check NVDA as I cannot recall how it behaves.
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Birkir R. Gunnarsson
> Sent: Wednesday, 11 April 2018 12:09 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Combobox: what should the Esc key do?
>
> Lynn
>
> Weird, I thought the screen reader did not intercept the escape key in
> forms/application mode if the page does something with it. A screen reader
> should be in forms mode when user navigates inside an input field or in an
> element with role="combobox" or "listbox".
> Now that you mention it, I think this is an NVDA bug. I don't thin jaws
> exhibits this behavior.
> Well, easy to find out.
>
>
>
>
> On 4/10/18, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi all,
>>
>> I'm creating a combobox widget, and wonder what's the most appropriate
>> behaviour for the Esc key when using a screenreader?
>>
>> On its own, when the Esc key is pressed the textbox is left with the
>> value the user typed into it, and the listbox that dropped down below
>> it disappears.
>>
>> When using JAWS or NVDA, the screenreader grabs the Esc key and
>> interprets it as an instruction to leave forms mode. Pressing Esc a
>> second time triggers the combobox's standard behaviour. I don't feel
>> that this is intuitive for the user.
>>
>> Would it be better if this could work the other way round: pressing
>> Esc the first time hides the dropdown list, and a second press takes
>> the screenreader out of forms mode? I think I could achieve this by
>> adding an application role to the wrapping div and then removing it
>> once the Esc key has been pressed.
>>
>> I'd really appreciate your thoughts on this.
>>
>> Cheers, Lynn
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
> > > > >

From: Isabel Holdsworth
Date: Tue, Apr 17 2018 8:08AM
Subject: Re: [EXTERNAL]Combobox: what should the Esc key do?
← Previous message | No next message

Thanks Tim. My only reason for not using a native HTML5 combobox is
that I'm doing that very thing: using ARIA to speak the number of
results as the user types and the list is updated.

On 13/04/2018, Tim Harshbarger < = EMAIL ADDRESS REMOVED = > wrote:
> Depending on what you are trying to do, you might think about using an aria
> live region to convey information to screen reader users.
>
> For example, if the person is typing information into a textfield and
> results that match that text are being put in the combobox, you could use an
> aria live region to tell them how many options are now displayed inside the
> box.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Isabel Holdsworth
> Sent: Friday, April 13, 2018 3:49 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [EXTERNAL] Re: [WebAIM] Combobox: what should the Esc key do?
>
> Sure enough the Esc key works as expected in native HTML5 comboboxes,
> but it doesn't seem to work in composite ARIA-enabled widgets. I
> wonder if there's some way to force the ESC key to be passed to the
> browser first before it's grabbed by the AT? I can build a hack where
> the container has a role of "application" until the Esc key is
> pressed, but in that scenario JAWS says "application" a lot when the
> user interacts with the widget.
>
> I'd much rather use a native implementation, but it's just not
> possible to get enough info from it to let users know how many results
> are available as they type. Very frustrating.
>
> On 11/04/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>> Jaws, passes the escape key through. AS it closes the dropdown after
>> being
>> pressed. Need to check NVDA as I cannot recall how it behaves.
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Birkir R. Gunnarsson
>> Sent: Wednesday, 11 April 2018 12:09 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Combobox: what should the Esc key do?
>>
>> Lynn
>>
>> Weird, I thought the screen reader did not intercept the escape key in
>> forms/application mode if the page does something with it. A screen
>> reader
>> should be in forms mode when user navigates inside an input field or in
>> an
>> element with role="combobox" or "listbox".
>> Now that you mention it, I think this is an NVDA bug. I don't thin jaws
>> exhibits this behavior.
>> Well, easy to find out.
>>
>>
>>
>>
>> On 4/10/18, Lynn Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>>> Hi all,
>>>
>>> I'm creating a combobox widget, and wonder what's the most appropriate
>>> behaviour for the Esc key when using a screenreader?
>>>
>>> On its own, when the Esc key is pressed the textbox is left with the
>>> value the user typed into it, and the listbox that dropped down below
>>> it disappears.
>>>
>>> When using JAWS or NVDA, the screenreader grabs the Esc key and
>>> interprets it as an instruction to leave forms mode. Pressing Esc a
>>> second time triggers the combobox's standard behaviour. I don't feel
>>> that this is intuitive for the user.
>>>
>>> Would it be better if this could work the other way round: pressing
>>> Esc the first time hides the dropdown list, and a second press takes
>>> the screenreader out of forms mode? I think I could achieve this by
>>> adding an application role to the wrapping div and then removing it
>>> once the Esc key has been pressed.
>>>
>>> I'd really appreciate your thoughts on this.
>>>
>>> Cheers, Lynn
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> at
>> http://webaim.org/discussion/archives
>> >>
>> >> >> >> >>
> > > > > > > > >