How new accessibility standard ISO 30071-1 helps developers

There’s a new international accessibility standard out – ISO 30071-1 – about embedding accessibility in your organisation and processes.

So why should we, as developers, care…?

Aren’t the WCAG checkpoints for developers, and the new ISO for the product/project managers?

Developers don’t have time to be reading every new bit of writing around accessibility. There’s loads of articles out there – some new, some old, some reliable, some misguided. An international standard should be able to be trusted, but does it give developers any solutions for tricky accessibility challenges that they may face?

I asked Jonathan Hassell who led the creation of the standard to help me understand if it’s relevant for developers too. Here we’ll touch on:

Getting accessibility aware and trained to deliver it

Graham: Most developers who face a project manager (large companies) or a client (agencies) who requires accessibility want an easy way in to know what accessibility is, why it’s important, who needs it, and what they need to do. While lots of devs now get accessibility, there are still loads who’ve never been trained.

Jonathan: The new ISO has some things to help here. Take an internal project manager asking about accessibility – if they are following the ISO, they’d should already have put in place awareness training for all staff, including devs. They need to ensure their team understand what accessibility is and how they should deliver it. If they don’t train team members in any areas of accessibility they need, they can’t claim ISO 30071-1 compliance. So the ISO should help get more devs the accessibility training they need.

If it’s a client asking you as a one-person dev company, you’d need to get the training yourself if you need it. But at least if the client was following ISO 30071-1 themselves, they would be clear about what level of accessibility they expect you to deliver, and should have budget set aside for you to do that.

Getting the right requirements for the product you’re creating

Graham: Once they know why accessibility is needed, developers need clear accessibility requirements for what they need to deliver in their project.

Jonathan: So I’m guessing some get these from Business Analysts, and some get them from the client brief?

Graham: Yes. But the key thing is how much detail the accessibility requirements include in each user story. We’ve been having lots of discussions about this recently. Some BAs don’t put in anything about accessibility, and just say “WCAG 2.0 AA is in the Definition of Done”. Others copy all the WCAG success criteria into each user story. Neither of those quite cuts it…

Jonathan: That’s tricky, because it’s about how you communicate accessibility requirements across the team. Copying all the success criteria into Jira isn’t exactly agile. ISO 30071-1 gives you options for what to do: some teams love Test-Driven-Development with loads of detailed Gherkin accessibility tests in the reqs; others haven’t got a clue what TDD is. In general, we think a balance is best: stating what set of accessibility guidelines should be used across the whole product, and then only putting success criteria in a user story when you think it’s key to delivering it, or the team might get them wrong. But whatever works for your team’s existing culture is fine.

Graham: Using the accessibility guidelines as a quick way of setting requirements makes sense. No-one creates their own.

Jonathan: But what if the product is a native app? Do devs (or BAs) know where to get their accessibility requirements from for those?

Graham: Developers could be confused about that. They may care about WCAG but don’t see how it could fit in a native app situation. They just want a list of requirements for accessibility that work for their project. But where else other than WCAG are they going to go, unless they read Apple or Android’s native accessibility API documentation, I guess? And even if they do, it’s not clear how or if WCAG and that documentation tie together. In the end, the stuff they really need is higher-level code and design patterns that explain how interactions like screen reader focus order should work in mobile apps, and what code to use to implement that.

That’s what I get when I’m training – people feeling relieved that I’m talking about how to create screens and widgets and other components. Putting stuff together, rather than just talking about individual success criteria and ARIA roles. It’s there in the documentation, but it’s just much easier to understand in training.

Jonathan: The Standard tries to help here. First, ISO 30071-1 is designed to be about ‘ICT systems’ beyond just web and mobile – so, we’re also talking about software developed for wearables, kiosks in shops and airports, ATMs, games consoles, augmented or virtual reality…

As it’s for more than just the web, ISO 30071-1 doesn’t necessarily expect WCAG to be the set of accessibility guidelines that will always be used. It makes the choice of the appropriate set of guidelines for the device your site or app will be used on a key activity in the project planning, references where to get accessibility standards for different types of device, and also gives hints on what to do to “roll your own” if there are no obvious accessibility guidelines available for the device you’re developing for.

Graham: Like the Native Mobile Accessibility Guidelines we’ve just created for one of our clients?

Jonathan: Yes, those came from our team being asked the same questions all the time about  focus management between screens, how to handle notifications, and the granularity of what’s voiced by the screen reader on each swipe. We realised we needed to build design patterns & code snippets to specify standard best practice behaviours for each of those across all the client’s apps.

They’re a good example of local guidelines being created to build on the great principles in WCAG to create something more specific for a newer device type. Not everyone can build their own like that, but if these design patterns are shared, it adds to the pool of guidelines to get things done.

Does it tell you which WCAG version to use?

Graham: Does the ISO deal with whether people should use WCAG 2.0 or WCAG 2.1? There’s been some confusion around that too.

Jonathan: It tries to be generic, so doesn’t say which you should use right now, because it’ll change as time goes on. And by the time WCAG 2.1 are accepted by most organisations as the ‘right’ guidelines to use, the next set of accessibility guidelines from W3C WAI (Silver) may possibly already have been released.

The ISO makes it clear that a choice needs to be made, and guides you through how to sensibly choose the guidelines you’ll use, based on local laws, accessibility policies in your company, client requirements and the cost implications for a project. In the end, the guidelines used should be a reasoned, conscious choice, based on the exact product being created and the established culture and project resource/budget constraints on the development team.

Graham: Like what we were talking about with WCAG 2.1 requiring apps to work in landscape mode, and product managers pushing back because of the cost?

Jonathan: Yep. ISO 30071-1 tries to get people to engage with the choices that they can make, and how to make justifiable decisions based on the cost/benefit implications. It doesn’t just say “you must comply with WCAG 2.1 AA”.

Graham: So the developer needs to choose?

Jonathan: Maybe, for small agencies, where a client has just said “make it accessible”. Hopefully the client will have specified the right requirements for their needs in the brief or request for proposals, if they’ve created those requirements following ISO 30071-1. If the client didn’t follow they may not know what they need, and have put the usual default of “WCAG 2.0 AA”, whatever the product is. Here the ISO should give the dev or BA the confidence to go back to the client to explain why that might not be sufficient or appropriate, if they’re creating an Alexa Skill or Apple Watch app, say.

Making sure the code or pattern libraries you use are accessible

Graham: What about code or pattern libraries? Does it talk about how to use them well for accessibility?

Jonathan: Yes. No-one’s got the time to create sites or apps from scratch these days. That means that knowing how to choose your JavaScript library, framework or content management system is probably more important in delivering an accessible product than knowing how to code an accessible date-picker. Does the developer usually make the choice of library, in your experience?

Graham: Yes. Unless their company is big enough to have technical architects to make those decisions for them.

Jonathan: So they’re doing the non-functional requirements like whether that date-picker should be an HTML 5 native element, something custom-made by hand with loads of divs, or something you get out of reactJS or a WordPress theme or something?

Graham: Yeah. It makes a lot of difference which you pick, and it’s not as simple a decision as it would be if the HTML 5 native elements were better supported by browsers, screen readers and speech recognition tools.

Jonathan: Which is why you’re doing your series of blogs on whether HTML5 native elements are safe to use yet…

Graham:Absolutely.

What browser and assistive technologies should you test with?

Jonathan: And all this assumes that accessibility options in browsers and assistive technologies like screen readers are available to make your WCAG-compliant code into an accessible user experience for people with disabilities.

Where’s the browser when you’re doing a native mobile app? If you’re doing a kiosk app, even if the kiosk screen’s operating system (many are Android tablets) has accessibility settings and supports assistive technologies (ATs), it’s a locked-down, shared device so people with disabilities are unlikely to be able to access the settings to turn them on.

So you can code to WCAG all you like, but then realise that without the browser settings or assistive technologies (officially the technologies that should follow the User Agent Accessibility Guidelines) that many of success criteria in WCAG are supposed to interface with, you’ve not made an accessible product, just a technically compliant one. Sometimes the type of device you’re working on completely changes the rules.

Graham: And all that’s included in the ISO?

Jonathan: It’s referenced, yes. I’ve been talking about it – what I call the Digital Accessibility Ecosystem that sits between your product and your users who have disabilities – in our BA/Product Manager training for years, and it’ll be a new section in the second edition of my book, which I’m currently updating for ISO 30071-1.

Graham: Cool.

Jonathan: And the ISO also talks about how you could deal with the many different types of ATs that could be in that ecosystem. On Apple it’s easy – your screen reader is Voiceover, whether you’re on Mac, iPad, iPhone, Watch, TV, whatever. But you’ve got 3 different screen readers on Windows, so do you need to support them all? How should you choose? Who should choose?

Graham: It’s a non-functional requirement that no-one wants to own.

Jonathan: Even if you have a test manager on the team, they probably don’t know either. It’s all in the ISO, to think about this stuff at the start, so you get all the requirements nailed down. That way devs, designers, and content people know how they should test the stuff they’re making.

Graham: Because if they don’t, everything will just show up in the accessibility audit, too late to easily sort.

What accessibility testing should developers do? Or should you just wait for the audit?

Jonathan: Exactly. ISO 30071-1 says you should come up with a test strategy for accessibility; a generic default for all your products, which you use on everything other than cutting-edge stuff which may need a different strategy. It talks about: getting people to test the stuff they create; using automated accessibility test tools for what they’re good at; getting QA testers to test what they can do easily and quickly; thinking about testing with ATs as well as testing against guidelines; and whether the cost-benefits of testing with people with disabilities make sense depending on budget. It’s not just audits.

The whole thing is about changing accessibility so it’s more about being trained so you can get things right, rather than having your stuff tested and found wanting at the end of projects because no-one bothered to train you.

It’s about making it the way your team works, not an addition. You don’t do performance, privacy or data-security as an addition. So why do accessibility that way …?

Graham: Absolutely.

Jonathan: And if you’re one of the great developers who has spent time and energy getting good at this stuff, because you think it’s the right thing to do, or because it’s cool, then the ISO can help you get your boss to appreciate your accessibility skills and take accessibility seriously.

Graham: Ok, I’m sold.

So how can you get it?

Jonathan: Glad you like it. You can get it online. It’s a bit expensive. So you could get in touch with us for training on it, or wait the new version of my book, which has loads of examples to make the Standard more understandable.

Graham: When will the new version of the book be released?

Jonathan: Look for it in the Autumn.

Graham: Thanks, Jonathan, for demystifying what ISO30071-1 is all about.

Jonathan: You’re welcome, Graham. Thanks for the questions. And if any developers have any more questions about it, please share them in the comments session below. I’ll be doing some Q&A sessions soon, so I can give you answers then.

Want more?

If this has been useful, you might like to sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every month.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.