INFO
There is an edit to this question that addresses the specific issues OP has with their current implementation. I have left this first part here as my original answer.
I don't want the the preview to be actually interactive like the real form would.
Why? Having the form be interactive would be great for all users (taking into account that some functionality needs to not work fully in a preview).
Let people see what default hover styles look like, what clicking links would do (i.e. click the link and alert says "would navigate to xxx page") etc.
I understand not wanting to be able to navigate to new pages and submit the form (any "save" or "update" actions plus any "navigation" actions) but everything else I believe should be able to work in a preview.
Also, in terms of accessibility, it might be very confusing if there are a bunch of input that don't do anything appearing on the screen.
It would be far more confusing if a preview appeared on screen but then I couldn't navigate to the buttons, links etc.
How would that behave for a screen reader user? i.e. would you hide all elements using aria-hidden="true" (in which case how would they test the page?).
My fallback will likely be to disable all of the elements. But this won't work for links for example.
This is really one of the worst ways you could handle it, disabled inputs generally can't receive focus so keyboard users would suffer when testing.
Plus if some elements in the final production form are disabled until a certain field is filled in (for example) then how could a user test that in your end form?
Also if you intercept the navigation for a link without explaining why the link doesn't work that could also cause confusion. (and yet again could that link open in a new window in "preview" mode if you explain that to end users? Obviously depends if it is a static link etc. but just a thought on a way users can check any custom links point to the right place).
Proposed Solution
I would say you need two versions of the finished form. The "real world" one and the "preview" one.
The HTML can be (read "should be") identical but you need to implement JavaScript handlers to disable the functionality you don't want to be active.
There is nothing wrong with having an editing tool only work with JavaScript if that is one of your concerns, as long as you provide a warning to end users that the tool requires JavaScript to work. (The difference between a publishing tool and an end user experience is you can be much more reliant on JavaScript.)
For example: Let's say you have a <button> that when clicked should add a new row to the form (in the production version of the form) and for whatever reason you do not want this functionality to be active in the preview version.
In that case in the preview / demo version of the form when you click this button an alert could be shown that says "will add a new row to the form".
That way screen reader users and keyboard only users can test the form without you needing to do too much extra work (and can also see if the form has usability issues for keyboard users while they are at it!)
I think this would be the most clear for everybody and a much better user experience.
You just need to think of navigating in and out of preview mode (Esc to close for example) and quick edits (when you preview the form give the option to focus the previously focused element if the forms are particularly long, keyboard only users will thank you for this! The same for when you go back to the edit, put focus back on the last edited item).
Further reading
From an accessibility perspective WCAG isn't what you are looking for in this scenario, Authoring Tool Accessibility Guidelines (ATAG) is.
This is a little known set of guidance on how to create editors, WYSIWYGS etc. etc.
As with all W3C guidance it is a heavy read but if you understand the core principles it will guide you to good decisions and you can always ask here if you need clarity on some of the individual points that aren't clear :-).
EDIT: How could you achieve an accessible interface with the current design
The issues that you have within the codepen you linked and their solutions are as follows:
Stop interactive items receiving focus
As you wrap each element you have correctly diagnosed your biggest issue which is nested interactive elements.
The solution to this is quite straight forward: Give every interactive element a tabindex="-1" as you said. This makes sure they cannot be focused incorrectly.
Make sure the actual wrapper item can be focused and activated
Then we just need to make sure that the wrapper .content-item has tabindex="0" so it is added to the focus order.
We also need to capture the Enter and the Space keys and ensure our panel is activated with them also.
Visual focus indicator
I also added an outline to the wrapper "button" so that visual focus indicators are available.
So that essentially fixes normal keyboard navigation issues, the next issue is how a screen reader will interpret nested buttons, inputs etc.
Screen reader corrections
Here I would also go simple, hide the button, input etc. entirely from a screen reader and instead explain what element is inside.
Effectively we make the button invisible and instead describe the contents of the .content-item.
To hide the element we use aria-hidden="true"
To announce something meaningful we can use some visually-hidden (screen reader only) text inside a <span>. This will be far more robust that using aria-label with such a complex application.
make the application behave well with a mouse
Final challenge - stop mouse events.
Luckily pointer-events: none has really good support and even on the few browsers that don't support it being able to click into an input isn't the end of the world (we have fixed it for keyboard users)
Example with all issues resolved:
This solves all of the issues with your selection method.
Please note it doesn't take into account accessibility errors of the components themselves (for example the <input> having no <label> etc.) but I assume that is just because it is an example.
The only thing you need to work out is how to generate the visually hidden text describing the item and the .content-info "button" action.
document.addEventListener("DOMContentLoaded", function () {
const items = document.getElementsByClassName("content-item");
const rightPanel = document.getElementById('right-panel');
for (let i = 0; i< items.length; i++) {
const item = items[i];
item.addEventListener("click", (e) => {
console.log(e.target);
const id = e.target.dataset.id;
rightPanel.innerHTML = id;
});
// ADDED this to capture the Enter and Space presses on our wrapper button
item.addEventListener("keydown", function(e){
if(e.keyCode == "32" || e.keyCode == "13"){
console.log(e.target);
const id = e.target.dataset.id;
rightPanel.innerHTML = id;
}
});
}
});
.main {
display: flex;
flex-flow: row nowrap;
}
.left {
flex: 1 1 auto;
}
.right {
flex: 1 1 auto;
}
.content-item {
margin-top: 20px;
width: 600;
border: solid 2px blue;
cursor: pointer;
}
/* ADDED a focus indicator so keyboard users know where they are */
.content-item:focus{
outline: 4px solid #333;
}
/* ADDED to stop pointer events reaching the input, button etc. */
input, button{
pointer-events: none;
}
/* ADDED the visually hidden class so we can provide meaningful text to screen reader users */
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<div class ="main">
<div class ="left">
<!-- Added `tabindex="0"` so the wrapper is focusable by keyboard -->
<div class="content-item" role="button" data-id="item-1" tabindex="0">
<!-- added `aria-hidden="true"` and `tabindex="-1"` to hide the input from screen readers and make sure it cannot be focused by keyboard, I also added `role="presentation"` just for good measure, although it shouldn't be needed. -->
<input type="text" aria-hidden="true" tabindex="-1" role="presentation">
<!-- Added this span that explains the action that the "content-item button" would perform if clicked. You need to come up with something meaningful for the contents of this -->
<span class="visually-hidden">Edit input [input identifier]</span>
</div>
<div class="content-item" role="button" data-id="item-2" tabindex="0">
<button aria-hidden="true" tabindex="-1" `role="presentation"`> I am a button</button>
<span class="visually-hidden">Edit button [button identifier]</span>
</div>
</div>
<div class ="right" >
<h2> Right panel</h2>
<div id ="right-panel">
</div>
</div>
</div>
