Report Information
↑ Back to topInternational Version
(Based on VPAT® Version 2.5)
Name of Product/Version:
WooCommerce, version 10.0
Report Date:
June 30, 2025
Product Description:
WooCommerce is a free plugin that adds ecommerce functionality to WordPress websites.
Contact Information:
If you encounter an accessibility issue, please contact support or email us at accessibility@woocommerce.com.
Notes:
The scope of this report is limited to the accessibility of front-end user interfaces for WooCommerce. It does not cover the backend WordPress admin interfaces of WooCommerce. It also does not cover the accessibility of any WooCommerce add-on plugins or extensions.
Testing of front-end components was completed on a website utilizing the Twenty Twenty-Four theme (version 1.3) with default settings. As WordPress themes can significantly impact frontend design and accessibility, the conformance levels reported may not apply to websites built with other or customized themes.
Additionally, this report does not cover accessibility in the WordPress content management system as a whole.
Information about product help and support documentation is located in our website Accessibility Statement.
Evaluation Methods Used:
Accessibility assessment was completed by Equalize Digital, Inc., using industry-standard automated testing tools and manual testing techniques. Manual testing was completed by certified accessibility professionals using leading assistive technology, such as screen readers (NVDA, VoiceOver, and JAWS), screen magnifiers, and keyboard navigation. Accessibility testing was conducted by certified accessibility professionals and also by blind individuals.
Applicable Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:
| Standard/Guideline | Included In Report |
|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A (Yes), Level AA (Yes), Level AAA (Yes) |
| Web Content Accessibility Guidelines 2.1 | Level A (Yes), Level AA (Yes), Level AAA (Yes) |
| Web Content Accessibility Guidelines 2.2 | Level A (Yes), Level AA (Yes), Level AAA (Yes) |
| Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018 | Yes |
| EN 301 549 Accessibility requirements for ICT products and services – V3.1.1 (2019-11) AND EN 301 549 Accessibility requirements for ICT products and services – V3.2.1 (2021-03) | Yes |
Terms
The terms used in the Conformance Level information are defined as follows:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.
WCAG 2.x Report
↑ Back to topTables 1 and 2 also document conformance with:
- EN 301 549: Chapter 9 – Web, Sections 10.1-10.4 of Chapter 10 – Non-Web documents, and Sections 11.1-11.4 and 11.8.2 of Chapter 11 – Non-Web Software (open and closed functionality), and Sections 12.1.2 and 12.2.4 of Chapter 12 – Documentation
- Revised Section 508: Chapter 5 – 501.1 Scope, 504.2 Content Creation or Editing, and Chapter 6 – 602.3 Electronic Support Documentation.
Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.
Table 1: Success Criteria, Level A
Notes: Applies to front-end accessibility only, as described in scope.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) Also applies to:
|
Supports | The product provides sufficient text alternatives for all instances of non-text content that are functional or provide meaning. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) Also applies to:
|
Not Applicable | There is no prerecorded audio or video in the product. |
| 1.2.2 Captions (Prerecorded) (Level A) Also applies to:
|
Not Applicable | There is no prerecorded video in the product. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) Also applies to:
|
Not Applicable | There is no prerecorded video in the product. |
| 1.3.1 Info and Relationships (Level A) Also applies to:
|
Partially Supports | The product substantially conforms to this criterion with these exceptions: Filter by Attribute, Rating Filter, and Stock Filter blocks (deprecated in version 9.9) have grouped inputs missing fieldsets and legends. These blocks are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter blocks introduced in version 9.9 for improved accessibility conformance. |
| 1.3.2 Meaningful Sequence (Level A) Also applies to:
|
Supports | The product presents content in a reading order that correctly communicates its meaning, and the correct reading sequence can be programmatically determined. |
| 1.3.3 Sensory Characteristics (Level A) Also applies to:
|
Supports | There are no instructions provided for understanding and operating the product that rely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound. |
| 1.4.1 Use of Color (Level A) Also applies to:
|
Supports | Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Where color is used as an indicator, a distinguishable icon, or visible number and text is also present. |
| 1.4.2 Audio Control (Level A) Also applies to:
|
Not Applicable | There is no audio that plays automatically. |
| 2.1.1 Keyboard (Level A) Also applies to:
|
Supports | All functionality of the product is operable through a keyboard interface without requiring specific timings for individual keystrokes. |
| 2.1.2 No Keyboard Trap (Level A) Also applies to:
|
Partially Supports | The product fully supports this criterion with one exception: If a shop is using the Filter by Attribute, Rating Filter, and Stock Filter blocks (deprecated in version 9.9), configured to use dropdowns and no “Apply” button, there is a keyboard trap when using VoiceOver in the Firefox browser that does not allow users to proceed past the dropdown using the Tab key. These blocks are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter blocks introduced in version 9.9 for improved accessibility conformance. |
| 2.1.4 Character Key Shortcuts (Level A 2.1 and 2.2) Also applies to: EN 301 549 Criteria
Revised Section 508 – Does not apply |
Not Applicable | There are no keyboard shortcuts in the product. |
| 2.2.1 Timing Adjustable (Level A) Also applies to:
|
Not Applicable | No time limits are present in the products. |
| 2.2.2 Pause, Stop, Hide (Level A) Also applies to:
|
Not Applicable | There is no moving, blinking, scrolling, or auto-updating content in the products. |
| 2.3.1 Three Flashes or Below Threshold (Level A) Also applies to:
|
Supports | The product does not contain flashing content or anything that flashes more than three times per second. |
| 2.4.1 Bypass Blocks (Level A) Also applies to:
|
Supports | Templates generated by the product offer a mechanism to bypass content blocks that are repeated across multiple web pages. |
| 2.4.2 Page Titled (Level A) Also applies to:
|
Supports | Pages created by the products have titles that describe the topic or purpose. |
| 2.4.3 Focus Order (Level A) Also applies to:
|
Supports | All components in the product receive focus in the expected left-to-right and top-to-bottom order, which matches the visual order on the web page. |
| 2.4.4 Link Purpose (In Context) (Level A) Also applies to:
|
Supports | All links generated by the product meaningfully communicate their purpose either via the link text or additional context added via screen reader text or ARIA attributes. |
| 2.5.1 Pointer Gestures (Level A 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Not Applicable | There is no functionality that uses multipoint or path-based gestures for operation in the product. |
| 2.5.2 Pointer Cancellation (Level A 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | All pointer-triggered events in the product happen on the up-event and it is possible for users to cancel interactions mid-click. |
| 2.5.3 Label in Name (Level A 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | In the product, all user interface components with labels that include text have a name that contains the text that is presented visually. |
| 2.5.4 Motion Actuation (Level A 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Not Applicable | There is no functionality in the product that is operated by device motion or user motion. |
| 3.1.1 Language of Page (Level A) Also applies to:
|
Supports | Pages created by the product declare the human language of the page. |
| 3.2.1 On Focus (Level A) Also applies to:
|
Supports | There are no components in the product that initiate a change of context when focused with a keyboard. |
| 3.2.2 On Input (Level A) Also applies to:
|
Partially Supports | The product substantially conforms to this criterion with one exception:The Filter by attributes block (deprecated in version 9.9), when configured to not have an apply button, triggers a change of context without notice and lacks suitable screen reader announcements. These blocks are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter blocks introduced in version 9.9 for improved accessibility conformance. |
| 3.2.6 Consistent Help (Level A 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable | The product's content does not include help mechanisms or support features for front-end user navigation or understanding. |
| 3.3.1 Error Identification (Level A) Also applies to:
|
Supports | If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. |
| 3.3.2 Labels or Instructions (Level A) Also applies to:
|
Partially Supports | The product substantially conforms to this criterion with two exceptions:The Filter by Attributes and All Products blocks (deprecated in version 9.9), when in dropdown mode lack visible labels. These blocks are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter or All Product blocks introduced in version 9.9 for improved accessibility conformance. |
| 3.3.7 Redundant Entry (Level A 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports | The product does not have scenarios that require users to re-enter information during the same process. When a logged-in user makes a purchase, any information saved on their user account (such as email or billing address) is pre-filled in on the checkout page. Customers can save payment information to their account for easier re-entry. |
| 4.1.1 Parsing (Level A) Applies to: WCAG 2.0 and 2.1 – Always answer ‘Supports’ WCAG 2.2 (obsolete and removed) – Does not apply
|
Supports | For WCAG 2.0, 2.1, EN 301 549, and Revised 508 Standards, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata. |
| 4.1.2 Name, Role, Value (Level A) Also applies to:
|
Supports | All elements in the product have the correct semantic name and role, and their values are programmatically identified. |
Table 2: Success Criteria, Level AA
Notes: Applies to front-end accessibility only, as described in scope.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) Also applies to:
|
Not Applicable | There are no live videos in the product. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) Also applies to:
|
Not Applicable | There is no prerecorded video in the product. |
| 1.3.4 Orientation (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | The product does not restrict the view and operation to a single display orientation, such as portrait or landscape. |
| 1.3.5 Identify Input Purpose (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | All inputs in the product are labeled and can be programmatically identified. |
| 1.4.3 Contrast (Minimum) (Level AA) Also applies to:
|
Supports | All text in the product has a contrast ratio of at least 4.5:1 with the background.Note: The default overlay opacity on the Featured Category and Featured Product blocks may fail color contrast if a light image is used. The blocks provide editors with tools that allow changing the background color and the opacity value of the overlay. Shop owners are encouraged to check the color contrast within this block and select the best overlay opacity depending on the image to ensure color contrast is accessible. |
| 1.4.4 Resize text (Level AA) Also applies to:
|
Supports | Text in the product can be resized without assistive technology up to 200 percent without loss of content or functionality. |
| 1.4.5 Images of Text (Level AA) Also applies to:
|
Supports | There are no images of text in the product. |
| 1.4.10 Reflow (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | The products are sufficiently responsive and can be zoomed up to 400% without loss of information or functionality and without requiring scrolling in two dimensions. |
| 1.4.11 Non-text Contrast (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | All user interface components and graphical objects in the product have a contrast ratio of at least 3:1. |
| 1.4.12 Text Spacing (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Supports | No loss of content or functionality of the product occurs by adjusting line height, paragraph spacing, word spacing, text-spacing, or letter spacing. |
| 1.4.13 Content on Hover or Focus (Level AA 2.1 and 2.2) Also applies to: EN 301 549 Criteria
|
Not Applicable | There is no content displayed on hover or focus in the product. |
| 2.4.5 Multiple Ways (Level AA) Also applies to:
|
Supports | The products provide multiple ways for users to search and filter or navigate to product pages and offer a variety of blocks and shortcodes in support of shop owners adding multiple ways of navigating to the shops. |
| 2.4.6 Headings and Labels (Level AA) Also applies to:
|
Supports | Headings and labels in the product adequately describe the topic or purpose of the sections or related content. |
| 2.4.7 Focus Visible (Level AA) Also applies to:
|
Partially Supports | The product substantially conforms to this criterion with two exceptions:The focus indicator is missing from linked images in the All Products block. This block has been deprecated. Shop owners should switch to the Product Collection block instead, which has focus indicators for images. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports | When a user interface component receives keyboard focus, it remains fully visible and is not obstructed by author-created content. |
| 2.5.7 Dragging Movements (Level AA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports | The products do not include content that rely on dragging movements for functionality. When a dragging movement is supported (such as in the Price Filter slider), alternative input fields are available for keyboard users. |
| 2.5.8 Target Size (Minimum) (Level AA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports | The size of the target for pointer inputs is at least 24 by 24 CSS pixels on all controls in the product. |
| 3.1.2 Language of Parts (Level AA) Also applies to:
|
Not Applicable | The product's content only includes the default language, with no additional languages. |
| 3.2.3 Consistent Navigation (Level AA) Also applies to:
|
Supports | Navigational mechanisms that are repeated on multiple pages within the product, occur in the same relative order each time they are repeated. |
| 3.2.4 Consistent Identification (Level AA) Also applies to:
|
Supports | Components that have the same functionality are identified consistently. |
| 3.3.3 Error Suggestion (Level AA) Also applies to:
|
Supports | The product offers users suggestions for resolving errors. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) Also applies to:
|
Supports | User-entered data is checked for input errors, and the user is given the opportunity to correct them. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports | The product uses username (or email) and password inputs as an authentication method, allowing the user agent (browsers and third-party password managers) to automatically fill in the fields if the author enables this feature. The product does not include any cognitive function tests (such as remembering a password or solving a puzzle) in its log-in forms. |
| 4.1.3 Status Messages (Level AA 2.1 and 2.2) Also applies to:EN 301 549 CriteriaRevised Section 508 – Does not apply
|
Partially Supports | The product substantially conforms to this criterion with some exceptions. The following blocks are missing status messages:These blocks were deprecated in version 9.9 and are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter blocks introduced in version 9.9 for improved accessibility conformance.
|
Table 3: Success Criteria, Level AAA
Notes: Applies to front-end accessibility only, as described in scope.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
1.2.6 Sign Language (Prerecorded) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
There is no prerecorded video in the product. |
1.2.7 Extended Audio Description (Prerecorded) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
There is no prerecorded video in the product. |
1.2.8 Media Alternative (Prerecorded) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
There is no prerecorded video in the product. |
1.2.9 Audio-only (Live) (Level AAA) EN 301 549 Criteria– Does not apply Revised Section 508 – Does not apply |
Not Applicable |
There is no live audio in the product. |
1.3.6 Identify Purpose (Level AAA 2.1 and 2.2) EN 301 549 Criteria– Does not apply Revised Section 508 – Does not apply |
Supports |
In content implemented within the product using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined. |
1.4.6 Contrast (Enhanced) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
All text in the product has a contrast ratio of at least 7:1 with the background. |
1.4.7 Low or No Background Audio (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
There is no prerecorded video or audio in the product. |
1.4.8 Visual Presentation (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The styles within the products allow users to change colors, width, and line spacing within their browser. The text is not justified and can be resized without assistive technology up to 200% without requiring horizontal scroll. |
1.4.9 Images of Text (No Exception) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
There are no images of text in the products. |
2.1.3 Keyboard (No Exception) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
All functionality of the product is operable through a keyboard interface without requiring specific timings for individual keystrokes. |
2.2.3 No Timing (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
Timing is not an essential part of the event or activity presented by the product. |
2.2.4 Interruptions (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
There are no auto-updating content or other interruptions in the product. |
2.2.5 Re-authenticating (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The product does not require users to re-authenticate during a session. Therefore, this criterion is not applicable. |
2.2.6 Timeouts (Level AAA 2.1 and 2.2) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The products do not contain or trigger timeouts which could result in a loss of data. |
2.3.2 Three Flashes (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The product does not contain flashing content or anything that flashes more than three times per second. |
2.3.3 Animation from Interactions (Level AAA 2.1 and 2.2) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The product does not contain animations from interactions. |
2.4.8 Location (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The products contain breadcrumbs on the shop archive, category pages, and product singles to help orient users. |
2.4.9 Link Purpose (Link Only) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The purpose of each link in the product can be identified from link text alone. |
2.4.10 Section Headings (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
Headings in the products effectively organize and label sections or related content. |
2.4.12 Focus Not Obscured (Enhanced) (Level AAA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
When a user interface component receives keyboard focus, it remains fully visible and is not obstructed by author-created content. |
2.4.13 Focus Appearance (Level AAA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Partially Supports |
Many components in the product have a 2px solid outline or utilize the browser default outline. Some components, such as the Product Filters block checkboxes have only a 1px outline on focus. The focus outline color on “Shop now” links in the Featured Category and Featured Product blocks does not use a browser default and may fail contrast depending upon the image used and overlay opacity. Focus outlines can be modified with custom CSS if the shop owner wants to fully to Level AAA for focus appearance. |
2.5.5 Target Size (Level AAA 2.1 and 2.2) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Partially Supports |
The product substantially conforms to this criterion with two exceptions: The buttons for triggering the mini cart and customer account in these blocks are only 42×42 pixels. The buttons for selecting a rating in the reviews block are 24×24 pixels. Target size for these elements can be modified with custom CSS if the shop owner wants to fully level AAA for target size. |
2.5.6 Concurrent Input Mechanisms (Level AAA 2.1 and 2.2) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The product content does not restrict the use of available input modalities on a platform, unless these restrictions are needed to ensure content security or to adhere to user preferences or settings. |
3.1.3 Unusual Words (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The products do not use definitions, words, or phrases in an unusual or restricted manner, including idioms and jargon. |
3.1.4 Abbreviations (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The abbreviations in the product\'s content are clear and easily understood by the intended audience, so no additional expansions or clarifications are necessary. |
3.1.5 Reading Level (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The product does not generate content on the front-end sufficient for calculating a reading-level check. Shop owners are encouraged to check the reading level for their content as it is entered. |
3.1.6 Pronunciation (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The products do not include words whose meaning is ambiguous in context without knowing the pronunciation. |
3.2.5 Change on Request (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Partially Supports |
The product substantially conforms to this criterion with one exception: The Filter by attributes block (deprecated in version 9.9), when configured to not have an apply button, triggers a change of context without notice and lacks suitable screen reader announcements. There is no mechanism for users to turn off this functionality. These blocks are no longer available in the block inserter but may exist on older stores. Shop owners are encouraged to upgrade to the new Product Filter blocks introduced in version 9.9 for improved accessibility conformance. |
3.3.5 Help (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Not Applicable |
The content does not require context-sensitive help, and the labels provided are sufficient to describe all functionality, making additional assistance unnecessary. |
3.3.6 Error Prevention (All) (Level AAA) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
User-entered data is checked for input errors, and the user is given the opportunity to correct them. |
3.3.9 Accessible Authentication (Enhanced) (Level AAA 2.2 only) EN 301 549 Criteria – Does not apply Revised Section 508 – Does not apply |
Supports |
The product uses username (or email) and password inputs as an authentication method, allowing the user agent (browsers and third-party password managers) to automatically fill in the fields if the author enables this feature. The product does not include any cognitive function tests (such as remembering a password or solving a puzzle) in its log-in forms. |
Revised Section 508 Report
↑ Back to topNotes: Applies to front-end accessibility only, as described in scope.
Chapter 3: Functional Performance Criteria (FPC)
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
302.1 Without Vision |
Supports |
Elements in the product that are presented visually (text and images) have alternatives that allow screen reader users and people without vision to operate and understand the product. The product supports non-visual operation through compatibility with screen readers, including JAWS, NVDA and VoiceOver. All interactive elements are accessible using a keyboard alone. Images have meaningful alternative text, and visual-only content is supplemented with text descriptions. Focus order and reading order are logical and programmatically determined. |
302.2 With Limited Vision |
Supports |
Elements in the product that are presented visually (text and images) have alternatives that allow people with limited vision to operate and understand the product when using screen readers, magnifiers, and similar assistive technology. |
302.3 Without Perception of Color |
Supports |
Elements in the product that are presented visually (text and images) do not rely on color alone to present information. Perception of color is not required to use the product. |
302.4 Without Hearing |
Supports |
An audible mode of operation is not provided in the product. Hearing is not required to use the product. |
302.5 With Limited Hearing |
Supports |
An audible mode of operation is not provided in the product. Hearing is not required to use the product. |
302.6 Without Speech |
Supports |
Speech is not used for input, control, or operation of the product. Speech is not required to use the product. |
302.7 With Limited Manipulation |
Supports |
The product provides alternative modes of operation that do not require fine motor control or simultaneous manual operations. All interactive elements are fully operable using a keyboard alone, supporting users with limited manipulation abilities. Controls are designed to be accessible through single actions without the need for complex gestures or multi-finger inputs. Testing with assistive technologies confirms that users with limited dexterity can effectively navigate and operate the product. |
302.8 With Limited Reach and Strength |
Not Applicable |
The product is purely software-based and does not require any physical manipulation, reach, or strength to operate. All functionality is accessed through standard input methods such as keyboard, mouse, or assistive technologies. |
302.9 With Limited Language, Cognitive, and Learning Abilities |
Supports |
The product supports users with limited cognitive and learning abilities by providing a consistent, predictable user interface with clear labels and instructions. Navigation is simple and logical with controls available in multiple locations for key activities such as marking lessons complete and navigating between lessons. Error messages include guidance for recovery. Language is plain and concise, avoiding jargon where possible. The product does not rely on memorization or time-limited interactions, and supports screen reader and text-to-speech tools. |
Chapter 4: Hardware
Notes: Not Applicable
Chapter 5: Software
Notes: The product runs in web browsers and supports platform-documented accessibility features as defined by W3C specifications (HTML5 and ARIA). All interactive elements use semantic HTML or appropriate ARIA attributes to ensure compatibility with assistive technologies. It adheres to WordPress accessibility coding standards as documented for theme accessibility (none exist for plugins).
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
501.1 Scope – Incorporation of WCAG 2.0 AA |
See WCAG 2.x section |
See information in WCAG 2.x section |
502.2.1 User Control of Accessibility Features |
Supports |
The product runs within web browsers and does not override or interfere with user control of platform accessibility features such as screen readers, high contrast mode, zoom, or text resizing. The product respects browser and OS-level accessibility settings and allows users to use assistive technologies without restriction. |
502.2.2 No Disruption of Accessibility Features |
Supports |
The product does not interfere with or disable any platform-defined accessibility features. It does not block screen readers, browser zoom, text resizing, system color schemes, or other assistive technologies. It adheres to standard web development practices and supports interaction with browser and operating system accessibility features as documented by platform vendors (e.g., W3C, Apple, Microsoft). |
502.3.1 Object Information |
Supports |
All user interface components generated by the product use semantic HTML or appropriate WAI-ARIA roles, properties, and states to ensure that role, name, state, description, and boundaries are programmatically determinable by assistive technologies. Custom interactive elements expose the required accessibility information through standard browser accessibility APIs and have been tested with screen readers such as NVDA and VoiceOver. |
502.3.2 Modification of Object Information |
Supports |
The product supports programmatic modification of object states and properties. Interactive components such as checkboxes, buttons, form fields, and expandable elements expose state changes using standard HTML and ARIA attributes. These states (e.g., checked, expanded, selected) can be updated through assistive technologies and are reflected in the accessibility tree, allowing users of screen readers and other AT to perceive and interact with changes appropriately. |
502.3.3 Row, Column, and Headers |
Supports |
The product uses semantic HTML markup for all data tables. Table structures include appropriate <table>, <thead>, <tbody>, <tr>, <th>, and <td> elements, with <th> elements used for row and column headers and scope attributes applied where necessary. This ensures that row and column associations, as well as header relationships, are programmatically determinable by assistive technologies. |
502.3.4 Values |
Supports |
The product ensures that the current values and allowable ranges of interactive components are programmatically determinable by assistive technologies. Standard HTML form elements (e.g., <input>, <select>, <textarea>) are used where applicable, and any custom components (such as sliders or toggles) expose value information through appropriate ARIA attributes (e.g., aria-valuenow, aria-valuemin, aria-valuemax). These values are updated dynamically and reflected in the accessibility tree for screen readers and other assistive tools. |
502.3.5 Modification of Values |
Supports |
The product uses standard HTML form controls and accessible custom components that allow users to set values programmatically, including through assistive technologies. Editable fields such as text inputs, checkboxes, selects, and sliders are fully operable via keyboard and compatible with screen readers and other AT. Where custom widgets are used, in most cases, appropriate ARIA attributes and event handling ensure values can be set without requiring a mouse or complex gestures. |
502.3.6 Label Relationships |
Supports |
The product ensures that nearly all form fields and interactive elements have accessible labels with programmatically determinable relationships. Native HTML labeling methods (e.g., <label for="id">, associated <button> text) are used wherever possible. When custom components are implemented, appropriate ARIA attributes such as aria-label or aria-labelledby are used to establish explicit labeling relationships. These labels are exposed to assistive technologies, allowing users to understand the purpose of each component. |
502.3.7 Hierarchical Relationships |
Supports |
The product maintains programmatically determinable parent-child relationships through semantic HTML structure and appropriate use of ARIA attributes where needed. Containers and their child components—such as grouped form fields, tab panels, menus, and accordions—are correctly structured using HTML nesting, appropriately nested heading levels, and/or ARIA roles like aria-controls and aria-labelledby. These relationships are exposed in the accessibility tree and allow assistive technologies to understand component grouping and hierarchy. |
502.3.8 Text |
Supports |
The product uses standard HTML elements to render text content, ensuring that the text, its attributes (such as bold or italic styling), and its boundaries are programmatically determinable by assistive technologies. Text is not embedded in images or canvas elements and is fully accessible to screen readers and other assistive tools via the browser’s accessibility tree. |
502.3.9 Modification of Text |
Supports |
The product uses standard HTML form elements such as <input>, <textarea>, and content-editable fields that allow users to enter and modify text. These elements support programmatic input and can be operated using assistive technologies, including screen readers, speech-to-text tools, and alternative input devices. The plugin ensures that user-entered text is accessible, editable, and properly exposed in the accessibility tree. |
502.3.10 List of Actions |
Supports |
The product exposes all executable actions on user-interface components through standard HTML semantics and, where necessary, WAI-ARIA roles (e.g., button, link, checkbox, switch) that map to the platform’s accessibility APIs. For custom widgets, the product implements appropriate ARIA interaction patterns (such as role="button" with keyboard event handling and aria-pressed state updates) so assistive technologies can programmatically determine the full set of available actions—such as invoke, toggle, expand/collapse, or select—without relying on pointer input or visual cues. |
502.3.11 Actions on Objects |
Supports |
The product allows assistive technologies to programmatically execute available actions on user interface components. Interactive elements such as buttons, links, form controls, and custom widgets are operable via keyboard and accessible to assistive technologies using standard HTML elements or appropriate ARIA roles and states. The product supports event handling that enables AT users to invoke actions such as clicking, toggling, expanding, or selecting components without requiring mouse or touch input. |
502.3.12 Focus Cursor |
Supports |
The product exposes focus, text insertion point, and selection information using standard HTML and platform accessibility APIs. Interactive elements receive visible focus indicators and support programmatic focus tracking for assistive technologies. Text input fields properly expose the caret position and selection range, allowing screen readers and other AT to report and interact with focused content. The product ensures logical tab order and does not override or suppress browser focus behavior. |
502.3.13 Modification of Focus Cursor |
Supports |
The product allows the focus, text insertion point, and selection attributes to be set programmatically by assistive technologies. All interactive components and text fields can receive focus via keyboard or assistive input, and the text caret and selection range within input fields can be manipulated through AT. The product uses standard HTML elements and adheres to browser and platform conventions to ensure compatibility with screen readers, screen magnifiers, and voice control tools. |
502.3.14 Event Notification |
Supports |
The product provides appropriate event notifications to assistive technologies for all relevant user interactions. Changes in component state (e.g., expanded/collapsed, selected), value, name, description, and boundaries are programmatically exposed using standard HTML and ARIA attributes in compliance with platform accessibility APIs. These notifications are delivered to assistive technologies such as screen readers, enabling users to receive real-time updates about changes within the user interface. |
502.4 Platform Accessibility Features |
Supports |
The product runs within a web browser environment and does not override or interfere with platform-level accessibility features provided by the operating system or browser. These features include support for sequential key entry (e.g., sticky keys), configurable keyboard response timing, visual alternatives to audio, synchronized audio equivalents for visual events, speech output services, and caption display. The product is fully compatible with these platform capabilities, allowing users to access and use assistive features such as screen readers, captions, and alternate input methods without restriction. |
503.2 User Preferences |
Supports |
The product is a web application and therefore qualifies for the exception under 503.2. However, the product is designed to respect user preferences where possible. It does not override browser or operating system settings for color schemes, high contrast mode, font size adjustments, or focus indicators. Users can modify text size using browser zoom or custom styles, and the product ensures compatibility with system-level and browser-based accessibility settings to enhance usability for individuals with vision or cognitive impairments. |
503.3 Alternative User Interfaces |
Not Applicable |
The product does not provide an alternative user interface that functions as assistive technology. |
503.4.1 Caption Controls |
Not Applicable |
The product does not include its own media player or provide custom media playback controls. If media is embedded from third-party platforms such as YouTube and Vimeo, the product does not alter or interfere with the accessibility features or user interface of these third-party players. |
503.4.2 Audio Description Controls |
Not Applicable |
The product does not include its own media player or provide custom controls for program selection or audio description. If media content is embedded from third-party platforms such as YouTube and Vimeo, the product does not modify or interfere with the accessibility features or control interfaces of these third-party media players. |
504.2 Content Creation or Editing (if not authoring tool, enter “not applicable”) |
See WCAG 2.x section |
See information in WCAG 2.x section |
504.2.1 Preservation of Information Provided for Accessibility in Format Conversion |
Not Applicable |
This evaluation covers only the front-end output of the product. The WordPress editor and content authoring features were not in scope for this audit. Therefore, this requirement does not apply. |
504.2.2 PDF Export |
Not Applicable |
The product does not provide functionality to export content as PDF documents. All content is delivered and managed through standard web formats. Therefore, this requirement does not apply. |
504.3 Prompts |
Not Applicable |
This evaluation covers only the front-end output of the product. The WordPress editor and content authoring features were not in scope for this audit. Therefore, this requirement does not apply. |
504.4 Templates |
Supports |
The product provides a variety of templates designed to create content that conforms to Section 508 accessibility requirements. These templates include properly structured headings, lists, tables, and other semantic elements to ensure compatibility with assistive technologies. The templates guide content creators to produce accessible documents by default. Documentation is available on building accessible ecommerce stores using the product. |
Chapter 6: Support Documentation and Services
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
602.2 Accessibility and Compatibility Features |
Partially Supports |
The product provides some documentation explaining accessibility or compatibility features, but the documentation is not comprehensive and does not exhaustively cover all features. Efforts are underway to improve support materials to include guidance for users of assistive technologies. |
602.3 Electronic Support Documentation |
Partially Supports |
The product’s electronic support documentation, including web-based help resources and user guides, does not fully conform to WCAG 2.0 Level A and AA requirements. Some accessibility barriers may exist, such as missing alternative text, improper heading structure, insufficient keyboard navigation, or empty buttons. The AI assistant chat on the website is not accessible. An accessibility remediation plan is being developed to bring documentation into conformance with applicable accessibility standards in the future. |
602.4 Alternate Formats for Non-Electronic Support Documentation |
Not Applicable |
All support documentation for the product is provided in electronic formats only. No non-electronic support documentation is produced or distributed. |
603.2 Information on Accessibility and Compatibility Features |
Partially Supports |
Some documentation about accessibility and compatibility features are available. Additional efforts to document and educate support team on accessibility features are planned. |
603.3 Accommodation of Communication Needs |
Partially Supports |
The product’s primary support services are accessible to individuals with disabilities. Support is provided via accessible electronic communication channels, including email and web-based forms. Users may request accommodations, and support staff respond directly or escalate to a trained point of contact when necessary. The product does not rely on phone-based support, ensuring compatibility with assistive technologies. Note: The AI assistant chat on the website is not accessible. |
EN 301 549 Report
↑ Back to topNotes: Applies to front-end accessibility only, as described in scope.
Chapter 4: Functional Performance Statements (FPS)
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
4.2.1 Usage without vision |
Supports |
The product provides a mode of operation that does not require vision. All interactive elements and content structures are built using semantic HTML and WAI-ARIA attributes, allowing users without vision to navigate and operate the interface using screen readers and other assistive technologies. The product supports keyboard navigation, provides meaningful labels, and exposes role, name, and state programmatically to assistive technologies, ensuring that users can interact with all features without relying on visual cues. |
4.2.2 Usage with limited vision |
Supports |
The product provides features that support users with limited vision. It does not restrict browser zoom functionality or text resizing, allowing users to magnify content as needed. The interface uses sufficient color contrast for text and interactive elements in accordance with WCAG 2.2 Level AA or allows content authors to adjust colors as-needed. No features depend on depth perception alone, and visual cues are supported by other indicators such as icons, labels, or borders. The product is designed to work with screen magnifiers and other assistive technologies, enabling users to make effective use of available vision. |
4.2.3 Usage without perception of colour |
Supports |
The product does not rely on color alone to convey information, instructions, status, or functionality. Where color is used to indicate meaning—such as required fields, errors, or statuses—it is supplemented by additional visual cues such as text labels, icons, or patterns. This ensures that users with limited color perception can fully understand and operate the interface. The product has been designed in accordance with WCAG 2.2 guidelines for color use. |
4.2.4 Usage without hearing |
Supports |
An auditory mode of operation is not provided in the product. Hearing is not required to use the product. |
4.2.5 Usage with limited hearing |
Supports |
An auditory mode of operation is not provided in the product. Hearing is not required to use the product. |
4.2.6 Usage with no or limited vocal capability |
Supports |
Speech is not used for input, control, or operation of the product. Vocal input is not required to use the product. |
4.2.7 Usage with limited manipulation or strength |
Supports |
The product provides alternative modes of operation that do not require fine motor control, simultaneous manual actions, or significant hand strength. Interactive controls are operable through single inputs such as keyboard navigation or assistive devices that accommodate users with limited manipulation abilities. The design minimizes the need for complex gestures, ensuring users with limited dexterity can access all functionality effectively. |
4.2.8 Usage with limited reach |
Not Applicable |
The product is a web-based software application and is not a free-standing or physically installed ICT product. It does not include any physical controls or hardware components that require physical reach. Therefore, this requirement does not apply. |
4.2.9 Minimize photosensitive seizure triggers |
Supports |
The product does not include flashing content, rapid animations, or other visual elements that could trigger photosensitive seizures. No components flash more than three times per second, and no visual effects exceed the thresholds defined in WCAG 2.1 Success Criterion 2.3.1. The product provides a stable and visually safe interface for users with photosensitive conditions. |
4.2.10 Usage with limited cognition, language or learning |
Supports |
The product is designed to be simple and easy to use, supporting individuals with limited cognition, language, or learning abilities. It features a logical focus order, consistent navigation, clear labeling of controls, and error messages that help users identify and correct mistakes. Time-based tasks are not imposed by default, and shop owners are able to organize content in a way that minimizes cognitive load. The product supports screen readers and other assistive technologies that provide audio output, and tasks are broken into clear, manageable steps where applicable. |
4.2.11 Privacy |
Supports |
The product maintains the privacy of users who rely on accessibility features at the same level as other users. Accessibility-related interactions, such as screen reader output or keyboard navigation, do not expose personal or sensitive information to others. The product does not announce masked characters (e.g., in password fields) via speech output and does not collect or transmit accessibility usage data without user consent. Users retain full control over their personal information and how it is displayed or shared. |
Chapter 5: Generic Requirements
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
5.1.2.1 Closed functionality |
See 5.2 through 13 |
See information in 5.2 through 13 |
5.1.2.2 Assistive technology |
See 5.1.3 through 5.1.6 |
See information in 5.1.3 through 5.1.6 |
5.1.3.1 Audio output of visual information |
Not Applicable |
The product is a WordPress plugin that outputs standard HTML content in web browsers. It does not contain <canvas> elements. All visual information is exposed through the browser's accessibility APIs and is available to assistive technologies such as screen readers. Because the product is not closed to assistive technologies, this requirement does not apply. |
5.1.3.2 Auditory output delivery including speech |
Not Applicable |
The product is a WordPress plugin that runs in web browsers on user-controlled devices. It does not provide closed functionality or require auditory output as a substitute for visual information. All content is rendered in standard HTML and is accessible to screen readers and other assistive technologies available on the host platform. Therefore, this requirement does not apply. |
5.1.3.3 Auditory output correlation |
Not Applicable |
The product is a WordPress plugin that operates within web browsers on platforms that support assistive technologies. It does not provide closed functionality or generate its own auditory output as a substitute for visual information. Audio correlation with on-screen content is handled by assistive technologies such as screen readers, which interpret the product’s HTML output. Therefore, this requirement does not apply. |
5.1.3.4 Speech output user control |
Not Applicable |
The product is a WordPress plugin that runs within standard web browsers and does not provide speech output as a form of non-visual access to closed functionality. Any speech output is provided by assistive technologies (such as screen readers), which are responsible for handling user control of speech playback. As the product does not generate or manage its own speech output, this requirement does not apply. |
5.1.3.5 Speech output automatic interruption |
Not Applicable |
The product is a WordPress plugin that does not provide built-in speech output for non-visual access. All auditory output is handled by user-enabled assistive technologies such as screen readers, which manage speech interruption behavior independently. Therefore, this requirement does not apply. |
5.1.3.6 Speech output for non-text content |
Not Applicable |
The product does not generate its own speech output. Non-text content is presented using semantic HTML and includes appropriate text alternatives in accordance with WCAG 2.1 Success Criterion 1.1.1. Speech output, when used, is provided by assistive technologies such as screen readers, not by the product itself. Therefore, this requirement does not apply. |
5.1.3.7 Speech output for video information |
Not Applicable |
The product does not provide speech output or operate as closed functionality. Any video content is embedded from third-party services and is not essential for using the product’s core functions. Assistive technologies such as screen readers are able to access all content rendered by the product. Therefore, this requirement does not apply. |
5.1.3.8 Masked entry |
Not Applicable |
The product does not provide its own speech output or operate as closed functionality. Any password or masked input fields follow standard HTML and browser behavior and are accessible to assistive technologies, which manage auditory feedback according to user settings and privacy controls. Therefore, this requirement does not apply. |
5.1.3.9 Private access to personal data |
Not Applicable |
The product does not provide built-in speech output or operate as closed functionality. Any auditory access to personal data is mediated by assistive technologies such as screen readers, which handle privacy settings and user preferences. Therefore, this requirement does not apply. |
5.1.3.10 Non-interfering audio output |
Not Applicable |
The product does not provide built-in auditory output as non-visual access to closed functionality. It operates within web browsers and relies on assistive technologies, such as screen readers, to deliver auditory information. The product does not automatically play any audio and does not interfere with assistive technology output. Therefore, this requirement does not apply. |
5.1.3.11 Private listening volume |
Not Applicable |
The product does not provide auditory output or operate as closed functionality. It does not include or manage private listening mechanisms or volume control. Auditory output, if any, is provided by assistive technologies such as screen readers, which handle volume control independently. Therefore, this requirement does not apply. |
5.1.3.12 Speaker volume |
Not Applicable |
The product does not include built-in speakers or provide auditory output through speakers as part of non-visual access to closed functionality. It operates within web browsers on user-controlled devices, and any audio output is handled by the platform or assistive technologies. Therefore, this requirement does not apply. |
5.1.3.13 Volume reset |
Not Applicable |
The product does not provide auditory output as non-visual access to closed functionality and does not include volume control or sound playback mechanisms. It operates within a web browser and relies on user devices and assistive technologies for audio output and volume control. Therefore, this requirement does not apply. |
5.1.3.14 Spoken languages |
Not Applicable |
The product does not provide built-in speech output as non-visual access to closed functionality. Any spoken output is handled by assistive technologies, such as screen readers, which manage language settings independently. The product delivers content using standard HTML and does not control or generate speech output directly. Therefore, this requirement does not apply. |
5.1.3.15 Non-visual error identification |
Not Applicable |
The product does not provide built-in speech output as non-visual access to closed functionality. Any error identification and announcement is handled by assistive technologies such as screen readers, which interpret the product’s HTML and ARIA markup. The product ensures that errors are properly exposed to the accessibility tree but does not generate speech output itself. Therefore, this requirement does not apply. |
5.1.3.16 Receipts, tickets, and transactional outputs |
Not Applicable |
The product provides receipts for transactions; however, these are delivered through an accessible web interface that supports screen readers and other assistive technologies. The product does not operate as closed functionality and does not provide speech output directly. As all transactional information is presented in a standard, accessible HTML format within the browser environment, this requirement does not apply. |
5.1.4 Functionality closed to text enlargement |
Not Applicable |
The product operates within standard web browsers and is not closed to platform or assistive technology text enlargement features. Users can enlarge text using browser zoom and operating system settings without loss of functionality or content. Because the product does not restrict or bypass these enlargement capabilities, this requirement does not apply. |
5.1.5 Visual output for auditory information |
Not Applicable |
The product does not provide auditory output as a means of enabling use of closed functionality. It operates within a web environment that is accessible to assistive technologies and does not rely on audio-only instructions or cues. All necessary information is provided visually through standard HTML elements. Therefore, this requirement does not apply. |
5.1.6.1 Closed functionality |
See 5.1.3.1 through 5.1.3.16 |
See information in 5.1.3.1 through 5.1.3.16 |
5.1.6.2 Input focus |
Not Applicable |
The product does not include functionality that is closed to keyboards or keyboard interfaces. It operates within a standard web browser environment and fully supports keyboard navigation. Focus can be moved to and from all interactive elements using standard keyboard interactions. Therefore, this requirement does not apply. |
5.1.7 Access without speech |
Not Applicable |
The product does not require speech input to operate and does not include any voice-controlled functionality. It operates within a web browser using standard input methods such as keyboard, mouse, or assistive technologies. As speech is not required to access any functionality, this requirement does not apply. |
5.2 Activation of accessibility features |
Not Applicable |
The product does not include user-activated accessibility features. All accessibility support (such as semantic HTML, ARIA markup, and screen reader compatibility) is implemented by default without requiring user activation. Therefore, this requirement does not apply. |
5.3 Biometrics |
Not Applicable |
The product does not use biometric data for user identification or control. It operates within a web browser environment and relies on standard web authentication methods, such as username and password. Therefore, this requirement does not apply. |
5.4 Preservation of accessibility information during conversion |
Not Applicable |
The product is a web-based software application that outputs information directly in HTML format. It does not convert or transform content between different formats. As such, it does not perform any restructuring or re-coding transformations that would impact accessibility information. Therefore, this requirement does not apply. |
5.5.1 Means of operation |
Not Applicable |
The product is a web-based software application and does not include any physical operable parts that require grasping, pinching, or twisting of the wrist. All interactions are performed through standard input devices such as a keyboard or mouse within a web browser. Therefore, this requirement does not apply. |
5.5.2 Operable parts discernibility |
Not Applicable |
The product does not include any physical operable parts. It is a web-based software application that operates within a browser using standard HTML controls accessible to assistive technologies. Therefore, this requirement does not apply. |
5.6.1 Tactile or auditory status |
Not Applicable |
The product does not include physical locking or toggle controls. It is a web-based software application that operates within a browser and exposes toggle states programmatically to assistive technologies. Therefore, this requirement does not apply. |
5.6.2 Visual status |
Not Applicable |
The product does not include user-operable locking or toggle controls. Access to course lessons is managed through backend logic based on user actions (e.g., purchase, prerequisites) and the access status is visually indicated on screen. Since the product does not present toggle controls whose state is only non-visually presented, this requirement does not apply. |
5.7 Key repeat |
Not Applicable |
The product does not implement or control key repeat functionality. It is a web-based application that runs in a browser environment, where key repeat behavior is managed by the operating system and user device settings. Therefore, this requirement does not apply. |
5.8 Double-strike key acceptance |
Not Applicable |
The product does not include or control a physical keyboard or keypad, nor does it implement double-strike key acceptance behavior. It operates within a web browser environment and relies on the operating system and browser to manage keyboard input behavior. Therefore, this requirement does not apply. |
5.9 Simultaneous user actions |
Not Applicable |
The product does not require simultaneous user actions for operation. It is a web-based software application that runs in a browser and is fully operable using standard sequential input methods, such as keyboard navigation or assistive technologies. The product does not include physical components or multi-touch gestures. Therefore, this requirement does not apply. |
Chapter 6: ICT with Two-Way Voice Communication
Notes: Not Applicable
Chapter 7: ICT with Video Capabilities
Notes: Not Applicable
Chapter 8: Hardware
Notes: Not Applicable
Chapter 9: Web (see WCAG 2.x section)
Notes: Report for web in the WCAG 2.x section.
Chapter 10: Non-Web Documents
Notes: Not Applicable
Chapter 11: Software
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
11.1.1.1 through 11.4.1.3 |
See WCAG 2.x section |
See information in WCAG 2.x section |
11.5.2.1 Platform accessibility service support for software that provides a user interface |
See 11.5.2.5 through 11.5.2.17 |
See information in 11.5.2.5 through 11.5.2.17 |
11.5.2.2 Platform accessibility service support for assistive technologies |
See 11.5.2.5 through 11.5.2.17 |
See information in 11.5.2.5 through 11.5.2.17 |
11.5.2.3 Use of accessibility services |
See information in 11.5.2.5 through 11.5.2.17 |
See information in 11.5.2.5 through 11.5.2.17 |
11.5.2.4 Assistive technology |
Not Applicable |
The product is a WordPress plugin and does not function as assistive technology. It does not implement or provide accessibility services as defined by the platform. Therefore, this requirement does not apply. |
11.5.2.5 Object information |
Supports |
The product provides a user interface built with semantic HTML and appropriate WAI-ARIA roles, states, and properties to ensure that the role, state, boundary, name, and description of all interactive elements are programmatically determinable by assistive technologies. Custom components such as toggles, progress indicators, and navigation menus expose their accessibility information through standard platform APIs. The product has been tested with screen readers including NVDA and VoiceOver to verify that UI elements are correctly announced and operable. |
11.5.2.6 Row, column, and headers |
Supports |
The product uses semantic HTML table markup to structure data tables, including proper use of <table>, <thead>, <tbody>, <tr>, <th>, and <td> elements. Row and column headers are marked using <th> elements with appropriate scope attributes to associate headers with their corresponding data cells. This ensures that assistive technologies can programmatically determine the position of each cell within the table and the headers associated with it. The product has been tested to confirm that screen readers accurately announce table structure and header relationships. |
11.5.2.7 Values |
Supports |
The product uses standard HTML form controls and appropriate ARIA attributes to ensure that the current value and any defined range of user interface elements are programmatically determinable by assistive technologies. Interactive elements like sliders, progress bars, and input fields expose these values accurately to the accessibility tree. Testing with screen readers confirms that value information is correctly announced and updated in real time. |
11.5.2.8 Label relationships |
Supports |
The product uses semantic HTML labeling techniques, including <label for=""> elements and ARIA attributes such as aria-labelledby and aria-label, to explicitly associate labels with their corresponding user interface controls. These relationships are programmatically determinable by assistive technologies, enabling users to understand the purpose of form fields, buttons, and other interactive elements. The product has been tested with screen readers to verify accurate label announcements and proper label–control associations. |
11.5.2.9 Parent-child relationships |
Supports |
The product uses semantic HTML and ARIA roles and properties to establish clear parent-child relationships among user interface components. Containers and their child elements—such as menus and submenus, accordion panels, tablists and tab panels, or grouped form fields—are programmatically determinable through attributes like aria-controls and appropriate HTML nesting. These relationships are exposed to assistive technologies, ensuring users can navigate and understand the structure and hierarchy of the interface. Testing with screen readers confirms that hierarchical relationships are correctly conveyed. |
11.5.2.10 Text |
Supports |
The product renders text content using standard HTML elements, ensuring that text contents, text attributes (such as bold or italic styling), and text boundaries are programmatically determinable by assistive technologies. Text is not embedded in images or inaccessible elements, and semantic markup is used to provide structure and meaning. Screen reader testing confirms that all text is correctly exposed and can be read aloud or manipulated by assistive tools. |
11.5.2.11 List of available actions |
Supports |
The product exposes all available actions on user interface elements through standard HTML semantics and appropriate ARIA roles and properties. Interactive elements such as buttons, links, checkboxes, toggles, and custom widgets provide programmatically determinable lists of actions, such as click, toggle, expand, and select. These actions are accessible to assistive technologies and can be invoked using keyboard or other input methods. Testing with screen readers confirms that users can discover and perform all supported actions. |
11.5.2.12 Execution of available actions |
Supports |
The product allows assistive technologies to programmatically execute all available actions exposed via the user interface in accordance with Clause 11.5.2.11. Interactive elements such as buttons, toggles, links, and custom widgets are operable using keyboard and other assistive inputs. The product adheres to platform security requirements and ensures that programmatic execution of actions respects those constraints. Testing confirms that assistive technologies can reliably trigger interface actions without security or functional restrictions. |
11.5.2.13 Tracking of focus and selection attributes |
Supports |
The product exposes focus, text insertion point, and selection attributes programmatically using standard HTML and ARIA attributes in accordance with Clause 11.5.2.3. Interactive elements receive visible focus indicators and support assistive technologies in tracking current focus and text selection. Text input fields properly expose caret position and selection range, enabling screen readers and other assistive tools to report and interact with focused content. Testing with multiple assistive technologies confirms accurate focus and selection tracking. |
11.5.2.14 Modification of focus and selection attributes |
Supports |
The product allows assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where users can modify these attributes. Standard HTML input controls and ARIA attributes ensure compatibility with screen readers and other assistive technologies. No security restrictions interfere with these capabilities, enabling users to interact fully with text inputs and navigation elements. |
11.5.2.15 Change notification |
Supports |
The product uses standard HTML and ARIA live regions and event handlers to notify assistive technologies about dynamic changes to user interface elements. Changes in roles, states, values, labels, hierarchical relationships, and focus/selection attributes are programmatically communicated in real time. This ensures that screen readers and other assistive technologies receive timely updates about UI changes, supporting an accessible and responsive user experience. The product has been tested with multiple assistive technologies to verify accurate change notifications. |
11.5.2.16 Modifications of states and properties |
Supports |
The product allows assistive technologies to programmatically modify the states and properties of user interface elements where users can modify these attributes. Using standard ARIA roles and properties, the product exposes interactive element states—such as expanded/collapsed, selected/unselected, and disabled/enabled—that can be updated by assistive technologies to reflect user actions. No security restrictions prevent these modifications. Testing confirms compatibility with screen readers and other assistive tools for real-time state updates. |
11.5.2.17 Modifications of values and text |
Supports |
The product allows assistive technologies to programmatically modify values and text of user interface elements where users have the ability to modify these items through standard input methods. Form fields and text areas expose their values using standard HTML and ARIA attributes, enabling assistive technologies to interact with and update content as necessary. No security restrictions prevent these modifications, ensuring full compatibility with screen readers and other assistive devices. Testing confirms that value and text changes can be performed programmatically by assistive technologies in real time. |
11.6.1 User control of accessibility features |
Not Applicable |
The product is a WordPress plugin and does not function as a platform. It does not provide or control platform-level accessibility features or user settings. Therefore, this requirement does not apply. |
11.6.2 No disruption of accessibility features |
Supports |
The product is designed to coexist with platform accessibility features without disruption. It does not disable, block, or interfere with assistive technologies such as screen readers, keyboard navigation, or high contrast modes. Users maintain full control over platform accessibility settings while using the product. Testing confirms compatibility with common assistive technologies and no observed disruption of accessibility features. |
11.7 User preferences |
Supports |
The product respects user preferences provided by the underlying platform and user agent, including units of measurement, color schemes, contrast, font type, font size, and focus cursor settings. The interface supports browser zoom and user-applied styles, and does not override user preferences unless explicitly changed by the user within the product. The product provides accessible modes that adapt to system settings, ensuring compatibility with user customizations and assistive technologies. |
11.8.2 Accessible content creation |
See WCAG 2.x section (If not authoring tool, enter “Not Applicable”) |
See information in WCAG 2.x section |
11.8.3 Preservation of accessibility information in transformations |
Not Applicable |
Although the product functions as an authoring tool capable of restructuring or re-coding content, the current scope of the audit and this ACR is limited to the front-end output only. The assessment does not cover the transformation processes or authoring interfaces. Therefore, this requirement is outside the scope of this evaluation and is marked as not applicable here. |
11.8.4 Repair assistance |
Not Applicable |
Although the product includes authoring capabilities, the scope of this evaluation is limited to front-end output only. The accessibility checking and repair assistance features related to content compliance with clauses 9 (Web) and 10 (Non-web documents) are outside the scope of this assessment and are not evaluated here. Therefore, this requirement is marked as not applicable for this report. |
11.8.5 Templates |
Partially Supports |
The product includes templates designed to support the creation of content that meets accessibility requirements of clauses 9 (Web) and 10 (Non-web documents). However, formal documentation and guidance for content creators on how to use these templates for accessible content creation have not yet been published. Efforts are underway to develop and provide comprehensive accessibility documentation and training materials.[v][w] |
Chapter 12: Documentation and Support Services
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
12.1.1 Accessibility and compatibility features |
Partially Supports |
The product provides some public documentation in its Accessibility Statement that describes its accessibility and compatibility features; however, the documentation is limited in scope and detail. While key features are noted, comprehensive user guides and detailed accessibility explanations are still in development. Additional documentation is planned to better support users in understanding and utilizing the product’s accessibility capabilities. |
12.1.2 Accessible documentation |
See WCAG 2.x section |
See information in WCAG 2.x section |
12.2.2 Information on accessibility and compatibility features |
Partially Supports |
Some documentation about accessibility and compatibility features are available. Additional efforts to document and educate support team on accessibility features are planned. |
12.2.3 Effective communication |
Supports |
The product’s support services accommodate the communication needs of individuals with disabilities. Support is provided directly through multiple accessible channels, including email and web-based support portals, which comply with accessibility standards. When necessary, the support team refers users to specialized resources or third-party services to ensure effective communication. Staff are trained to recognize and address various accessibility needs, facilitating inclusive and accessible customer service. |
12.2.4 Accessible documentation |
See WCAG 2.x section |
See information in WCAG 2.x section |
Chapter 13: ICT Providing Relay or Emergency Service Access
Notes: Not Applicable
Legal Disclaimer (WooCommerce)
↑ Back to topThis Accessibility Conformance Report (ACR) is provided for informational purposes only and does not constitute legal advice or a guarantee of full legal compliance. The purpose of this ACR is to assist WooCommerce customers in making preliminary assessments regarding the features that support frontend accessibility in version 10.0 of WooCommerce.
WooCommerce makes no warranties of any kind, expressed or implied, in or about this ACR. WooCommerce and Equalize Digital, Inc. expressly disclaim any liability with respect to this ACR, including reliance thereon.
WooCommerce cannot guarantee the accuracy or completeness of this information, which is current as of the date of publication but may be changed without prior notice as further updates are made.
Website owners are solely responsible for assessing and ensuring that their websites are compliant with any applicable laws and regulations, including the Americans with Disabilities Act (ADA), European Accessibility Act (EAA), and Section 508, among others.