wpaccessibility · rianrietveld · Mar 31, 2026 · Mar 30, 2026 · Mar 30, 2026
diff --git a/_includes/components/footer.html b/_includes/components/footer.html
@@ -12,7 +12,7 @@ <h3>Quick links</h3>
             <li><a href="{{site.baseurl}}/docs/topics/theme-guidelines/">Theme accessibility-ready tag</a></li>
             <li><a href="{{site.baseurl}}/docs/topics/code/screen-reader-text/">CSS class .screen-reader-text</a></li>
             <li><a href="{{site.baseurl}}/docs/topics/legislation/">Legislation worldwide</a></li>
-            <li><a href="{{site.baseurl}}/blog/">Blog</a></li>
+            <li><a href="{{site.baseurl}}/docs/start/overlays/">Accessibility Overlays</a></li>
             <li><a href="{{site.baseurl}}/docs/about/sponsors/">Sponsors</a></li>
             <li><a href="{{site.baseurl}}/docs/about/contact/">Contact us</a></li>
           </ul>

diff --git a/...25-09-05-insights-wordcamp-europe-2025.md → docs/start/business/priority.md b/...25-09-05-insights-wordcamp-europe-2025.md → docs/start/business/priority.md
@@ -1,14 +1,17 @@
 ---
-layout: post
-title: "Why accessibility should be your next priority, insights from WordCamp Europe 2025"
-permalink: /blog/2025/insights-wordcamp-europe-2025/
-author: Wendie Huis in't Veld
-categories: EAA, WordCamp, business
-parent: Blog
-description: "One topic that really stands out on WordCamp Europe 2025, is accessibility. With the European Accessibility Act (EAA) coming into effect in June, it's clear that this is something we all need to pay attention to. While the Act isn’t specific to WordPress, it affects all website owners, especially those running businesses online."
-date: 2025-09-08
+title: Why accessibility should be your next priority
+layout: default
+parent: Accessibility, the business case
+description: Wendie Huis in't Veld gives her insights about why accessibility should be your next priority.
+nav_order: 2
 ---
 
+# Why accessibility should be your next priority
+
+September 8, 2025 by Wendie Huis in't Veld.
+
+Wendie gives her insights from WordCamp Europe 2025.
+
 In the beginning of June [WordCamp Europe 2025 happened](https://wordpress.tv/event/wordcamp-europe-2025/), the biggest WordPress event in the world where thought leaders, and industry experts share their insights and knowledge. Luckily, sessions from Tracks 1 and 2 are available on WordPress TV for everybody that missed the event, so you can always dive into the valuable insights at a later moment.
 
 One topic that really stands out, especially when you are a European entrepreneur, is accessibility. With the European Accessibility Act (EAA) having come into effect in June 2025, it's clear that this is something we all need to pay attention to. While the Act isn’t specific to WordPress, it affects all website owners, especially those running businesses online.

diff --git a/...-27-offer-multiple-ways-to-contact-you.md → docs/topics/content/multiple-ways-contact.md b/...-27-offer-multiple-ways-to-contact-you.md → docs/topics/content/multiple-ways-contact.md
@@ -1,18 +1,14 @@
 ---
-layout: post
-title: "I have a question, but I don’t have WhatsApp!"
-permalink: /blog/2025/offer-multiple-ways-of-contact/
-author: Rian Rietveld
-categories: contact
-parent: Blog
-description: "It’s better to offer multiple ways to get in touch, so people can choose what suits them. Think about your visitors first, not just what’s easiest for you."
-date: 2025-08-27
+title: Multiple ways to contact
+layout: default
+parent: Content and images
+description: It’s better to offer multiple ways to get in touch, so people can choose what suits them. Think about your visitors first, not just what’s easiest for you.
+nav_order: 4
 ---
 
-## Summary
+# Offer multiple ways to get in touch
 
-{: .lead }
-You want to reach out to customer service, and they say  *“Send us a WhatsApp message.”* What if you don’t use WhatsApp, or cannot make a phone call, or use the chatbox? By offering multiple contact options, you make sure every customer has a way to connect.
+You want to reach out to customer service, and they say  *“Send us a WhatsApp message”*. What if you don’t use WhatsApp, or cannot make a phone call, nor use the chatbox? By offering multiple contact options, you make sure every customer has a way to connect.
 
 ## Don’t make getting in touch their problem
 

diff --git a/docs/topics/content/readability.md b/docs/topics/content/readability.md
@@ -3,7 +3,7 @@ title: Readability
 layout: default
 parent: Content and images
 description: Make the text scannable and easy to read.
-nav_order: 4
+nav_order: 5
 ---
 
 # Readability

diff --git a/...-16-accessible-error-messages-in-forms.md → ...rms/feedback/accessible-error-messages.md b/...-16-accessible-error-messages-in-forms.md → ...rms/feedback/accessible-error-messages.md
@@ -1,18 +1,14 @@
 ---
-layout: post
-title: "Accessible error messages in forms"
-permalink: /blog/2025/accessible-error-messages-forms/
-author: Rian Rietveld
-categories: forms
-parent: Blog
-description: "When you put care into preventing errors and clearly indicating when something goes wrong, users are much more likely to successfully submit a form."
-date: 2025-08-16
+title: Accessible feedback in forms
+layout: default
+parent: Feedback on errors
+description: How to offer feedback in forms in an accessible way. When you put care into preventing errors and clearly indicating when something goes wrong, users are much more likely to successfully submit a form.
+nav_order: 1
 ---
 
-## Summary
+# Accessible feedback in forms, step-by-step
 
-{: .lead }
-When you put care into preventing errors and clearly indicating when something goes wrong, users are much more likely to successfully submit a form. In this post, we’ll walk step-by-step through how to prevent errors, indicate them clearly, and offer help with error messages in forms for different types of users.
+When you put care into preventing errors and clearly indicating when something goes wrong, users are much more likely to successfully submit a form. In this page, we’ll walk step-by-step through how to prevent errors, indicate them clearly, and offer help with error messages in forms for different types of users.
 
 ## When designing a form, ask yourself the following questions
 
@@ -50,7 +46,7 @@ For example: users recognize radio buttons as circles and checkboxes as squares.
 Some field types are better avoided due to poor usability, such as multi-selects. Using date pickers? Check the experience for keyboard or screen reader users.
 
 Sometimes a simple solution works best for everyone. For example, KLM’s method for selecting a date with a text input for the day, a dropdown for the month, and another text input for the year:
-![Date selection with a text field for day, a select for month, and a text field for year](/assets/images/blog_toegankelijker-foutmeldingen-date-picker.png)
+![Date selection with a text field for day, a select for month, and a text field for year]({{site.baseurl}}/assets/images/blog_toegankelijker-foutmeldingen-date-picker.png)
 
 For a deep dive into asking for dates in forms, see the GOV.UK Design System pattern library: [Ask users for Dates](https://design-system.service.gov.uk/patterns/dates/).
 
@@ -64,7 +60,7 @@ This success criterion was added in [WCAG 2.2: 3.3.7 Redundant Entry](https://ww
 We’ve all been there: you enter a new password, click submit, and *then* you’re told what the password requirements are. You yell at the screen: “Why didn't you tell me that before?”.
 
 The blog post [Blind people don't visit my website](https://www.a11y-collective.com/blog/blind-people-dont-visit-my-website/) lists frustrations from web users, such as:
-> "Error messages that come afterwards and eventually don't explain what you need to change."
+> "Error messages that come afterward and eventually don't explain what you need to change."
 
 Don’t make users guess — offer clear help in plain language, at the right moment. Tell users in advance which documents they'll need, and which fields are or aren't required. Add descriptions to fields where necessary.
 

diff --git a/docs/topics/forms/feedback/error-check.md b/docs/topics/forms/feedback/error-check.md
@@ -3,7 +3,7 @@ title: Check at the right moment
 layout: default
 parent: Feedback on errors
 description: To help users and not confuse them, it’s important to choose the right moment to validate user input.
-nav_order: 1
+nav_order: 2
 ---
 
 # Check for form errors at the right moment

diff --git a/docs/topics/forms/feedback/error-message-format.md b/docs/topics/forms/feedback/error-message-format.md
@@ -3,7 +3,7 @@ title: Use text for error messages
 layout: default
 parent: Feedback on errors
 description: Always write out the error message in text with clear, plain language.
-nav_order: 4
+nav_order: 5
 ---
 
 # Write out an error message in text

diff --git a/docs/topics/forms/feedback/error-message-location.md b/docs/topics/forms/feedback/error-message-location.md
@@ -3,7 +3,7 @@ title: Best message location
 layout: default
 parent: Feedback on errors
 description: For error messages, the best location is above the form field.
-nav_order: 3
+nav_order: 4
 ---
 
 # The best location for error messages

diff --git a/docs/topics/forms/feedback/error-message-text.md b/docs/topics/forms/feedback/error-message-text.md
@@ -3,7 +3,7 @@ title: Write clear error messages
 layout: default
 parent: Feedback on errors
 description: A custom-written error message gives the user the most guidance.
-nav_order: 5
+nav_order: 6
 ---
 
 # Write a clear error message

diff --git a/docs/topics/forms/feedback/error-summary.md b/docs/topics/forms/feedback/error-summary.md
@@ -3,7 +3,7 @@ title: Error summary
 layout: default
 parent: Feedback on errors
 description: A user-friendly way to display errors is a combination of a summary above the form and repeating the error message for each form field.
-nav_order: 6
+nav_order: 7
 ---
 
 

diff --git a/docs/topics/forms/feedback/html-form-validation.md b/docs/topics/forms/feedback/html-form-validation.md
@@ -3,7 +3,7 @@ title: HTML form validation
 layout: default
 parent: Feedback on errors
 description: At this time (2026), form validation by the browser is not sufficiently accessible.
-nav_order: 2
+nav_order: 3
 ---
 
 # Avoid HTML form validation

diff --git a/docs/topics/forms/feedback/index.md b/docs/topics/forms/feedback/index.md
@@ -10,4 +10,4 @@ nav_order: 5
 
 Use understandable, well-timed error messages and logical validation rules. If a form field is not filled out correctly, it should be clear to everyone what is wrong. 
 
-Please also read our blog post [Accessible error messages in forms](/blog/2025/accessible-error-messages-forms/), which explains step by step how to prevent errors, indicate them, and provide help with error messages in a form for different types of users. Another good writeups are [A Guide To Accessible Form Validation](https://www.smashingmagazine.com/2023/02/guide-accessible-form-validation/) by Sandrina Pereira on Smashing Magazine and [10 Design Guidelines for Reporting Errors in Forms](https://www.nngroup.com/articles/errors-forms-design-guidelines/) by Rachel Krause for the NN Group.
+Please read [Accessible feedback in forms, step-by-step]({{site.baseurl}}/docs/topics/forms/feedback/accessible-error-messages/) first, which explains how to prevent errors, indicate them, and provide help with error messages in a form for different types of users. Another good writeups are [A Guide To Accessible Form Validation](https://www.smashingmagazine.com/2023/02/guide-accessible-form-validation/) by Sandrina Pereira on Smashing Magazine and [10 Design Guidelines for Reporting Errors in Forms](https://www.nngroup.com/articles/errors-forms-design-guidelines/) by Rachel Krause for the NN Group.
diff --git a/docs/topics/forms/feedback/screen-reader-feedback.md b/docs/topics/forms/feedback/screen-reader-feedback.md
@@ -3,7 +3,7 @@ title: Screen reader feedback
 layout: default
 parent: Feedback on errors
 description: There are several ways to provide feedback to screen reader users on form errors
-nav_order: 7
+nav_order: 8
 ---
 
 # Provide feedback to screen reader users on form errors
Original file line number	Diff line number	Diff line change
Expand Up		@@ -10,4 +10,4 @@ nav_order: 5

		Use understandable, well-timed error messages and logical validation rules. If a form field is not filled out correctly, it should be clear to everyone what is wrong.

		Please also read our blog post [Accessible error messages in forms](/blog/2025/accessible-error-messages-forms/), which explains step by step how to prevent errors, indicate them, and provide help with error messages in a form for different types of users. Another good writeups are [A Guide To Accessible Form Validation](https://www.smashingmagazine.com/2023/02/guide-accessible-form-validation/) by Sandrina Pereira on Smashing Magazine and [10 Design Guidelines for Reporting Errors in Forms](https://www.nngroup.com/articles/errors-forms-design-guidelines/) by Rachel Krause for the NN Group.
		Please read [Accessible feedback in forms, step-by-step]({{site.baseurl}}/docs/topics/forms/feedback/accessible-error-messages/) first, which explains how to prevent errors, indicate them, and provide help with error messages in a form for different types of users. Another good writeups are [A Guide To Accessible Form Validation](https://www.smashingmagazine.com/2023/02/guide-accessible-form-validation/) by Sandrina Pereira on Smashing Magazine and [10 Design Guidelines for Reporting Errors in Forms](https://www.nngroup.com/articles/errors-forms-design-guidelines/) by Rachel Krause for the NN Group.