Able to reproduce the behavior as stated above on the latest canary(62.0.3197.0) of Windows-10 and Linux Ubuntu 14.04. Mac OS 10.12.6 seem to show the correct behavior as other typed fruits was not selected from typing, however 'apple' was selected by default.

Marking this as Untriaged for more inputs from the respective team.

> Hidden elements should not be visible. "Apple" should not be displayed to begin with, and other typed fruits should not be selected from typing them in, either in whole or in part.

As for the default selection, "Apple" should be selected according to the specification [1]. The algorithm in the specification doesn't check visibility of OPTION elements.

Keyboard operation without opening popup menu is inconsistent.
- Up/Down arrow skips hidden OPTIONs
- Type-ahead selection doesn't skip hidden OPTIONs.  e.g. typing 'c' repeatedly selects invisible "Cherry".

IMO, we should *not* skip hidden OPTIONs for up/down arrows. "hidden" should affect only OPTION visibility, and the data in hidden OPTIONs are still valid. 

[1] https://html.spec.whatwg.org/multipage/form-elements.html#ask-for-a-reset

Sorry, I should have referenced the latest W3C recommended spec:
https://www.w3.org/TR/2016/REC-html51-20161101/editing.html#the-hidden-attribute
Since you have referenced WHATWG, I'll put a ref to that here, too:
https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute

OK, perhaps I was thinking about this the wrong way. Firstly, should we be treating the default value that appears in the select element as just a value, not an option element? If so, I am surmising that the select option's list items that appear when the arrow is clicked, are considered to be the option elements themselves. Correct? If so, then *perhaps* the current behaviour in Chrome is also valid.

HOWEVER:

With regards to pressing keys on the keyboard, there is a potential dilemma due to a lack of details about the accessibility of the data to the user in the spec. While not explicitly stating that data should not be *accessible* to the user, it does state the following:

"When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page *as opposed to being directly accessed by the user*."

Furthermore, it states:
"The hidden attribute must not be used to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers."

Taking this into account, if something is visible on the screen, then why shouldn't a screen reader be able to read it?

Perhaps the select element is an exception to all other elements, in that it effectively acts as a conduit in retrieving otherwise inaccessible data from the option elements?

Having said all of this, I am willing to side with your argument, as setting a disabled attribute effectively prevents access to the data, should a web developer require such behaviour (or lack of). Then again, perhaps this is something that needs to be raised with WHATWG to help clear things up for the future.

Reporter, would you file a spec bug on https://github.com/whatwg/html/issues please?  If the specification is changed so that ask-for-a-reset algorithm is "hidden"-aware, I agree that all UI behavior should ignore hidden OPTIONs.

A HTML spec bug has been filed:
https://github.com/whatwg/html/issues/3063

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot