Chosen: Accessibility issues with Chosen

relevant piece from that discussion:

Way too much needs work. Appears like accessibility hasn't been considered at
all in this widget, so a lot of WAI-ARIA and JS work would be needed to *
attempt * to make this conform to WCAG 2.0.

The biggest issue, from a 30 second review with FF6 / JAWS12 is that the
component is represented as a input type=text followed by an unordered list
of all options (243 for countries) that the user needs to navigate past to
even ignore the field.

The search text field could use a label, for starters, but that is easy to fix.

A bigger issue is that the generated list items do not have anchors in them...can screen reader users take action if they know what the list items are for?

This is a very nice plug-in! I really like the functionality.
Is there going to be any future development into better accessibility? Adding WAI-ARIA to make it conform to WCAG 2.0???

I have just read this article on thefilamentsgroups's website. The ARIA roles could lend itself to Chosen:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

For example: the Chosen results UL would have role="menu" aria-activedescendant="active-menuitem" applied to them and the results <li> would have role="menuitem".
The search box in the Chosen drop down would probably need some sort of ARIA role too??

@dotdreaming you point to the right documentation, but the roles you mention are not quite correct.

I think the following roles should be used:

• combobox.
• option

I think it would be really cool if someone would really dive into the WAI-ARIA documentation and apply it to chosen.

If I can find the time I may do this myself. It doesn't look like it would be very hard to do.

Any movement on getting ARIA into this project?

Even if it does work with Assistive Technology, it also needs to be tested to see that it also works with keyboard only users.

Btw, this is just a way to check out the low hanging fruit for accessibility improvements, but WAVE identified some pretty basic things that should be cleaned up -> http://wave.webaim.org/report?url=http%3A%2F%2Fharvesthq.github.com%2Fchosen%2F&js=2

Any of these accessibility issues been address? I've really like to use this on our main university site but these accessibility issues put me off

+1 - We've received feedback from a blind user that Chosen dropdown lists are hard to use and they're having difficulties selecting options. They are using JAWS 14 as their screenreader.

Tried out just using a keyboard only for navigation. Selecting items works very well and intuitively (down to open the list for a new item, up/down to navigate the list, esc to close the list, enter to select). Removing items from the multiselect was straightforward (backspace) however clearing a single-select dropdown presented itself with more challenges. It looks like, having selected an item, I can press down to open the list again and then navigate up until no option is selected (much like a normal dropdown works if your first item is blank as the examples are), but I'm unable to press Enter to select the null option. Some method for deselecting an option completely (or at least a blank default option) would be very useful.

Also not sure if this is worthwhile, but I noticed that the data is still stored in the hidden select control (I assume this is how it's passed into the form). It might be worthwhile to update the Chosen dropdown when the select is is changed as well - I was debating if this would satisfy criteria 4.1.2 from WCAG, since UAs can interact with the select control programmatically and we could treat Chosen as a facade on top of it for the purposes of accessibility.

for the second part, we are requiring to trigger a listz:updated even when you change the value of the select control programmatically to update chosen.
This is required because browsers don't trigger an event when the value is changed programmatically to let Chosen know about it (and it they were doing it, we would still have to avoid infinite loops as we are also changing it programmatically)

I'm going to look into adding accessiblity today. @marklagendijk I think what you mentioned the best way to go atm. Ill update on my findings.

This may be helpful, it may not, but we have strict accessibility guidelines to follow and with version 1.0.0 our client's accessibility tester came back with the following comments:

1. the 'select' associated with the 'label' has display: none; and so the
   'label' is effectively orphaned. The 'div class="chosen-container-single"' that takes
   its place as the form control has no programmatic accessible name or label.

2.There's no visible focus on the faux dropdown.

1. There's no visible focus on the link within the faux dropdown.

I am using this in conjunction with the Drupal Chosen module. We also have a blind tester who noted that once he got to the input he was not aware of being able to type, nor the results returned, including "No results found".

@marklagendijk
Any progress on this issue. I am looking at re-introducing the issue to add Chosen to Drupal core and this is the main blocker.

I found a really good example of how this can be done here:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Here's the javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

I believe that this maps almost exactly to the basic chosen functionality.It looks pretty simple to implement using the listbox and multiselectable aria properties
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria-multiselectable

I would make a patch myself but I'm not so hot at js.

My PR linked above provides a solution via a much simpler approach centered around the principles of progressive enhancement instead of taking the "deep dive" into making a completely accessible widget out of the current Chosen codebase. I welcome any and all feedback.

Why focus on ARIA when it is still not properly supported by IE8? Unfortunately this 5 year old browser is still in the list of common browser. This means that wile undergoing an accessibility scan an implementation that depends on ARIA will fail.

Why not use a fallback method that simply disables chosen alltogether and provides a user with the original select? This could be achieved by adding a (hidden) link that would use a small piece of javascript code which disables chosen.

Resource concerning IE8 ARIA support : http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

You could just do browser/feature detection and not use Chosen when IE8 is used.

@Daniel15 That would probably even be an easier fix. Thanx for sharing your thoughts. In my post i was merely trying to point out that implementing ARIA (for now) does not mean it is accessible and ready for usage on applications that need to be WCAG 2.0 compliant.

Would love to see this working. Screenreaders and keyboard-only users really need access to these fields. I'm not so concerned with IE8 but at least a solution for modern browsers would be acceptable. I quite like the IE8 fallback idea. It looks like there are two good PRs up - I'd love to see either one of them merged in.

a big +1 on this please

+1 (+) We need to have this in Chosen. It's a problem

aria-label (property)

Defines a string value that labels the current element. Also see aria-labelledby.

The purpose of aria-label is the same as that of aria-labelledby. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.

If the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. There may be instances where the name of an element cannot be determined programmatically from the content of the element, and there are cases where providing a visible label is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g. the title attribute in HTML [HTML]), yet this may present a browser tooltip. In the cases where a visible label or visible tooltip is undesirable, authors MAY set the accessible name of the element using aria-label. User agents give precedence to aria-labelledby over aria-label when computing the accessible name property.

@Natshah Can you do a pull request with the change?

@Natshah actually, can you review https://github.com/harvesthq/chosen/pull/2047 to see whether it implements it the right way ?

Hi,

I have this fixed for my case at this link
https://www.drupal.org/node/2384865

Thanks.

Rewarding :)

Yes. That what should be as something as in the following code. .

      if (this.is_multiple) {
        this.container.html('<ul class="chosen-choices"><li class="search-field"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'" value="' + this.default_text + '" class="default" autocomplete="off" style="width:25px;" /></li></ul><div class="chosen-drop"><ul class="chosen-results"></ul></div>');
      } else {
        this.container.html('<a class="chosen-single chosen-default" tabindex="-1"><span>' + this.default_text + '</span><div><b></b></div></a><div class="chosen-drop"><div class="chosen-search"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'"  autocomplete="off" /></div><ul class="chosen-results"></ul></div>');
      }

But we can use this code:

        $(".views-exposed-widget").each(function( index, element ) {
           $(this).find('.form-type-select .chosen-container input').attr("aria-label" ,$.trim($(this).find('label').text()));
        });

Thanks.

Rewarding :)

Any update on this? We recently implemented chosen, and had feedback from users using assisstive technology "Jaws" that they cannot use the select fields at all.

Seems like an important issue to look into. Has there been any movement on this front?

Nothing that I know of, unfortunately it's very hard to replicate issues given the massive combinations of assistive technologies with browsers and OSes... Normally as long as you can keyboard navigate + you have correct ARIA implementation it should work in the majority of cases.

For a quick fix I have resorted to ensuring that screen readers at least get to use the original select field. For this, instead of hiding the select element, I am adding a screenreaders-only class and aria-hidden:true on the generated chosen container.

So, in chosen.jquery.js lines 599 to 605 look like this:

container_props = {
        'class': container_classes.join(' '),
        'style': "width: " + (this.container_width()) + ";",
        'title': this.form_field.title,
        // hide widget for screen-readers
        'aria-hidden': 'true'
};

And line 616 looks like this:

      // instead of hiding the original select field, adding the .sr-only class to keep it accessible for screen readers
      this.form_field_jq.addClass('sr-only').after(this.container);

It's not a perfect solution, as both the hidden select and the widget are keyboard focusable, but it's way better than having an inaccessible widget.

This worked for me.
I followed all of the above advice and I changed the following line:

this.container.bind('mousedown.chosen', function(evt)   // around line 630

to:

this.container.bind('mousedown.chosen keydown.chosen', function(evt)

Thanks

Try if it works out. Structure should be this way. :)

I took a stab at adding some ARIA elements based off the work @kirstenmalin had done. That work was a nice push toward A11Y, but was missing a few items which I added.

I've got a branch available here that does the following:

ARIA Labels and Other Helpful Attributes

• Adds the following aria elements to the search input box
  
  
  
  • role="combobox"
  
  
  • Used to indicate that users can type to select an option or add new elements to a list
  
  
  • aria-haspopup (implicit when using the combobox role)
  
  
  • Used to indicate that this box has a related menu
  
  
  • aria-expanded
  
  
  • Required when using the combobox, indicates that the results list is visible or hidden
  
  
  • The state needs to be updated dynamically as the chosen field is activated/de-activated
  
  
  • aria-activedescendant="id_of_highlighted_option"
  
  
  • Used to indicate which options is the currently selected value
  
  
  • This needs to be updated as a new option is selected
  
  
  • aria-owns="id_of_list_of_options"
  
  
  • Indicates the list of choices that this search box is related to
  
  
  • aria-autocomplete="list"
  
  
  • "If an author sets a combobox's value of aria-autocomplete to 'list', user agents MUST expose changes to the aria-activedescendant attribute on the combobox while the combobox remains focused. If a change to the aria-activedescendant attribute occurs while the combobox is focused, assistive technologies SHOULD alert the user of that change, for example, by speaking the text alternative of the new active descendant element. Authors SHOULD associate the combobox textfield with its listbox using aria-owns."
  
  
  • aria-labeledby="id_of_field_label"
  
  
  • This is the ID of the form label element that chosen is replacing
  
  
• Adds the following attributes to the list of options
  
  
  
  • id
  
  
  • A simple ID based on the form field ID to be targeted by the aria-owns attribute in the search input box
  
  
  • role="listbox"
  
  
  • "A widget that allows the user to select one or more items from a list of choices."
  
  
• Adds the following attributes to each individual option in the list of options
  
  
  
  • id
  
  
  • A simple ID based on the index of the option in the list and the form field ID to be used by the aria-activedescendant which indicates the currently selected element
  
  
  • role="option"
  
  
  • A selectable item in a select list.
  
  
  • aria-busy
  
  
  • The reason we need this is that when Chosen is initialized on a field, it _does not_ build out the options list until the field is first activated.
  
  
  • This is an issue for assitive technology, as well as scanners that look for accesibility issues. Since the search box (role="combobox") is now delcaring it owns a listbox (aria-owns="id_of_list_of_options"), the listbox (our results list) _must_ have options within it OR be delcared as busy in order to comply with the spec.
    
    
    
    
    
    • I'm not even 100% sure that this is the right move. It certainly prevents the fields from being flagged by scanners, but these aren't entirely busy, we just haven't yet built out the options.
    
    
    
  
  
  • I'm hoping someone with more A11Y experience can weigh in on this.
  
  
  • I also considered a more radical approach, which involves building out the result list when a field is first activated, but that involves adding a new trigger to Chosen.
    
    
    
    
    
    • This trigger was essentially a pass through to the winnow_results method, which built out the search results (still hidden), but it made scanners happy.
    
    
    
  
  

Managing State

• Managing the aria-expanded attribute
  
  
  
  • In order to indicate when the search results should be relevant to assitive technology, we need to toggle the aria-expanded attribute as fields are activated/deactivated.
  
  
  • The easiest way to do this (AFAIK) is to adjust the attribute during the close_field and activate_field methods.
  
  
  • A simple switch from true to false or false to true in each of these methods is sufficient enough to keep the state updated
  
  

I am going to start using this version on several of our projects, and will keep updating my branch with changes as we get a more detailed look at our projects from an A11Y view.

Thanks to all who read this far, I know it's a lot and please, if you have feedback, let me know! I want to push this as far along as possible.

@cooperfellows please open a pull request with your changes

@stof Done, but as I said, I'm no A11Y expert, and I plan on doing some more testing. I just wanted to share around my first stable pass at this.

Is there any "official" update with this? Have any changes been made based on @cooperfellows efforts?

Reason I ask is that we're getting increasing numbers of Jaws users reporting the widget as unusable, effectively rendering the form they are looking at unusable.

We can replicate, so happy to assist / share examples if that helps?

The pull request was made (it had some minor issues that had been resolved after the fact) but nothing has happened yet. The branch I am using in production right now is here:

• https://github.com/cooperfellows/chosen/tree/a11y-updates

I'd love some other feedback though. I don't have Jaws, so i'm relying on audits from various online tools.

So that branch is basically current production plus your changes, or a previous version with recent changes not yet merged in?

(Thanks BTW)

Yes, that's right @wcndave. Though the PR could really use some other eyes for review.

@cooperfellows I'm happy to assist with accessibility testing as I need to port an existing chosen implementation into a new build that needs to meet WCAG 2.

Any update on your pull request?

Silly question - do you have a compiled JavaScript version that I can download?
Or do I need to install coffeescript and compile myself?

@KITSKevinBonett Thanks for the help!

Attached is a zip of the jquery and proto type version, both compressed and un-compressed.

compiled-a11y-chosen-jquery-proto.zip

@cooperfellows That was quick. I'll add to our project, do some testing, and let you know...

@KITSKevinBonett Ya, I'm looking to get some more eyes on it, as I am no A11Y expert. So any feedback (harsh and positive) is appreciated.

Hi @cooperfellows - I've reviewed your implementation - very good indeed.

There are some issues which may not be (easily) resolved due to screen reader / browser incompatibilities.

I have documented my findings in the attached. I have made 1 or 2 minor recommendations which I hope you find useful.

_UPDATE_

1. Some of my comments mentioned functionality that is local to our implementation - I have removed these.
2. Issue with typing inside "combobox" and hitting ENTER - our form submit is not being activated - again, this is a local implementation issue.
3. The ZIP below has been updated to remove (1) and (2).

aria-chosen-plugin.zip

Hi @cooperfellows - did my audit make sense?

Hi @KITSKevinBonett I've been away for a week on vacation. I will take a look at this as soon as I'm caught up on my other work. Thanks for the feedback though, I'm sure it's helpful.

@KITSKevinBonett Thanks for the audit, this seems pretty thorough. I've broken my thoughts down based on the sections of the audit as you laid them out.

HTML markup generated by plugin

• Is there feedback here? Or are you just showing what get's generated?

Keyboard Only Behavior

• "However, when option has been selected, keyboard focus gets lost on tabbing again."
  
  
  
  • I'm thinking this could this be solved by toggling the aria-hidden attribute on and off as that element is made visible/hidden?
  
  
  • I will look into this approach.
  
  
• "CSS Disabled Issues"
  
  
  
  • Standard select is visible
  
  
  • I can't recreate this, can you give me a screen shot or screen cast or something?
  
  
  • No visible cue when highlighting results with keyboard.
  
  
  • We could wrap the text of the currently highlighted item in an <em> tag, which does get italicized (at least in Chrome).
    
    
    
    
    
    • The potential issue here is that the search also uses <em> to indicate text matches, so I'd be worried those would potentially conflict with each other.
    
    
    
  
  

Screen Readers

• I don't have access to JAWS, so I won't be able to do too much here. I will spin up a trial when I get some more time to see what I can find.
• Screen readers are the area I would really appreciate some more help with, so thanks for the detailed breakdown.

Aria Thoughts

• I can remove the haspopup attribute, as you noted, it's redundant.
• The reason I added aria-busy, is that by default, Chosen does not generate any list elements in the hidden div's until focus is placed.
  
  
  
  • This means that the role="listbox" element has no options by default, which was giving me issues when scanning this with tools. By adding the aria-busy element at the start, it is ignored by those tools.
  
  
  • The reason for the issue is that a listbox element _must own_ an option element (source)
  
  
  • It gets removed the first time the list is populated, so it seemed to me like a no-harm no-foul situation.
  
  
• Adding aria-selected seems like an obvious step, can't believe I missed that. Thanks for catching it.
  * Closing Thoughts *
  Did you write up the HTML for this audit yourself, or did a tool create this for you? It's very helpful so thanks again.

@cooperfellows - answers to your questions:

HTML markup

• Just showing what's generated during each phase of plugin's behaviour.

Keyboard behaviour

• The "lost focus" is only in Firefox. You could add tabindex="-1" to prevent focus, then remove it again. Then you wouldn't need ARIA.

CSS disabled

• Basically, the original SELECT is visible on the page and usable with UP | DOWN arrows because default browser behaviour shows the various options as you navigate through them.
• The plugin-rendered HTML is also visible, but the dropdown doesn't indicate which "option" is highlighted.
• You suggested using an EM. Use STRONG instead - it has more semantic meaning than EM in HTML5. See http://html5doctor.com/i-b-em-strong-element/
• But I don't think this is a major issue as users can still use the SELECT.
• See screenshot

Screen readers

• This is a difficult one because results vary depending on which combination of browser and screen reader is being used, and which versions.
• What I would say is that your accessiblity updates to the plugin in terms of ARIA roles / states / properties are aligned with W3C / WAI recommendations. So that's good news. :)
• It's up to the browser & screen reader manufacturers to ensure their software adheres to these.

ARIA

• Your explanation for "aria-busy" makes sense. Even if it was obsolete, it won't cause any issues being there.
• Audit HTML. Hand crafted. I've been building a UI compnent library / living style guide for the company I work for, so I just used components from there. Didn't take long at all. The hardest part was re-listening to all the screen reader output to make sure I had captured everything correctly.

Hope this all helps with your pull request. You've done a great job with the A11Y. :)

Hello,

I am blind. I have tested @cooperfellows 's work with JAWS. It work perfectly. The selected option is spoken as I arrow through the options.

Any news on merging this in master?

In my daily work, I use MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), whose developpers have recently decided to use "chosen" for autocomplete combo boxes. It has become a nightmare for me.

Thank you in advance for your help.

After a few tests, I can confirm the compiled version (.zip archive) posted above (on July 1, 2016) works.

However, when I try @cooperfellows 's branch, or when I clone the @cooperfellows 's branch and then merge with harvesthq/master, the menu options are properly spoken by JAWS but the ENTER key does not submit the form.

Hi @obert01, thanks so much for taking a look at this using JAWS, that was a big piece I was missing during my work.

This branch is way out of date from the current harvesthq/master branch, I will likely need to review the changes and adjust my PR in order to get things back to a working state.

I will try to get to this sometime before the end of the month, I'm pretty backed up at work right now.

I would love to get one of the contributors eyes on it again once it is updated, so I will ping @stof (who looked at the initial pull back in 2016) once I've got it updated.

Thanks a lot.

For your information, I can test with all combinations of JAWS and NVDA screen readers, with the following browser : Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

Any progress on this?

I'm sorry to insist, but my daily work suffers of this lack of accessibility.

Moreover, adding accessibility support would allow Chosen to be used in public sector / administration websites, since regulation in more and more countries is going in this way.

Thank you

Hi,
We have an application that has used chosen and now we need to support accessibility but going through this what I can see is this has not been merged yet. It will be really helpful if @cooperfellows can finalize this and merge please.

Hi @obert01 and @csmuthukuda,

I've just made updates to get my PR up to speed with the latest version of Chosen, please take a look here:
https://github.com/harvesthq/chosen/pull/2596

You can get a copy of my forked repository and test on your end. I would love some real life feedback.

It passed all of the TravisCI checks, but I don't think they cover any A11Y issues. Let me know what you think.

Hi @cooperfellows ,
Thanks, a lot for your dedication to keeping this alive. I'll test this and let you know the feedback of this. I really hope the owners will consider merging this to the master. This is a mandatory requirement now.

Thanks @csmuthukuda I would love for it to be merged in....

@pfiller @stof @tjschuck @koenpunt, anything I can do to help get this looked at? It really is a missing piece to an otherwise incredibly awesome system.

Hi @cooperfellows,

I have tested your awesome work with most current web browser and the JAWS and NVDA screen readers. Thank you !

Arrowing through the options with the keyboard works well: speech and braille feedback is perfect, meaning that all ARIA attributes are well defined. However, when I press ENTER to choose an option, nothing happens. I am not experienced enough with JavaScript to determine if the issue comes from Chosen, or if it is present in the application using it.

To reproduce, try choosing an option in a Chosen combobox only using the keyboard: TAB to focus the combobox, arrow keys to browse the list, ENTER to select.

Once again, thank you very much.

Thanks for that information @obert01. I will take a look and see what I can find.

@obert01 Can you try using this JS fiddle to confirm it's working/not working? THis fiddle is loading the compiled jQuery version of my latest commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

I am able to navigate that dropdown using my keyboard (Chrome Latest), but I am NOT running a screen reader.

Let me know what you think.

Hi @cooperfellows,

No problem with your JS Fiddle. Thus I suppose the problem is due to the way Chosen is used in MISP (https://www.misp-project.org/).

I will check this with the MISP project team.

Thanks

Thanks @obert01. Please do let me know what you find out. It could point to an incompatibility with a specific set up of Chosen, so if there is a way for me to see how MISP utilizes it, I can try to take a look at their implementation.

Is chosen used somewhere publicly?

@cooperfellows can you please give me a new build with the latest changes I don't know how to build it.

@obert01 @cooperfellows I just tried the Fiddle with NVDA, it seems that the keyboard navigation works perfectly (including selecting with ENTER key). However, when I navigate through with up and down arrow keys, the screen reader reads, "________not selected", i.e. "Bermuda not selected". Is this the expected behavior?

I have the same issue as @woenlee. It is not so harmful. But maybe, the way the "selected" attribute is set on the selected item should be checked.

What is the expected behavior when you "enter" and "exit" a list item? When
you navigate down onto a new item, should it read out the newly selected
item? Does it also announce what is NO longer selected? @obert01 @woenlee

On Sun, Aug 25, 2019 at 12:18 PM Olivier BERT notifications@github.com
wrote:

I have the same issue as @woenlee https://github.com/woenlee. It is not
so harmful. But maybe, the way the "selected" attribute is set on the
selected item should be checked.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/harvesthq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CWTYY#issuecomment-524642787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

--
~Cooper

@cooperfellows After running some axe accessibility tests, I seem to have found a bug in your PR, which explains why it was doing that. In line 342 of Abstract-chosen.coffee, the input has 2 roles assigned to it, "combobox" and "listbox".

<input class="chosen-search-input" type="text" autocomplete="off" aria-expanded="false" aria-haspopup="true" role="combobox" aria-autocomplete="list" autocomplete="off" role="listbox" /> </div> <ul class="chosen-results"></ul>

After giving the

Paying customers of Harvest here, and testing to be internally accessible ran into this. Accessibility is a must, and we will move off of Harvest if this is not addressed, if a maintainer with Harvest does not at least show some support to this soon.

@obert01 Can you try using this JS fiddle to confirm it's working/not working? THis fiddle is loading the compiled jQuery version of my latest commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

I am able to navigate that dropdown using my keyboard (Chrome Latest), but I am NOT running a screen reader.

Let me know what you think.

@cooperfellows
I was testing this JS Fiddle with JAWS 2019 and experienced something slightly different when navigating the options with the up and down arrow keys.
On Google Chrome 71.0.3578.98:
JAWS would not read the current highlighted value unless the list did some scroll/rendering. i.e. If the list is showing

<option selected="selected" value="United States">United States</option>
<option value="Afghanistan">Afghanistan</option>
<option value="Albania">Albania</option>
<option value="Algeria">Algeria</option>
<option value="American Samoa">American Samoa</option>
<option value="Andorra">Andorra</option>
<option value="Angola">Angola</option>
<option value="Anguilla">Anguilla</option>
<option value="Antarctica">Antarctica</option>

9 options, JAWS does not read the highlighted option when pressing down until you get to the 10th option at Antigua and Barbuda. The box does a little auto scroll to highlight Antigua and Barbuda and then read the option.

On IE 11.0.9600.19463: Navigating with the arrow keys seems to read the current highlighted option correctly going up and down. Does not require some sort of render.

Would like to know if anyone else has experienced this. @obert01 @woenlee

Hello and thanks for your work.

Unfortunately, this doesn't work properly. It is extremely hard to describe, as the behavior changes in function of the browser or screen reader used.

I think some aria properties are not present or are not updated. Here the general problems I encounter:

• Scrolling issue: when I arrow down and reach the end of the visible list of items, I have to press two times on the down arrow to focus the next item.
• When I press ENTER to select an item, the focus is not released. The expected behavior would be that the screen reader goes back in quick navigation mode and let me read the rest of the web page. Instead, the arrow keys are still controlling my choice in the list.
• The current scripts do not allow to know if proposals are displayed and how many are they. In most accessible select plugins I know, JAWS/NVDA announce how many results match the string entered in the text input.
• Finally, I have the impression JAWS does not understand if the list is collabsed or expanded. Sometimes, after making a choice with ENTER and trying to read the rest of the page, JAWS still reads the latest proposals that have been displayed.

Good points:

• The auto-complete part works well. If I enter "fra", JAWS pronounce "France", and I can press ENTER to select.
• The items are read properly as I arrow in the list.

I unfortunately don't know many things in regards of ARIA, JavaScript and web in general. I suggest you to be sure the maximum of ARIA properties are properly set and updated.

Please find below the demo and code of a JQuery plugin that perfectly interacts with screen readers:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

I am sorry not being able to help more.

Don't hesitate to post new demos of your work. I am happy to test for you.