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. Our WCAG 2.2 Level AA audit and fixes are complete across all 9 Vue components in the add-on sidebar.

What's working well

Dialog accessibility

All modals use role="dialog" and aria-modal="true" with matching aria-labelledby IDs. Focus management and Escape key dismissal are supported.

Button semantics

Every interactive button includes type="button" and descriptive aria-label attributes. Trigger buttons use aria-expanded and aria-controls to communicate state.

Decorative SVG handling

All decorative icons include aria-hidden="true" and focusable="false" so screen readers skip them. No conflicting ARIA attributes on any SVG element.

Loading state announcements

All loading spinners use role="status" with screen-reader-only text so assistive technologies announce when actions are in progress.

Color contrast

All text meets WCAG 2.2 contrast ratios. Helper text uses a minimum opacity of 60% against the base background to ensure readability.

What we fixed

ARIA ID mismatches

Corrected aria-labelledby and aria-controls references that pointed to wrong element IDs across multiple modals.

Textarea accessibility

Replaced disabled with readonly on output textareas so screen readers can still access the content. Removed invalid type="text" attributes from textarea elements.

External link safety

All external links now include rel="noopener noreferrer" and labels indicating they open in a new tab.

Player controls grouping

Audio playback controls in the text-to-speech modal are wrapped in a role="group" with a descriptive aria-label for screen reader context.

What's in the remaining 4%

The remaining items include real-device screen reader testing across NVDA and VoiceOver, and verifying focus trap behavior within Google's sandboxed iframe environment where some native dialog behaviors may differ.

Google Workspace Marketplace requirements

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.

How we test

We audit the add-on with manual code review against WCAG 2.2 Level AA criteria, keyboard-only testing, and automated attribute validation. Each of the 9 Vue components (Text-to-Speech, Translate, Settings, Upgrade, A11Y Checker, Immersive Reader, Statistics, Dyslexia Font, and TTS Trigger) is tested independently.

Links

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