Accessibility
How Borago Board and this website work with a screen reader, a keyboard and a touch screen, what is known to be missing, and how to report a barrier.
This statement covers the Borago Board desktop app, the board in a browser and on a phone, and this website. It describes what has been done, in the app's own terms, and names the gaps that are known. It is not a certification.
The board
Dialogs. Every dialog is announced as a dialog with a name, such as the task's title, "Settings" or "Edit project". A confirmation is announced as an alert dialog. The notifications panel is a named dialog, and the bell button tells a screen reader that it opens one, whether it is open, and how many notifications are unread.
Buttons that are only an icon carry a spoken name as well as a tooltip. That includes the container controls, the terminal, edit and add-project buttons, a card's edit control, comment actions and every dialog's close button.
Controls that appear on hover also appear on keyboard focus, and on a touch screen they are always visible and sized for a finger. Nothing is a hidden hit target.
Status shown by an icon or a colour has a text equivalent. A card's working spinner, its hung and container-error icons, the container warnings in the filter bar and the connection dots in the top bar all have spoken names.
Columns are regions named by their status and their task count, with a real heading each. Filters are grouped, toggles announce their state as switches, and the project picker is a list box that arrow keys, Home and End move through and Escape closes.
Buttons are in one order everywhere. The button that commits is on the right and the one that cancels is on the left, in every dialog and every inline form, and that is also the tab order. Enter submits.
Text is legible. Meaningful text on the dark theme sits at no less than 45 percent white, form labels at 55 percent, and no meaningful text is smaller than 11 pixels. Placeholders and disabled states are the deliberate exceptions.
Copy style. No em dashes, no decorative arrows, no semicolons, and no trailing ellipsis on a control's name, so a label reads the same way on a screen and through a screen reader.
On a phone, each column is a full-width page. Swiping moves between columns. A card is moved with press and hold, and dragged onto a rail of drop targets to change column.
This website
- Every page starts with a skip link to the main content.
- The navigation is named, and the current page's link says so.
- The download page's requirement tabs follow the full tabs pattern, including arrow key, Home and End movement.
- Every section has a heading, sometimes visible only to a screen reader. Repeated links such as the per-package download buttons say which file they fetch.
- Decorative graphics are hidden from assistive technology. The theme switch describes the current and the next theme.
- The site sets no cookies, loads no third-party scripts and shows no pop-ups.
- Text and layout work at phone width with no horizontal scrolling, and the site follows the operating system's light or dark preference.
Known gaps
- A task card can be focused and moved with the keyboard, but opening it is a click. Full keyboard operation of the board is not complete.
- The terminal is a canvas-drawn terminal. Its content is not exposed as text to a screen reader.
- The paint dialog is a drawing surface and has no non-visual equivalent.
- No formal audit against WCAG has been carried out. The conventions above were set in a screen-reader compatibility pass and are kept by tests, not by an external review.
Reporting a barrier
Use Report a problem under Settings, then Help & diagnostics, in the app, or the contact form at Borago Soft. Say which screen, which control and which assistive technology, and what happened.
Related: Keyboard and mouse, FAQ, Privacy.