I'm currently expending the original question posted on the discussion thread https://community.oracle.com/thread/4073512
The question I have is related to accessibility and if we utilized the disable option, would this fail an accessibility audit?
In the screen capture below, we implemented the disable option and configured CSS to produce a read-only UI view radio set, checkbox set, and select. The screenshot is using the theme builder to test out the implementation. The question, once we implement disable, the items are not focusable, would we need to programmatically apply focus to the options in the radio set, checkbox set, and select? We would like to utilize OJET accessibility configuration and swap the state options on an edit click event (see below for context). Currently, we display a custom template to resolve the read-only view. The custom template would require custom accessibility markup. I'm addressing the WCAG 2.0 - 2.1.2 No Keyboard Trap, the definition is listed below.
I'm addressing the WCAG 2.0 - 2.1.2 No Keyboard Trap, the definition is listed below.
WCAG 2.0 - 2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page or document or software (whether it is used to meet other success criteria or not) must meet this success criterion.
Would this method pass without additional logic modification?
To provide more context, we have two different states in our form view. We have a read-only and an edit view.
