Thanks for opening this pull request! 💯

This is a community-driven project, and we can't do it without your participation. Please check out our contributing guidelines and review the Contributor Checklist if you haven't already, to make sure everything is squared away. CircleCI will take about 10 minutes to run through the same items that are on the Contributor checklist with a pass/fail check below. Please fix any issues that cause CircleCI to fail or ask for clarification--we try, but sometimes the errors can be unclear.
A maintainer will try to respond within 7 days. If you haven’t heard anything by then, please bump this thread. To ensure codebase quality, large code line changes may take more than 2 weeks to review, but may take longer depending on the number of pull requests in the queue. Feel free to ask for a status update at any time--you won't be bothering anyone.
Once feedback has been given, please reply to the feedback giver once the feedback on been addressed, so that they can continue the review.
If you need a release while you are waiting for a code review, you can publish a built tag to your own fork. See directions in the release README.

Thanks for the contribution! Before we can merge this, we need @anunay999 to sign the Salesforce Inc. Contributor License Agreement.

@anunay999 I tested out your change in storybook. I think removing readOnly from input might not be the right fix for this issue and here is why:

• 1. If a text input is not readOnly, it will show a cursor when focused indicating you can edit it, which is not what we want here.

• 2. I think the right solution would be to use a div or span instead of an input here. (See here: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/)
• 3. I noticed some other issues with how combobox is implemented. For example we have a container that wraps around the input widget that has role="combobox" instead of the input having role as combobox.

I think combobox might require a factoring to follow the most up to date accessibility standard.

@anunay999 You may want to check out this blueprint. https://www.lightningdesignsystem.com/components/combobox/#Base-Combobox

I'm pretty sure the blueprints used to use read-only. It looks like the LWC version of this still uses read-only, too. https://developer.salesforce.com/docs/component-library/bundle/lightning-combobox/example

When reviewing the Base Combobox blueprint, keep in mind it may be using a different ARIA specs: 1.0 vs 1.1 vs 1.2.

The latest version of SLDS is using a span: <span class="slds-truncate" id="combobox-value-id-96">Select an Option…</span>

@anunay999 You may want to check out this blueprint. https://www.lightningdesignsystem.com/components/combobox/#Base-Combobox

I'm pretty sure the blueprints used to use read-only. It looks like the LWC version of this still uses read-only, too. https://developer.salesforce.com/docs/component-library/bundle/lightning-combobox/example

When reviewing the Base Combobox blueprint, keep in mind it may be using a different ARIA specs: 1.0 vs 1.1 vs 1.2.

The latest version of SLDS is using a span: <span class="slds-truncate" id="combobox-value-id-96">Select an Option…</span>

Thank you for pointing out the differences in ARIA specifications and HTML structures between the SLDS and LWC versions of the combobox. Upon reviewing the LWC combobox example, it is evident that it uses a element with the class slds-truncate to display the selected value. In contrast, the React implementation includes a readonly attribute on the element.

Please find the attached screenshots from the above mentioned source for reference

HTML structure for lwc

HTML structure for react

The read-only attribute was present to prevent folks from typing in the input. An input without the read-only is confusing for screen readers also, because the user will think they can type in it.

The LWC is using a button and the SLDS blueprint is using a div with the Combobox 1.2 spec (I believe). It's likely the only way to remove the read-only is to convert the Combobox to 1.2--we considered doing this about 5 years ago when the SLDS blueprint changed. After discussion the issue, the Analytics Cloud engineers agree to leave it the same, because change the spec would change the markup enough that it would be a breaking change.

In short, I'm totally open to updating to the 1.2 spec, but I don't think having a role=textbox with an input that is not read-only is a good idea either.

Also, here's the copy of the markup I'm seeing for the Base component which is using read-only. It looks different than yours: