E-mail List Archives
Thread: Combobox sufficiently accessibility-supported?
Number of posts in this thread: 13 (In chronological order)
From: Detlev Fischer
Date: Fri, Oct 09 2015 3:37AM
Subject: Combobox sufficiently accessibility-supported?
No previous message | Next message →
Hi list,
I did a bit of due diligence searching but the last Webaim entry mentioning the combobox is more than a year old.
Would you still consider it best practice to avoid the combobox if favour of native selects?
I like the possibility to type in a search term and see suggestions dynamically appear in a list below the input field, but I am worried that the experience might still be bad for some screen reader users.
One example I found is http://oaa-accessibility.org/example/10/ but there may be better ones.
Any thoughts?
--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
From: Patrick H. Lauke
Date: Fri, Oct 09 2015 3:54AM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
On 09/10/2015 10:37, Detlev Fischer wrote:
> Hi list,
> I did a bit of due diligence searching but the last Webaim entry mentioning the combobox is more than a year old.
> Would you still consider it best practice to avoid the combobox if favour of native selects?
> I like the possibility to type in a search term and see suggestions dynamically appear in a list below the input field, but I am worried that the experience might still be bad for some screen reader users.
> One example I found is http://oaa-accessibility.org/example/10/ but there may be better ones.
> Any thoughts?
Certainly for touchscreen/AT users (e.g. mobile phones/tablets),
comboboxes can present considerable problems, such as not being able to
actually navigate to any of the suggestions. This is particularly true
for the ones that rely purely on activedescendant, as that - from my
cursory testing a while ago - is not supported in iOS/VoiceOver nor
Android/TalkBack.
And beyond AT, even for non-AT touchscreen users, comboboxes can present
usability challenges on small screens, due to the on-screen keyboard
being in the way and not allowing for quick and easy interaction with
any results that show up.
In recent projects, I've actually recommended that for touchscreen and
small screen use, comboboxes / type-ahead suggestions / results should
be reimplemented as actual controls/buttons/lists of results that
dynamically show after an input (so they don't disappear once the input
loses focus).
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Bryan Garaventa
Date: Fri, Oct 09 2015 12:06PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
> Certainly for touchscreen/AT users (e.g. mobile phones/tablets), comboboxes can present considerable problems, such as not being able to actually navigate
> to any of the suggestions. This is particularly true for the ones that rely purely on activedescendant, as that - from my cursory testing a while ago -
> is not supported in iOS/VoiceOver nor Android/TalkBack.
This is true, and likely never will be since the element that is touched is the one that is being interfaced with by the AT, and that is what aria-activedescendant will always convey.
It is possible though, to use responsive design to detect touch screen devices and adjust the behavior accordingly so that Listboxes with referenced items aren't lost, and to detect the sizing of such screens to dynamically adjust the number of listed items.
An example of this can be tested at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm
Which uses the ARIA Combobox module in the TSG at
https://github.com/accdc/tsg
This functionality includes standard desktop navigation usage, but also touch device detection to prevent auto closing when focus moves away from the input, as well as size detection to adjust the list size when viewed on a phone sized device versus a tablet. When typing, a basic live region is used to announce the first suggested item.
I agree that when zooming in for low vision usage, it can be difficult to detect dynamic content such as this when it appears, but from an accessibility standpoint given current technologies and what is possible to accomplish with spec compliant responsive design, it is possible to create dynamic Combobox widgets such as these that are accessible to the vast majority of users if programmed with these concepts in mind.
From: Patrick H. Lauke
Date: Fri, Oct 09 2015 2:41PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
On 09/10/2015 19:06, Bryan Garaventa wrote:
>> Certainly for touchscreen/AT users (e.g. mobile phones/tablets), comboboxes can present considerable problems, such as not being able to actually navigate
>> to any of the suggestions. This is particularly true for the ones that rely purely on activedescendant, as that - from my cursory testing a while ago -
>> is not supported in iOS/VoiceOver nor Android/TalkBack.
>
> This is true, and likely never will be since the element that is touched is the one that is being interfaced with by the AT, and that is what aria-activedescendant will always convey.
It is conceivable that this could be made to work though, with the focus
nominally remaining on the combobox' input, but VoiceOver/TalkBack
allowing the user to swipe up/down (same as cursor up/down) to cycle
through the results/suggestions, while swiping left/right would take the
user to previous/next item in the sequential focus order.
> It is possible though, to use responsive design to detect touch screen devices
Maybe nitpicking here, but: no, you can't detect a touchscreen
https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/.
The closest you can come to, nowadays, is detecting whether or not a
browser supports touch events (which says nothing about whether or not a
touchscreen is actually present, though most browsers pretend not to
understand touch events in the absence of a touchscreen when they first
start up) or, using pointer events, you can query
navigator.maxTouchPoints
http://www.w3.org/TR/pointerevents/#extensions-to-the-navigator-interface -
while this is more accurate, it still doesn't account for multi-input
situations (such as a Microsoft Surface) where a user may be using a
mouse or keyboard despite the presence of a touchscreen.
The CSS 4 Interaction Media Features
(pointer/hover/any-pointer/any-hover) are similarly flawed when it comes
to multi-input scenarios https://dev.opera.com/articles/media-features/
If your implication, however, was that we can detect touchscreen devices
by looking at the viewport size, I'd warn that this is simply bad
practice (and in an increasingly diverse ecosystem, where you can have
desktops/laptops with touchscreens, or users of large screens that
simply make their browser small or enlarged/zoomed in) - don't rely on
one thing (in this case, viewport width) to deduce something else
(whether or not it's a touchscreen device).
> and adjust the behavior accordingly so that Listboxes with referenced items aren't lost, and to detect the sizing of such screens to dynamically adjust the number of listed items.
>
> An example of this can be tested at
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm
Ah, looking at the demo, you're actually doing browser sniffing. This
is, of course, also a discouraged practice.
https://developer.mozilla.org/en-US/docs/Browser_detection_using_the_user_agent
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Bryan Garaventa
Date: Fri, Oct 09 2015 5:52PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
> It is conceivable that this could be made to work though, with the focus nominally remaining on the combobox' input, but VoiceOver/TalkBack allowing the
> user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next
> item in the sequential focus order.
That is true, and would be helpful if implemented. It doesn't say anything about this in the spec though, so achieving consensus on how it should work is debatable.
> Maybe nitpicking here, but: no, you can't detect a touchscreen
> https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/.
> The closest you can come to, nowadays, is detecting whether or not a browser supports touch events (which says nothing about whether or not a touchscreen
> is actually present, though most browsers pretend not to understand touch events in the absence of a touchscreen when they first start up) or, using pointer
> events, you can query navigator.maxTouchPoints
> http://www.w3.org/TR/pointerevents/#extensions-to-the-navigator-interface
> - while this is more accurate, it still doesn't account for multi-input situations (such as a Microsoft Surface) where a user may be using a mouse or
> keyboard despite the presence of a touchscreen.
Yes, I know, the "if ('ontouchstart' in window || navigator.maxTouchPoints > 0 || navigator.msMaxTouchPoints > 0)" hack is the method being used to identify the presence of a browser that supports it within the module, which beyond some basic onFocus/onBlur modification and offscreen text changing, does little else to change the underlying functionality of the widget. It is however sufficient until something better comes along as a more reliable and spec-compliant method becomes available by the OS/Browser venders.
> The CSS 4 Interaction Media Features
> (pointer/hover/any-pointer/any-hover) are similarly flawed when it comes to multi-input scenarios
> https://dev.opera.com/articles/media-features/
Yes, we live in exciting times...
> If your implication, however, was that we can detect touchscreen devices by looking at the viewport size, I'd warn that this is simply bad practice (and
> in an increasingly diverse ecosystem, where you can have desktops/laptops with touchscreens, or users of large screens that simply make their browser small
> or enlarged/zoomed in) - don't rely on one thing (in this case, viewport width) to deduce something else (whether or not it's a touchscreen device).
No, that is not my implication. If you use the ontouchstart hack it is then possible to compare/combine this with the browsers being used within different devices as needed such as with the useragent string to detect when the touch device is a phone or tablet. The result simply being a slight UI modification as needed if successful.
> Ah, looking at the demo, you're actually doing browser sniffing. This is, of course, also a discouraged practice.
> https://developer.mozilla.org/en-US/docs/Browser_detection_using_the_user_agent
As the same webpage you referenced states:
"But browsers and standards are not perfect, and there are still some edge cases where detecting the browser is needed."
Until something better becomes available by the OS/browser venders, this method works for the time being.
As a note, the ARIA Combobox module doesn't do any browser sniffing, this is added separately to tweak the UI in combo with the setup.js code as needed.
E.G http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/js/setup.js
Specifically, where it states:
// Set a default list option display size for touch screens, 3 for phones, 5 for tablets
myAuthorCombobox.setSize(isPhone ? 3 : 5);
From: Patrick H. Lauke
Date: Fri, Oct 09 2015 7:11PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
On 10/10/2015 00:52, Bryan Garaventa wrote:
>> It is conceivable that this could be made to work though, with the focus nominally remaining on the combobox' input, but VoiceOver/TalkBack allowing the
>> user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next
>> item in the sequential focus order.
>
> That is true, and would be helpful if implemented. It doesn't say anything about this in the spec though, so achieving consensus on how it should work is debatable.
I don't believe the spec authoritively defines any user agent behavior
http://www.w3.org/TR/wai-aria/ - and while we do have the best practices
http://www.w3.org/TR/wai-aria-practices/ these are aimed at web content
developers, and are not meant as a guide for user agent developers.
I don't think there's any particular need for consensus - all the
various ATs don't have to use the same touchscreen gestures (and
indeed, they don't for many things), but what they do need is an
underlying implementation of the concept of activedescendant, and some
means for a user to interact with a widget that uses it. Whether it be
an up/down swipe, or a two- or three-finger swipe, or a more complex
gesture is really up to each AT to decide.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: _mallory
Date: Sat, Oct 10 2015 1:49PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
Question: as a web developer, if I listen for a Touch event on my
combobox, similar to checking for a keyup (and then checking which
keys) on a control, can I determine that someone touched the screen?
Or can I get false touchWhatevers being fired by a mouse or kb because
the device+browser also supports touch?
_mallory
On Sat, Oct 10, 2015 at 02:11:35AM +0100, Patrick H. Lauke wrote:
> On 10/10/2015 00:52, Bryan Garaventa wrote:
> >>It is conceivable that this could be made to work though, with the focus nominally remaining on the combobox' input, but VoiceOver/TalkBack allowing the
> >>user to swipe up/down (same as cursor up/down) to cycle through the results/suggestions, while swiping left/right would take the user to previous/next
> >>item in the sequential focus order.
> >
> >That is true, and would be helpful if implemented. It doesn't say anything about this in the spec though, so achieving consensus on how it should work is debatable.
>
> I don't believe the spec authoritively defines any user agent
> behavior http://www.w3.org/TR/wai-aria/ - and while we do have the
> best practices http://www.w3.org/TR/wai-aria-practices/ these are
> aimed at web content developers, and are not meant as a guide for
> user agent developers.
>
> I don't think there's any particular need for consensus - all the
> various ATs don't have to use the same touchscreen gestures (and
> indeed, they don't for many things), but what they do need is an
> underlying implementation of the concept of activedescendant, and
> some means for a user to interact with a widget that uses it.
> Whether it be an up/down swipe, or a two- or three-finger swipe, or
> a more complex gesture is really up to each AT to decide.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >
From: Patrick H. Lauke
Date: Sat, Oct 10 2015 3:23PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
On 10/10/2015 20:49, _mallory wrote:
> Question: as a web developer, if I listen for a Touch event on my
> combobox, similar to checking for a keyup (and then checking which
> keys) on a control, can I determine that someone touched the screen?
Yes, with some caveats. If there is also an AT running, some touch
interactions may be intercepted by the AT and never make it to the
browser/fire a JS event. It will also depend how a user reaches the
combobox - if for instance we're talking about an iOS device with
VoiceOver running, and the user navigated to the combobox, only a
"focus" event would be fired (even if using touch-to-explore) - see
http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events
(which, it has to be noted, is based on tests carried out with a
<button>, rather than an <input> from a combobox).
> Or can I get false touchWhatevers being fired by a mouse or kb because
> the device+browser also supports touch?
In the case of phones/tablets with a paired mouse/keyboard, this varies
depending on OS/browser - in some cases, a mouse will behave exactly
like a touch, firing touch events first, followed by compatibility mouse
events and click - see
http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-keyboard-mouse-events.
For paired keyboards, this is not the case though.
For desktop/laptop with a touchscreen (e.g. Surface 3 etc), the answer
is a straight no - mouse and keyboard will behave as they always did,
and no false touch events will be triggered.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Sat, Oct 10 2015 3:25PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
On 10/10/2015 22:23, Patrick H. Lauke wrote:
> On 10/10/2015 20:49, _mallory wrote:
>> Question: as a web developer, if I listen for a Touch event on my
>> combobox, similar to checking for a keyup (and then checking which
>> keys) on a control, can I determine that someone touched the screen?
As an aside, I like your thinking here. As we can't "a priori" detect if
a device is a touchscreen device AND (in the case of multi-input
devices) if the user is in fact going to use a touchscreen even when
present, we can (for the most part) try to determine which kind of
combobox adaptation right at the point where the user interacts with it.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: _mallory
Date: Sat, Oct 10 2015 3:40PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
Yeah I was thinking if it made sense to hold open listbox options
when users touched, then I can not care about if the device supports
touch or not, or how big/small the screen is, and let other means
close it, that could fix a lot of small-touchy-screen issues that
come up.
But it sounds like neither sniffing nor touch-event detection would
work nicely.
_m
On Sat, Oct 10, 2015 at 10:25:05PM +0100, Patrick H. Lauke wrote:
> On 10/10/2015 22:23, Patrick H. Lauke wrote:
> >On 10/10/2015 20:49, _mallory wrote:
> >>Question: as a web developer, if I listen for a Touch event on my
> >>combobox, similar to checking for a keyup (and then checking which
> >>keys) on a control, can I determine that someone touched the screen?
>
> As an aside, I like your thinking here. As we can't "a priori"
> detect if a device is a touchscreen device AND (in the case of
> multi-input devices) if the user is in fact going to use a
> touchscreen even when present, we can (for the most part) try to
> determine which kind of combobox adaptation right at the point where
> the user interacts with it.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >
From: Bryan Garaventa
Date: Sun, Oct 11 2015 7:13PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
> I don't think there's any particular need for consensus - all the various ATs don't have to use the same touchscreen gestures (and indeed, they don't for
> many things), but what they do need is an underlying implementation of the concept of activedescendant, and some means for a user to interact with a widget
> that uses it. Whether it be an up/down swipe, or a two- or three-finger swipe, or a more complex gesture is really up to each AT to decide.
I agree, and this would be nice if supported. A lot of these issues are coming up as we continue working on the ARIA APG 1.1 update, and touch devices are sort of a hot topic for this across various interactive widgets.
Going back to the original question though:
> Hi list,
> I did a bit of due diligence searching but the last Webaim entry mentioning the combobox is more than a year old.
> Would you still consider it best practice to avoid the combobox if favour of native selects?
With this in mind, can you identify any accessibility issues with the demo implementation that I referenced?
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm
I really would like to know what these are, so I can improve this in the future.
Thanks,
Bryan
From: Detlev Fischer
Date: Sun, Oct 11 2015 11:43PM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | Next message →
Thanks to both of you, Patrick and Brian, to pick up this the question and have this instructive discussion.
Brian, I have just opened your example on an iPhone (Safari), turned on VoiceOver, and tried using the Combobox. There are several issues that make it hard to use at least with iOS/ VO on a small screen:
*Default font small, making bigger via browser zoom cuts off content & requires horizontal panning
* Position and width of postbox not adapted to screen width (the native "fruit machine" widget would certainly be easier to use)
*Suggestions come unexpected (both visually and as VO output), they cause a jump in scroll status, making me lose the visual context of the input field
* Odd behavior of suggestions - typing "Ch" offers "Butcher" not "Chalker" as first list item voiced
* After selecting an option that is placed into the input, I seem to lose VO focus, I.e. I think it is no longer on the input so that the next focus point would be submit. The focus is instead on your text instruction at the physical position where the list box focus was before selecting the item
* Deleting content in the select makes the page immediately scroll to the list box top so the input where deletion takes place is no longer visible
Note this is just a quick check by a sighted user who is not a VO expert.
Best, Detlev
Sent from phone
Am 12.10.2015 um 03:13 schrieb Bryan Garaventa < = EMAIL ADDRESS REMOVED = >:
>> I don't think there's any particular need for consensus - all the various ATs don't have to use the same touchscreen gestures (and indeed, they don't for
>> many things), but what they do need is an underlying implementation of the concept of activedescendant, and some means for a user to interact with a widget
>> that uses it. Whether it be an up/down swipe, or a two- or three-finger swipe, or a more complex gesture is really up to each AT to decide.
>
> I agree, and this would be nice if supported. A lot of these issues are coming up as we continue working on the ARIA APG 1.1 update, and touch devices are sort of a hot topic for this across various interactive widgets.
>
> Going back to the original question though:
>
>> Hi list,
>> I did a bit of due diligence searching but the last Webaim entry mentioning the combobox is more than a year old.
>> Would you still consider it best practice to avoid the combobox if favour of native selects?
>
> With this in mind, can you identify any accessibility issues with the demo implementation that I referenced?
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Substring%20Match)/demo.htm
>
> I really would like to know what these are, so I can improve this in the future.
>
> Thanks,
> Bryan
>
>
>
From: Bryan Garaventa
Date: Mon, Oct 12 2015 9:39AM
Subject: Re: Combobox sufficiently accessibility-supported?
← Previous message | No next message
Thanks, that helps a lot actually :)
Luckily most of the things you mentioned are styling and content based, and not related to the functionality of the Combobox widget.
For example, the font sizing, plus content widths relative to small screen devices, which are also relative to portrait to landscape device modes, will add complications for any UI. There are options that may help with styling this type of layout better for small devices, such as using CSS Media Queries
https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#orientation
In this case too, I've added a lot of content within the dropdown, which isn't really typical for most auto suggests, thus accounting for the wider than usual horizontal display. I'll experiment with the media queries and see if it's possible to conditionally display this better and look into cutting down the extra verbiage within the listbox options as well.
> * Odd behavior of suggestions - typing "Ch" offers "Butcher" not "Chalker" as first list item voiced
This gets more into the functionality of the Combobox widget. The widget supports three modes, first letter matching, substring matching, and whole word matching. In this case, substring matching is set so that the letter combinations that are typed will match any substring within the Option nodes. This is configurable though. Also, the widget distinguishes between 'editable' and 'readonly' Comboboxes as well.
You can see the more traditional use of editable and readonly Combobox dropdowns here, where State is editable and Country is readonly.
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm
(This has first letter matching enabled.)
And here is an example of whole word matching:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20with%20Word%20Match)/demo.htm
(Which matches any combination of these words within each Option)
And here is an example of a readonly simulated Combobox:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm
(Which matches the first letter typed for each Option)
All of these use the same Combobox widget, which converts a standard HTML select element into the associated dropdown including requisite ARIA attributes, even though all of the content, modality types, and styling are variable.
> * After selecting an option that is placed into the input, I seem to lose VO focus, I.e. I think it is no longer on the input so that the next focus point would be submit. The focus is instead on your text instruction at the physical position where the list box focus was before selecting the item
This is a difference with touch devices, where focus doesn't necessarily match programmatic focus. The Combobox widget for example always sets programmatic focus back to the input or focusable triggering element in the case of a readonly simulated Combobox, but when you interact with the screen via touch, focus is always where you touch irrespective of where programmatic focus was initially set.
> * Deleting content in the select makes the page immediately scroll to the list box top so the input where deletion takes place is no longer visible
This likely goes back to the CSS styling issue where the content and sizing are too large for a small screen like this, because the widget uses optionNode.scrollIntoView() when a new suggested item is displayed in order to account for default options that are set within the HTML select element, such as when 'United States' is selected by default within the readonly simulated Combobox. This will cause the default selection to automatically scroll into view when the listbox is rendered. The same thing happens when typing a letter like 'p' in such cases to automatically scroll the option that starts with that letter into view. So if the screen is too small, and the content is too wide, it scrolls the item into view and moves other things like the input offscreen.
This will likely be fixed when I get the UI to change on smaller device sizes using the CSS Media Query or something equivalent for styling. Being blind sucks for stuff like this since I can't verify what I'm doing visually, so it may take me a bit to work out the calculations.