Legal · No. 014

Accessibility Statement

BarGraphCreator targets WCAG 2.2 Level AA conformance, with colorblind-safe defaults, full keyboard navigation, and screen reader support built into the tool from the start.

Last reviewed: May 2026

Conformance status: Partial - actively working toward full WCAG 2.2 AA

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.

Contrast Note

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 2.2 AA criterion status as of May 2026
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.

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:

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:

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

  1. W3C Web Accessibility Initiative. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, October 2023. https://www.w3.org/TR/WCAG22/
  2. WebAIM. The WebAIM Million: 2025 Report. Average of 51 accessibility errors per homepage detected across 1 million pages. https://webaim.org/projects/million/
  3. 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
  4. W3C Web Accessibility Initiative. WAI-ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/
  5. W3C Web Accessibility Initiative. Images Tutorial: Complex Images. https://www.w3.org/WAI/tutorials/images/complex/
  6. 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
  7. Deque Systems. axe-core: Accessibility Engine for Automated Testing. https://github.com/dequelabs/axe-core