This is unfortunate, but reflects reality.

The first time you choose an item, it is rendered without the details icon. The widget fires a request to the language service to ask if the item has details and then it repaints to show that it has details.

The aria alerts reflect what the widget paints. Most of the times, this request is so fast that you don't notice the flicker visually.

IMHO the data structures are flawed, they should have a boolean up front for each item that contains details. This would reduce spammy communication (the details could be resolved only when doing Ctrl+Space again to actually show details) and the fact that there are details would be known up front, instead of making a request on every selection change.

For some language services the extra info is a second (and more expensive call) and the detail information isn't only loaded on the second Ctrl+Space but on focus (it shows more info). Since the backend cannot blindly fetch details for each and every item and since the backend doesn't know what item the UI will focus first it's not that easy.

@alexandrudima assigning to you that it doesn't get lost.

Doesn't the screen reader reads the sentence on focus change in the complete widget?

@jrieken My suggestion is simple. The suggestions should contain a boolean field if they have details or not.

The backend does not need to fetch details for each and every item, but say that it has such details. In many ASTs I suppose that would be an if stmt on the node?

If a backend really does not know then it should say it has details for all suggestions and then fail when asked for those details (as it works today).

that's how it works. they never really know if there more data or not unless the provider doesn't offer the resolveDetails call - I can reflect that in the API

We now only register the details-resolver when the provider actually supports it. I don't see the double request anymore. Closing.