Accessibility Statement

1.1 We target WCAG 2.2 Level AA for the website, the web application, and the desktop application.

1.2 Where a WCAG success criterion is written for web content and does not map cleanly onto a native desktop application, we apply the equivalent guidance in Apple’s accessibility guidance for macOS.

1.3 We also work towards the requirements of EN 301 549, which is the standard referenced by the European Accessibility Act and by UK public sector regulations.

1.4 Accessibility is treated as a defect class, not a feature request. An accessibility bug is filed, triaged, and fixed like any other bug.

2.1 Status: not yet assessed. No accessibility assessment has been completed for the website, the application, or the desktop application.

2.2 That is the accurate answer, and it is the reason this page does not claim conformance. “Partially conformant” would mean most of the product meets the standard with the exceptions listed honestly in section 6, and we cannot say that without having checked. Overstating conformance is the most common legal exposure in a statement like this one, and it is not a risk worth taking for a sentence.

2.3 Sections 3 and 4 describe measures that are built in. They are what we have done, not what an assessment has verified.

2.4 This statement is reviewed after any significant interface change, and on a cadence that is set when the first assessment is scheduled.

3.1 Keyboard navigation. Every interactive element is reachable and operable by keyboard alone. Tab order follows visual order. There are no keyboard traps. A “skip to content” link is the first focusable element on every page.

3.2 Focus visibility. Focus indicators are visible in both light and dark themes, are not removed by CSS, and are built to the contrast and area requirements of WCAG 2.2 success criteria 2.4.11 (Focus Not Obscured) and 2.4.13 (Focus Appearance).

3.3 Contrast. Body text is set to meet at least 4.5:1 against its background, large text at least 3:1, and interface components and focus indicators at least 3:1, in both themes. Muted text is held to the same floor as body text; we do not use a lighter grey to look calmer.

3.4 Reduced motion. prefers-reduced-motion: reduce disables all non-essential transitions. No content depends on motion to be understood.

3.5 Structure and semantics. One h1 per page, headings in order, landmark regions, lists marked up as lists, tables with real headers, and no heading level used for visual size alone.

3.6 Text alternatives. Every meaningful image has alt text that says what it shows. Decorative images are marked as decorative. Product screenshots that carry information are accompanied by that information in text, so a screenshot is never the only way to learn something.

3.7 Colour is never the only signal. Risk levels (safe, caution, danger) carry a label as well as a colour, on the site and in the product.

3.8 Zoom and reflow. Content reflows to 320 CSS pixels wide without horizontal scrolling and remains usable at 400% zoom. Text can be resized to 200% without loss of content or function.

3.9 Forms. Every field has a persistent visible label, not a placeholder standing in for one. Errors are identified in text, associated with the field programmatically, and describe how to fix the problem.

3.10 Language and titles. Every page declares its language and has a unique, descriptive title.

3.11 Code samples. Code blocks are real text, never images, and are selectable and copyable. Git identifiers are set in the mono face.

4.1 Keyboard navigation. The application is operable by keyboard throughout. Modes are reachable directly, and the command palette reaches every real intent by name, without needing to find it in a menu.

4.2 Focus visibility. Focus is always visible, including inside the Operation Preview drawer, which traps focus while open and returns focus to the element that opened it when it closes.

4.3 Screen-reader labelling. Controls have accessible names and roles. Status changes (an operation starting, a capsule being taken, an operation being refused, Safe Mode engaging) are announced through live regions rather than communicated by colour alone.

4.4 The Operation Preview drawer is built to be fully accessible. The intent, risk level, preconditions, exact commands, checkpoint, and rollback plan are all readable text, in reading order, announced by a screen reader. A dangerous operation is never presented in a way that a screen-reader user cannot fully review before confirming.

4.5 UI scale. The interface scales without clipping or overlap, and independently of the operating system’s own display scaling, so you can combine both.

4.6 Themes. Light, dark, and system themes are all built to the contrast requirements in section 3.3. Light is a fully supported theme, not a degraded second.

4.7 Reduced motion. The operating system’s reduce-motion setting is honoured. Transitions become instant state changes; nothing is lost.

4.8 Colour independence. Risk levels, diff status, conflict markers, and file status carry text or icon indicators alongside colour, so they are distinguishable without colour vision.

4.9 Text. Interface text is real text throughout, never rendered into an image.

4.10 Timing. Nothing in the interface imposes a time limit on a user decision. Agent branch leases have a TTL, and their remaining time is shown as text and can be extended.

4.11 Error messages. Errors say what happened, what state the repository is in, and what you can do next, in text. Doctor findings show evidence in readable text and can be exported as a plain report.

4.12 No demonstration mode. If the core is unavailable, the interface says so in text and stops, rather than showing a silent empty state that a screen-reader user would read as “nothing here”.

5.1 We test with:

5.2 There is no Windows or Linux build, so there is no Windows or Linux testing to report.

5.3 We test across UI scales, in light and dark themes.

5.4 We test keyboard-only operation of every destructive operation path, because those are the paths where a mistake is expensive.

6.1 We would rather tell you what does not work than let you find out. We cannot yet, and saying so is the honest version of this section: no assessment has been completed, so there is no verified list of barriers to publish.

6.2 A statement claiming no limitations at all is not credible, and an invented list is not better than none. The real list goes here when the assessment in section 8 produces one, with what does not work, who it affects, what to do instead in the meantime, and a fix target for each.

6.3 Until then, section 7 is the route. If you hit a barrier, it is a defect we did not know about. Please report it, and it will be listed here.

6.4 Third-party content. Some content would be served by third parties whose accessibility we do not control: a payment checkout and a hosted status page. Neither is engaged yet. When they are, if a third-party barrier stops you completing something, contact us and we will complete it for you by another route.

7.1 Email support@gitaegis.com, or use any channel on the Support page: you do not have to use a special address to be taken seriously. A dedicated accessibility address is not published in this draft.

7.2 It helps if you can tell us:

• what you were trying to do;
• where: a URL, or the mode and screen in the desktop application;
• what assistive technology and version you use, and your operating system;
• what happened, and what you expected.

7.3 What you get back:

• Acknowledgement from a person, not a queue
• An assessment telling you whether we can reproduce it, the severity, and what we intend to do
• A workaround in that same response, where one exists
• A barrier that blocks a task is prioritised for the next release, with a target date given to you
• A non-blocking barrier is scheduled, tracked, and listed in section 6 until it ships
• Follow-up when it is fixed, and a question to you about whether it actually helped

7.4 The number of days each of those stages takes is not set in this draft. It is stated here once it is something a person is rostered to meet.

7.5 A barrier that prevents you completing a task is treated as a blocking defect, at the same severity as a data-affecting bug.

7.6 We will not ask you to prove a disability, and we will not ask you to justify your setup. If it does not work, that is enough.

7.7 If we cannot fix something quickly, we will offer an alternative way to complete the task, including a member of our team doing it with you.

8.1 No assessment has been carried out. Neither a self-evaluation nor a third-party evaluation has been completed, and no auditor has been engaged. A self-evaluation described as an audit is a misrepresentation, and this page will say plainly which one it was when there is one to describe.

8.2 The process we run in the meantime:

• automated checks run in CI on every website build, and a failing check blocks merge;
• manual keyboard-only walkthroughs of every primary task, including every destructive operation path;
• screen-reader walkthroughs on the platforms in section 5;
• contrast verification of every colour pair in the design system, in both themes, whenever a colour changes;
• accessibility review as part of code review for any interface change.

8.3 Automated tooling catches roughly a third of issues. We do not treat a clean automated run as conformance, and we do not publish an automated score as if it were an audit. That is exactly why section 2 says “not yet assessed” rather than borrowing a number from CI.

8.4 We do not use an accessibility overlay, a toolbar widget, or a script that claims to remediate a site automatically. Those tools do not fix underlying defects and frequently interfere with the assistive technology you already use.

9.1 The website works with current versions of Safari, Firefox, Chrome, and Edge, with and without assistive technology, and degrades to readable content without JavaScript.

9.2 The desktop application requires the operating system version on the System requirements page. Accessibility depends in part on the platform’s own accessibility APIs, so an unsupported operating system may behave differently.

9.3 The application respects operating-system settings for contrast, reduce motion, reduce transparency, and text size, in addition to its own UI scale control.

10.1 If our response under section 7 does not resolve the problem, ask for it to be escalated and it will be reviewed independently of whoever answered first. A named escalation contact is not published in this draft.

10.2 If you remain dissatisfied, you may be able to complain to a national enforcement body. The body depends on where you live, for example a national accessibility or equality authority in an EU member state under the European Accessibility Act, or the relevant enforcement body in the United Kingdom or the United States.

10.3 We would much rather fix the problem than be complained about. Section 7.6 applies: tell us, and we will act.

11.1 Accessibility and general support: support@gitaegis.com, Support

11.2 Dedicated accessibility and escalation addresses, and a postal address for Fahid Digital Ventures LLC, are not published in this draft.

11.3 Related: Support · System requirements · Terms of Service · Privacy Policy