You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: concepts/framework/in-app-purchases.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,13 +5,13 @@ nav:
5
5
6
6
---
7
7
8
-
# In-App purchases (IAP)
8
+
# In-App Purchases (IAP)
9
9
10
10
::: info
11
11
In-App Purchase is available since Shopware version 6.6.9.0
12
12
:::
13
13
14
-
In-App Purchases are a way to lock certain features behind a paywall within the same extension.
14
+
In-App Purchases allow you to lock certain features behind a paywall within the same extension.
15
15
This is useful for developers who want to offer a free version of their extension with limited features and a paid version with more features.
16
16
17
17
## Creation
@@ -25,7 +25,7 @@ This JWT ensures that purchase data cannot be tampered with or spoofed and allow
25
25
All bought In-App Purchases are part of the JWT claims.
26
26
27
27
To verify the JWT signature, you can use the JSON Web Key Set (JWKS) available at [`https://api.shopware.com/inappfeatures/jwks`](https://api.shopware.com/inappfeatures/jwks)
28
-
Shopware automatically verifies the signature for the use within the Core and Admin.
28
+
Shopware automatically verifies the signature for use within the Core and Admin.
29
29
30
30
Tokens are retrieved when a new purchase is made and during periodic updates.
31
31
You can also manually trigger an update by running the command `bin/console scheduled-task:run-single in-app-purchase.update` or by calling the `/api/_action/in-app-purchases/refresh` endpoint.
@@ -37,12 +37,12 @@ In-app purchases are optimized for use with app servers.
37
37
Whenever Shopware sends a request to the app server, it includes the [IAP JWT](#token).
38
38
The app server can use this token to validate active purchases and unlock related features accordingly.
39
39
40
-
Plugins are inherently less secure, as their open nature makes them more vulnerable to spoofing or tampering.
40
+
Plugins are inherently less secure because their open nature makes them more vulnerable to spoofing and tampering.
41
41
42
-
<PageRefpage="../../guides/plugins/apps/in-app-purchases"title="In-App purchases for Apps" />
42
+
<PageRefpage="../../guides/development/monetization/in-app-purchases"title="In-App purchases for Apps" />
43
43
<PageRefpage="../../guides/plugins/plugins/in-app-purchases"title="In-App purchases for Plugins" />
44
44
45
-
## Checkout Process
45
+
## Checkout process
46
46
47
47
When integrating In-App Purchases, Shopware handles the entire checkout process for you—including payment processing and subscription management.
Copy file name to clipboardExpand all lines: guides/development/accessibility/accessibility-checklist.md
+25-25Lines changed: 25 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,101 +10,101 @@ Creating an accessible storefront ensures that all users can navigate, interact
10
10
11
11
This checklist outlines the key principles and technical requirements for building accessible web interfaces, with a focus on semantic structure, keyboard usability, screen reader compatibility, and inclusive design practices.
12
12
13
-
## Storefront Accessibility Checklist: Best Practices for Inclusive Web Design
13
+
## Storefront accessibility checklist: Best practices for inclusive web design
14
14
15
-
### Use Semantic HTML
15
+
### Use semantic HTML
16
16
17
17
Leverage native HTML elements that communicate their purpose effectively:
18
18
19
19
- Use appropriate tags for actions: `<button>`, `<a>`, `<select>` instead of `<div>` or `<span>`.
20
20
- Structure your layout with semantic elements: `<nav>`, `<main>`, `<header>`, `<footer>`.
21
21
- Always pair `<label>` elements with form controls using `for` and `id`. Avoid relying solely on `placeholder` text for labeling.
22
22
23
-
### Set the Correct Document Language
23
+
### Set the correct document language
24
24
25
25
Proper language settings help screen readers use accurate pronunciation and intonation:
26
26
27
27
- Add `lang="en"` (or the appropriate language code) to the `<html>` tag.
28
28
29
-
### Ensure Accessible Forms
29
+
### Ensure accessible forms
30
30
31
-
All form fields must be clearly labeled and error states must be identifiable:
31
+
All form fields must be clearly labeled, and error states must be identifiable:
32
32
33
33
- Use `<label for="input-id">`, `aria-label`, or `aria-labelledby`.
34
34
- Provide error messages that are clear and easy to locate.
35
-
- Don’t rely solely on color (e.g., red) to indicate errors. You can use icons or text additionally.
35
+
- Don’t rely solely on color (e.g., red) to indicate errors. You can also use icons or text.
36
36
- Use `aria-describedby` to connect input fields to help or error messages.
37
37
38
-
### Manage Focus
38
+
### Manage focus
39
39
40
40
Ensure users know where they are and can move through the interface logically:
41
41
42
-
- Use `tabindex="0"` for custom interactive elements. Try to not mess around with the tabindex if possible and keep the "natural" tab flow.
43
-
- Do not remove focus outlines unless replaced with a clear visible alternative.
44
-
- Use `focus()` to direct user attention (e.g. after form errors or modal open).
45
-
- Each interactive element that can be clicked or navigated by keyboard (`<a>`, `<button>` etc.) must have a clearly visible focus indication.
42
+
- Use `tabindex="0"` for custom interactive elements. Try not to mess around with the tabindex if possible, and keep the "natural" tab flow.
43
+
- Do not remove focus outlines unless replaced with a clear, visible alternative.
44
+
- Use `focus()` to direct user attention (e.g., after form errors or modal open).
45
+
- Each interactive element that can be clicked or navigated by keyboard (`<a>`, `<button>`, etc.) must have a clearly visible focus indication.
46
46
47
-
### Keyboard Accessibility
47
+
### Keyboard accessibility
48
48
49
49
Users should be able to navigate and interact with all features using only the keyboard:
50
50
51
51
- Ensure `Enter` and `Space` activate interactive elements.
52
52
- Avoid using `onclick` on non-focusable elements without keyboard support.
53
53
- Custom widgets must respond to arrow keys and expected keyboard patterns.
54
54
55
-
### Use ARIA Carefully
55
+
### Use ARIA carefully
56
56
57
57
Use ARIA roles and attributes only when native HTML doesn’t work.
58
58
59
59
- Use `role="alert"` for live error messaging.
60
60
- Apply `aria-expanded`, `aria-controls`, and `aria-hidden` for toggleable UI elements.
61
61
- Prefer native HTML elements over ARIA whenever possible to reduce complexity.
62
62
63
-
### Provide Live Region Updates
63
+
### Provide live region updates
64
64
65
65
Ensure real-time changes are accessible:
66
66
67
-
- Use `aria-live="polite"` or `aria-live="assertive"` for real-time updates (e.g. validation messages, chat widgets).
67
+
- Use `aria-live="polite"` or `aria-live="assertive"` for real-time updates (e.g., validation messages, chat widgets).
68
68
69
-
### Manage Page Titles and Headings
69
+
### Manage page titles and headings
70
70
71
71
Headings and titles provide structure and orientation. It helps users understand page structure:
72
72
73
-
- Always update the `<title>`tag on page load or route change.
73
+
- Always update the `<title>` tag on page load or route change.
74
74
- Use one `<h1>` per page, followed by correct heading hierarchy (`<h2>`, `<h3>`, etc.).
75
75
76
-
### Support Skip Links
76
+
### Support skip links
77
77
78
78
Help keyboard users skip repetitive content:
79
79
80
80
- Include a skip link at the top of the page:
81
81
82
-
```html
82
+
```html
83
83
<ahref="#main-content"class="skip-link">Skip to main content</a>
84
-
```
84
+
```
85
85
86
-
### Control Focus When Using Modals or Popovers
86
+
### Control focus when using modals or popovers
87
87
88
88
Focus should remain within the modal and return to the trigger element after closing:
89
89
90
90
- Trap focus while the modal is open.
91
91
- Return focus to the initiating element once it is closed.
92
92
93
-
### Avoid Auto-Playing Audio or Video
93
+
### Avoid auto-playing audio or video
94
94
95
95
If unavoidable, make sure users can easily pause or stop it:
96
96
97
97
- Provide controls on `<video>` or `<audio>` elements.
98
98
- Avoid autoplay unless muted and non-disruptive.
99
99
100
-
### Ensure Unique IDs and ARIA Attributes
100
+
### Ensure unique IDs and ARIA attributes
101
101
102
102
Avoid duplicated IDs to maintain screen reader reliability:
103
103
104
104
- Validate that `id` attributes are unique.
105
105
- Ensure any referenced IDs in `aria-labelledby` or `aria-describedby` exist and are not duplicated.
106
106
107
-
### Test with Assistive Technologies
107
+
### Test with assistive technologies
108
108
109
109
Test your site with real-world tools and scenarios:
110
110
@@ -116,4 +116,4 @@ Test your site with real-world tools and scenarios:
116
116
117
117
Following this checklist will help ensure your storefront is usable by everyone, regardless of ability. It also improves SEO, performance, and user satisfaction for all visitors.
118
118
119
-
Regularly audit your code, test with assistive technologies, and stay updated with evolving accessibility standards. Inclusive design is good design.
119
+
Regularly audit your code, test with assistive technologies, and stay up to date with evolving accessibility standards. Inclusive design is good design.
Shopware is committed to creating inclusive and barrier-free shopping experiences. Accessibility affects both the core Storefront and all custom themes and extensions. Developers are responsible for ensuring their implementations comply with accessibility standards, such as WCAG 2.1 Level AA.
10
+
11
+
## In this section
12
+
13
+
<PageRefpage="./storefront-accessibility" />
14
+
<PageRefpage="./accessibility-checklist" />
15
+
16
+
## Why accessibility matters
17
+
18
+
* Legal compliance (e.g., EU accessibility regulations)
19
+
* Better usability for all users
20
+
* Improved SEO and performance
21
+
* Future-proof storefront implementations
22
+
23
+
Shopware continuously introduces accessibility improvements in new releases. Always test extensions with the `ACCESSIBILITY_TWEAKS` feature flag enabled to ensure compatibility.
0 commit comments