Last reviewed: August 19, 2026
PitchDetector.com is committed to making its browser-based music tools, educational content, and supporting pages easier to use for as many people as possible.
Our accessibility target is WCAG 2.2 Level AA. We use that standard as a practical benchmark for improving keyboard access, focus visibility, color contrast, text scaling, screen-reader support, responsive layouts, form usability, and other aspects of the user experience.
We do not claim that every page or tool is perfectly accessible in every browser, device, or assistive-technology combination. Where we identify barriers or limitations, our goal is to document them honestly and improve them over time.
For the official accessibility standard, see the W3C Web Content Accessibility Guidelines (WCAG) 2.2.
Our Accessibility Commitment
PitchDetector.com includes interactive tools as well as articles, reference pages, and trust resources.
Accessibility therefore involves more than making text readable. Core experiences may include:
- starting and stopping microphone-based tools;
- reviewing live pitch results;
- using buttons, tabs, sliders, and selectors;
- uploading an audio file where supported;
- changing tuning or notation settings;
- reading charts and educational content;
- navigating between tools and guides;
- contacting us for support.
We aim to make these experiences usable with different input methods and assistive technologies wherever practical.
Our goal is not simply to pass automated accessibility checks. We also consider how real users navigate, understand, and operate the site.
Scope of This Statement
Our accessibility target applies across PitchDetector.com.
Because the site contains a large and growing collection of pages and interactive tools, testing is prioritized around:
- the Online Pitch Detector;
- major tool interfaces;
- navigation and footer systems;
- high-traffic educational pages;
- trust and policy pages;
- contact and support pathways.
Not every page is tested with every browser, operating system, screen reader, zoom level, or device combination.
When we describe a specific environment as tested, that should reflect actual testing rather than a general assumption that all platforms behave the same way.
Semantic Structure and Page Organization
We aim to use meaningful HTML structure so users and assistive technologies can understand page hierarchy and purpose.
This includes appropriate use of:
- headings;
- paragraphs;
- lists;
- buttons;
- form labels;
- links;
- landmarks;
- tables where suitable;
- native HTML controls where practical.
We prefer native browser controls when they can provide the required functionality.
Where custom components are necessary, we aim to provide appropriate accessible names, roles, states, and values.
Keyboard Access
Core site functionality should not require a mouse.
We design interactive elements so users can navigate using the keyboard, including controls such as:
- Start and Stop buttons;
- tabs;
- settings;
- links;
- file selectors;
- form fields;
- reset or copy controls.
We aim for a logical focus order and visible indication of which element currently has keyboard focus.
Interactive components should also avoid trapping keyboard users.
Where dialogs or modal interfaces are used, keyboard behavior should allow users to enter, operate, and leave the component appropriately.
If you encounter a control that cannot be reached or operated using a keyboard, please report it to us.
Focus Visibility
Keyboard users need to be able to see where focus is located.
We aim to provide visible focus indicators for interactive elements and to prevent focused controls from being hidden behind interface elements such as:
- sticky headers;
- banners;
- overlays;
- floating widgets;
- advertising areas.
Focus behavior can vary depending on browser and page layout, so this is an area we continue to review as the site changes.
Color and Visual Information
Color should not be the only way important information is communicated.
For example, pitch or tuning feedback should not rely solely on green, red, or another color.
Where possible, we also provide information such as:
- note name;
- frequency;
- cents value;
- sharp or flat text;
- status labels;
- numerical results.
We also aim to maintain sufficient contrast between text, controls, backgrounds, and focus indicators.
Because visual designs and third-party elements can change, we treat contrast testing as an ongoing quality check rather than claiming that every possible state has been permanently verified.
Text Scaling, Zoom, and Reflow
Users may need larger text or substantial browser zoom.
We aim to support text resizing and high zoom without hiding important content or making core functionality unusable.
Our goal is for layouts to reflow appropriately on narrow screens and at high zoom levels.
However, some complex interactive elements or older layouts may still require horizontal scrolling in certain high-zoom or narrow-screen conditions.
We consider these known accessibility limitations rather than claiming complete 400% reflow support across the entire site.
If you encounter content that becomes unusable when enlarged, please let us know.
Screen Reader Support
We aim to make important controls, labels, instructions, and results understandable to screen-reader users.
For dynamic tools, this may include accessible information about:
- tool state;
- microphone status;
- detected note;
- pitch result;
- errors;
- completed actions.
Live audio tools can generate rapidly changing values, so announcing every numerical change to a screen reader could create an overwhelming experience.
Where live announcements are used, they should prioritize meaningful updates rather than continuously reading every fluctuation.
Screen-reader behavior depends on the browser, operating system, assistive technology, and implementation.
We therefore avoid claiming universal compatibility with every screen reader unless that environment has actually been tested.
Dynamic Results and Status Messages
Interactive audio tools may change state without reloading the page.
Examples include:
- microphone permission requested;
- listening started;
- signal too weak;
- no stable pitch found;
- file analysis completed;
- error detected;
- microphone stopped.
Where practical, important status changes should be exposed in a way that does not require users to visually monitor the screen.
We continue to review dynamic result areas because they are among the most accessibility-sensitive components on an audio-analysis website.
Motion and Animation
Pitch meters, visual indicators, and other interfaces may include motion.
We aim to avoid unnecessary rapid flashing and excessive animation.
Where practical, non-essential motion should respect operating-system reduced-motion preferences or remain understandable without relying on animation.
Important information should still be available through text or numeric results.
If an animation causes difficulty, please report the page and component so we can review it.
Touch Targets and Mobile Use
Many visitors use PitchDetector.com on phones and tablets.
We aim to make important controls large enough and sufficiently spaced for touch interaction.
This is particularly important for:
- Start and Stop controls;
- tabs;
- sliders;
- icon buttons;
- reset controls;
- close buttons;
- tuning settings.
WCAG 2.2 includes updated guidance around minimum pointer-target size and spacing, and we use those principles as part of our mobile accessibility review.
Forms and Input Controls
Forms and tool inputs should provide clear labels and instructions.
We aim to ensure that:
- fields have understandable labels;
- required information is identifiable;
- errors are communicated clearly;
- users can correct errors using a keyboard;
- validation is not communicated through color alone.
This applies to both tool inputs and support/contact interactions.
If you encounter an unlabeled control or unclear validation message, please contact us.
Audio and Microphone Permissions
Microphone permission itself is controlled by the browser and operating system.
PitchDetector.com cannot make the browser’s permission dialog fully accessible on its own because that interface is managed by the user’s browser or device.
Our responsibility is to make the surrounding instructions and tool controls understandable and operable.
For information about how microphone access and audio handling work, see our Data Security & Audio Privacy page.
If the microphone is not working because of browser or device settings, our Troubleshooting page may help.
Audio Files
Where a tool supports audio-file analysis, we aim to provide a clearly labeled method for choosing the file and understanding the analysis state.
Browser support for audio formats and the accessibility of native file-picker interfaces can vary by device and operating system.
If you encounter an accessibility barrier in a file-analysis workflow, please tell us:
- which page you were using;
- your browser;
- operating system;
- assistive technology if applicable;
- what prevented you from completing the task.
How We Test Accessibility
We use a combination of methods rather than relying solely on automated scanners.
Accessibility review may include:
Automated Checks
Automated tools can help identify issues such as:
- missing labels;
- invalid ARIA;
- some contrast problems;
- structural errors;
- duplicate IDs.
Automated testing cannot identify every usability or accessibility issue.
Keyboard Testing
We review representative pages and tool flows without using a mouse.
This can reveal problems with:
- focus order;
- unreachable controls;
- keyboard traps;
- invisible focus;
- modal behavior.
Screen Reader Testing
Representative testing may include supported screen-reader and browser combinations where available.
We do not claim routine testing with a specific assistive technology unless that testing has actually been performed.
Zoom and Reflow Testing
We review layouts at increased zoom and narrow viewport widths to identify content that becomes:
- clipped;
- overlapping;
- inaccessible;
- unnecessarily horizontally scrollable.
Mobile Testing
Important controls are reviewed on representative mobile layouts for:
- target size;
- spacing;
- readability;
- orientation;
- permission workflows.
Manual Review
Manual review is used to evaluate things automation may not understand well, including:
- whether labels make sense;
- whether link text is meaningful;
- whether dynamic updates are understandable;
- whether page order is logical;
- whether important information depends only on color or visual position.
W3C also recommends combining multiple evaluation methods rather than treating a single automated result as proof of accessibility. See its guidance on evaluating web accessibility.
Known Accessibility Limitations
We want to be transparent about areas that may still need improvement.
Potential limitations can include:
High-Zoom Reflow
Some complex tool layouts may require horizontal scrolling at very high zoom or on unusually narrow viewports.
Rapidly Updating Pitch Information
Live pitch values can change quickly. Screen-reader users may receive less granular information than sighted users viewing the meter continuously because announcing every change would be impractical.
Browser-Controlled Interfaces
Microphone permission dialogs and native file pickers are controlled by browsers and operating systems, so their accessibility may vary independently of PitchDetector.com.
Older or Newly Added Tools
A recently added tool or older interface may not yet meet the same accessibility standard as our highest-priority pages.
Third-Party Components
Advertising, embedded services, or independent third-party content may not always meet the same accessibility standards as content we directly control.
Identifying a limitation does not mean we consider it acceptable permanently. It means we want users to know where barriers may currently exist.
Third-Party Content and Services
PitchDetector.com may link to or use services operated by third parties.
We cannot guarantee the accessibility of independent websites, social-media platforms, advertising systems, or other external services.
Where practical, we aim to choose services that do not prevent users from accessing our core tools and content.
If a third-party element blocks navigation, obscures a control, traps keyboard focus, or otherwise interferes with use of PitchDetector.com, please report it.
Advertising and Accessibility
PitchDetector.com may use advertising to support the site.
Advertising should not prevent users from accessing the main tool or important content.
We aim to avoid situations where advertisements:
- obscure interactive controls;
- create keyboard traps;
- unexpectedly move focus;
- prevent a user from reaching content;
- make the page unusable at increased zoom.
Because third-party advertising behavior can change, these areas need ongoing review after ads are deployed.
Requesting Assistance or an Alternative Format
If you cannot access information or complete a task on PitchDetector.com because of an accessibility barrier, contact us.
Tell us:
- the page URL;
- what you were trying to do;
- the barrier you encountered;
- your preferred format or accommodation if relevant.
Where reasonably practical, we will try to provide the information or assistance in another accessible way.
We do not promise that every type of alternative format will always be available, but we will review reasonable requests.
Report an Accessibility Problem
Accessibility feedback is valuable because automated and internal testing cannot reproduce every user’s experience.
If you find:
- an inaccessible control;
- a keyboard problem;
- missing or confusing labels;
- insufficient contrast;
- unreadable text;
- broken zoom/reflow;
- a screen-reader issue;
- a motion problem;
- inaccessible third-party content;
please contact us.
Email: support@pitchdetector.com
When possible, include:
- the page URL;
- browser;
- operating system;
- device;
- assistive technology, if used;
- a brief description of what happened.
You can also use our Contact Us page.
We aim to review accessibility reports as promptly as practical rather than promise a fixed resolution time that may not fit every issue.
Ongoing Improvement
Accessibility is an ongoing part of maintaining PitchDetector.com.
We may review and improve accessibility when:
- new tools are added;
- interfaces are redesigned;
- browser behavior changes;
- accessibility problems are reported;
- third-party services change;
- new accessibility guidance becomes relevant.
A recently modified page should not automatically be assumed accessible simply because its content is newer.
Meaningful testing and user feedback remain important.
Related Policies and Resources
For additional information about PitchDetector.com, see: