Our commitment and the target
The target for wms.info is WCAG 2.2 Level AA — a working standard the site is measured against, not a badge to display. This page describes where we have got to. It is written to be checked rather than believed, the same posture we ask you to take toward our vendor reviews.
We do not claim full conformance. The known gaps are below.
What is built in
Accessibility here is a consequence of how pages are constructed rather than a layer added afterward:
- Semantic HTML. Headings run in order without skipped levels, lists are real lists, tables are real tables with header cells, and landmark elements let a screen reader jump straight to the main content.
- Keyboard operability. Every interactive element is reachable and operable with a keyboard alone, in an order that follows the visual layout.
- Visible focus indicators. Focus is drawn with a thick outline and a contrasting halo, so it stays visible on light panels, dark sections and the footer alike. We do not remove focus rings.
- Colour contrast verified against AA. The palette was re-checked against the 4.5:1 body-text threshold and several colours failed, so they were darkened. The teal behind the main call-to-action button measured 3.74:1 against white text — under the threshold, on the most important control on the site — and is now a darker teal at 5.47:1. The muted grey used for secondary body text measured 2.56:1 and was replaced. Borders on interactive controls were separated from decorative hairlines so they meet the 3:1 non-text contrast requirement.
- Alt text. Images carry alternative text describing what they convey in context; decorative images take an empty alt attribute so assistive technology skips them rather than reading out a filename.
- Reduced motion. If your system asks for reduced motion, the site honours it: transitions and animation are switched off and smooth scrolling becomes an instant jump.
Known limitations
These are the problems we know about and have not fixed.
Wide comparison tables on small screens
Several comparison tables carry more columns than a phone screen can show. They sit in a container that scrolls sideways, which keeps the columns intact but leaves part of the table off-screen at any moment. We do not give that container a keyboard affordance of its own, so whether you can scroll it without a pointing device depends on your browser: some recent versions make an overflowing region focusable by themselves, and older ones do not. That is a gap, and it is ours to close. Reading a wide feature matrix through a narrow viewport is a poor experience however it is scrolled, and we have not found a presentation that keeps the comparison intact at that width.
Table header associations
Our comparison tables mark the top row as header cells, so the column a value sits under is announced. The first column is not: the criterion name in each row is a plain data cell rather than a row header, and no scope attributes are set. A screen reader moving cell by cell can therefore tell you a value belongs to one vendor without telling you which criterion it answers — and in a comparison table that pairing is most of the meaning. This affects comparison tables across the site rather than a handful of older pages, and we are correcting them as pages come up for revision.
Third-party advertising
We do not control the markup of advertising creatives served by third parties and cannot guarantee their accessibility. What we publish ourselves is ours to fix; how advertising works here is set out in how we make money.
How we test
Templates go through automated accessibility checks when they change, and key page types get a manual pass by keyboard alone and a second pass with a screen reader.
The automated part catches a fraction of what matters. It reliably finds missing alt attributes, unlabelled controls and contrast failures in the stylesheet. It cannot tell you whether alt text is useful, whether the focus order makes sense to someone who cannot see the layout, or whether a comparison table is intelligible read one cell at a time. Those failures surface only when a person attempts a real task.
Reporting a barrier
If something on this site blocks you, email [email protected]. There is no contact form or phone number here; email is the route, and our contact page describes what happens to it.
What helps us reproduce the problem:
- The URL of the page
- What you were trying to do when you hit the barrier
- Your assistive technology and its version
- Your browser and operating system
You will get a reply within two business days. If the fix will take longer than that, the reply will say so and describe a workaround for reaching the same information meanwhile — an alternative page, or the content sent to you in a usable format. We would rather tell you a fix is weeks away than leave you waiting. Factual corrections, a separate matter, go to [email protected].
Why this matters here specifically
Most of what we publish is dense: weighted scores, feature matrices, side-by-side vendor criteria. People read it while evaluating a purchase that runs to six figures and shapes warehouse operations for years. That reader is comparing specifics — this vendor's integration story against that one's implementation timeline — and the comparison is the whole product.
So an accessibility failure on a comparison page is not cosmetic. If a table cannot be read column by column, the page has failed at its only job, and failed a reader who is trying to make a defensible recommendation to a board. The standard we set for accuracy in our editorial policy applies equally to whether the information can be reached at all.
This statement describes our current position and is revised as the site changes; our terms of use govern use of the site.