Creating a banking web app with accessibility in mind - Interview with Kitty Giraudel of N26
It's always fascinating to talk to people that are moving the needle towards inclusivity in their company by ensuring their web app's accessibility. While last time I had the opportunity to talk to Michael Berger from Basecamp, this month accessibility and diversity advocate, author, speaker, and former Google Developer Expert Kitty Giraudel was so kind to answer my questions.
The European legislation is still on its way and it probably will take a while for it to take effect: but have you been able to argue internally at N26 that in the near-ish future bank interfaces could be obliged to be accessible under the European Accessibility Act and that making an investment in inclusive design is a matter of time?
Fortunately, I didn’t really have to pick up this battle because I have been fighting for more accessible interfaces since my first day at N26, over 2 years ago. In that time, we rebuilt our entire web platform with accessibility in mind, and as far as I know the native applications also have made tremendous progress in that regard. We can always do better, but I think we don’t have to take the legal obligation approach to make this happen, and that’s a pretty big win to me.
Since I am currently working on SPA and accessible routing: In the N26 app you can see that after route transition the focus is not changed but an aria live region, announcing the section name, is used. What prompted you or your team to choose this variant?
Limiting the amount of page-refreshes was quite a goal for us when rebuilding the web application: we want things to feel fast and snappy, and going through an entire page load every time is not really helping it. However we are also aware that screen-readers need that page load to announce a certain amount of information, without which their user might feel lost.To solve this problem, when following a React router link, we announce the new title thanks to a live region, blur the current active element to effectively reset the focus (although I’ve recently learnt we need to improve on that) and scroll the page back up to the top. This might not be the best solution, but it’s the one we managed to implement and that does the job decently so far.
When building the N26 app, have you used any recommendable and accessible third party React components or other ready-made solutions (apart from a11y-dialog, which is your project in the first place)?
Except for a11y-dialog (and react-a11y-dialog), because they are, you know, amazing and you gotta eat your own dog food. ;)
From what sources stems your knowledge about web accessibility in general and of Single Page Applications in particular?
I started getting interested in web accessibility a couple of years back. Since then, Twitter has been my main source of information regarding anything related to the web industry, including accessibility. We have the luck of having world-wide experts who share their knowledge for free and are always happy to help and answer questions. That’s pretty incredible when you think about it.
When it comes to single page applications, it is the first time for me that I get to work on one, so I really had to learn on the job and do my own research to make things good (enough).
Have you consulted external experts during creation of the app, and/or do you still to during the app's further development?
Funny you should mention that because we recently had Aurélien Levy from Temesis coming to our office to give a full-day workshop to our team and help us improve the accessibility of our web application. It was great to have the insights of an actual web accessibility expert and get to issue so many small fixes over the next few days. Other than that, we are not afraid to ask for industry leaders’ help on Twitter every now and then when not sure how to approach a problem.
Within the N26 app, what UI element was the biggest challenge to making accessible?
Well, the chat was definitely a challenge and it’s still not perfect. Our “PINputs” (numeric inputs split in 1-digit fields, used for PINs) with their automatic focus jump, password-style and numeric-only inputs were definitely tricky as well, and not just because of accessibility concerns.Another common problem we have is forms split across several steps but with a unique API call at the end. When receiving errors from our backend API, we have technically no idea which field caused an error, so we don’t know which field to mark as invalid, or to which step the focus should go back. It’s tricky and unfortunately we didn’t find a good fix for this, outside of defining a good design for future APIs.
As a published author of books on web development ("CSS 3 Pratique du Design Web", "Jump Start Sass") - have you ever felt the urge to write a new book, maybe on inclusive web app design, and common and unusual accessibility problems you are faced with in your every day's work?