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 WCAG 2.2 Level AA audit and fixes are complete. The remaining 4% covers edge cases that require real-device screen reader testing.

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 fixed

Modal focus management

All modals now trap focus, return focus on close, and can be dismissed with the Escape key or by clicking outside.

Semantic HTML for interactive elements

All clickable elements now use native button elements instead of divs or images with role="button".

Toggle switch labels

Every feature toggle now has a unique, descriptive label so screen reader users can tell exactly which setting each toggle controls.

ARIA attributes

Form inputs are linked to their helper text with aria-describedby. The sticky note color picker now uses proper role="radio" with aria-checked state. Invalid ARIA values have been corrected.

Heading hierarchy

Every sub-application now has a proper H1 heading. Dynamic content updates use aria-live regions.

Decorative SVG cleanup

All decorative SVG icons now include aria-hidden="true" so screen readers skip them.

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