Accessibility

What we aim for

We are working towards WCAG 2.1 Level AA, the standard the ADA Title II web rule adopts for state and local government. This product records the meetings of associations, and some of those associations are public bodies; the console should meet the standard the record it produces has to meet.

We do not claim conformance. The sections below say what has been measured, what has been changed but not yet independently verified, and what is known not to work. That distinction is the whole point of the page.

What has been measured

These are checked by automated tests that run on every build, so a change that breaks one of them fails before it can ship.

• Contrast of text and controls (1.4.3, 1.4.11). Every colour pair in the interface is held in a test that computes its contrast ratio, including text over gradients, which is measured against the lighter end rather than the average.
• Keyboard focus is always visible (2.4.7). One focus treatment across every control family, measured against each background it is drawn on, with a test that fails if a hover rule can paint over it.
• State is exposed as state (4.1.2). ARIA state attributes are checked to be strings rather than booleans, because a Blazor boolean silently renders aria-pressed="" for true and omits it for false — a toggle that looks correct and announces nothing.

What has been changed but not independently verified

These were audited page by page and corrected in September 2026. They have not been walked through with a screen reader by someone who uses one daily, which is the verification that would let us say more than this.

• The navigation can be bypassed (2.4.1). Arriving at a page, or moving between pages, puts keyboard focus on that page's heading — past the navigation, without anyone pressing anything. A skip-to-content link is also the first control on every page with the navigation, for the case where scripting has not loaded. Pages are divided into main, nav, header and footer regions, so assistive technology can jump between them directly.
• Heading structure: every page opens at a level-1 heading and descends one level at a time (1.3.1).
• Table structure: every table has a caption and column headers that declare what they head; name-and-value panels use row headers (1.3.1).
• Live captions during a meeting, and status and error messages throughout, are announced without moving focus. Errors interrupt; confirmations wait their turn (4.1.3).
• Instructions that were tooltips are now text on the page — including how to reorder an agenda with the keyboard, which was reachable only by hovering a mouse (3.3.2).
• The page language is declared, and every page has its own title (3.1.1, 2.4.2).
• Animation that starts by itself holds still when the operating system is set to reduce motion (2.2.2).
• A phone or tablet can be set to draw the full desktop layout, and a computer used by touch to show finger-sized controls: see Display on this device, below. The choice belongs to the browser it is made in.
• Reordering an agenda from the keyboard (2.1.1). Focus a row's handle and press the up or down arrow. This was exercised on a running console with real keystrokes on 6 September 2026, and it was broken: the item moved, but focus stayed on the row position rather than following the item, so a second press moved something else. Fixed, and re-measured on the same page — focus now travels with the item across repeated moves, and each move is announced.

Display on this device

The console normally works out its layout from the size of the screen, and makes its controls finger-sized on a touch screen. If that does not suit this device, choose here. The choice is kept by this browser, not by your account, and choosing reloads this page.

• Automatic: the layout follows the screen, and controls grow for a finger on a touch screen. Right for almost everyone.
• Desktop layout: a phone or tablet draws the full layout a computer gets. Pinch to zoom; controls still grow for a finger.
• Touch controls: finger-sized controls and larger form fields on a computer used by touch, such as a Surface or a touch monitor.

What this device reports

Open this page on a phone, tablet or computer to see what its browser tells the console about the screen. The layout follows the screen's size, controls grow when the main pointer is a finger, hover effects appear only where there is hover, and animation holds still when reduced motion is on; the high-contrast answer is shown so it can be checked. These answers are worked out by the stylesheet alone: no script runs to find them, the browser's name is never read, and nothing here is sent to the server. Rotate, resize or zoom, and they change with the layout. The layout line describes the top bar, which appears once you are signed in.

Main pointer

Mouse or trackpad Finger (touch screen) None reported

Hover

Yes No

Layout

Wide: the links in one row Tablet: the links in a second row Phone: the links under the Menu button

Short screen

No Yes: the top bar scrolls away with the page

High-contrast theme

Off On

Reduced motion

Off On: animation holds still

If something looks wrong on a device, a screenshot of this list with the report says which layout the page was drawn with.

Telling us about a problem

If something here stops you doing what you came to do, tell the association whose console this is — they hold the support route for this installation. If you are the administrator of this installation, the problem should reach the supplier who deployed it.

This console usually runs on an association's own network rather than on the public internet, so there is no single address that would be right for every reader of this page. That is why this section names a route rather than a mailbox.