Accessibility
Accessibility statement
This statement covers the j2commerce.com website only. The site is built to WCAG 2.2 Level AA and is partially conformant today; this page lists the parts of the site it covers, the testing behind it, and the limitations that have not been resolved yet.
Our WCAG 2.2 AA target, and where we stand today.
The target is the Web Content Accessibility Guidelines 2.2 at Level AA, published by the W3C. It applies to the parts of the j2commerce.com website listed below, and they are not all at the same point.
We say partially conformant, which means most of the standard is met, and the unmet items are listed as known limitations.
This statement is about this website only. What the J2Commerce 6 extension renders in your own store is described on the storefront accessibility page, and your store's own conformance depends on your template and content.
| Surface | What it is | Conformance claimed | Who controls it |
|---|---|---|---|
| Storefront | This site's extension listings, product pages, cart and modules | Partially conformant, WCAG 2.2 AA | Us |
| Checkout | This site's checkout, address forms, payment and shipping selection | Partially conformant, WCAG 2.2 AA | Us, except fields hosted by a payment provider |
| Admin | The store-management screens our team uses to run this site | Partially conformant, re-audit in progress | Us, on top of Joomla's own admin template |
| Content pages | Feature, solution, support and company pages on j2commerce.com | Partially conformant, WCAG 2.2 AA | Us |
Accessibility measures you can verify on a live page.
- Product pages are keyboard-operable. Choosing a variant, changing quantity, opening the image gallery and adding to the cart all work from the keyboard, in the order the page reads. Nothing needs a hover or a drag.
- Focus is always visible. Every focusable control draws a visible indicator with its own contrast against the surface behind it. No shipped stylesheet removes an outline without drawing a replacement.
- State is never signaled by color alone. Stock state, validation errors, order-status pills and the badges on this very page each pair their color with a word and usually an icon shape.
- Updates announce themselves. A variant switch, an add-to-cart, a coupon, a shipping refresh: each change that happens without a page load is announced to assistive technology or moves focus to the result.
- Native buttons, not scripted look-alikes. The storefront runs on native DOM APIs and native elements. A real button beats a div with a click handler, and dropping the jQuery layer removed a pile of widgets that were never keyboard-operable.
- Admin lists use Joomla's own layouts. Store-management screens are built from the core Joomla 6 list layouts, which ship the table caption, sortable-column semantics and checkbox labeling that hand-rolled markup loses.
- Both template families, together. Two template families ship. A fix to one is not finished until the other matches, so a merchant's choice of front end never decides how accessible their checkout is.
- Accessible names are translated. Labels a screen reader reads aloud go through the language files like any other string. An untranslated name is read out as a raw key, which is its own accessibility defect.
- Tested by hand, not only by tool. Automated checks run on every change, and the W3C itself puts tool coverage at roughly a third of real issues. Keyboard order, focus return after a dialog closes and whether an update is announced are checked by driving the page.
What isn’t accessible yet, listed until it’s fixed.
Current as of September 12, 2026. This list is the reason the conformance claim says partial. It is kept here rather than in an internal tracker, and items leave it only when they are fixed.
| Area | The limitation | Why it exists | What is being done |
|---|---|---|---|
| Payment fields | Card fields hosted by a payment provider are outside our markup | The provider's iframe keeps card data off the store, which is the right trade | Providers whose fields fail basic label and focus checks are flagged on their extension listing |
| Admin forms | A few long configuration forms have grouping that is visual rather than programmatic | Carried over from the pre-rebuild screens and not yet re-cut | Re-audit of admin list and form screens is in progress — it is on the roadmap |
| Flow builder | The visual flow editor is a drag-and-drop canvas with no full keyboard equivalent | A canvas widget, built before the keyboard path was designed | Every flow it can build is also configurable from ordinary forms; a keyboard path for the canvas is open work |
| Merchant content | Product image alt text, headings and link text are written by the store owner | It is their store, and nothing can generate a truthful alt text for a product we cannot see | The product form asks for alt text and the store health screen reports images that have none |
| Generated PDFs | Invoices and packing slips are not tagged PDFs | The rendering path predates the requirement | Every invoice is also available as an HTML page, which is accessible today |
| Older extensions | Extensions still on the 4.x line have not been re-audited against 2.2 | They predate this standard and are in maintenance only | Each listing states its compatibility line, so you can tell before you buy |
| Published audit | There is no third-party audit report or conformance report to link to | None has been commissioned | When one exists it will be linked from this page, with its date and its scope |
On the phrase “100% accessible”
This page does not use it, because accessibility is not a percentage and the work is ongoing. A page can pass every automated check and still be hard to use with a keyboard, so every claim here is checked by hand as well as by automated tools.
How to report an accessibility problem.
This is a separate address from general support, and it is not tied to a purchase. You do not need to own a store, or have bought anything, to tell us that something does not work.
A report that names a limitation we have not listed yet gets that limitation added to the table, whether or not the fix is ready. The list is supposed to grow when someone finds something.
Useful to include
- The page on j2commerce.com where it happened
- What you were trying to do, and where it stopped working
- Your browser, and the assistive technology and version if you use one
What happens next
- A person reads it and replies. No target in hours is published yet, so none is implied.
- We try to reproduce it, and tell you which success criterion it falls under.
- If it is real and not yet listed, it goes into the limitations table above.
- The fix is tracked in public on the issue tracker like any other defect.
When this statement is reviewed, and how we test.
This statement was last reviewed on September 12, 2026, with this website running version 6.6.3 of the J2Commerce core package. It is reviewed again at every minor release, and whenever a report arrives that changes the limitations table.
Method
- Automated checks on every code change, as part of the review that gates a release
- Manual keyboard passes over the buying path: category, product, cart, checkout, confirmation
- Screen-reader passes on the same path, on both shipped template families
- Contrast measured against the tokens in the stylesheet, not judged by eye
No third-party audit has been commissioned, and this page does not imply one. When that changes, the report and its date will be linked from here.
The standard itself, and the rest of the trust pages
- WCAG 2.2, at the W3C
The normative text. Level AA is the middle of its three levels. - Public roadmap
The admin re-audit and the keyboard path for the flow canvas are both on it. - Core changelog
Accessibility fixes appear there like any other change. - Support policy
What a ticket covers, and what is open to everyone. - Security advisories
The same approach applied to a different kind of defect.
