Christoph Letmaier

Dear Takayuki,

deleting the div “screen-reader-response” lead to an JavaScript error in the console. I wrapped the remove() method in a setTimeout statement, so remove() is executed, after the Contact Form 7 JavaScript Code is executed (and the DOM is changed).

Is there a more elegant way to do this? Is there another way to intecept the Contact Form 7 JavaScript code which is update-save?

EDIT: deleting the div “screen-reader-response” is not an option, because this creates errors with the Contact Form 7 JavaScript code. So I but aria-hidden=”true” to the div “screen-reader-response” and the jump links inside this div. Also, i set on each jump link tabindex=”-1″, so this link are not reachable via tabulator navigation.

Regards

Christoph

• This reply was modified 1 month, 1 week ago by Christoph Letmaier.

Dear Takayuki,

thanks for the link.

I have found out, the the “hidden links” i mentioned are acctually inside a hidden error messages div.

I have to mention, that the way i proposed in my original post is wrong, because Contact Form 7 will then set the names of the input fields to eg. “id:name”. So i have to stick with the form syntax in the link you provided.

My intention was to prevent hidden elements, which are only visible for screen readers. In my opinion this doesn’t make sense. To give visible elements proper aria attributes makes much more sense for me.

Imagine a person in a wheelchair who can read very well but relies on tab navigation (no screen reader is used). If a form error message appears, and this person navigates up using SHIFT+Tab, the invisible links in the error DIV are also marked, but remain invisible. I’m wondering if this is correct.

So far, my contact says, the way you create the hidden error messages DIV is also correct in terms of accessibility.

Please leave this post open for now, perhaps i get more infos form my accessibility expert, which I want to share.

Hey Stef,

I want to share some information from my in-depth testing with the plugins you proposed:

WooCommerce Multi-Step Checkout by SilkyPress:
not bad, but if someone enters an invalid shipping address, then reenter a valid shipping address, the “wrong delivery address” warning doesn’t disappear

WooCommerce MultiStep Checkout Wizard:
seems not to be on the WordPress plugin repository, only on WooCommerce MultiStep Checkout Wizard by Kole_Roy | CodeCanyon. LivePreview doesn’t work “Sorry, your session has expired.”.

CheckoutWC:
makes an completly custom checkout page with own design, look not bad, but has not so nice JavaScript loading animations, can’t turn that off

YITH WooCommerce Multi-step Checkout:
is not maintained anymore, plugin page is closed (https://ww.wp.xz.cn/plugins/yith-woocommerce-multi-step-checkout/)

CartFlows:
way to much, as far as i tested, you have to build the checkout page frome the scratch in an template builder.

I assume, the plugin developers do basically this, what i was doing with my review page programming. I don’t want the checkout process on an extra page, because the design differs greatly from the shop page design.

So, i have the choice between talking to the plugin developers or go on with my custom programming, I assume the effort will be nearly equal.

I understand, that you can’t tell me more in the forum about WooCommerce in-depth coding. Can you tell me perhaps, if an offical documenation of WooCommerce exists, where i can find more about how WooCommerce use hooks and JavaScript on the checkout page?

Hey Stef, thanks for your reply.

I can say, the workaround, similar to the description in the link i have posted, works. I produce a hidden fake error message, and then redirect (in error.php) to my custom review page, where i integrate hooks from the WooCommerce file checkout.php. My review page is, so to speak, a „copy“ of checkout.php, with other contents.

I know the „review section“ very well, but, i want this info, combined with the customer data, on an extra page. I want a splitted checkout process, so the user first fills in his personal data, on the second page, he can review his order and his personal data (and select a payment method). Out-of-the-box, all steps in WooCommerce are on a single page.

My customer sells highly configurable products, not products with choosing only color and size. So, we want, that the customer can read again (before buying), what he/she is buying, with all details. Stuffing input fields and the order review on a single page could be error prone. We think it is better, if the customer can double check his/her entries/order on an extra review page.

Out-of-the-box, in WooCommerce the order/review process is handled by checkout.php. There is no (easy and update-safe) workflow described, to split the order process steps: data entry, review, select payment method, place order. I can use template overrides only with php files, but not with JavaScript code – which is used in processing the functions of checkout.php.

I can develop the workaround further on my own, but it would be nice, if WooCommerce can support me doing this. So far, i rely on a trial and error method, testing, if everythink works, if i change/alter the order of the WooCommerce checkout.php hook calls. This is a rather painstaking process.

Consider the fact, that other shop systems have integrated an extra review page out-of-the-box – because it makes sense, is user friendly, and prevent perhaps false user entries. See the checkout process of Amazon – there is a (from user entries) seperated review page.

So, maybe you can help me with the correct order of the WooCommerce hooks. It would be fine, if Automattic develops a paid extra plugin for WooCommerce, which enables a separated review page.

• This reply was modified 2 years ago by Christoph Letmaier.
• This reply was modified 2 years ago by Christoph Letmaier.

@seank123: it didn’t say it works on the local server. On the local server I run the downgraded configuration that works.

The problem appeared suddenly, i have nothing changed, so i assume the problem has to do with very new versions of WordPress/WooCommerce and automatic update.

Also, I run another live server with the exact same configuration, the problem occured there likewise and at the same time.

• This reply was modified 2 years, 2 months ago by Christoph Letmaier.

Very well, but the user account has configured the option that the admin bar doesn’t show up on frontend, so your solution will not work in this case.