Baking in #a11y from the start - Interview with Michael Scharnagl of Feediary

In what is now the third part of an interview series (that never was intended to become one) I had the opportunity to ask Michael Scharnagl about his product, Feediary, and how he built it with progressive enhancement, robustness, accessibility and privacy in mind.

You may now Michael from his blog, justmarkup, and same-named twitter account, and if you are based in Berlin, maybe from our Accessibility Meetup. Just last year, Michael launched Feediary, a RSS (and more) reader that cares about your privacy, and a quality experience when consuming your feeds. Michael's approach is in generall to supply both an ethical and inclusive product. Recently I was able to ask him seven questions, focusing on accessibility and the technical implementation of Feediary (funnily enough the concept of "seven questions about building web apps" has become a tradition now, I guess):

What is the tech stack behind feediary?

We are currently using Node.js and Express on the back-end and Vue.js on the front-end. I often thought about using other technologies when starting the project, but in the end decided to use what I am most comfortably with.

If you had to guess how large the share of solving challenges regarding accessibility was during development - what would you say?

Much less than I estimated. Starting with accessibility in mind and using progressive enhancement for all core features helped a lot here. Every feature/component started with HTML and from there on we enhanced it step-by-step and made sure that no enhancement made something inaccessible.

Have you written all inclusive interface components yourself or used existing ones? If so, which ones?

Most components were written by myself based on similar components from the community, eg. Inclusive Components. As we are using various dialogues and overlays for items and interactions we also used A11y Dialog which saved us a lot of research and development time as building accessible dialogues is really hard and often done wrong. We also found that many components on Github mention that they are 100% accessible, but after some testing many were not at all accessible. So, make sure to always test it before betting on something and investing to much time with it.

What component was the most difficult to implement in relation to a11y, what was the biggest challenge?

The reader view was one of the biggest challenge and we made various things wrong there at the beginning to be honest. For example, we used aria-live on too many elements, making this annoying from screen reader users. Thanks to feedback from Marco Zehe we were able to fix this and now use aria-live only on the element saying "X new items".

Which technical paragons (in terms of accessibility, progressive enhancement, offline capability) does feediary have, if any?

Sadly, there are very few popular and accessible apps out there where you could learn from. As I always use progressive enhancement and try to make it all as accessible as possible it was clear for me that I will do the same when building feediary.

From what sources stems your knowledge about web accessibility in general and about inclusive widgets, JavaScript-heavy apps in particular?

I follow a lot of RSS feeds from awesome people I found over the last couple of years. Apart from that I use Twitter as my source of information. I can recommend this list if you are also on twitter.

A conceptual question: Do you consider your accessible product an advantage over your "competitors", similar projects?

Hard to say, as we don't know why somebody is using feediary. From user feedback we got, I can say that some are really happy that feediary is accessible and that there is now an usable RSS reader available. For me, it would be great if an accessible product would be no advantage, simple because all products would be accessible.

Enjoyed reading this mini interview? Here are the past two: