Include citations to:
Also note that :enabled and :disabled can only match elements from exactly the same set, which includes three that aren't listed form-associated elements and don't have form IDL attributes: <optgroup>, <option>, and <menuitem>. All three have label IDL attributes (as do the non-disableable <menu> and <track>), but none of them need to consider ancestor fieldsets (although <option> does need to consider parent <optgroup>).
The bottom line is that boolean disabled is a good indicator, excepting two special cases where an element can match :disabled instead of :enabled despite having .disabled === false:
.disabled === false
It is interesting to observe that special processing is required if and only if disabled is false and form exists. I think the resulting logic will look like
// Only certain elements can match :enabled or :disabled
// Check for inherited disabledness on relevant non-disabled elements:
// * listed form-associated elements
// * option elements
return "form" in elem && elem.disabled === false ?
// Support: IE 6 - 11
// Use the shortcut property, which already covers inheritance
elem.isDisabled === disabled ||
elem.isDisabled !== !disabled && ("label" in elem ?
// Option elements defer to a parent optgroup if present
(elem.parentNode && "label" in elem.parentNode ?
elem.parentNode.disabled === disabled :
elem.disabled === disabled) :
// All others defer to ancestor fieldsets if present
disabledAncestor( elem ) === disabled
// Check other disableable elements for direct disabledness
// Some victims get caught in our net (label, legend, menu, track),
// but they shouldn't have the property anyway.
"form" in elem && elem.disabled === disabled ||
"label" in elem && elem.disabled === disabled;
Selector: Properly implement :enabled/:disabled for select contents