binse

ACCESSIBILITY

What works, what does not, and what is untested.

This statement is voluntary. No law requires a one-person business to publish it, and that is exactly why it is worth reading: nothing here is written to satisfy an auditor, so nothing here is rounded up.

Last changed 2026-09-11 · Covers binselytics.com, and the app separately

01 · WHY THIS PAGE EXISTS

We are exempt, and that is a poor answer.

No law requires this page. Here is why it exists.

The European Accessibility Act, Directive (EU) 2019/882, exempts microenterprises providing services from its accessibility requirements under Article 4, and a business with one person in it is a microenterprise. The desktop application is not one of the products the Act lists either: it is not an operating system, a self-service terminal, terminal equipment or an e-reader. So none of what follows is legally required of us.

The exemption is also conditional on staying small, and it is worth nothing to somebody who cannot use the thing. A buyer in a public body or a large organisation will ask this question, and "we are exempt" is not an answer they can put in a file. So here is the real position, including the parts that are not finished.

02 · SCOPE AND TARGET

Two different things, held to two different standards.

Two things, two standards, two separate claims.

This website. Every page of binselytics.com. The target is the Web Content Accessibility Guidelines, version 2.2, Level AA. That is a target rather than a claim of conformance, and section 04 says what has not been checked.

The desktop application. Covered separately, in section 05, and held to no standard at all today, because it has not been tested against one. We are not going to state a level for software nobody has measured. One of its three canvases, Diagrams, is further on than the other two: an automated pass runs over its own screens on every build, and it ships an accessibility checker for the drawings you make in it. Section 05 says what that covers and what it does not.

Where this page says something was checked, it was checked. Where it says something was not, it was not.

03 · WHAT IS BUILT IN

The parts a build can enforce, and does.

Some of this could quietly rot. The rest cannot.

The script that builds this site refuses to finish if any of the checked items below is broken, so those ones are not promises. The others are decisions, and a decision can rot.

  • Contrast. Every text colour on the site was computed against the background it sits on, rather than picked by eye, and the palette was chosen from what passed.
  • The focus ring is never removed. The build fails if the rule that would hide it appears anywhere in the stylesheets. Every focusable thing shows a blue outline when you reach it with a keyboard.
  • One heading of the first level per page, and no level skipped. Both are checked on every built page, and both fail the build.
  • Every image carries a width, a height and a description. Also checked, also fails the build. The width and height are there so that nothing moves under you while the page loads.
  • It works without JavaScript. Every footnote is a real link to a real element that is already in the page, so the evidence behind every number is reachable with scripting switched off. Nothing readable is hidden waiting for a script to reveal it.
  • Motion. The only things that move are a blinking cursor in the wordmark and a progress thread in the margin. If your system asks for reduced motion, both stop. Nothing flashes, nothing auto-plays, and nothing moves for more than a few seconds.
  • Keyboard. A skip link is the first thing you reach. Focus is never moved for you, and there is nothing to get trapped in.
  • Targets. The footnote markers are small, so each one carries an invisible target of 24 by 24 CSS pixels, which is what success criterion 2.5.8 of the standard asks for.
  • Language and structure. The page declares Irish English. Header, navigation, main and footer are real landmarks rather than styled boxes.

04 · WHAT IS NOT DONE

The tests we have not run.

Five checks are on our own list. None has been run.

Our own build brief lists five checks before this site goes live: an automated pass with axe, a manual keyboard pass on every page, a screen-reader pass with NVDA, a rendering pass in Safari and another in Firefox. As of 2026-09-11, none of the five has been run. The site was developed in a Chromium browser, which will approve almost anything and therefore tells you nothing.

So the honest statement is this: the site is built to meet Level AA and has not been tested against it. When those five passes are run, this page will say what they found, including whatever they find that is wrong, and it will keep its date.

There is no light theme, and for some readers that is a barrier. The site is dark because the product is dark and because a second theme is a maintenance cost that a one-person business would eventually stop paying. A reader who needs a light background can print any page, or use the browser's own reader mode: the print stylesheet is a real light rendering rather than an inverted one, and the long pages, the receipts and these legal ones, were laid out with printing in mind.

Some content is dense by nature. The receipts carry raw terminal output in blocks that scroll sideways on a narrow screen. A table of measurements is a table of measurements. We have not found a way to make those easy at a small size without removing the evidence, and we would rather keep the evidence and say so.

05 · THE DESKTOP APPLICATION

Not tested, and here is where it will hurt.

Not tested for conformance. Here is what its own source and its own test runs say instead.

Binse has not been tested for conformance against any accessibility standard, by us or by anybody else. Rather than leave it at that, here is what is known about it from its own source.

  • The workflow canvas is a mouse instrument. Tools are dragged from the palette onto the canvas and joined by dragging between them. There is no keyboard equivalent for placing or connecting a tool. If you cannot use a mouse, you cannot build a workflow.
  • A screen reader will not describe most of the interface. The application's screens carry very little of the markup a screen reader needs to announce a control and its state.
  • The data grid has not been tested with a screen reader or with keyboard navigation on its own, and a grid of that kind is one of the harder things to get right.
  • What does work in your favour: the interface is a web page shown in your own browser, so the browser's zoom, your Windows display scaling and your own text settings apply to it the way they do to any site.

Diagrams is further on than the rest of the app, and it is worth being exact about how far. It is the newest of the three canvases and accessibility was built into it rather than added afterwards. Here is what has been done, and what has not.

  • A keyboard-only path exists, and a test holds it open. One of the acceptance runs builds a connected flowchart with text in it without sending a single pointer event. If placing, joining or labelling a shape from the keyboard stops working, that run fails and the work does not ship. That is the opposite of the workflow canvas above, and it is the honest difference between a canvas built with the keyboard in mind and one that was not.
  • It checks the drawings you make. Diagrams has an accessibility checker of its own, which reads the diagram rather than the interface: text whose contrast is under the threshold, text under a minimum size, a shape or a picture with no description, meaning carried by colour alone with nothing in words beside it, a diagram or page with no useful title, and a reading order that contradicts the arrows. Each finding names the shapes and offers the change that clears it. The user guide lists every check.
  • An automated pass runs over its own screens. Every panel and dialog of Diagrams, in both themes, at three window widths, reports nothing serious or critical from an automated accessibility tool. Two honest qualifications: that tool finds a minority of real barriers, and the moderate and minor findings it does report have never been reviewed.
  • No screen reader has been near it either. The canvas is drawn as a picture with a parallel description of the diagram in the page beside it, which is the arrangement that makes a screen reader possible rather than the proof that one works. Walking the menus, the palette, the properties panel and the outline with a screen reader is on the list of things that still need a person, and nobody has done it.

Why print it. Saying all of that costs a sale to somebody, and finding it out after buying would cost more than a sale. If any of it is a blocker for you, do not buy it yet, and write to us. Knowing that somebody is waiting on a fix is how it gets prioritised.

06 · IF SOMETHING BLOCKS YOU

Tell us, and you get a straight answer.

One address, and a reply that says what happens next.

Write to support@binselytics.com and say what you were trying to do, what got in the way, and what you were using: the browser or the part of the app, and any assistive technology. The support page carries the response window.

You will get one of three answers, and never silence: it is fixed, it is scheduled and here is when, or it is not going to be fixed and here is why. If you need anything on this site in another format, ask and it will be sent as plain text.

The trading identity and the postal address behind that mailbox are on the legal notice.

ABOUT THIS PAGE

This page was written in plain English by the person who wrote the software. It is not legal advice, and it is not a solicitor's work. The legal notice, the terms of sale, the licence agreement, the privacy notice and the accessibility statement are all pending review by an Irish solicitor, and that review has to be finished before the first sale. If the review changes any of them, the changed page is republished and the date at the top of it changes with it.