Last reviewed: May 2026
BarGraphCreator is a free, browser-based bar chart tool built by Ready Utilities. It was built to work for everyone, including people who rely on keyboard navigation, screen readers, or who have color vision deficiencies. That wasn't added later as a patch.
This statement covers the current conformance level, what's in place to support users with disabilities, what isn't working yet, and how to flag an issue if something gets in the way.
Conformance Target
BarGraphCreator targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. WCAG 2.2 was published by the W3C in October 2023. It sets out how to make web content accessible to people with disabilities, built around four principles: Perceivable, Operable, Understandable, and Robust (POUR).
Full WCAG 2.2 AA conformance isn't claimed yet. Some areas are still being tested and fixed. Those gaps are laid out in the Known Limitations section below.
The bar across the industry isn't high. The 2025 WebAIM Million report, which scans the top one million homepages every year, found an average of 51 accessibility errors per page, totaling over 50 million distinct errors detected. That number dropped 10.3% from 2024, but 94.8% of homepages still had at least one detectable WCAG failure. BarGraphCreator aims to do considerably better than that.
Accessibility Features
Keyboard Navigation
Every control in the chart builder, including data entry fields, color pickers, chart type selectors, and export buttons, is reachable and operable by keyboard alone. No keyboard traps exist. Tab moves forward through controls; Shift+Tab moves back. Buttons activate with Enter or Space.
Focus Indicators
Focus indicators are visible on every interactive element, satisfying WCAG 2.2 SC 2.4.7 (Focus Visible) at Level AA. SC 2.4.11 (Focus Not Obscured) is also met: no focused element is entirely hidden by sticky headers or overlapping content. Focus styles aren't suppressed anywhere in the CSS, and a distinct :focus-visible style is applied to buttons, links, and form controls throughout the tool.
ARIA Labels and Roles
Landmark regions (header, navigation, main, footer) carry ARIA roles and labels so screen reader users can orient quickly. Non-standard interactive controls get aria-label or aria-labelledby attributes. Live regions flag dynamic changes, such as when a chart updates after data entry, so screen readers announce the update in place rather than requiring the user to navigate away and back.
Colorblind-Safe Default Palette
The default bar palette is built to stay distinguishable across the most common forms of color vision deficiency, including deuteranopia, protanopia, and tritanopia. Color is never the sole means of conveying information in a chart. The colorblind-safe bar chart palette guide covers each palette option and explains how it was chosen.
Custom colors are allowed. The tool doesn't block non-accessible choices, but it flags combinations that are likely to cause contrast problems so users know what they're working with.
SVG Exports with Embedded Accessibility Metadata
SVG exports include an embedded <title> and <desc>. The title comes from whatever the user entered as the chart title. The description gives a brief summary of the chart data. When the SVG is inlined in a webpage, screen readers can read both elements instead of announcing a filename or nothing at all.
For guidance on writing useful text alternatives for data visualizations, see the alt text for bar charts guide.
PNG Export Alt Text Suggestions
PNG files don't carry embedded metadata the way SVG does. When a chart is exported as PNG, the tool displays a suggested alt text string based on the chart title and data summary. Copy it and apply it to the alt attribute when embedding the image. It's a starting point, not a finished description. The user still needs to write something that fits the specific publishing context.
Text Contrast
Body text meets the WCAG 2.2 AA contrast ratio of 4.5:1 against its background. Buttons and labels meet the 3:1 ratio required for large text and graphical UI components. The site uses #0f1419 (near-black) on #f7f3ec (warm off-white), a combination that exceeds the 4.5:1 threshold.
The accent color #c2410c (burnt orange) on #f7f3ec (main paper background) achieves approximately 4.68:1, meeting the 4.5:1 AA threshold. It is used as a decorative accent on kicker labels and borders. Where accent text appears on the warmer #efe8db surface (callout and author byline labels), ink (#0f1419) is used instead to maintain adequate contrast.
Responsive Layout
Pages and the tool interface reflow correctly at 320px viewport width without horizontal scrolling, in line with WCAG 2.2 Success Criterion 1.4.10 (Reflow). Two-dimensional scrolling isn't required at any standard viewport size, with the exception of data tables where collapsing the layout would cause a loss of meaning.
No Motion Traps
There are no auto-playing animations, no content that flashes more than three times per second, no parallax effects, and no animated sequences that could trigger photosensitive or vestibular responses. The prefers-reduced-motion media query is implemented in the CSS, removing the smooth-scroll behavior for users who have set that preference in their operating system.
Conformance Summary Table
| WCAG Criterion | Level | Status | Notes |
|---|---|---|---|
| 1.1.1 Non-text Content | A | Partial | SVG exports include title/desc; PNG alt text is user-applied |
| 1.3.1 Info and Relationships | A | Meets | Semantic HTML5 structure; H1 inside main landmark |
| 1.4.1 Use of Color | A | Meets | Color is not the sole differentiator in default palette |
| 1.4.3 Contrast (Minimum) | AA | Meets | Body text exceeds 4.5:1; small labels use ink on all surfaces |
| 1.4.10 Reflow | AA | Meets | Responsive at 320px width |
| 1.4.11 Non-text Contrast | AA | Meets | Focus indicators and UI boundaries meet 3:1 |
| 2.1.1 Keyboard | A | Meets | All functionality reachable by keyboard |
| 2.1.2 No Keyboard Trap | A | Meets | No traps present |
| 2.4.1 Bypass Blocks | A | Meets | Skip link targets main landmark, which now includes the H1 |
| 2.4.3 Focus Order | A | Meets | Logical DOM order, no tabindex abuse |
| 2.4.7 Focus Visible | AA | Meets | Explicit focus-visible style on all links, buttons, and summary elements |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Meets | scroll-padding-top:74px prevents sticky header from fully hiding focused elements |
| 2.5.8 Target Size (Minimum) | AA | Meets | Nav and footer links: min-height and padding ensure ≥24×24 CSS-pixel targets |
| 3.1.1 Language of Page | A | Meets | lang="en" on every page |
| 4.1.2 Name, Role, Value | A | Partial | Some custom controls under review; page-hero section now carries aria-labelledby |
Known Limitations
These are the known gaps as of May 2026. Each one is being worked on.
- Complex chart ARIA patterns: The rendered SVG chart output doesn't yet implement the full ARIA authoring pattern for data tables or charts as described in the WAI-ARIA Authoring Practices Guide. A screen reader user navigating the chart will hear the title and description, but can't move through individual bar values by arrow key. This is on the development roadmap.
- Color picker control: The custom color picker for individual bar colors doesn't have a fully accessible alternative yet. Users who can't operate the picker via mouse can type a hex value directly into the accompanying text field. That text field path works; the picker itself isn't compliant.
- Error identification: Inline validation messages on the data entry form don't meet WCAG 3.3.1 (Error Identification) in all cases. Some error states show visually but may not surface to all screen reader configurations. This is under active remediation.
- PNG export button: The download trigger for PNG exports uses a dynamically generated anchor element. Testing with NVDA on Windows and VoiceOver on macOS has shown inconsistent announcement behavior across different browser combinations. A fix is in progress.
The WCAG bar chart accessibility guide covers success criteria, testing methods, and practical implementation steps for anyone building accessible charts from the ground up.
About WCAG 3 and Future Planning
WCAG 3, which the W3C's Accessibility Guidelines Working Group has been developing since 2016, introduces a new outcome-based scoring model and a broader scope than previous versions. It's no longer called Web Content Accessibility Guidelines; the name now reads W3C Accessibility Guidelines, reflecting coverage beyond web pages specifically.
As of March 2026, it's still a Working Draft. The most recent update was published on March 3, 2026. A Candidate Recommendation isn't expected until Q4 2027, and a final W3C Recommendation isn't likely before 2028. It won't replace WCAG 2.2 immediately when it does land. Both standards are expected to coexist for several years. No regulator is requiring WCAG 3 conformance today.
WCAG 2.2 AA is the working target here. The WCAG 3 drafts are worth tracking for long-term planning, but nothing built to WCAG 2.2 is wasted effort.
Technical Approach
BarGraphCreator is built with plain HTML, CSS, and JavaScript. No JavaScript framework sits between the DOM and the user, which keeps the markup semantic and makes testing with real assistive technologies more straightforward. Manual testing has been done with:
- NVDA + Firefox on Windows 11
- VoiceOver + Safari on macOS 15 (Sequoia)
- VoiceOver + Safari on iOS 18
- Keyboard-only navigation (Chrome, Firefox, Edge)
- Axe browser extension for automated scanning
Axe automated scanning runs on each page. Automated tools catch a real but limited slice of accessibility problems. Screen reader and keyboard testing is done on top of that because scanners can't catch things like confusing reading order or ARIA labels that are technically present but useless in practice.
Frequently Asked Questions
Is BarGraphCreator usable without a mouse?
Yes. Every core function, data entry, chart type selection, color adjustments, and export, is reachable by keyboard. Tab moves between controls; Enter or Space activates buttons. If a control isn't keyboard-reachable, that's a bug. Report it.
Does the tool work with screen readers?
Partially. The interface, form controls, and page content work with NVDA, VoiceOver, and TalkBack. The SVG chart includes a title and description that screen readers can read. Bar-by-bar navigation within the chart output isn't supported yet. That's being worked on.
Can users with color blindness use BarGraphCreator?
Yes. The default palette is chosen to stay distinguishable across the most common types of color vision deficiency. The colorblind-safe palette guide explains how each default color was selected and how to evaluate custom choices.
Are exported charts accessible when embedded in a webpage?
SVG exports carry embedded title and description text that screen readers pick up when the file is inlined in HTML. PNGs don't carry that metadata, so the tool generates a suggested alt text string at export time. Apply it to the alt attribute when embedding the image. The alt text guide for bar charts covers how to write useful descriptions for different chart types and audiences.
Where can accessibility issues be reported?
Use the contact page to report an issue. Describe what happened, what assistive technology and browser were in use, and how to reproduce the problem. All reports get reviewed. There's no formal turnaround commitment, but the goal is to acknowledge reports within five business days.
Reporting an Accessibility Issue
If something on BarGraphCreator is hard or impossible to use, the contact form is the right place to report it. Including these details helps fix things faster:
- The page URL where the issue occurred
- A description of what was being attempted
- The assistive technology and version in use (for example, NVDA 2026.1, VoiceOver on iOS 18.3)
- The browser and operating system
- What happened versus what was expected
There's no third-party audit body reviewing this site's accessibility. Ready Utilities makes and owns all accessibility decisions here. This statement gets updated when something significant changes in the tool or when the conformance status changes.
Sources & References
- W3C Web Accessibility Initiative. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, October 2023. https://www.w3.org/TR/WCAG22/
- WebAIM. The WebAIM Million: 2025 Report. Average of 51 accessibility errors per homepage detected across 1 million pages. https://webaim.org/projects/million/
- W3C Web Accessibility Initiative. WCAG 3 Working Draft, March 3, 2026. Most recent published Working Draft; Candidate Recommendation not expected before Q4 2027. https://www.w3.org/WAI/news/2026-03-03/wcag3
- W3C Web Accessibility Initiative. WAI-ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/
- W3C Web Accessibility Initiative. Images Tutorial: Complex Images. https://www.w3.org/WAI/tutorials/images/complex/
- W3C Web Accessibility Initiative. WCAG 2.2 SC 2.4.11 Focus Not Obscured (Minimum) and SC 2.4.7 Focus Visible. https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum
- Deque Systems. axe-core: Accessibility Engine for Automated Testing. https://github.com/dequelabs/axe-core