I Spent Two Weeks Writing an Accessibility Report for Brush Ninja

A few weeks ago, someone emailed me asking if Brush Ninja had a VPAT. It didn’t. I also didn’t know where to start - but since a lot of schools use the app, I thought it was worth taking seriously.

For anyone new to the term (as I was), a VPAT (Voluntary Product Accessibility Template) is a document that describes how accessible a product is. It isn’t a pass or fail test - it’s guidance that helps people, like schools, decide if a tool/ website meets their accessibility needs.

Getting Started

When I first opened the template, I’ll admit I felt overwhelmed. There were rows and rows of criteria, and I wasn’t sure how to tackle them. Eventually, I took a deep breath, made a hot chocolate, and started going through each one - slowly, methodically, one item at a time.

I’ve always tried to make Brush Ninja accessible, but I’d never done a proper audit. A lot of the answers were easy - things like Supports or Not Applicable. Others needed more attention.

Sometimes I could have ticked “Partial Support” and moved on, but I decided to fix the problems instead. If I was doing this, I wanted to do it properly.

The Changes I Made

While working through the VPAT, I ended up improving quite a few things:

• Better focus styles. Making sure it’s always clear which part of the app is selected.
• Accessible modals. The tab key now locks focus inside the modal and returns it to the button that opened it once closed.
• Improved file uploads. They now look good, support drag and drop, and work with a keyboard. (CSS :focus-within was a lifesaver here.)
• A rebuilt animation timeline. The keyboard focus order now makes sense, and the selected frame is obvious.
• Added Captions to all user animations. The Brush Ninja gallery is controlled by me, I download videos from social media and re-upload them to the gallery. I went through and added descriptions of the animations to every one.
• Skip Navigation Link. A hidden link at the top of the page that becomes visible when focused. I used to add these in WordPress themes, they allow keyboard users to skip straight to the main content.

None of these were huge changes on their own, but together they made the app feel smoother and more consistent - not just for accessibility, but for everyone.

I have now made a public accessibility statement for Brush Ninja which you can read on the Accessibility page. You can also download the full VPAT document there if you’re interested in the details.

Reflections

Writing the VPAT was a really useful exercise. It forced me to look at Brush Ninja with fresh eyes and consider details I’d taken for granted.

I’ve also learned a lot about accessibility best practices along the way. Things like ARIA roles, semantic HTML, and keyboard navigation are now much clearer to me.

Why It Matters

Accessibility isn’t just about ticking boxes. It’s about making sure that anyone - whether they use a mouse, a keyboard, or a screen reader - can create something. I’ve long understood that accessibility is important and not just for people with sight deficencies. Motor impairments, cognitive differences, and temporary disabilities/ impairments all play a role in how people interact with technology.

Brush Ninja is used by classrooms all over the world. If this work helps even one more student express themselves, it’s worth every minute.

Resources

If you’re thinking about doing your own accessibility review, these tools helped me a lot:

• WAVE Evaluation Tool – a quick, visual way to spot common accessibility issues.
• Axe DevTools – a browser extension that finds more detailed WCAG problems and gives clear suggestions for fixes.

Both are great starting points if you’re new to accessibility audits - and just trying to get these scores as high as possible will make a big difference.