Happy Global Accessibility Awareness Day (GAAD), one and all!
We’re celebrating by rolling out several small improvements for screen readers and automatic tools. But we’re avoiding any big surprises, as we’ve always designed with access for all in mind.
As we enter an accessible new year, I thought I’d give a whistle stop tour of some of the ways we do this – and spotlight some amazing free tools that help us. We’re a tiny tech team and hope that this shows that any organisation can build sites accessibly.
Non-decorative images need alternative text. Forms need labels. Headings should follow the right semantic structure.
If you’ve worked on websites for a while, these are all well worn principles. But you’re never too experienced to forget! Every new piece of content we write comes with a responsibility to help everyone access it equally.
If you’re new to writing for the web or haven’t thought about accessibility before, there are some amazing free resources to learn more: Access Guide gives a lovely concise overview of many best practices, with tags so you can review e.g. just those for content authoring in one place; and WebAIM explains the basics, plus loads more.
Accessibility isn’t just for Christmas GAAD Day!
We want to ensure that our most used and most important pages – especially for donors – stay as accessible as they are now, forever.
So we’ve been applying a growing team of robots to the problem! Three favourite tools that have helped us get better just this week include:
- Axe browser extensions. For manual checking – simple but a classic. If you already suspect a problem, it’s such a quick way to hone in on what to fix. We’ve even made some changes to help the robot out, because we’re BFFs now. By using background images less – because a bot can’t tell what overlaps to see whether the contrast is good enough – there is less to re-check manually next time.
- Axe in automated tests. It’s mostly the same tool under the hood, but it runs every single hour we’re working! And messages us if we break anything important. This helpful, noisy bot is in service as of this week and I’m happy we were able to improve things and remove almost all exceptions from our key checks. The less we skip over, the better the chance we hear about a new problem. Regression tests are a great place for these checks to live, because they cover every layer of the site together and it doesn’t really matter how it’s built. I tested out the new checks by making half our footer almost invisible yesterday! (Don’t ask whether it was on purpose🙃). I noticed immediately because now our trusty helper checks colour contrast and other essentials every time it checks that the page is fit for purpose.
- Angular best practice rules. Sometimes we can check our Donate site’s code even sooner and catch mistakes faster. So it’s good to “shift left”: check for certain common mistakes as early in our development process as we can.
We made a new Accessibility statement today. It sets out what we’re aiming for so far, and we’re keen to keep improving to meet those goals.
We also recognise that browser support is connected to widening access, as well as to the environmental impact of planned device obsolescence. We test some older browsers too, but as we iterate I’d love to get donations working on even more older phones to help them stay useful for longer.
How are we doing?
We’d love to hear from you if you have any feedback on Big Give’s accessibility. You can email hello@biggive.org if you’d like to let us know. Thanks to the tools I mentioned, we’re working on making the form to do this more accessible too!