#Introduction
At Birchwood Group LLC ("Birchwood Group", "we", "us", or "our"), we believe that a tool for capturing your voice should be usable by every voice. ArcScribe is a voice recorder and speech to text Chrome extension, and accessibility is not an afterthought for us. Software that turns speech into text has a natural role to play in an accessible web, and we hold ourselves to a high standard so that people with disabilities can record, transcribe, organize, and export their work with confidence.
This Accessibility Statement describes our commitment to inclusive design, the standards we align with, the accessibility features built into ArcScribe, the areas we are still improving, and how you can reach us with feedback. We treat accessibility as an ongoing responsibility, not a box to check, and we welcome the input of the people who use assistive technology every day.
Note: Accessibility is a journey rather than a destination. We publish this statement to be transparent about where we are, what we support well, and where we are still improving.
#Table of Contents
- Executive Summary
- Purpose
- Scope
- Definitions
- Our Accessibility Commitment
- Inclusive Design Principles
- WCAG Alignment
- Keyboard Navigation
- Screen Reader Support
- Color and Contrast
- Text Scaling and Zoom
- Responsive and Flexible Layout
- Motion and Reduced Motion
- Speech to Text as an Accessibility Feature
- Accessibility Testing
- Ongoing Improvements
- Known Limitations
- User Responsibilities
- Company Responsibilities
- Feedback Process
- Examples
- Frequently Asked Questions
- Accessibility Contact
- Future Improvements
- Effective Date, Version, and Last Updated
- Future Policy Changes
- Conclusion
#Executive Summary
- We aim to conform to WCAG 2.1 Level AA. The Web Content Accessibility Guidelines are our benchmark, and we design and test with them in mind.
- Keyboard first. ArcScribe's core actions are reachable with the keyboard, with visible focus indicators.
- Screen reader friendly. We use clear structure, labels, and roles so assistive technology can describe the interface.
- Readable by design. We use strong color contrast, support text scaling, and respect reduced-motion preferences.
- Speech to text is inherently assistive. For people who find typing difficult, ArcScribe turns speech into editable text.
- We listen. If you hit an accessibility barrier, tell us and we will work to fix it.
Best practice: If you use assistive technology, keep it updated to a current version. Accessibility works best when the browser, the assistive tool, and the extension are all current.
#Purpose
The purpose of this statement is to explain how we approach accessibility in ArcScribe, to set clear expectations about what we support, to be honest about current limitations, and to give you a direct channel for feedback. We want people who rely on assistive technology to know, before they install, that ArcScribe was built with them in mind.
#Scope
This statement applies to the ArcScribe Chrome extension, including its side panel interface, and to the ArcScribe website at https://usearcscribe.com. It reflects the current state of the product and is updated as we make improvements. It does not cover third-party websites or services you may reach through links, or the internal behavior of Google Chrome and its speech engine, which are governed by Google's own accessibility commitments.
#Definitions
| Term | Meaning |
|---|---|
| Assistive technology | Software or hardware that helps people with disabilities use computers, such as screen readers, magnifiers, or switch devices. |
| WCAG | The Web Content Accessibility Guidelines, an international standard for digital accessibility. |
| Conformance level | The tier of WCAG compliance (A, AA, or AAA); AA is the common target for products and services. |
| Focus indicator | A visible outline showing which element currently has keyboard focus. |
| Semantic structure | The use of meaningful headings, labels, roles, and landmarks so assistive technology can interpret an interface. |
#Our Accessibility Commitment
Birchwood Group is committed to making ArcScribe usable by the widest possible range of people, including those who are blind or have low vision, are deaf or hard of hearing, have limited mobility, have cognitive differences, or use assistive technology of any kind. We commit to:
- Designing with accessibility in mind from the start, not as a retrofit.
- Aligning our work with recognized standards, principally WCAG 2.1 Level AA.
- Testing with keyboards and assistive technology, not only with a mouse.
- Being transparent about known limitations and our plans to address them.
- Responding to accessibility feedback quickly and treating it as a priority.
Accessibility is an expression of our broader belief that good software respects everyone who uses it.
#Inclusive Design Principles
Our design decisions are guided by a small set of inclusive design principles:
- Provide comparable experiences. Everyone should be able to accomplish the core tasks of recording, transcribing, organizing, and exporting, regardless of how they interact with the interface.
- Consider the full range of users. We design for varied vision, hearing, motor, and cognitive needs, and for a range of devices and settings.
- Give control. We respect user preferences such as reduced motion and text scaling, and we avoid taking control away from the person.
- Offer clarity. We favor clear language, predictable layouts, and obvious controls over clever but confusing patterns.
- Add value without forcing complexity. Powerful features should not come at the cost of a usable, understandable interface.
#WCAG Alignment
We use the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as our primary benchmark. WCAG organizes accessibility around four principles, often summarized as POUR:
- Perceivable. Information and interface elements are presented in ways users can perceive, including through assistive technology.
- Operable. Interface controls can be operated by keyboard and other input methods, not only by mouse.
- Understandable. Content and operation are clear and predictable.
- Robust. The interface works reliably with current assistive technologies.
We design and evaluate ArcScribe against these principles. While we strive for full Level AA conformance, no complex software is ever perfectly conformant at every moment, and we treat any gap we discover as a defect to fix.
#Keyboard Navigation
Many people navigate without a mouse, using a keyboard or a switch device. ArcScribe is designed so that its core actions can be reached and operated from the keyboard, including moving between controls in a logical order and activating buttons. We provide visible focus indicators so you can always tell which control is currently selected.
Best practices we follow for keyboard support include maintaining a sensible focus order, avoiding keyboard traps, and ensuring that interactive elements are reachable and operable without pointing devices. If you find a control that cannot be reached or used with the keyboard, please report it so we can correct it.
#Screen Reader Support
We build ArcScribe so that screen readers can describe the interface accurately. This includes using semantic structure such as meaningful headings and landmarks, providing text labels for buttons and controls, and using appropriate roles and states so assistive technology can announce what an element is and what it does.
Screen reader behavior can vary across combinations of browser and assistive technology. We test with common configurations and continue to refine labeling and structure. If a screen reader announces something incorrectly or fails to describe a control, that feedback is especially valuable to us.
#Color and Contrast
Readability depends heavily on contrast. ArcScribe uses a color system designed to meet or exceed WCAG AA contrast expectations for text and essential interface elements, so content remains legible for people with low vision or color vision differences. We avoid conveying meaning through color alone, pairing color with text or icons where a status needs to be communicated. This means that if you cannot distinguish certain colors, you can still understand the interface.
#Text Scaling and Zoom
People often increase text size or zoom the page to read comfortably. ArcScribe is designed to remain usable when text is enlarged or the interface is zoomed, without content being cut off or controls becoming unreachable. Because ArcScribe runs in the browser, you can also use your browser's zoom and font settings, and the extension aims to respond gracefully to those settings.
Best practice: Use your browser's built-in zoom (commonly Control and Plus, or Command and Plus) together with any operating system text-size settings for the most comfortable reading experience.
#Responsive and Flexible Layout
ArcScribe's interface is built to adapt to different sizes and conditions, including the constrained width of the Chrome side panel and larger website layouts. A flexible layout benefits everyone, and it is particularly important for people who zoom, who use magnification, or who work on smaller displays. We design so that content reflows sensibly rather than forcing horizontal scrolling or hiding important controls.
#Motion and Reduced Motion
Some people are sensitive to motion or prefer a calmer interface. ArcScribe uses motion sparingly and tastefully, and we respect the operating system and browser "reduced motion" preference. When you indicate that you prefer reduced motion, non-essential animations are minimized so the interface feels steady and comfortable. Motion is never used in a way that is essential to understanding a control.
#Speech to Text as an Accessibility Feature
ArcScribe has an inherently assistive purpose. For people who find typing difficult, painful, or slow, whether because of a motor disability, a temporary injury, or another reason, the ability to speak and receive editable text can be genuinely enabling. Live transcription can also support people who prefer to process information as text.
We recognize that this same capability places responsibility on us to make the recording and transcript experience itself accessible, so that the tool designed to help does not introduce new barriers. That is why we pair the speech to text feature with accessible controls, clear labels, and keyboard and screen reader support.
Note: Live transcription uses Chrome's built-in speech engine, which processes audio in the browser and needs an internet connection. Transcription accuracy varies with audio quality, accents, and terminology, so please review transcripts where accuracy matters.
#Accessibility Testing
We evaluate ArcScribe for accessibility using a combination of methods:
- Keyboard testing to confirm that core actions can be performed without a mouse.
- Screen reader checks with common assistive technologies to verify labels, roles, and structure.
- Contrast evaluation to confirm text and key elements meet AA contrast expectations.
- Zoom and text-scaling checks to confirm the interface remains usable when enlarged.
- Reduced-motion checks to confirm the interface honors that preference.
Automated tools help us catch common issues, but we know that automated testing alone cannot capture the real experience of using assistive technology. Human testing and user feedback remain essential, and we prioritize both.
#Ongoing Improvements
Accessibility work is never finished. As we add features and refine the interface, we re-evaluate accessibility and address issues we find. We treat accessibility defects with the same seriousness as functional bugs, and we fold accessibility review into our regular development process rather than saving it for a single audit. When standards evolve, such as the progression of WCAG, we update our targets accordingly.
#Known Limitations
In the spirit of transparency, we acknowledge that some aspects of ArcScribe may not yet be perfectly accessible in every configuration:
- Speech engine dependence. Live transcription depends on Chrome's built-in speech service, and its accuracy and availability are outside our control. Transcripts may contain errors that require review.
- Assistive technology variability. Behavior can differ across combinations of browser version and assistive technology, and we may not have validated every combination.
- Newer features. Recently added features receive continued accessibility refinement after release as we gather real-world feedback.
We list these limitations not as excuses but as commitments: each is an area we are actively working to improve, and your feedback helps us prioritize.
#User Responsibilities
You can help us give you the best accessible experience by:
- Keeping your browser and assistive technology updated to current versions.
- Telling us when something does not work with your setup, including which assistive technology and browser you use.
- Using browser and operating system accessibility settings (such as zoom, text size, and reduced motion) that suit your needs.
#Company Responsibilities
Birchwood Group commits to:
- Designing and building ArcScribe with accessibility as a core requirement.
- Aligning with WCAG 2.1 Level AA and updating our targets as standards evolve.
- Testing with keyboards and assistive technology, not only with a mouse.
- Being transparent about known limitations.
- Responding to accessibility feedback promptly and treating fixes as a priority.
#Feedback Process
Your feedback directly improves ArcScribe's accessibility. If you encounter a barrier, here is how to reach us and what helps us act quickly:
- Email us at support@bwg.llc with "Accessibility" in the subject line.
- Describe the barrier, including what you were trying to do and what happened.
- Tell us your setup, such as your browser, browser version, operating system, and any assistive technology you use.
- Share steps to reproduce if you can, since that helps us find and fix the issue faster.
We aim to acknowledge accessibility reports promptly and to keep you informed as we work on a resolution.
#Examples
Example 1: A keyboard-only user records a note. A user who cannot use a mouse tabs to the record control, activates it with the keyboard, and later tabs to export. Visible focus indicators show where they are at each step, so the whole flow is possible without pointing.
Example 2: A screen reader user reviews a transcript. A blind user navigates the transcript using their screen reader, which announces headings and controls with clear labels, allowing them to read, edit, and export the text.
Example 3: A user with low vision enlarges the interface. A user increases browser zoom and operating system text size. ArcScribe's layout reflows so controls remain reachable and text remains legible without horizontal scrolling.
#Frequently Asked Questions
Which accessibility standard does ArcScribe follow? We use WCAG 2.1 Level AA as our primary benchmark and design and test against it.
Can I use ArcScribe with only a keyboard? Yes. Core actions are reachable and operable from the keyboard, with visible focus indicators.
Does ArcScribe work with screen readers? We build ArcScribe with semantic structure, labels, and roles so screen readers can describe the interface. Behavior can vary across setups, and we welcome reports.
Is speech to text an accessibility feature? Yes. For people who find typing difficult, turning speech into editable text can be genuinely enabling, which is part of ArcScribe's purpose.
How do I report an accessibility issue? Email support@bwg.llc with "Accessibility" in the subject, describe the barrier, and tell us your browser and assistive technology so we can reproduce and fix it.
#Accessibility Contact
- Company: Birchwood Group LLC
- Product: ArcScribe
- Email: support@bwg.llc (please include "Accessibility" in the subject)
- Website: https://usearcscribe.com
- Company website: https://www.bwg.llc
#Future Improvements
We plan to keep raising the bar for accessibility in ArcScribe. Our ongoing priorities include broadening the range of assistive technology configurations we validate, continuing to refine screen reader labeling as features evolve, and monitoring updates to accessibility standards so our targets stay current. As we ship improvements, we will update this statement to reflect them.
#Effective Date, Version, and Last Updated
- Effective Date: July 19, 2026
- Version: 1.0
- Last Updated: July 19, 2026
#Future Policy Changes
We will revise this Accessibility Statement as ArcScribe evolves and as we make accessibility improvements or discover new limitations. When we make a material change, we will update the version number and the "Last Updated" date. We encourage you to check back periodically to see how our accessibility work is progressing.
#Conclusion
Accessibility is central to what ArcScribe is for. A tool that converts speech into text has a real opportunity to remove barriers, and we take seriously the responsibility that comes with that opportunity. We have built ArcScribe to be usable with a keyboard, understandable to screen readers, readable at higher zoom, and respectful of motion preferences, and we are committed to closing the gaps that remain. If ArcScribe does not work well for you, please tell us at support@bwg.llc. Your experience shapes our priorities, and we want ArcScribe to work for everyone.