fix links

Author: ConnorLand

content/en/docs/refguide/modeling/best-practices/accessibility-best-practices.md

@@ -63,7 +63,7 @@ The [Robust Principle](https://www.w3.org/TR/WCAG22/#robust) SCs are specificall
 
 ## Using Mendix's Accessibility Options
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/text-box-label.png" alt="Text box widget properties showing label, aria-required and autocomplete options." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/text-box-label.png" alt="Text box widget properties showing label, aria-required and autocomplete options." width="300" >}}
 
 ### Labels
 
@@ -93,15 +93,15 @@ You should avoid using autocomplete in the following situations:
 
 ARIA labels are available in several widgets. ARIA labels take precedent over anything else available for that element. A good ARIA label should describe the element the user is currently interacting with. It is helpful in situations where a visible label would be redundant due to the context of the input field. The ARIA label provides an opportunity to add extra context for [Success Criterion 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value):
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/combobox-aria-labels.png" alt="Combobox widget properties showing ARIA labels options." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/combobox-aria-labels.png" alt="Combobox widget properties showing ARIA labels options." width="300" >}}
 
 {{% alert color="info" %}}
 While ARIA labels are very useful for adding context, using them excessively can even hurt accessibility. An example could be a situation where you have a button that says **Send**, if you add an ARIA label with a description such as **Click this button to reserve your spot in line!** that new text takes precedent over the **Send** text of the button. It would impact voice control. If a user who uses voice control said *Press send*, it would no longer activate that button.
 {{% /alert %}}
 
 ### Alternative Text (Image widget)
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/static-image-alt-text.png" alt="Static Image widget properties showing the Alternative Text option." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/static-image-alt-text.png" alt="Static Image widget properties showing the Alternative Text option." width="300" >}}
 
 Adding alternative text that explains an image helps visually impaired users understand the page (as required by [Success Criterion 1.1.1 Non-text Content](https://www.w3.org/TR/WCAG22/#non-text-content)). It should be left empty if the image is purely decorative. Informative images require alt text, which should be a brief description explaining what is happening in the image. If there is text in the image that is not available in another form, it should be included in the alt text.
 
@@ -111,7 +111,7 @@ There is a key difference between decorative images and informative images. Deco
 
 ### Tab Index
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/static-image-alt-text.png" alt="Static Image widget properties showing the Tab index option." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/static-image-alt-text.png" alt="Static Image widget properties showing the Tab index option." width="300" >}}
 
 The `tabindex` helps users who only use a keyboard navigate the page (as required by [Guideline 2.1 Keyboard Accessible](https://www.w3.org/TR/WCAG22/#keyboard-accessible)). The <kbd>Tab</kbd> key allows users to navigate through interactive elements on a website, such as links, buttons, and form fields. Any element that can be interacted with should have a tab index.
 
@@ -128,13 +128,13 @@ Avoid using positive `tabindex` values, as they can confuse users by altering th
 
 ### Role Type
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/action-button-role-type.png" alt="Action button widget properties showing role type option." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/action-button-role-type.png" alt="Action button widget properties showing role type option." width="300" >}}
 
 Changing the role type helps screen readers understand the kind of element you added ([Success Criterion 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG22/#name-role-value)). You may have added a link, but the function performed is that of a button (instead of navigating to a new page, it performs an action on that page). In this case, it is better to change the element to a button. Changing role types can lead to confusion for users of assistive technologies, as incorrect roles may misrepresent the function of an element, making it harder for users to navigate and interact with content. Whenever possible, always choose semantic HTML over [ARIA (Accessible Rich Internet Applications)](https://www.w3.org/TR/wai-aria/) roles.
 
 ### Accessibility Helper
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/accessibility-helper.png" alt="The Accessibility helper widget." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/accessibility-helper.png" alt="The Accessibility helper widget." width="300" >}}
 
 If you need additional settings or attributes for your page, you can add them using the accessibility helper. It allows you to add attributes to widgets that are not available in the settings. It ensures you can add the necessary extra attributes without needing access to the codebase of that widget.
 
@@ -196,7 +196,7 @@ A situation where this would fail would be if you change your button color to `$
 
 ### Focus
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/group-box-focus-indicator.png" alt="A group box widget with an active focus indicator" width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/group-box-focus-indicator.png" alt="A group box widget with an active focus indicator" width="300" >}}
 
 The focus indicator helps users identify where the focus currently is on the page. There are a few success criteria that describe what the focus indicator should look like.
 
@@ -216,7 +216,7 @@ $form-input-border-focus-color: $brand-primary;
 
 ### Page Titled
 
-{{< figure src="/attachments/refguide/modeling/accessibility-best-practices/page-properties-title.png"  alt="Page properties title option." width="300" >}}
+{{< figure src="/attachments/refguide/modeling/best-practices/accessibility-best-practices/page-properties-title.png"  alt="Page properties title option." width="300" >}}
 
 [Page titled](https://www.w3.org/TR/WCAG22/#page-titled): Every page needs a meaningful name that describes the page. Entitling one just **Page**, for example, is not enough to make the page easy to find among other tabs.