Creating a banking web app with accessibility in mind - Interview with Kitty Giraudel of N26

Caution! This article was published over a year ago, and hasn't been updated since. Situation, software and support of the topic below could have changed in the meantime.

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.

Even if you aren't familiar with Kitty - I bet that you stumbled over at least once piece of their Open Source work, spanning from Sass related boilerplates and guidelines, JavaScript tools to accessibility related scripts like a11y-dialog, toggle and menu button scripts.

Currently, they are working as front-end developer for German direct bank N26 and has been a driving force behind the accessibility of its web app. Since I am always eager to learn from hands-on examples and best practices regarding inclusivity in modern JavaScript environments I was very glad and grateful when they agreed to answer my questions regarding their work.

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)?

We support the complete absence of JavaScript for most features to work around connectivity, parsing or execution issues, so it de facto brings us quite far in the accessibility landscape, just by using plain good solid HTML and CSS, with simple and straightforward design.Now for more complex interface modules, it has been quite uncommon that we had to look for third-party solutions as we either had enough knowledge to make it work internally, or we (I) asked on Twitter for some materials on how to do things well. We did install the occasional React component to do something tricky, but most of the time we ended up replacing it with a custom solution to be less limited.

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?

Not really… To start with, writing a book is a lot of work. It’s dramatically harder than writing an article, or even a series of dozens of articles on the same topic. Now I’m not saying I won’t write a third book, because I still love writing very much and we never know.When it comes to accessibility now, I have some solid theoretical knowledge, which probably helped N26 getting where it is now, but I’m far from being an expert. I have a lot of fundamental knowledge gaps, starting with how screen-readers and other assistive technology work. This would be quite an impediment if I were to write a book on the matter, or would require me to do so much knowledge on the topic that it would take too much time. Also and more importantly, some people would be way better suited to write such publication.That being said, and again, I do love writing and I still very much enjoy writing articles about discoveries or things I find interesting related to my work in accessibility and inclusive design. This is how I got to write how we at N26 recover from JavaScript errorsbuilt the discreet mode or enabled users to disable animations across the board. I’m looking forward to write some more.