How do I add screen reader functionality to select-2 combo box and bootstrap's datetime-picker?

Question

My pre-existing website has select-2 combo boxes for drop-down lists and I also have a Bootstrap Calendar widget. These work great, but aren't accessible to people who may have disabilities. I am attempting to add screen reader functionality so that the website and these widgets may be useful for everyone.

I have done extensive research into trying to locate a solution, have added aria-label code through the inspector and have looked at various examples of drop-down lists and calendar widgets at various sites. I would like to include some code of my various pages and screenshots of my inspector in case those provide useful information. Please let me know if any additional information is required/wanted. Thank you in advance for taking the time to assist me.

CSHTML page

<div>
    @Html.CustomEditorFor(model => model.HouseDetails.HouseTypeID, CachedTableTypes.CUSTOM_HouseTypes)
</div>
        
<div>
    @Html.CustomEditorFor(model => model.DateStart)
</div>

Extension.cs page

public static MvcHtmlString CustomEditorFor<TModel, TValue>(this HtmlHelper<TModel> htmlHelper, Expression<Func<TModel, TValue>> expression, CachedTableTypes cacheTableName, object htmlAttributes = null, bool excludeLabel = false, string appendedText = null)
        {
            var selectedValue = GetValue(htmlHelper, expression);

            string editor = SelectExtensions.DropDownListFor(htmlHelper, expression, WebHelper.GetSelectListFromCache(cacheTableName, (string)htmlHelper.ViewData["CurrentCulture"], selectedValue)).ToString();

            return htmlHelper.InputWrapper(editor, expression, htmlAttributes, excludeLabel, appendedText);
        }

Calendar Inspector page Dropdown Inspector page

Answer 1

Adding ARIA roles and states to a 3rd party library via its API is not a viable option.

The APIs are rarely flexible enough to hook into the component’s life cycle to add these heavily state-dependent parts. Even in the rare case where it might be possible, it requires a lot of code which is a performance issue, and impacts maintenance.

When using 3rd party component libraries, which were chosen without taken their accessibility into account, you have two options, as I see it.

Option 1: Get involved in the library’s development

If you got the budget to improve accessibility for components you use from an open source library like select2, you should contribute the improvements directly to the project. It’s time to give back to the open source community.

Do your screen reader testing, file issues on the Github project, fork the source code, make your improvements and create a pull request.

Until the PR is accepted, you could use and maintain your own fork for your project.

Option 2: Replace with an accessible library

Depending on how strong your dependencies are, you could replace certain component libraries with more accessible ones.

When choosing a library you should have a clear idea of your quality criteria, to be able to make a comparison.