Our Standards

Our website at helperbird.com is built with accessibility and performance in mind. We aim to meet or exceed WCAG 2.2 Level AA across every page.

What we follow

WCAG 2.2 Level AA

All pages are tested against the Web Content Accessibility Guidelines 2.2 at the AA conformance level. This covers keyboard navigation, color contrast, screen reader support, and more.

Semantic HTML

We use proper heading structure, landmarks, ARIA attributes, and native HTML elements so assistive technologies can navigate our site reliably.

Keyboard accessible

Every interactive element on our website can be reached and operated with a keyboard alone. Focus indicators are visible on all focusable elements.

Reduced motion support

Animations and transitions respect the prefers-reduced-motion setting. Users who prefer less motion will see a simplified experience.

High contrast and forced colors

Our styles adapt to Windows High Contrast Mode and other forced color schemes so content stays readable regardless of display settings.

Performance

Pages are statically generated, images are lazy loaded, and we keep our JavaScript bundle small so the site loads fast on any connection.

What's in the remaining 4%

A few areas are still being refined. These include adding aria-current="page" to navigation links dynamically, and improving third-party embed accessibility where we rely on external providers like YouTube.

How we test

We run a combination of automated and manual accessibility testing. Automated scans catch common issues, and we follow up with keyboard and screen reader testing to catch what tools miss.

We ship updates to the site on a regular basis and review accessibility with every change. If you find an issue, please reach out at [email protected].

The Helperbird browser extension is available on Chrome, Edge, Firefox, and Safari. It's the core of what we do and we take its accessibility seriously. Our initial WCAG 2.2 Level AA audit found strong foundations with some areas to improve.

What's working well

Accessible toggle component

Our custom toggle button component supports aria-pressed, dynamic labels, and keyboard activation out of the box.

Focus trap composable

We have a dedicated useFocusTrap composable ready to use across dialogs and modals.

Color picker accessibility

The main popup color picker uses proper role="radiogroup" and role="radio" with arrow key navigation.

Button labelling

Good aria-label coverage on icon-only buttons across the popup and sub-applications. No misuse of positive tabindex values.

Heading structure

The Dictionary sub-app has excellent heading hierarchy from H1 through H3. Reading list cards include proper alt text and labels.

What we're fixing

Modal focus management

Some modals in the settings and editor sub-apps don't yet trap focus or return focus when closed. We'll wire up our existing focus trap composable across all dialogs.

Semantic HTML for interactive elements

A small number of clickable elements use div or img with role="button" instead of native button elements. These will be replaced.

Toggle switch labels

Several feature toggle switches share generic labels. Screen reader users can't easily tell which setting a toggle controls. We're adding unique, descriptive labels to each.

Missing ARIA attributes

Some form inputs are missing aria-describedby links to their helper text, and the sticky note color picker needs role="radio" with aria-checked state.

Missing headings

The Notes and PDF sub-applications are missing H1 headings. Dynamic content updates in the editor statistics modal need aria-live regions.

Decorative SVG cleanup

Some decorative SVG icons are missing aria-hidden="true", causing screen readers to announce irrelevant elements.

How we test

We audit the extension with a combination of manual code review, keyboard-only testing, and screen reader validation. The extension popup and each sub-application (Dictionary, Editor, Notes, PDF, Reading List, Settings) are tested independently.

Links

Chrome · Edge · Firefox · Safari · Privacy Policy · Security

Helperbird for Google Docs and Google Slides runs as a Google Workspace add-on. It brings reading and writing tools directly into the documents you already use.

We haven't started a formal accessibility or compliance audit for the Google Workspace add-on yet. This section will be updated once testing is underway. In the meantime, here's what we already know about how the add-on is built.

What we know so far

Google Workspace Marketplace requirements

Our add-on is published on the Workspace Marketplace and meets Google's requirements for OAuth scope restrictions, data handling, and user consent flows.

Minimal permissions (OAuth scopes)

We request only the OAuth scopes the add-on needs to function. We do not access, store, or share document content beyond what is required for the features you use.

Privacy and data handling

No document content leaves your browser unless a feature explicitly requires it, such as text-to-speech. We do not sell or share user data. We comply with Google's User Data Policy and Limited Use requirements.

Built within Google's UI

The add-on sidebar uses Google's Card Service UI patterns. It runs inside Google's sandboxed iframe environment and does not inject external scripts.

What's next

We plan to run a full accessibility and compliance audit covering keyboard navigation, screen reader support, and WCAG 2.2 conformance within the add-on sidebar. Once complete, we'll publish the results and a compliance score here.

Links

View on Google Workspace Marketplace · Privacy Policy · Terms of Service