Accessibility statement for BiasLens

1. Compliance status

BiasLens is partially compliant with WCAG 2.2 Level AA.

Partially compliant means the platform meets most of the standard, and some parts have not been verified. We are not aware of any outstanding failure at Level A or Level AA in the areas we have examined. We are also clear that we have not yet examined everything, and section 4 says exactly what we have and have not tested.

This statement applies to the BiasLens platform at biaslens.beaccessible.co.za, including the public BiasLens Guide, assessment tools, the documents the platform generates, and the emails it sends.

2. What we have verified

Each of these has been checked against the code, page by page, or through real-use testing where stated:

• A skip link to the main content on every assessment tool.
• Semantic landmarks and a logical heading order.
• Every form field has a label that is programmatically joined to it.
• Required fields are announced to screen reader users, not marked with a symbol that only sighted users can perceive.
• Status, risk and findings are conveyed with words as well as colour. No meaning depends on colour alone.
• Results and confirmations are announced to assistive technology as they appear, using live regions.
• Lists of options use standard browser controls rather than custom widgets, so they behave the way people already expect.
• Generated Word documents use real heading styles and table headers, so they can be navigated with assistive technology.
• Your organisation and name are carried across the tools, so you do not have to type them again in each one.
• BiasLens Guide supports typed questions, optional microphone input, editable speech transcription before sending, and optional read-aloud of answers. Real-use testing in Firefox on 19 August 2026 confirmed that speech input, text answers and read-aloud can all complete an end-to-end question-and-answer journey.
• BiasLens Guide keeps voice optional: every voice interaction has a text equivalent, and microphone input never submits automatically.

3. What we found and fixed

We are recording these after fixing them, because they were real barriers that affected real people. We would rather say so than quietly remove them from the record.

Typing moved the cursor out of the field (fixed 31 July 2026)

In the Fairness Metrics Calculator, entering a group name moved focus away from the field after each character. Anyone affected had to click back in repeatedly. This did not meet 3.2.2 On Input (Level A). It affected people typing with one hand, using switch devices or using speech input most of all.

Required fields were not announced (fixed 31 July 2026)

Required fields were marked with a red asterisk that was deliberately hidden from screen readers, and carried no other indication. Sighted users were told a field was required; screen reader users were not. This did not meet 3.3.2 Labels or Instructions (Level A).

The same details had to be typed in every tool (fixed 31 July 2026)

Organisation and name were not carried between tools. This did not meet 3.3.7 Redundant Entry (Level A) and related to 1.3.5 Identify Input Purpose (Level AA). Both are now addressed.

Signing in without a password did not work (fixed 29 July 2026)

The emailed sign-in link failed, and the error told people to try again — which could not have worked. This mattered because signing in without a password is the more accessible route for people who find passwords hard to remember, manage or type. This did not meet 3.3.8 Accessible Authentication (Level AA) or 3.3.3 Error Suggestion (Level AA).

Resetting a forgotten password did not work (fixed 31 July 2026)

The same fault affected password reset. It was confirmed by completing a real reset, not by reading the code, and then fixed and re-tested. Error messages now explain whether a link has expired, has already been used, or was opened in a different browser, and return you to the screen where you can request a new one.

BiasLens Guide duplicated itself on its own page (fixed 19 August 2026)

The floating Guide launcher appeared on the dedicated Guide page, so opening it created a second copy of the same interface. The launcher is now suppressed on the dedicated Guide route and hidden while the floating panel is open.

BiasLens Guide had nested scrolling and duplicate close controls (fixed 19 August 2026)

The page and the conversation panel could scroll independently, and more than one control could appear to close or leave the Guide. This increased mouse precision demands and made the interaction harder to understand. The page behind the Guide is now locked while the panel is open, the inner conversation scrollbar has been removed, and the open panel has a single clear Close control.

Voice input did not work reliably in Firefox (fixed 19 August 2026)

The first implementation depended on browser speech-recognition support, which Firefox does not provide consistently. We replaced that dependency with user-controlled microphone recording followed by server-side audio transcription. The recognised words are placed into the question box for review before the user presses Send.

Voice transcription was blocked by an unavailable model (fixed 19 August 2026)

Microphone recording worked, but the first server-side transcription model was unavailable on the deployed service tier. The voice route was changed to a supported audio-capable model, and Firefox now prefers an OGG/Opus recording format where available. Real-use testing confirmed successful speech-to-text transcription after the change.

Read-aloud controls were difficult to find after long answers (fixed 19 August 2026)

A single read-aloud control was positioned near the question box, which meant it could be out of view after a long response. Each substantive answer now carries its own Listen to this answer andStop listening controls at the end of the answer.

Status and error feedback had insufficient visual contrast (fixed 19 August 2026)

Some voice and read-aloud status messages used text that was too pale to read comfortably against its background. These states were changed to high-contrast text and clearer bordered status or error treatments.

Assistant answers exposed raw markdown symbols (fixed 19 August 2026)

Some answers displayed formatting characters such as double asterisks and raw list markers. The display and read-aloud layers now clean those markers so answers are easier to read and listen to.

Guide layout contained unnecessary controls and empty space (fixed 19 August 2026)

The floating Guide included an unnecessary “Open full page” action, duplicated the Guide heading, and reserved excessive empty space between the conversation and question box. These have been removed or reduced so the interaction uses fewer controls, clearer grouping and less pointer movement.

4. What we have not tested

This is the honest limit of our assessment. An accessibility statement that implies more testing than actually happened is worth less than no statement at all.

• No structured screen reader walkthrough has been carried out.
• No complete keyboard-only walkthrough has been carried out. We have not verified that every function can be reached and operated without a mouse across the full platform.
• No systematic testing at 200% zoom or at 320 pixels width has been carried out.
• Touch target sizes have not been measured systematically.
• Reduced-motion behaviour has not been verified systematically.
• Colour contrast has been measured or corrected on several screens and Guide states, but not systematically across every assessment tool.
• BiasLens Guide multilingual text and terminology have not yet been validated by native-language reviewers across all six supported languages.
• BiasLens Guide speech recognition and read-aloud have been confirmed in Firefox for the real-use journey described above, but they have not yet been tested systematically across browsers, operating systems, all six languages, or a representative range of microphones and speech patterns.
• The platform is used regularly by a member of our team who types with one hand. That is real lived experience of one kind of access need. It is not a substitute for structured testing with people who use screen readers, magnification or switch devices, and we have not yet done that testing.

Until that work is done, we will not claim more than partial compliance, however well the platform performs in the areas we have checked.

5. Content outside our control

BiasLens is built on services provided by other companies:

• Supabase — accounts, sign-in and data storage
• Vercel — hosting and AI Gateway
• Google Gemini — AI responses and audio transcription used by the public BiasLens Guide
• Resend — email delivery
• Your browser and operating system — speech synthesis voices used for optional read-aloud

We have configured these services and we are responsible for how we use them. We cannot change how they are built internally. We have not assessed their own conformance and have not yet requested all relevant conformance reports. We will do so.

We can only vouch for what we built ourselves. Where a barrier comes from one of these services, we will say so and help you work around it.

6. How this statement was prepared

This statement was prepared on 31 July 2026 and last reviewed on 19 August 2026.

It is based on an accessibility audit carried out between 29 and 31 July 2026, covering the sign-in and authentication paths and a code-level review of the assessment tools, together with iterative real-use testing of BiasLens Guide on 18 and 19 August 2026. That Guide testing covered typed and spoken questions, visible feedback, read-aloud, scrolling, control placement, error recovery and pointer effort in Firefox.

Method: self-assessment by BeAccessible. No independent evaluation has been carried out. When we commission one, we will say so here and publish the outcome.

We review this statement whenever we release a significant change, and at least every six months. The next scheduled review is 31 January 2027.

7. Tell us about a barrier

If you find a barrier in BiasLens, please tell us. We would much rather hear about a problem than have someone quietly give up on the tool.

Email: hello@beaccessible.co.za

Tell us what you were trying to do and what got in the way. You do not need to know the technical name for the problem, and you do not need to explain your disability to us.

What happens next: we will acknowledge your message within two working days and tell you what we intend to do and by when. If we cannot fix something quickly, we will offer you a way around it in the meantime.

If you cannot sign in, tell us that too. You do not need an account to contact us, and you do not need an account to read this page.

Alternative formats: if you need this statement, or anything else in BiasLens, in large print, plain text, audio, or read aloud to you, ask and we will arrange it at no cost.

8. If you are not satisfied with our response

We would ask you to raise the matter with us first, but you are not obliged to.

• South Africa — the South African Human Rights Commission, which investigates complaints of human rights violations including unfair discrimination on the grounds of disability. You can lodge a complaint at sahrc.org.za/index.php/lodge-complaints, where complaint forms are provided in eleven languages.
• United Kingdom — the Equality Advisory and Support Service. Freephone 0808 800 0082, textphone 0808 800 0084, or equalityadvisoryservice.com.
• European Union — the national accessibility enforcement body or equality body for your country. These differ by member state, and we will help you identify the right one if you ask.