From my read of the normative requirements and understanding docs, it's clear that inactive controls / "components" have an exception to contrast requirements. But also, reading through the content pertaining to focus indicators, it's very clear how important it is to make sure that they meet contrast requirements so that users will be more likely to identify where focus is within an interface.
What I find to be lacking is the cross section of an inactive control that can receive keyboard focus. There are absolutely times where controls such as buttons, or even more commonly - menuitems or options - may be marked as disabled, but remain keyboard accessible by tab or arrow keys to improve discoverability of these items. Doing something like this is presently only possible by authors modifying the standard functionality/styling of controls, or creating custom ARIA controls. But there has also been tentative talk of introducing a "soft disabled" state, primarily in the context of the proposed new menulist/menubar elements in HTML - see this ARIA Authoring Practices section on the focusing of disabled elements.
From my read of the WCAG SCs and understanding docs, it seems to me that the SC / understanding docs were written under the assumption that an inactive control would not be focusable. Or, if this wasn't the assumption, there's at least no overt acknowledgement of this scenario and why in this case, it's fine for a focus indicator to not meet contrast requirements - though the only way an inactive element would be focusable is if it was modified by the author (e.g., not user agent behavior or default styling), when then seems like it might mean that at least the focus indicator needs to meet contrast requirements?
From my read of the normative requirements and understanding docs, it's clear that inactive controls / "components" have an exception to contrast requirements. But also, reading through the content pertaining to focus indicators, it's very clear how important it is to make sure that they meet contrast requirements so that users will be more likely to identify where focus is within an interface.
What I find to be lacking is the cross section of an inactive control that can receive keyboard focus. There are absolutely times where controls such as buttons, or even more commonly - menuitems or options - may be marked as disabled, but remain keyboard accessible by tab or arrow keys to improve discoverability of these items. Doing something like this is presently only possible by authors modifying the standard functionality/styling of controls, or creating custom ARIA controls. But there has also been tentative talk of introducing a "soft disabled" state, primarily in the context of the proposed new menulist/menubar elements in HTML - see this ARIA Authoring Practices section on the focusing of disabled elements.
From my read of the WCAG SCs and understanding docs, it seems to me that the SC / understanding docs were written under the assumption that an inactive control would not be focusable. Or, if this wasn't the assumption, there's at least no overt acknowledgement of this scenario and why in this case, it's fine for a focus indicator to not meet contrast requirements - though the only way an inactive element would be focusable is if it was modified by the author (e.g., not user agent behavior or default styling), when then seems like it might mean that at least the focus indicator needs to meet contrast requirements?