mynamesleon / aria-autocomplete Goto Github PK

This is a suggestion to enhance this plug-in : add a "delete all" control, to remove all selected items at once.

Hello,

Thanks again for your plug-in, which we use on several projects.

We realized recently that if we use it on required fields (<select required>), it seems not to work correctly :

• no required attribute on the generated input, so no screen-reader announcement that the field is indeed required
• when trying to submit the form without filling that field, the browser wants to display the native HTML5 error message on the required select, but as it's invisible (with display none), it's not possible : so the form isn't submitted but there is no clue for the user to know what's wrong

Am I missing something in the process, is there a way to handle correctly that kind of required fields ?

If a user is using assistive technology without touch support, it would be beneficial to skip the directions on how to use with touch support

There is a , the list of which depends on other parameters. The hidden changes, but the outer list does not. How to update everything?

Hello,

As my colleague Pascal already said, thanks for this very good and useful plug-in.

We had an exchange with an accessibility expert about it, and he listed some corrections to do :

• span.aria-autocomplete__selected (multiple selection tags) : on click (deletion), put the focus back on the input field
• ul.aria-autocomplete__list : add aria-describedby="xxx" where xxx = label id
• span.aria-autocomplete__sr-assistance :
  • replace with a "p" instead of span
  • mask with display none
• span.aria-autocomplete__sr-announcements
  • replace with a "p" instead of span
  • empty when the suggestions list closes
  • empty after 2s when deleting an item, if no other action changes its content in the meantime

We're going to try and fix some of this things by ourselves, and maybe we'll submit some PR, but feel free to give your insights on these points !
Thanks in advance.

Hello there,

I'm currently trying to implement your autocomplete as a replacement for "select2" in my project. While the main focus of your library obviously lies on the "autocompletes", I figured using the "showAllControl" option, the usage as a "select-box" with build-in search would work as well. And generally speaking it does.

One Problem I have noticed is however, that there is an issue when you hydrate a select element which contains an "empty" option, like this:

<label for="select-cf222fe5b2">
    Filter by degree
</label>
<select id="select-cf222fe5b2" data-ref="select">
   <option value="">All degrees</option>
   <option value="16_30">Bachelor</option>
   <option value="17_31">Master</option>
</select>

With a js like this:

AriaAutoComplete(select, {
    noResultsText: this.noResultsText,
    multiple: this.multiple,
    showAllControl: true,
    srDeleteText: this.$t('c.select.js.srDeleteText'),
    srShowAllText: this.$t('c.select.js.srShowAllText'),
    srSelectedText: this.$t('c.select.js.srSelectedText'),
    srListLabelText: this.$t('c.select.js.srListLabelText'),
    srAssistiveText: this.$t('c.select.js.srAssistiveText'),
    srResultsText: length => this.$t('c.select.js.srResultsText', {count: length}),
    onFocus: () => {
        this.$proxy.setTimeout(() => {
            if (this.instance) {
                this.instance.filter('');
                this.instance.open();
            }
        }, 100);
    }
});

Only shows "Bachelor" and "Master" in the Dropdown. I had a brief look at the code and I see, that you deliberately remove the empty option here.

For now, I resolved the issue by setting the value of the empty option to NULL, because I only use the result in JS. For the usage in a PHP form I think it would make sense to allow option elements with an empty value via the options.

Have a great day and stay safe.

The included filtering currently only searches for matches between the input value, and the label property in the processed data. It might be useful to be able to search against other properties too, potentially even Arrays, but only against Strings.

E.g. when searching against US universities:

[{
    'label': 'UCI Paul Merage School of Business',
    'metadata': ['Irvine', 'Orange County', 'California', 'Los Angeles']
}, {
    'label': 'Clarkson University',
    'metadata': ['Potsdam', 'New York', 'Beacon']
}]

Note: This would have a performance impact, particularly in older browsers.
Note: when checking for the starting selected options, still needs to only match against the value.

When there are several autocompletes on the same page, some controls have the same text : "show all" and "delete all" controls, selected options.
This makes them hard to distinguish while navigating with a screen reader.
To differentiate them, the suggestion of our accessibility expert is to add a aria-describedby attribute pointing to the label of the corresponding autocomplete. The label text would then supplement the control text to make it more explicit.

Hello @mynamesleon, thank you for your work on this very useful tool.

Following the issue #9 in which it was requested to move the focus back on the input element after deleting the last selected item.
I have taken good note of your concerns for the users who would want to delete only a few items. However, in our projects, we still find ourselves in need of moving the focus back on the input element after deleting all the selected items.

We chose to perform this action using the onDelete callback, but it turns out that this callback is executed in the middle of the delete actions, and not at the end as we expected. It resulted in the focus being moved to the input before the deleting action is completed, and so the input receives the Enter key action, which triggers the form submission.

Here are a few solutions we've investigated to overcome this:

• provide a boolean option to move the focus to the input element after the last selected element is deleted, instead of letting it go back to the body, then to the next available element?
• always execute event.preventDefault when the input receives the Enter key action?
• call onDelete after the delete action is completely performed: could we consider a beforeDelete / afterDelete callback?

What do you think?

Thank you in advance

When using iOS VoiceOver, it seems that the first selected item is not announced.

Here is the captured result of typing a letter and pressing the down arrow

Hello Leon,

aria-autocomplete is really useful. Thank you for this very good job.
I have an issue with it. Why empty the input field on blur ?
User should be able to submit the text field even if the autocompletion has no results.
Why did you make this choice?
Is there a way to keep the contents of the input even if there are no results?
Thanks.

Pascal.

The rendered list currently only includes the label. It would be more extensible to allow customising of how this renders to include other data. Would need to be a Function that returns a String.

Note: render the label regardless, and render the additional String afterwards? or allow full control?

Hi,
Thank you for this module! It does everything I need <3

I made a form that has a "clear all" button for clearing all values in my input fields (most are not using autocomplete). I would like this button to do the same thing as the "Delete All" button that is created with the deleteAllControl option. Is there a method defined for this?
All I can find are the functions "close", "destroy", "disable", "enable", "filter" and "open". If I use destroy() and recreate my autocomplete, it returns to the same state (e.g. with its previous selections).

Best regards,

The text input has its aria-describedby attribute set to point to sr-assistance at initialization, but it's removed when the input has some value (and comes back again when the input is emptied).
We can see the logic in setInputDescription().

This means that the navigation help text is not returned by screenreaders as soon as the input is filled, although it should be available at all times (especially when the user hasn't interacted yet).
Was there a problem with letting this description permanently available ?

This is also a point notified by our accessibility expert : while navigating with the keyboard, we want the suggestions list to stay open as long as we're still in the container.

There are special conditions to handle this in the handleComponentBlur() function, but it seems that it's not working : when focus goes from input to "show all" or a selected item, the suggestions list closes (this can be tested in example 2).

It seems that it's because the 'isSelectedItem()' function returns undefined instead of false, hence the condition isn't correctly interpreted.