appsforall
appsforall_blog.jpg

Blog

Our recent blogs


What You SHOULD'NT Do When Building an Accessible App

This blog is based on Kira Daley and Amir Ansari’s A11y Camp 2018 presentation ‘Dos and Don’ts When Building an Accessible App’.

Here’s the first part of this blog - What You SHOULD Do When Building an Accessible App.

Don’t Assume Baseline Acceptance Criteria Will Be Used

Even when entire delivery teams know what their responsibilities are in regards to baseline acceptance criteria, conversations around its importance can soon disappear when tight timeframes and conflicting priorities come into play.

One example at Transpire was the first accessibility test on a recent app, which had obvious gaps - blind users struggled to perform a task because certain elements weren't labelled correctly.

But because one of our developers was in the room during usability testing - something Transpire strongly believes in for better collaboration and teamwork - we quickly rectified the issue by the end of the day.

Another way in which we aim to improve communication among our delivery team is with project tracking software Jira, which allows us to set tasks and scope out how certain components could work.

Custom Jira template to ensure accessibility criteria is always front of mind.

Custom Jira template to ensure accessibility criteria is always front of mind.

Previously, we simply copied and pasted the acceptance criteria into Jira. But during our conversations about backlog refinements, we made the effort to create a custom template across every Jira story, ensuring that accessibility criteria such as touch targets and colour contrast is always front of mind.

Another top tip for designers and developers - keep a copy of the acceptance criteria text for the story you’re working on near your design or coding tool. You can then tick off the needs of the story line-by-line as you design or code.

Don’t Shy Away From Challenging Brand Guidelines

More often than not, it’s normal for our designers to be given brand guidelines or some sort of style guide from the customer. The problem is they are typically meant for print and designed by agencies or consultancies who aren't across accessibility, especially when it comes to fonts and colour contrast.

This is despite the fact colour blindness or colour vision deficiency affects around 8% of males and 0.4% of females to some degree in Australia. This year, on three separate occasions, we have found that our customers' brand colours do not adhere to WCAG 2.1 AA standards for colour contrast.

We had conversations with our customers and their brand teams about this, recommending alternative colours that improved accessibility. Here are some examples:

Different brand colours that do and don’t adhere to WCAG 2.1 AA standards.

Different brand colours that do and don’t adhere to WCAG 2.1 AA standards.

Thanks to these open discussions, we managed to modify their colours and make them more accessible. In the third example, we still couldn't meet the minimum 4.5:1 ratio without totally breaking the customer's brand colours, but it did improve dramatically.

As well as colour, custom fonts can also have a big impact on app accessibility. Unfortunately, most companies use custom fonts as part of their brand guidelines.

Even though you can use custom fonts when building native mobile applications, it does have an affect on accessibility. For example, the way one of our design programs rendered a certain font was a lot different to how iOS rendered it.

Therefore, it is highly advisable to design with native fonts because they're optimised for small screens, feature dynamic text support, improve readability, and have trusted rendering weights.

If you can't avoid using custom fonts, ensure your delivery team fully understands how to display them in an accessible way. Needless to say, don't use an image of that font as a means to display it either.

Don’t Let Accessibility Training Slip Within Your Team

Ever since we made accessibility a non-negotiable line item, our team have fully embraced digital inclusion at all stages of the product lifecycle. It's also had a measurable and meaningful impact on every project, ultimately leading to products and experiences that are the best they can be.

But accessibility isn't something that's set in stone - it constantly evolves and adapts to advances in technology or approaches to design. Therefore, it's important to stay up-to-date with the latest trends and developments.

For Transpire, this means sending the team to Apple's Worldwide Developers Conference (WWDC), being aware of changes to Google Material Design guidelines, inviting special guests to run workshops at our office, and raising discussions around the topic of accessibility across the organisation.

Another thing we try to keep our team across at all times is device gestures, as they're often affected by changes to a phone's form factor, like Apple removing the home button for the iPhone X.

We've learnt not to assume how people use assistive technology on their phones either, such as turning on accessibility shortcuts from the get-go. Even though you'll develop a huge sense of empathy without these shortcuts, you'll also receive a huge dose of anxiety.

Key takeaways

  • Start somewhere - Building an accessible app is an evolution. As long as you're starting to do something at some point in time, you're on the right track.

  • It’s OK to get it wrong - One of our guiding principles is ‘good, better, best’.

  • Showcase the impact being accessible has, regardless of whether it’s to internal teams or external stakeholders.

  • Keep up the conversation.

Kira DaleyComment