E-mail List Archives
Thread: Does role="combobox" eat the identity of nested elements?
Number of posts in this thread: 16 (In chronological order)
From: glen walker
Date: Fri, Sep 06 2019 5:59PM
Subject: Does role="combobox" eat the identity of nested elements?
No previous message | Next message →
If I have a simple pattern of a <div role="combobox"> and it contains a
nested <input> (as taken from the ARIA 1.1 combobox design pattern [which
is different from the ARIA 1.0 design pattern]), the nested <input> can be
navigated to with the tab key but you cannot navigate to it with the E
shortcut key.
The shortcut key not working happens in NVDA. I'm not sure about JAWS.
If I walk the DOM using the down arrow, it skips over the nested elements
of the combo. I can't find the <input> using the down arrow. The only way
to navigate to the <input> is with tab.
Is this expected behavior with the combobox pattern?
For fun I put a <button> in the <div>. I can't navigate to the button with
the B shortcut key or the down arrow key. I can still tab to the button,
although when my focus is on the button and I use the B shortcut key to go
to the next button on the page (a button that is not contained in a combo),
the B shortcut key is ignored. Nothing happens.
I tried using aria-owns and aria-activedescendent but that didn't seem to
help.
<div role="combobox">
<label for="a1">alpha</label>
<input id="a1">
<button id="b1">foo</button>
</div>
From: Steve Green
Date: Sat, Sep 07 2019 8:50AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
If you are referring to the examples at https://www.w3.org/TR/wai-aria-practices-1.1/#combobox, my advice is not to use any of them. They might be compliant in theory, but they give a truly horrible and incomprehensible user experience. Using JAWS 2019, the behaviour is different in each browser, but it's bad in all of them. It would take hours to describe all the issues, so I suggest people just try it for themselves.
Part of the problem is that the design patterns are trying to be too clever. They all include autocomplete, but most authors don't want that - they just want to replicate the exact behaviour of a native combobox. None of the design patterns does this, and there is no point adding extra features such as autocomplete or grid popups until they do. Is this too much to ask for?
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 07 September 2019 00:59
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Does role="combobox" eat the identity of nested elements?
If I have a simple pattern of a <div role="combobox"> and it contains a nested <input> (as taken from the ARIA 1.1 combobox design pattern [which is different from the ARIA 1.0 design pattern]), the nested <input> can be navigated to with the tab key but you cannot navigate to it with the E shortcut key.
The shortcut key not working happens in NVDA. I'm not sure about JAWS.
If I walk the DOM using the down arrow, it skips over the nested elements of the combo. I can't find the <input> using the down arrow. The only way to navigate to the <input> is with tab.
Is this expected behavior with the combobox pattern?
For fun I put a <button> in the <div>. I can't navigate to the button with the B shortcut key or the down arrow key. I can still tab to the button, although when my focus is on the button and I use the B shortcut key to go to the next button on the page (a button that is not contained in a combo), the B shortcut key is ignored. Nothing happens.
I tried using aria-owns and aria-activedescendent but that didn't seem to help.
<div role="combobox">
<label for="a1">alpha</label>
<input id="a1">
<button id="b1">foo</button>
</div>
From: Birkir R. Gunnarsson
Date: Sat, Sep 07 2019 11:10AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
You're right, the combobox role overrides the role of the text input field.
You should be able to find it using "c" in Jaws/NVDA (just like you
would find a <select>). You should also be able to find it with the
arrow keys in browse mode.
If you can't, that's a bug I think.
The combobox role triggers application/forms mode so once inside the
combobox screen reader browse commands / keyboard navigation stop
working and all navigation within the widget is the responsibility of
the widget author.
If you put other widgets inside the combobox you must control
navigation with Javascript.
I agree with Steve that comboboxes are unnecessarily complex and the
functionality can be implemented differently, either with a <select>
or listbox if it's just a drop down function, or a com bination of
live regions and arrow key navigation for inline autocomplete search,
use the value attribute of the search input to indicate currently
selected option from suggestions.
If you are tackling a specific problem I can probably find some
examples of solutions I'd recommend.
On 9/7/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> If you are referring to the examples at
> https://www.w3.org/TR/wai-aria-practices-1.1/#combobox, my advice is not to
> use any of them. They might be compliant in theory, but they give a truly
> horrible and incomprehensible user experience. Using JAWS 2019, the
> behaviour is different in each browser, but it's bad in all of them. It
> would take hours to describe all the issues, so I suggest people just try it
> for themselves.
>
> Part of the problem is that the design patterns are trying to be too clever.
> They all include autocomplete, but most authors don't want that - they just
> want to replicate the exact behaviour of a native combobox. None of the
> design patterns does this, and there is no point adding extra features such
> as autocomplete or grid popups until they do. Is this too much to ask for?
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen
> walker
> Sent: 07 September 2019 00:59
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] Does role="combobox" eat the identity of nested elements?
>
> If I have a simple pattern of a <div role="combobox"> and it contains a
> nested <input> (as taken from the ARIA 1.1 combobox design pattern [which is
> different from the ARIA 1.0 design pattern]), the nested <input> can be
> navigated to with the tab key but you cannot navigate to it with the E
> shortcut key.
>
> The shortcut key not working happens in NVDA. I'm not sure about JAWS.
>
> If I walk the DOM using the down arrow, it skips over the nested elements of
> the combo. I can't find the <input> using the down arrow. The only way to
> navigate to the <input> is with tab.
>
> Is this expected behavior with the combobox pattern?
>
> For fun I put a <button> in the <div>. I can't navigate to the button with
> the B shortcut key or the down arrow key. I can still tab to the button,
> although when my focus is on the button and I use the B shortcut key to go
> to the next button on the page (a button that is not contained in a combo),
> the B shortcut key is ignored. Nothing happens.
>
> I tried using aria-owns and aria-activedescendent but that didn't seem to
> help.
>
> <div role="combobox">
> <label for="a1">alpha</label>
> <input id="a1">
> <button id="b1">foo</button>
> </div>
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: glen walker
Date: Sat, Sep 07 2019 4:12PM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
Thanks Birkir. I was thinking it was being treated like a mini application
role.
Neither the C shortcut nor the down arrow can find the combos, at least
with NVDA on Firefox or Chrome.
And I agree with Steve too that the patterns are very complex, but my
example was very simple. No autocomplete or anything. Just that little
snippet that I include in the OP.
From: Jonathan Avila
Date: Mon, Sep 09 2019 8:27AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
At this time we do not recommend implementation of the ARIA 1.1. combobox pattern as it's not accessibility supported by browser and assistive technology combinations. The ARIA 1.0 pattern can still be used.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Friday, September 6, 2019 7:59 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Does role="combobox" eat the identity of nested elements?
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
If I have a simple pattern of a <div role="combobox"> and it contains a nested <input> (as taken from the ARIA 1.1 combobox design pattern [which is different from the ARIA 1.0 design pattern]), the nested <input> can be navigated to with the tab key but you cannot navigate to it with the E shortcut key.
The shortcut key not working happens in NVDA. I'm not sure about JAWS.
If I walk the DOM using the down arrow, it skips over the nested elements of the combo. I can't find the <input> using the down arrow. The only way to navigate to the <input> is with tab.
Is this expected behavior with the combobox pattern?
For fun I put a <button> in the <div>. I can't navigate to the button with the B shortcut key or the down arrow key. I can still tab to the button, although when my focus is on the button and I use the B shortcut key to go to the next button on the page (a button that is not contained in a combo), the B shortcut key is ignored. Nothing happens.
I tried using aria-owns and aria-activedescendent but that didn't seem to help.
<div role="combobox">
<label for="a1">alpha</label>
<input id="a1">
<button id="b1">foo</button>
</div>
From: Steve Green
Date: Mon, Sep 09 2019 6:14PM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
The ARIA 1.0 examples are equally terrible. Maybe they didn't used to be, but they are with current browsers and screen readers (and if my memory is correct, they always were).
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jonathan Avila
Sent: 09 September 2019 15:28
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
At this time we do not recommend implementation of the ARIA 1.1. combobox pattern as it's not accessibility supported by browser and assistive technology combinations. The ARIA 1.0 pattern can still be used.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Friday, September 6, 2019 7:59 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Does role="combobox" eat the identity of nested elements?
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
If I have a simple pattern of a <div role="combobox"> and it contains a nested <input> (as taken from the ARIA 1.1 combobox design pattern [which is different from the ARIA 1.0 design pattern]), the nested <input> can be navigated to with the tab key but you cannot navigate to it with the E shortcut key.
The shortcut key not working happens in NVDA. I'm not sure about JAWS.
If I walk the DOM using the down arrow, it skips over the nested elements of the combo. I can't find the <input> using the down arrow. The only way to navigate to the <input> is with tab.
Is this expected behavior with the combobox pattern?
For fun I put a <button> in the <div>. I can't navigate to the button with the B shortcut key or the down arrow key. I can still tab to the button, although when my focus is on the button and I use the B shortcut key to go to the next button on the page (a button that is not contained in a combo), the B shortcut key is ignored. Nothing happens.
I tried using aria-owns and aria-activedescendent but that didn't seem to help.
<div role="combobox">
<label for="a1">alpha</label>
<input id="a1">
<button id="b1">foo</button>
</div>
From: Graham Armfield
Date: Tue, Sep 10 2019 1:23PM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
Which of course begs the question...
If we're showing developers how an accessible combobox should be
implemented, what accessible patterns are there out there - that work
nicely for screen reader users through browsers and AT that are in use at
the moment?
Regards
Graham Armfield
On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
wrote:
> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to be,
> but they are with current browsers and screen readers (and if my memory is
> correct, they always were).
>
> Steve
>
>
>
From: Steve Green
Date: Tue, Sep 10 2019 3:40PM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
There aren't any accessible patterns for comboboxes, and I am far from convinced that it is even possible with the current state of browsers and assistive technologies. I test every pattern I come across and they all have shortcomings. Some work adequately if you are in the right mode i.e. browse mode or forms mode, but they are terrible if you are in the wrong mode. Some work when you initially navigate to them, but do not work correctly when you return to them after making a selection.
I listed at least nine different means of interaction that need to be supported, such as which mode a screen reader is in when navigating to the combobox, whether or not a selection is made or changed, how the selection is made (e.g. spacebar or Enter key) and how you navigate away from the combobox (e.g. Tab key, Escape key etc.). Any viable pattern needs to work correctly with all of these means of interaction, but I have not found a pattern that comes close.
And all that needs to work properly before you can even start to think about embellishments such as autocomplete or making a selection by character key.
I tell all our clients to use native select elements and to live with the fact that some browsers won't allow you to style them the way you want. For the time being, there's no point trying to pretend there's another solution.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Graham Armfield
Sent: 10 September 2019 20:24
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
Which of course begs the question...
If we're showing developers how an accessible combobox should be implemented, what accessible patterns are there out there - that work nicely for screen reader users through browsers and AT that are in use at the moment?
Regards
Graham Armfield
On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
wrote:
> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
> be, but they are with current browsers and screen readers (and if my
> memory is correct, they always were).
>
> Steve
>
>
>
From: mhysnm1964@gmail.com
Date: Wed, Sep 11 2019 6:08AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
I am sure I have come across accessible combo boxes with edit fields. Do not
recall if they have auto-search or not. I must keep an eye out for one.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve
Green
Sent: Wednesday, 11 September 2019 7:40 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
elements?
There aren't any accessible patterns for comboboxes, and I am far from
convinced that it is even possible with the current state of browsers and
assistive technologies. I test every pattern I come across and they all have
shortcomings. Some work adequately if you are in the right mode i.e. browse
mode or forms mode, but they are terrible if you are in the wrong mode. Some
work when you initially navigate to them, but do not work correctly when you
return to them after making a selection.
I listed at least nine different means of interaction that need to be
supported, such as which mode a screen reader is in when navigating to the
combobox, whether or not a selection is made or changed, how the selection
is made (e.g. spacebar or Enter key) and how you navigate away from the
combobox (e.g. Tab key, Escape key etc.). Any viable pattern needs to work
correctly with all of these means of interaction, but I have not found a
pattern that comes close.
And all that needs to work properly before you can even start to think about
embellishments such as autocomplete or making a selection by character key.
I tell all our clients to use native select elements and to live with the
fact that some browsers won't allow you to style them the way you want. For
the time being, there's no point trying to pretend there's another solution.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Graham Armfield
Sent: 10 September 2019 20:24
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
elements?
Which of course begs the question...
If we're showing developers how an accessible combobox should be
implemented, what accessible patterns are there out there - that work nicely
for screen reader users through browsers and AT that are in use at the
moment?
Regards
Graham Armfield
On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
wrote:
> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
> be, but they are with current browsers and screen readers (and if my
> memory is correct, they always were).
>
> Steve
>
>
>
http://webaim.org/discussion/archives
http://webaim.org/discussion/archives
From: Steve Green
Date: Wed, Sep 11 2019 6:10AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
They might have been accessible with the interaction modes that you used, but I guarantee they won't be accessible with all the different interaction modes that are possible.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: 11 September 2019 13:08
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
I am sure I have come across accessible combo boxes with edit fields. Do not recall if they have auto-search or not. I must keep an eye out for one.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Wednesday, 11 September 2019 7:40 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
There aren't any accessible patterns for comboboxes, and I am far from convinced that it is even possible with the current state of browsers and assistive technologies. I test every pattern I come across and they all have shortcomings. Some work adequately if you are in the right mode i.e. browse mode or forms mode, but they are terrible if you are in the wrong mode. Some work when you initially navigate to them, but do not work correctly when you return to them after making a selection.
I listed at least nine different means of interaction that need to be supported, such as which mode a screen reader is in when navigating to the combobox, whether or not a selection is made or changed, how the selection is made (e.g. spacebar or Enter key) and how you navigate away from the combobox (e.g. Tab key, Escape key etc.). Any viable pattern needs to work correctly with all of these means of interaction, but I have not found a pattern that comes close.
And all that needs to work properly before you can even start to think about embellishments such as autocomplete or making a selection by character key.
I tell all our clients to use native select elements and to live with the fact that some browsers won't allow you to style them the way you want. For the time being, there's no point trying to pretend there's another solution.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Graham Armfield
Sent: 10 September 2019 20:24
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
Which of course begs the question...
If we're showing developers how an accessible combobox should be implemented, what accessible patterns are there out there - that work nicely for screen reader users through browsers and AT that are in use at the moment?
Regards
Graham Armfield
On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
wrote:
> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
> be, but they are with current browsers and screen readers (and if my
> memory is correct, they always were).
>
> Steve
>
>
>
From: Birkir R. Gunnarsson
Date: Wed, Sep 11 2019 6:18AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
I saw an interesting presentation from Matt King regarding the future
of the authoring Practices at CSUN last spring.
The idea was to ensure support by at least 1 (I think at least 2)
a.t./browser combos for every pattern.
There was an offshoot effort in the work to document desired and
actual assistive technology support for different patterns.
I haven't heard anything since, but these are exactly the types of
updates I want to see to the authoring practices.
I want people to be able to use the authoring practices patterns out
of the box and be sure that there is at least adequate assistive
technology support for that implementation.
On 9/11/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> They might have been accessible with the interaction modes that you used,
> but I guarantee they won't be accessible with all the different interaction
> modes that are possible.
>
> Steve
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 11 September 2019 13:08
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> I am sure I have come across accessible combo boxes with edit fields. Do not
> recall if they have auto-search or not. I must keep an eye out for one.
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve
> Green
> Sent: Wednesday, 11 September 2019 7:40 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> There aren't any accessible patterns for comboboxes, and I am far from
> convinced that it is even possible with the current state of browsers and
> assistive technologies. I test every pattern I come across and they all have
> shortcomings. Some work adequately if you are in the right mode i.e. browse
> mode or forms mode, but they are terrible if you are in the wrong mode. Some
> work when you initially navigate to them, but do not work correctly when you
> return to them after making a selection.
>
> I listed at least nine different means of interaction that need to be
> supported, such as which mode a screen reader is in when navigating to the
> combobox, whether or not a selection is made or changed, how the selection
> is made (e.g. spacebar or Enter key) and how you navigate away from the
> combobox (e.g. Tab key, Escape key etc.). Any viable pattern needs to work
> correctly with all of these means of interaction, but I have not found a
> pattern that comes close.
>
> And all that needs to work properly before you can even start to think about
> embellishments such as autocomplete or making a selection by character key.
>
> I tell all our clients to use native select elements and to live with the
> fact that some browsers won't allow you to style them the way you want. For
> the time being, there's no point trying to pretend there's another
> solution.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Graham Armfield
> Sent: 10 September 2019 20:24
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> Which of course begs the question...
>
> If we're showing developers how an accessible combobox should be
> implemented, what accessible patterns are there out there - that work nicely
> for screen reader users through browsers and AT that are in use at the
> moment?
>
> Regards
> Graham Armfield
>
> On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
>> be, but they are with current browsers and screen readers (and if my
>> memory is correct, they always were).
>>
>> Steve
>>
>>
>>
> > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> >
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.
From: Steve Green
Date: Wed, Sep 11 2019 6:32AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
I would not argue against that, but it has often been stated that it's a chicken and egg problem. The browser and AT vendors won't build in support until they see people using the new technologies, but people won't use them until the browsers and ATs support them adequately.
Someone needs to break that cycle, but you can understand why they don't. With something like 160 ARIA attributes, roles and values, it's likely that browser and AT vendors have spent a lot of time and money implementing support for features that almost no one uses.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: 11 September 2019 13:18
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
I saw an interesting presentation from Matt King regarding the future of the authoring Practices at CSUN last spring.
The idea was to ensure support by at least 1 (I think at least 2) a.t./browser combos for every pattern.
There was an offshoot effort in the work to document desired and actual assistive technology support for different patterns.
I haven't heard anything since, but these are exactly the types of updates I want to see to the authoring practices.
I want people to be able to use the authoring practices patterns out of the box and be sure that there is at least adequate assistive technology support for that implementation.
On 9/11/19, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> They might have been accessible with the interaction modes that you
> used, but I guarantee they won't be accessible with all the different
> interaction modes that are possible.
>
> Steve
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 11 September 2019 13:08
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> I am sure I have come across accessible combo boxes with edit fields.
> Do not recall if they have auto-search or not. I must keep an eye out for one.
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Steve Green
> Sent: Wednesday, 11 September 2019 7:40 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> There aren't any accessible patterns for comboboxes, and I am far from
> convinced that it is even possible with the current state of browsers
> and assistive technologies. I test every pattern I come across and
> they all have shortcomings. Some work adequately if you are in the
> right mode i.e. browse mode or forms mode, but they are terrible if
> you are in the wrong mode. Some work when you initially navigate to
> them, but do not work correctly when you return to them after making a selection.
>
> I listed at least nine different means of interaction that need to be
> supported, such as which mode a screen reader is in when navigating to
> the combobox, whether or not a selection is made or changed, how the
> selection is made (e.g. spacebar or Enter key) and how you navigate
> away from the combobox (e.g. Tab key, Escape key etc.). Any viable
> pattern needs to work correctly with all of these means of
> interaction, but I have not found a pattern that comes close.
>
> And all that needs to work properly before you can even start to think
> about embellishments such as autocomplete or making a selection by character key.
>
> I tell all our clients to use native select elements and to live with
> the fact that some browsers won't allow you to style them the way you
> want. For the time being, there's no point trying to pretend there's
> another solution.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Graham Armfield
> Sent: 10 September 2019 20:24
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested
> elements?
>
> Which of course begs the question...
>
> If we're showing developers how an accessible combobox should be
> implemented, what accessible patterns are there out there - that work
> nicely for screen reader users through browsers and AT that are in use
> at the moment?
>
> Regards
> Graham Armfield
>
> On Tue, 10 Sep 2019, 01:14 Steve Green,
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
>> be, but they are with current browsers and screen readers (and if my
>> memory is correct, they always were).
>>
>> Steve
>>
>>
>>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
--
Work hard. Have fun. Make history.
From: Graham Armfield
Date: Wed, Sep 11 2019 8:02AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
One ideal solution to all this would be for browsers and AT to support 1)
extending existing elements, and 2) to actually get behind the newer HTML5
elements. Two examples:
1) Using the native <select> element gives a good accessible experience,
but it's a pain to style nicely. It also will not support the <option>
elements containing anything but text. This is why developers and designers
search for a customized listbox solution.
If that restriction were relaxed a bit and other elements could be
contained within the <option> elements - eg thumbnail images of flags for a
currency converter - then devs and designers could have styled controls
with inherent accessibility without having to mess about with javascript
and ARIA.
2) HTML5 introduced the <datalist> element that can be used with textboxes.
The theory (I believe) is that this can work like a combobox where the user
can type a couple of characters and a filtered list of options can be shown.
If this element were better supported by browsers and AT then the need for
complex accessible ARIA patterns would substantially disappear as the
native browser functionality could take care of everything.
But I guess chicken and egg sums it up.
Regards
Graham Armfield
Coolfields Consulting
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
From: Birkir R. Gunnarsson
Date: Wed, Sep 11 2019 8:25AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
I absolutely agree with you guys on the root of the problem.
I think, instead of continuously updating ARIA adding more and more
attributes and roles and complexities, the approach should be to make
ARIA more concise and stricter from a semantic point of view (you can
use ARIA to implement terribly inaccessible and unsupported widget
without breaking a single ARIA validation requirement, which makes
automated tools powerless)
Together with a strictre validation should come more collaboration
with browser and AT vendors to ensure adequate support, with fewer
ARIA properties it should be more manageable.
And I 100% agree on HTML5,proper support for the <dialog> element, the
<datalist> element (I created a decently workin auto complete search
that works in Firefox and Chrome without a single line of JavaScript)
and development of a <tablist>/<tab> construct and a <tooltip> element
(there is a <toast> element being proposed that sort of does the same
thing) my job would be simplified by 75%.
For the auto complete serch, the construct was something like the
ollowing (I did this a whil back s my <datalist> implementation may be
wrong)
<label for="search">Search</label>
<input type="text" list="options" id="search">
<datalist id="options">
<option value="apples">Apples</option>
<option value="pairs">pairs</option>
</datalist>
If you type A and press arrow own, I think both Firefox and Chrome
will update the value to "Apples" and NVDA / Jaws announce it.
A bit of JavaScript is needed to alert screen reader users when rsults
are available and probably a tooltip to infomrthem that the field
contains auto complete suggestions, but it's really quite as simple as
that.
I mean, if things like this were properly supported, it would be so
easy to do accessibility.
On 9/11/19, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
> One ideal solution to all this would be for browsers and AT to support 1)
> extending existing elements, and 2) to actually get behind the newer HTML5
> elements. Two examples:
>
> 1) Using the native <select> element gives a good accessible experience,
> but it's a pain to style nicely. It also will not support the <option>
> elements containing anything but text. This is why developers and designers
> search for a customized listbox solution.
>
> If that restriction were relaxed a bit and other elements could be
> contained within the <option> elements - eg thumbnail images of flags for a
> currency converter - then devs and designers could have styled controls
> with inherent accessibility without having to mess about with javascript
> and ARIA.
>
> 2) HTML5 introduced the <datalist> element that can be used with textboxes.
> The theory (I believe) is that this can work like a combobox where the user
> can type a couple of characters and a filtered list of options can be
> shown.
>
> If this element were better supported by browsers and AT then the need for
> complex accessible ARIA patterns would substantially disappear as the
> native browser functionality could take care of everything.
>
>
> But I guess chicken and egg sums it up.
>
> Regards
> Graham Armfield
> Coolfields Consulting
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >
--
Work hard. Have fun. Make history.
From: Mohith BP
Date: Fri, Sep 13 2019 3:32AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | Next message →
Hi All,
As pointed by Steve Green, there is no way other than <select> to
build an completely accessible custom combobox as of now.
I learnt it around 2 years ago hard way.
Implementing Button with aria-expanded and aria-haspopup and having
listbox which will be visible after expanding the button is one of the
work around. However, this too will have some issues with all the
patterns and ways of navigation.
Thanks & Regards,
Mohith BP
On 9/11/19, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> I absolutely agree with you guys on the root of the problem.
> I think, instead of continuously updating ARIA adding more and more
> attributes and roles and complexities, the approach should be to make
> ARIA more concise and stricter from a semantic point of view (you can
> use ARIA to implement terribly inaccessible and unsupported widget
> without breaking a single ARIA validation requirement, which makes
> automated tools powerless)
> Together with a strictre validation should come more collaboration
> with browser and AT vendors to ensure adequate support, with fewer
> ARIA properties it should be more manageable.
> And I 100% agree on HTML5,proper support for the <dialog> element, the
> <datalist> element (I created a decently workin auto complete search
> that works in Firefox and Chrome without a single line of JavaScript)
> and development of a <tablist>/<tab> construct and a <tooltip> element
> (there is a <toast> element being proposed that sort of does the same
> thing) my job would be simplified by 75%.
>
> For the auto complete serch, the construct was something like the
> ollowing (I did this a whil back s my <datalist> implementation may be
> wrong)
>
> <label for="search">Search</label>
> <input type="text" list="options" id="search">
>
> <datalist id="options">
> <option value="apples">Apples</option>
> <option value="pairs">pairs</option>
> </datalist>
>
> If you type A and press arrow own, I think both Firefox and Chrome
> will update the value to "Apples" and NVDA / Jaws announce it.
>
> A bit of JavaScript is needed to alert screen reader users when rsults
> are available and probably a tooltip to infomrthem that the field
> contains auto complete suggestions, but it's really quite as simple as
> that.
> I mean, if things like this were properly supported, it would be so
> easy to do accessibility.
>
>
>
> On 9/11/19, Graham Armfield < = EMAIL ADDRESS REMOVED = > wrote:
>> One ideal solution to all this would be for browsers and AT to support 1)
>> extending existing elements, and 2) to actually get behind the newer
>> HTML5
>> elements. Two examples:
>>
>> 1) Using the native <select> element gives a good accessible experience,
>> but it's a pain to style nicely. It also will not support the <option>
>> elements containing anything but text. This is why developers and
>> designers
>> search for a customized listbox solution.
>>
>> If that restriction were relaxed a bit and other elements could be
>> contained within the <option> elements - eg thumbnail images of flags for
>> a
>> currency converter - then devs and designers could have styled controls
>> with inherent accessibility without having to mess about with javascript
>> and ARIA.
>>
>> 2) HTML5 introduced the <datalist> element that can be used with
>> textboxes.
>> The theory (I believe) is that this can work like a combobox where the
>> user
>> can type a couple of characters and a filtered list of options can be
>> shown.
>>
>> If this element were better supported by browsers and AT then the need
>> for
>> complex accessible ARIA patterns would substantially disappear as the
>> native browser functionality could take care of everything.
>>
>>
>> But I guess chicken and egg sums it up.
>>
>> Regards
>> Graham Armfield
>> Coolfields Consulting
>>
>>
>>
>>
>> <http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> Virus-free.
>> www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
From: Bryan Garaventa
Date: Fri, Sep 13 2019 11:25AM
Subject: Re: Does role="combobox" eat the identity of nested elements?
← Previous message | No next message
Hi,
I don't know why I keep having to resend this to WebAim and others, but the 1.0 ARIA Combobox design pattern has been accessible for years now, across all mainstream AT and browser combinations, as long as you follow the guidance on this article.
https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/
It takes into account the changes discussed in 1.1, and how this applies to 1.0, and how the 1.0 design pattern needs to be adapted to ensure accessibility going forward. With these changes, ARIA comboboxes are indeed accessible. I know this because I was involved in the process of ensuring the mappings would be maintained as 1.1 was developed.
All the best,
Bryan
Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Wednesday, September 11, 2019 5:08 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
I am sure I have come across accessible combo boxes with edit fields. Do not recall if they have auto-search or not. I must keep an eye out for one.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Wednesday, 11 September 2019 7:40 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
There aren't any accessible patterns for comboboxes, and I am far from convinced that it is even possible with the current state of browsers and assistive technologies. I test every pattern I come across and they all have shortcomings. Some work adequately if you are in the right mode i.e. browse mode or forms mode, but they are terrible if you are in the wrong mode. Some work when you initially navigate to them, but do not work correctly when you return to them after making a selection.
I listed at least nine different means of interaction that need to be supported, such as which mode a screen reader is in when navigating to the combobox, whether or not a selection is made or changed, how the selection is made (e.g. spacebar or Enter key) and how you navigate away from the combobox (e.g. Tab key, Escape key etc.). Any viable pattern needs to work correctly with all of these means of interaction, but I have not found a pattern that comes close.
And all that needs to work properly before you can even start to think about embellishments such as autocomplete or making a selection by character key.
I tell all our clients to use native select elements and to live with the fact that some browsers won't allow you to style them the way you want. For the time being, there's no point trying to pretend there's another solution.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Graham Armfield
Sent: 10 September 2019 20:24
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does role="combobox" eat the identity of nested elements?
Which of course begs the question...
If we're showing developers how an accessible combobox should be implemented, what accessible patterns are there out there - that work nicely for screen reader users through browsers and AT that are in use at the moment?
Regards
Graham Armfield
On Tue, 10 Sep 2019, 01:14 Steve Green, < = EMAIL ADDRESS REMOVED = >
wrote:
> The ARIA 1.0 examples are equally terrible. Maybe they didn't used to
> be, but they are with current browsers and screen readers (and if my
> memory is correct, they always were).
>
> Steve
>
>
>